Pylons 0.9.6.1 + Apache 2.2.6 via mod_wsgi: segmentation fault!
bsdemon
Apache 2.2.6 and mos_wsgi compiled by me. Configuration by:
http://code.google.com/p/modwsgi/wiki/IntegrationWithPylons
But after I direct my browser to my wsgi pylons app it's only put in
log following:
"[Sun Oct 21 23:15:50 2007] [notice] child pid 2392 exit signal
Segmentation fault (11)"
Graham Dumpleton
Have you read:
http://code.google.com/p/modwsgi/wiki/ApplicationIssues
http://code.google.com/p/modwsgi/wiki/InstallationIssues
If not, then do so.
If that doesn't help, then post further information about what third
party modules your Pylons application is loading, plus how you have
configured Apache to use mod_wsgi to run your application.
Graham
bsdemon
> Have you read:
>
> http://code.google.com/p/modwsgi/wiki/ApplicationIssues
> http://code.google.com/p/modwsgi/wiki/InstallationIssues
yes
>
> If that doesn't help, then post further information about what third
> party modules your Pylons application is loading, plus how you have
> configured Apache to use mod_wsgi to run your application.
there is no 3rd party modules only pylons and my simple helloworld
controller that returns "Hello".
in httpd.conf:
WSGIScriptAlias /pymax /home/bsdemon/opt/easymax/pymax/apache/pymax.py
<Directory /home/bsdemon/opt/easymax/pymax/apache>
Order deny,allow
Allow from all
</Directory>
with web.py it works well, but with pylons...
bsdemon
Graham Dumpleton
>
>
> > Have you read:
> >
> > http://code.google.com/p/modwsgi/wiki/ApplicationIssues
> > http://code.google.com/p/modwsgi/wiki/InstallationIssues
>
> yes
>
> >
> > If that doesn't help, then post further information about what third
> > party modules your Pylons application is loading, plus how you have
> > configured Apache to use mod_wsgi to run your application.
>
> there is no 3rd party modules only pylons and my simple helloworld
> controller that returns "Hello".
> in httpd.conf:
The problem is that Pylons tends to drag in lots of third party
modules. If you use the simple WSGI only hello world program from the
documentation.
def application(environ, start_response):
status = '200 OK'
output = 'Hello World!'
response_headers = [('Content-type', 'text/plain'),
('Content-Length', str(len(output)))]
start_response(status, response_headers)
return [output]
does it work? Ie., ensure that Pylons isn't being imported.
Also, are you importing mod_python into Apache at the same time? Did
you verify that mod_wsgi is using a shared Python library rather than
a static library as discussed in documentation?
If the simple WSGI hello world program works, go back to the Pylons
example but add to the Apache configuration:
WSGIApplicationGroup %{GLOBAL}
Does it then work? If it does, it indicates that one of the third
party modules dragged in by Pylons isn't safe to use in a secondary
Python sub interpreter.
Graham
bsdemon
> def application(environ, start_response):
> status = '200 OK'
> output = 'Hello World!'
>
> response_headers = [('Content-type', 'text/plain'),
> ('Content-Length', str(len(output)))]
> start_response(status, response_headers)
>
> return [output]
>
> does it work? Ie., ensure that Pylons isn't being imported.
yes, it works
> Also, are you importing mod_python into Apache at the same time? Did
> you verify that mod_wsgi is using a shared Python library rather than
> a static library as discussed in documentation?
No there is no mod_python, and mod_wsgi uses shared python library
> If the simple WSGI hello world program works, go back to the Pylons
> example but add to the Apache configuration:
>
> WSGIApplicationGroup %{GLOBAL}
>
> Does it then work?
No, it doesn't work, with segmentation fault.
Graham Dumpleton
import sys
print >> sys.stderr, "hello 1"
# your code
print >> sys.stderr, "hello 2"
When you try again, do both those debug lines appear in the Apache
error log. Ie., is the crash happening when the WSGI script file is
imported, or in the execution of the WSGI application?
In the directory where the WSGI script file is, run interactive
command line 'python'. Then do an 'import' of the WSGI script file as
a module. Thus, if called 'script.py', run:
import script
inside of Python again.
Then do:
import sys
print sys.modules.keys()
Post the list of imported modules so can see what Pylons is importing for you.
It has to be one of those imported by Pylons which is causing the
problem. The only other possibility is that you are trying to use a
workingenv/virtualenv setup and the Python extension modules pointed
at don't match the version of Python being used.
Graham
On 23/10/2007, bsdemon <8ma...@gmail.com> wrote:
>
>
bsdemon
>
> import sys
> print >> sys.stderr, "hello 1"
>
> # your code
>
> print >> sys.stderr, "hello 2"
>
> When you try again, do both those debug lines appear in the Apache
> error log. Ie., is the crash happening when the WSGI script file is
> imported, or in the execution of the WSGI application?
I see only message in log before paste.deploy.loadapp call
the list of imported modules:
['copy_reg', '__main__', 'site', '__builtin__', 'pymax', 'encodings',
'encodings.encodings', 'posixpath', 'encodings.codecs', 'os.path',
'_codecs', 'stat', 'zipimport', 'warnings', 'encodings.types',
'UserDict', 'encodings.utf_8', 'sys', 'codecs', 'readline', 'types',
'_types', 'signal', 'apport_python_hook', 'linecache', 'posix',
'encodings.aliases', 'exceptions', 'os']
Graham Dumpleton
Okay, this didn't translate to what I was expecting to see as no
Pylons stuff is showing here.
Can you post your WSGI script file as was expecting when you imported
it into command line Python that it would have triggered the loadapp
but it hasn't. Thus you mustn't be setting up WSGI script file as I
would expect for Pylons.
The point of doing this was to see what modules were being included so
I can see if there are any listed in there which are known to be
problematic as far as shared library version mismatching etc, as
explained in the application issues document on wiki I originally
pointed you at. Even if couldn't see a suspect, would then have
suggested that in standalone hello world program you add import
statements for all the modules that Pylons would indirectly import and
see if that crashes. Then whittle back the list to work out which one
crashes.
BTW, what operating system are you using and what version of Python?
Graham
bsdemon
http://code.google.com/p/modwsgi/wiki/IntegrationWithPylons):
import os, sys
sys.path.append('/home/bsdemon/opt/easymax/pymax')
os.environ['PYTHON_EGG_CACHE'] = '/home/bsdemon/opt/easymax/tmp'
from paste.deploy import loadapp
print >> sys.stderr, "Hello!"
application = loadapp('config:/home/bsdemon/opt/easymax/pymax/
development.ini')
it loads my pylons app, that was created with:
paster create -t pylons pymax
And so on, it's default pylons app, that i didn't modified yet, except
I add only one controller:
from pymax.lib.base import *
log = logging.getLogger(__name__)
class HelloController(BaseController):
def index(self):
# Return a rendered template
# return render('/some/template.mako')
# or, Return a response
return 'Hello World'
That's all.
I'm running Python 2.5.1 with Ubuntu 7.10
Graham Dumpleton
suggests it is a GUI for some other package. GUIs and a web server
aren't going to go to well.
If you eliminate the pymax module and make just a simple Pylons hello
world program, does it work?
Only two other suggestions at this point. First is to run your
application in a daemon process, Thus use:
WSGIDaemonProcess proc user=yourusername grou=yourusername
WSGIProcessGroup proc
WSGIScriptAlias /pymax /home/bsdemon/opt/easymax/pymax/apache/pymax.py
<Directory /home/bsdemon/opt/easymax/pymax/apache>
Order deny,allow
Allow from all
</Directory>
Substitute your actual user name to 'yourusername'.
If that doesn't work, also try:
WSGIDaemonProcess proc user=yourusername group=yourusername
WSGIProcessGroup proc
WSGIApplicationGroup %{GLOBAL}
WSGIScriptAlias /pymax /home/bsdemon/opt/easymax/pymax/apache/pymax.py
<Directory /home/bsdemon/opt/easymax/pymax/apache>
Order deny,allow
Allow from all
</Directory>
If still no joy, final suggestion is you try procedure described in
'Debugging Crashes With GDB' of:
http://code.google.com/p/modwsgi/wiki/DebuggingTechniques
Ie., try and work out where it is crashing by using GNU debugger.
Graham
bsdemon
paster create -t pylons pymax
krishna2
Hello, Thanks for all the helpful hints.
I had the same segfault error as well.
Linux RedHat, Python 2.4.3, Apache 1.3x, Mod_wsgi 1.2, Pylons 0.9.6.1
Apache, pylons, python works. I got the 'hello world' 4 line app
to work with mod_wsgi.
Then I tried the pylons and kept getting segfault. Followed all of
your suggestions from above and still didn't help.
Finally, went the gdb way and got this error.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1207990048 (LWP 8427)]
0x01037927 in PyString_FromString () from /home/y/libexec/mod_wsgi.so
(gdb) l
1 /home/jafo/rpm/BUILD/Python-2.4/Modules/pyexpat.c: No such
file or directory.
in /home/jafo/rpm/BUILD/Python-2.4/Modules/pyexpat.c
Let me know if I can provide any other info.
Thanks,
Krishna.
On Oct 26, 1:31 am, "Graham Dumpleton" <graham.dumple...@gmail.com>
wrote:
Graham Dumpleton
expat problem.
http://code.google.com/p/modwsgi/wiki/IssuesWithExpatLibrary
It is cross referenced from the document covering any application issues.
http://code.google.com/p/modwsgi/wiki/ApplicationIssues
The application issues document was pointed out to the OP. It is not
known whether they went through and eliminated the possible sources of
problems as described.
Graham
krishna2
Thanks for the quick reply.
Apologies for not looking thoroughly.
My python version seems to have version 1.95.8.
However when I do ldd on httpd, there is no libexpat.
However the problem still is due to expat (as I confirmed
that with the simple script which does a 'import pyexpat').
So what is the way to proceed now ? Add the same version
of expat to apache ?
Thanks,
Krishna.
On Nov 7, 2:29 pm, "Graham Dumpleton" <graham.dumple...@gmail.com>
wrote:
> There is a whole document in the mod_wsgi wiki dedicated to just this
> expat problem.
>
> http://code.google.com/p/modwsgi/wiki/IssuesWithExpatLibrary
>
> It is cross referenced from the document covering any application issues.
>
> http://code.google.com/p/modwsgi/wiki/ApplicationIssues
>
> The application issues document was pointed out to the OP. It is not
> known whether they went through and eliminated the possible sources of
> problems as described.
>
> Graham
>
Graham Dumpleton
it is is either linked in as a static library, or that it is using a
version of expat that comes with Apache and is compiled directly into
Apache.
What I think you will need to do in either case, is recompile and
reinstall Apache, but when you run 'configure' for Apache, ensure that
you supply the --with-expat option specifying the location of the
expat library to use.
I think the argument to --with-expat is the parent directory for where
expat is installed. So, if expat is installed in /usr/local/expat,
ie., under that are lib and include directories, that would be the
argument.
--with-expat=/usr/local/expat
Am not 100% sure on this though as the option is buried in apr-util
and not Apache itself.
How exactly was your Apache installed? Was it from an OS package, or
did you compile it yourself. Do you have expat library installed in
standard system directories, or somewhere else like under /usr/local?
Graham
On 08/11/2007, krishna2 <kris...@gmail.com> wrote:
>
>
krishna2
Thanks for the reply.
The local system does have an expat. Coincidentally (to the
wiki page listing this issue), I have versions 1.9.8 on python
and 1.9.7 on the system [so looks like this is not the issue].
However you are right - since I think the prebuilt apache I am
dealing with might be using the expat that is packaged along
with it or using a static one.
I will try getting a new apache and see how that works out.
Thanks a lot,
Krishna.
On Nov 7, 4:11 pm, "Graham Dumpleton" <graham.dumple...@gmail.com>
wrote:
> If Apache shows no dependence on an expat library, it indicates that
> it is is either linked in as a static library, or that it is using a
> version of expat that comes with Apache and is compiled directly into
> Apache.
>
> What I think you will need to do in either case, is recompile and
> reinstall Apache, but when you run 'configure' for Apache, ensure that
> you supply the --with-expat option specifying the location of the
> expat library to use.
>
> I think the argument to --with-expat is the parent directory for where
> expat is installed. So, if expat is installed in /usr/local/expat,
> ie., under that are lib and include directories, that would be the
> argument.
>
> --with-expat=/usr/local/expat
>
> Am not 100% sure on this though as the option is buried in apr-util
> and not Apache itself.
>
> How exactly was your Apache installed? Was it from an OS package, or
> did you compile it yourself. Do you have expat library installed in
> standard system directories, or somewhere else like under /usr/local?
>
> Graham
>
Graham Dumpleton
(Solaris), but it may matter on a different sort of system, such a
Linux. Thus, is preferable to ensure the same version is used.
You can validate whether expat is compiled into Apache by running:
nm httpd
or perhaps:
ldd httpd
work out where apr-util shared library is and run nm on int:
nm /usr/local/lib/libaprutil-0.so.0
Look for 'XML_ExpatVersion'. If it is marked as 'FUNC |GLOB' in either
of those it is embedded in the Apache executable rather than it being
dragged in from separate library.
By rights, if expat library is installed in proper OS system
locations, then when you build Apache it should automatically find it
without needing to use --with-expat.
As I asked before, where did you get Apache from? Is is standard OS
version or did you compile it yourself? Where is the libapr-util
library installed?
If you tell me where these bits have come from and/or installed, can
suggest what may be able to better suggest what to do.
Graham
On 08/11/2007, krishna2 <kris...@gmail.com> wrote:
>
>
krishna2
nm does not yield anything other than this one line :
08062d4c T suck_in_expat
Cannot find a libapr there.
The OS is RHEL. The apache is an internally cooked up one
(left over by someone else).
My approach is going to be that I will be installing a
newer version of apache. Hopefully that will resolve
the issues.
Thanks a lot again,
Krishna.
On Nov 7, 4:31 pm, "Graham Dumpleton" <graham.dumple...@gmail.com>
wrote:
> The patch level difference didn't matter on the system I was checking
> (Solaris), but it may matter on a different sort of system, such a
> Linux. Thus, is preferable to ensure the same version is used.
>
> You can validate whether expat is compiled into Apache by running:
>
> nm httpd
>
> or perhaps:
>
> ldd httpd
>
> work out where apr-util shared library is and run nm on int:
>
> nm /usr/local/lib/libaprutil-0.so.0
>
> Look for 'XML_ExpatVersion'. If it is marked as 'FUNC |GLOB' in either
> of those it is embedded in the Apache executable rather than it being
> dragged in from separate library.
>
> By rights, if expat library is installed in proper OS system
> locations, then when you build Apache it should automatically find it
> without needing to use --with-expat.
>
> As I asked before, where did you get Apache from? Is is standard OS
> version or did you compile it yourself? Where is the libapr-util
> library installed?
>
> If you tell me where these bits have come from and/or installed, can
> suggest what may be able to better suggest what to do.
>
> Graham
>