Segmentation fault on failed imports

[GoogleCodeExporter]

What steps will reproduce the problem?

 - Not exactly very sure how to get the problem triggered. Both embeded 
and deamon mode seem to segfault upon loading a faulty module from within 
a django middleware.

 1: Configure a django installation for use with mod_wsgi
 2: Load a page that will require the import of a faulty python module
 3: Segfault

What is the expected output? What do you see instead?

The error chain should be able to display the problem with loading the 
module, like any other python error. 

Instead the result is - Internal server errors, segfault for the processes 
in the apache log. 

What version of the product are you using? On what operating system?

Debian Etch Linux  - mod_wsgi versions 1.3 and 2.0

Please provide any additional information below.

The python libraries were messed up by a dist-upgrade from an old sarge 
installation. The correct error messages were collected by running the 
django development server, that displayed them correctly. Importing the 
moule from command line python was also impossible. 

This is the output for loading the page from the django dev-server:
Traceback (most recent call last):

  File "/usr/lib/python2.4/site-packages/django/core/servers/basehttp.py", 
line 277, in run
    self.result = application(self.environ, self.start_response)

  File "/usr/lib/python2.4/site-packages/django/core/servers/basehttp.py", 
line 631, in __call__
    return self.application(environ, start_response)

  File "/usr/lib/python2.4/site-packages/django/core/handlers/wsgi.py", 
line 195, in __call__
    self.load_middleware()

  File "/usr/lib/python2.4/site-packages/django/core/handlers/base.py", 
line 36, in load_middleware
    raise exceptions.ImproperlyConfigured, 'Error importing middleware %s: 
"%s"' % (mw_module, e)

ImproperlyConfigured: Error importing middleware 
knowledgebase.middleware.xslt: "/usr/lib/python2.4/site-packages/
lxml-1.3.3-py2.4-linux-i686.egg/lxml/etree.so: undefined symbol: 
gcry_check_version"

The last part of the error message is the output of:
"from lxml import etree" in the python command line. 

I'm not sure whether the django chain of loading middlewares has something 
to do with it, or mod_wsgi crashes when critical import errors are 
triggered at runtime. 

Original issue reported on code.google.com by theati...@gmail.com on 22 Apr 2008 at 2:19

[GoogleCodeExporter]

The C extension module component of the module you are trying to use hasn't 
been correctly linked against 
all libraries it has as dependencies.

In particular, gcry_check_version() comes from libgcrypt.

  http://www.fifi.org/doc/libgcrypt-doc/reference.html

Ideally the C extension module should be recompiled with the option '-lgcrypt' 
used at the point that the 
extension module is linked to produce a .so file.

If you cannot arrange this, the alternative is to force the the library into 
Apache itself when it starts up.

To do this you need to add:

  LD_PRELOAD=-lgcrypt
  export LD_PRELOAD

to the 'envvars' file in same directory as Apache httpd executable (if it 
exists), or if on a Linux distribution 
that has dispensed with the standard Apache 'envvars' file, modify the system 
init startup scripts for Apache, 
ie., '/etc/sysconfig/httpd'.

The prefered option out of these two is to rebuild the C extension module 
properly.

For similar issues, albeit with main Python library and not an extension 
module, see section 'Undefined Thread 
Functions on FreeBSD' and 'Undefined 'forkpty' On Fedora 7' of:

  http://code.google.com/p/modwsgi/wiki/InstallationIssues

Original comment by Graham.Dumpleton@gmail.com on 22 Apr 2008 at 9:44

[GoogleCodeExporter]

Whoops. LD_PRELOAD should be absolute path to .so file for libcrypt.so and not 
just -lgcrypt.

Original comment by Graham.Dumpleton@gmail.com on 22 Apr 2008 at 9:51

[GoogleCodeExporter]

The original problem - lxml not Importing properly was fixed after a good time 
of 
cleaning up the Debian upgrade mess, luckily without having to get in any 
detail 
outside of the scope of the debian package system. 

I still haven't tried reproducing the segfault issue with any other type of 
ImportError, but this specific linkage error does cause a segfault on all 
versions 
of mod_wsgi I tried to compile. 

Original comment by theati...@gmail.com on 22 Apr 2008 at 10:12

[GoogleCodeExporter]

If lxml isn't the problem per stack trace and your real problem is a core dump, 
you
need to work out the cause of the core dump. Usually this is because of use of
conflicting shared library versions. Various examples of this are covered in 
mod_wsgi
documentation for application issues.

Without knowing exactly which Python module is being imported when crash 
occurs, hard
to say which library may be conflicting. Because it is a conflicting library 
and thus
a hard crash at C code level, it is impossible for mod_wsgi to somehow catch it 
and
produce any sort of debug or stack trace indicating where the problem is.

All I can suggest as means to debug it, is to run Apache under gdb as described 
in
'Debugging Crashes With GDB' of:

  http://code.google.com/p/modwsgi/wiki/DebuggingTechniques

While debugging issue, you may want to take the discussion over to the mod_wsgi
discussion group rather than try and carry out a conversation under this issue.

Original comment by Graham.Dumpleton@gmail.com on 22 Apr 2008 at 11:45

[GoogleCodeExporter]

Nothing more heard about this so no action being taken. If there is still an 
issue, bring it up on the mod_wsgi 
discussion list.

Original comment by Graham.Dumpleton@gmail.com on 26 Apr 2008 at 4:27

• Changed state: WontFix
• Added labels: Type-Other
• Removed labels: Type-Defect