|
Graham Dumpleton
grahamd at dscpl.com.au
Wed Oct 19 00:16:48 EDT 2005
Philippe C. Martin wrote .. > Got it I think: you mean more than one library are on my disk ? Not quite. The version embedded in the pyexpat module of Python is what is effectively called statically linked. The libexpat.so in your lib directory would be dynamically loaded as a shared library at some point because of some dependency on that library by something else. Usually this is Apache itself and it will get loaded as soon as Apache is started. For those who understand what I am talking about, yes I know that the Python module is dynamically loaded into Python, but the expat part is statically linked into the Python module .so which is loaded. > If so, that's the only I found in the LIB path: /usr/lib/libexpat.so.0.5.0. > > So that would mean that apache and python use the same right ? No. When Python is run from the command line and pyexpat is imported, it uses the version statically linked into the Python module .so. When Apache starts up it will load the libexpat.so from lib. Now, when mod_python is run in the context of Apache, when the pyexpat module is imported, because Apache has already loaded libexpat.so from the lib directory, the version of expat statically linked into the Python module .so is actually ignored and it uses the version that Apache had already loaded. Going back to my machine here (different one this time), from command line: grahamd at fiona:public_html$ python Python 2.3.5 (#1, Aug 12 2005, 10:35:05) [GCC 3.3.2] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import pyexpat >>> pyexpat.version_info (1, 95, 7) If I run "ldd" on the Apache httpd program to see what version of libexpat it is using I get: grahamd at fiona:public_html$ ldd /usr/local/sys/apache/bin/httpd libaprutil-0.so.0 => /usr/local/lib/libaprutil-0.so.0 libexpat.so.0 => /usr/local/lib/libexpat.so.0 libapr-0.so.0 => /usr/local/lib/libapr-0.so.0 libsendfile.so.1 => /usr/lib/libsendfile.so.1 librt.so.1 => /usr/lib/librt.so.1 libm.so.1 => /usr/lib/libm.so.1 libsocket.so.1 => /usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libresolv.so.2 => /usr/lib/libresolv.so.2 libpthread.so.1 => /usr/lib/libpthread.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libthread.so.1 => /usr/lib/libthread.so.1 libc.so.1 => /usr/lib/libc.so.1 libaio.so.1 => /usr/lib/libaio.so.1 libmd5.so.1 => /usr/lib/libmd5.so.1 libmp.so.2 => /usr/lib/libmp.so.2 /usr/platform/SUNW,UltraAX-i2/lib/libc_psr.so.1 /usr/platform/SUNW,UltraAX-i2/lib/libmd5_psr.so.1 The version number on the library itself is useless, so run "strings" command to get the version number out of the library itself. grahamd at fiona:public_html$ strings /usr/local/lib/libexpat.so.0 | grep expat_ expat_1.95.2 Thus Apache is actually using 1.95.2 whereas the Python module .so for pyexpat has 1.95.7 embedded into it. Now if I create a mod_python.publisher function: import pyexpat def index(): return pyexpat.version_info and access that page, I get returned: 1952 I don't quite understand why it is returning an integer rather than a tuple, it may actually indicate a problem. As one can see though, it is now actually using 1.95.2 which Apache loaded and not that embedded in the pyexpat Python module .so. The important bit in the above which you didn't do was to run "strings" on libexpat.so file. Hopefully this will find that string I was picking up which indicated which version was used. BTW, you may be able to confirm whether the expat version is the problem by simply creating a handler which all it does is import "pyexpat" as above. If that crashes Apache you probably have a problem as I recollect that just loading pyexpat will cause the crash, you don't actually have to use it. This though may only be the case on certain platforms. Another module you can try importing is "xmlrpclib". This one from memory definitely crashed Apache for me when I personally had this expat library version problem on a Linux platform, even without trying to use the functionality of the module. Hope I made it clear this time. Graham > On Wednesday 19 October 2005 01:33 am, Graham Dumpleton wrote: > > Philippe C. Martin wrote .. > > > > > Hi, > > > > > > I'm not sure that's enough info: > > > > > > Just for my knowledge, why would that have an effect in apache and > not > > > the > > > command line ? > > > > Imagine if each version of expat used a slightly different structure > > layout or structure size for something. An object created in the code > of > > the shared library when accessed by C code compiled against the library, > > but that of a different version, could access the wrong bit of the > > object and thus follow a bogus pointer and thus crash. > > > > Consider this platform I have access to: > > > > cinderella$ python > > Python 2.3.4 (#1, Nov 25 2004, 17:05:37) > > [GCC 3.3.2] on sunos5 > > Type "help", "copyright", "credits" or "license" for more information. > > > > >>> import pyexpat > > >>> pyexpat.version_info > > > > (1, 95, 7) > > > > >>> ^D > > > > cinderella$ cd /usr/local/lib > > cinderella$ strings libexpat.so | grep expat_ > > expat_1.95.4 > > > > The libexpat.so installed on the system has an older version than that > > compiled into Python. If something causes the libexpat.so to be linked > > into Apache at the same time as the Python code executing from > > mod_python is using the embedded one, if there is an incompatability, > > there may be a problem. > > > > In this case, I should be looking at upgrading the one installed in the > > operating system. > > > > Depending on your system the libexpat.so might be in /lib, /usr/lib, > > /usr/local/lib or elsewhere. > > > > Graham > > > > > [philippe at pcmsc philippe]$ python > > > Python 2.4.2 (#1, Oct 18 2005, 04:32:14) > > > [GCC 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk)] on linux2 > > > Type "help", "copyright", "credits" or "license" for more information. > > > > > > >>> import pyexpat > > > >>> pyexpat.version_info > > > > > > (1, 95, 8) > > > > > > >>> import expat > > > > > > Traceback (most recent call last): > > > File "<stdin>", line 1, in ? > > > ImportError: No module named expat > > > > > > > > > > > > [philippe at pcmsc SC]$ find /usr/lib/python2.4/ -name '*expat*' -exec > ls > > > -l {} > > > \; > > > -rw-r--r-- 1 root root 2586 Oct 18 > > > 04:35 /usr/lib/python2.4/test/output/test_pyexpat > > > -rw-r--r-- 1 root root 12012 Oct 18 > > > 04:35 /usr/lib/python2.4/test/test_pyexpat.py > > > -rw-r--r-- 1 root root 11514 Oct 18 > > > 04:36 /usr/lib/python2.4/test/test_pyexpat.pyc > > > -rw-r--r-- 1 root root 11514 Oct 18 > > > 04:36 /usr/lib/python2.4/test/test_pyexpat.pyo > > > -rw-r--r-- 1 root root 36379 Oct 18 > > > 04:35 /usr/lib/python2.4/xml/dom/expatbuilder.py > > > -rw-r--r-- 1 root root 31084 Oct 18 > > > 04:36 /usr/lib/python2.4/xml/dom/expatbuilder.pyc > > > -rw-r--r-- 1 root root 30453 Oct 18 > > > 04:36 /usr/lib/python2.4/xml/dom/expatbuilder.pyo > > > -rw-r--r-- 1 root root 112 Oct 18 > > > 04:35 /usr/lib/python2.4/xml/parsers/expat.py > > > -rw-r--r-- 1 root root 273 Oct 18 > > > 04:36 /usr/lib/python2.4/xml/parsers/expat.pyc > > > -rw-r--r-- 1 root root 273 Oct 18 > > > 04:36 /usr/lib/python2.4/xml/parsers/expat.pyo > > > -rw-r--r-- 1 root root 14408 Oct 18 > > > 04:35 /usr/lib/python2.4/xml/sax/expatreader.py > > > -rw-r--r-- 1 root root 13471 Oct 18 > > > 04:36 /usr/lib/python2.4/xml/sax/expatreader.pyc > > > -rw-r--r-- 1 root root 13471 Oct 18 > > > 04:36 /usr/lib/python2.4/xml/sax/expatreader.pyo > > > -rwxr-xr-x 1 root root 436290 Oct 18 > > > 04:33 /usr/lib/python2.4/lib-dynload/pyexpat.so > > > > > > On Wednesday 19 October 2005 12:35 am, Graham Dumpleton wrote: > > > > Philippe C. Martin wrote .. > > > > > > > > > Hi, > > > > > > > > > > If any of you wish to look at this: this code works in command > line, > > > > > > and > > > > > > > > crashes with apache. Something I'm doing is really anoying minidom. > > > > > > > > > > > > > > > you can fetch the xml file responsible at: > > > > > www.snakecard.com/mod_python > > > > > > > > > > Any help is greatly appreciated. > > > > > > > > I you are using a module which does XML processing and it is literally > > > > crashing, look at what version of the expat libraries that are > > > > installed on your system. > > > > > > > > A problem that can occur is that Python embeds a version of expat > > > > within its pyexpat module. If an incompatible version of expat is > also > > > > linked in as a shared library, a crash generally occurs. > > > > > > > > To determine the version of expat embedded in Python, do from a command > > > > > > > > line run Python: > > > > >>> import pyexpat > > > > >>> pyexpat.version_info > > > > > > > > (1, 95, 6) > > > > > > > > Ensure that the version of any expat shared library is at least newer > > > > than that embedded into Python, or the same version if possible. > > > > > > > > Graham > > > > > > -- > > > ************************************* > > > Philippe C. Martin > > > SnakeCard, LLC > > > www.snakecard.com > > > +1 405 694 8098 > > > ************************************* > > -- > ************************************* > Philippe C. Martin > SnakeCard, LLC > www.snakecard.com > +1 405 694 8098 > *************************************
|