[mod_python] Re: Upgrading expat for apache question

Graham Dumpleton graham.dumpleton at gmail.com
Fri Mar 12 22:09:24 EST 2010


On 13 March 2010 11:28, wayne collier <Wayne.Collier at noaa.gov> wrote:
> Okay I am running RH linux and I don't seem to have mod_ldap or
> mod_authnz_ldap shared objects loaded in my httpd.conf file.

They may not be loaded from httpd.conf but from a configuration file
snippet loaded into Apache. I don't know RH Apache configuration
layout, but check all snippet files in subdirectories to the
httpd.conf directory.

The conflict may also be because you are loading mod_php.

Ultimately you may have to use gdb to work out exactly where it
crashes. Hopefully not too much symbol information has been stripped
and gdb will be able to tell you from which library LDAP code that is
crashing is coming from.

Use first documented procedure for running Apache in single process
under gdb in:

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

This is for mod_wsgi, but same can be done for mod_python.

Graham

> Also I ran ldd
> and got the following results:
>
>
>> ldd /usr/local/httpd-2.2.11/bin/httpd
>     linux-gate.so.1 =>  (0x00157000)
>     libm.so.6 => /lib/libm.so.6 (0x00ce8000)
>     libaprutil-1.so.0 => /usr/local/httpd-2.2.11/lib/libaprutil-1.so.0
> (0x00315000)
>     libexpat.so.0 => /lib/libexpat.so.0 (0x00d70000)
>     libapr-1.so.0 => /usr/local/httpd-2.2.11/lib/libapr-1.so.0 (0x00844000)
>     libuuid.so.1 => /lib/libuuid.so.1 (0x002f2000)
>     librt.so.1 => /lib/librt.so.1 (0x00d65000)
>     libcrypt.so.1 => /lib/libcrypt.so.1 (0x07e07000)
>     libpthread.so.0 => /lib/libpthread.so.0 (0x00d17000)
>     libdl.so.2 => /lib/libdl.so.2 (0x00d11000)
>     libc.so.6 => /lib/libc.so.6 (0x00ba0000)
>     /lib/ld-linux.so.2 (0x00b82000)
>
>> ldd /usr/local/httpd-2.2.11/modules/mod_python.so
>     linux-gate.so.1 =>  (0x00aec000)
>     libpthread.so.0 => /lib/libpthread.so.0 (0x00730000)
>     libdl.so.2 => /lib/libdl.so.2 (0x0027f000)
>     libutil.so.1 => /lib/libutil.so.1 (0x00f70000)
>     libm.so.6 => /lib/libm.so.6 (0x009b1000)
>     libc.so.6 => /lib/libc.so.6 (0x00110000)
>     /lib/ld-linux.so.2 (0x00b82000)
>
> I don't seem to have anything with ldap listed. Am I on the right track.?
>
>
> Wayne
>
> Graham Dumpleton wrote:
>
> A segmentation fault can occur for other reasons. If it is happening
> when you use LDAP, it could be a conflict in versions of LDAP
> libraries being used by Apache or PHP and Python LDAP module.
>
> You should use the 'ldd' command to determine what LDAP shared library
> is used by mod_authnz_ldap and compare that to the LDAP library being
> used by the C extension module component of the Python module you are
> using to access LDAP. Similarly find any PHP extension modules which
> use LDAP and look at those.
>
> If mod_authnz_ldap is loaded into Apache and you don't need it, then
> don't load it and see if problem goes away. Also try not loading PHP
> if it is being loaded. Narrow down which is in conflict.
>
> As far as I remember, Apache itself doesn't link to LDAP library and
> even possible that mod_authnz_ldap uses an internal LDAP library
> rather than linking external library. All the same even use ldd on
> Apache binary itself to see which LDAP library may be linked.
>
> Graham
>
> On 10 March 2010 04:18, wayne collier <Wayne.Collier at noaa.gov> wrote:
>
>
> Okay I guess I will look else where. However, I keep getting segmentation
> faults when try an execute the ldap command
>
> t=l.simple_bind_s(dn,pw). It is only line of code that crashes. If the have
> the classic expat problem, would that mean I would get a segmentation
> fault problem from the start.  Also, ldap script works okay as a stand alone
> script. Thanks.
>
> Wayne
>
>
> Graham Dumpleton wrote:
>
> That is not your problem, quoting:
>
> http://code.google.com/p/modwsgi/wiki/IssuesWithExpatLibrary
>
> which is more up to date in respect of this issue, even if the
> mod_wsgi variant of that document:
>
> """Note that this only applies to Python versions prior to Python 2.5.
> >From Python 2.5 onwards, the copy of the "expat" library bundled in
> with Python is name space prefixed, thereby avoid name clashes with an
> "expat" library which has previously been loaded."""
>
> You are using Python 2.6, so you cannot be affected by this problem.
>
> Graham
>
> On 9 March 2010 05:54, wayne collier <Wayne.Collier at noaa.gov> wrote:
>
>
> Hello all. I need some help solving the dreaded segmentation fault that has
> cropped several time on this board. I have read the link
> http://www.dscpl.com.au/wiki/ModPython/Articles/ExpatCausingApacheCrash and
> followed the step and have uncovered the following.
>
>
>
>
> ldd    /usr/local/httpd-2.2.11/bin/httpd | grep expat
>
>
>     libexpat.so.0 => /lib/libexpat.so.0 (0x00d70000)
>
>
>
> strings /lib/libexpat.so.0  | grep expat_
>
>
> expat_1.95.8
>
>
>
>   ps aux | grep http | head -3
>
>
> webuser  14986  0.0  2.1  54236 19048 ?        S    Mar04   0:01
> /usr/local/httpd-2.2.11/bin/httpd -d /usr/local/httpd-2.2.11 -f
> /usr/local/httpd-2.2.11/conf/httpd.conf
> webuser  14987  0.0  3.2 144128 29540 ?        S    Mar04   0:01
> /usr/local/httpd-2.2.11/bin/httpd -d /usr/local/httpd-2.2.11 -f
> /usr/local/httpd-2.2.11/conf/httpd.conf
> webuser  14998  0.0  3.2 144212 29660 ?        S    Mar04   0:01
> /usr/local/httpd-2.2.11/bin/httpd -d /usr/local/httpd-2.2.11 -f
> /usr/local/httpd-2.2.11/conf/httpd.conf
>
>
>
>   /usr/sbin/lsof -p 14986 | grep expat
>
>
> httpd   14986 webuser  mem    REG     3,5   572313  972637
> /opt/Python/lib/python2.6/lib-dynload/pyexpat.so
> httpd   14986 webuser  mem    REG     3,5   133120 1883791
> /lib/libexpat.so.0.5.0
>
> I am not sure why I get 2 shared libaries here.
>
>
>
>   strings  /lib/libexpat.so.0.5.0 | grep expat_
>
>
> expat_1.95.8
>
>
>
>
> strings /opt/Python/lib/python2.6/lib-dynload/pyexpat.so | grep expat_
>
>
> pyexpat.expat_CAPI 1.0
> expat_CAPI
> expat_2.0.0
>
>
>
>
> import pyexpat
> pyexpat.version_info
>
>
> (2, 0, 0)
>
>
> So it seems like I need get expat_1.95.8 apache is using up to expat_2.0.0.
> Can I simply try replacing the 1.95.8 library with 2.0.0. Or do I have
> recompile with Apache? If I do recompile I need to recompile apache with
> mod_python as well?
>
>
>
>
>
>
> _______________________________________________
> Mod_python mailing list
> Mod_python at modpython.org
> http://mailman.modpython.org/mailman/listinfo/mod_python
>
>
>
>
>
> _______________________________________________
> Mod_python mailing list
> Mod_python at modpython.org
> http://mailman.modpython.org/mailman/listinfo/mod_python
>
>
>



More information about the Mod_python mailing list