Re: Re: Upgrading expat for apache question
wayne collier <[email protected]> Thu, 18 Mar 2010 16:48:39 -0400
| Newsgroups | gmane.comp.python.mod_python |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============1237167319==
Content-type: multipart/alternative;
boundary="Boundary_(ID_woBPSIo6zkaVcCEyB+JNgg)"
This is a multi-part message in MIME format.
--Boundary_(ID_woBPSIo6zkaVcCEyB+JNgg)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
Graham -my understanding of RH apache is modules have to explicitly
loaded in httpd.con file. I check all the snippet files and no
php shared object file is being loaded. I noticed before that did not
seem to have any mod_authz_ldap shared object loaded in my configuration
file. Do I need to set things up like i am doing authorization and
authentication thru apache? Is possible that needs to be included?
Also, I went thru some of the troubleshooting steps. I ran my web code
to reproduce the seg fault and then gbc to attach the process id. I got
the following before getting really lost here. Any suggestions here
would greatly appreciated. Thanks.
Wayne
*GBD WORK .....*
Detaching from program: /usr/local/httpd-2.2.11/bin/httpd, process 18421
[root@mingus psp]# gdb /usr/local/httpd-2.2.11/bin/httpd 18421
GNU gdb Fedora (6.8-37.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...
Attaching to program: /usr/local/httpd-2.2.11/bin/httpd, process 18421
warning: .dynamic section for "/usr/lib/libgssapi_krb5.so.2" is not at
the expected address
warning: difference appears to be caused by prelink, adjusting expectations
warning: .dynamic section for "/usr/lib/libkrb5.so.3" is not at the
expected address
warning: difference appears to be caused by prelink, adjusting expectations
warning: .dynamic section for "/lib/libcom_err.so.2" is not at the
expected address
warning: difference appears to be caused by prelink, adjusting expectations
warning: .dynamic section for "/usr/lib/libk5crypto.so.3" is not at the
expected address
warning: difference appears to be caused by prelink, adjusting expectations
warning: .dynamic section for "/lib/libresolv.so.2" is not at the
expected address
warning: difference appears to be caused by prelink, adjusting expectations
warning: .dynamic section for "/usr/lib/libkrb5support.so.0" is not at
the expected address
warning: difference appears to be caused by prelink, adjusting expectations
warning: .dynamic section for "/lib/libkeyutils.so.1" is not at the
expected address
warning: difference appears to be caused by prelink, adjusting expectations
warning: .dynamic section for "/lib/libselinux.so.1" is not at the
expected address
warning: difference appears to be caused by prelink, adjusting expectations
warning: .dynamic section for "/lib/libsepol.so.1" is not at the
expected address
warning: difference appears to be caused by prelink, adjusting expectations
warning: .dynamic section for "/usr/lib/liblber-2.3.so.0" is not at the
expected address
warning: difference appears to be caused by prelink, adjusting expectations
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /usr/local/httpd-2.2.11/lib/libaprutil-1.so.0...done.
Loaded symbols for /usr/local/httpd-2.2.11/lib/libaprutil-1.so.0
Reading symbols from /lib/libexpat.so.0...done.
Loaded symbols for /lib/libexpat.so.0
Reading symbols from /usr/local/httpd-2.2.11/lib/libapr-1.so.0...done.
Loaded symbols for /usr/local/httpd-2.2.11/lib/libapr-1.so.0
Reading symbols from /lib/libuuid.so.1...done.
Loaded symbols for /lib/libuuid.so.1
Reading symbols from /lib/librt.so.1...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libpthread.so.0...done.
[Thread debugging using libthread_db enabled]
[New Thread 0x135700 (LWP 18421)]
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
(gdb) print PyRun_SimpleString("import traceback; traceback.print_stact()")
Program received signal SIGSEGV, Segmentation fault.
PyImport_AddModule (name=0x5596b3 "__main__") at Python/import.c:366
366 PyInterpreterState *interp = PyThreadState_GET()->interp;
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function
(PyRun_SimpleString) will be abandoned.
(gdb)
Graham Dumpleton wrote:
> On 13 March 2010 11:28, wayne collier <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
>> [email protected]
>> http://mailman.modpython.org/mailman/listinfo/mod_python
>>
>>
>>
>>
>>
>> _______________________________________________
>> Mod_python mailing list
>> [email protected]
>> http://mailman.modpython.org/mailman/listinfo/mod_python
>>
>>
>>
>>
>
> _______________________________________________
> Mod_python mailing list
> [email protected]
> http://mailman.modpython.org/mailman/listinfo/mod_python
>
>
--Boundary_(ID_woBPSIo6zkaVcCEyB+JNgg)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Graham -my understanding of RH apache is modules have to explicitly
loaded in httpd.con file. I check all the snippet files and no
php shared object file is being loaded. I noticed before that did not
seem to have any mod_authz_ldap shared object loaded in my
configuration file. Do I need to set things up like i am doing
authorization and authentication thru apache? Is possible that needs
to be included?<br>
<br>
Also, I went thru some of the troubleshooting steps. I ran my web code
to reproduce the seg fault and then gbc to attach the process id. I
got the following before getting really lost here. Any suggestions here
would greatly appreciated. Thanks.<br>
<br>
Wayne <br>
<br>
<b>GBD WORK .....</b><br>
<br>
Detaching from program: /usr/local/httpd-2.2.11/bin/httpd, process 18421<br>
[root@mingus psp]# gdb /usr/local/httpd-2.2.11/bin/httpd 18421<br>
GNU gdb Fedora (6.8-37.el5)<br>
Copyright (C) 2008 Free Software Foundation, Inc.<br>
License GPLv3+: GNU GPL version 3 or later
<a class="moz-txt-link-rfc2396E" href="http://gnu.org/licenses/gpl.html"><http://gnu.org/licenses/gpl.html></a><br>
This is free software: you are free to change and redistribute it.<br>
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"<br>
and "show warranty" for details.<br>
This GDB was configured as "i386-redhat-linux-gnu"...<br>
Attaching to program: /usr/local/httpd-2.2.11/bin/httpd, process 18421<br>
<br>
warning: .dynamic section for "/usr/lib/libgssapi_krb5.so.2" is not at
the expected address<br>
<br>
warning: difference appears to be caused by prelink, adjusting
expectations<br>
<br>
warning: .dynamic section for "/usr/lib/libkrb5.so.3" is not at the
expected address<br>
<br>
warning: difference appears to be caused by prelink, adjusting
expectations<br>
<br>
warning: .dynamic section for "/lib/libcom_err.so.2" is not at the
expected address<br>
<br>
warning: difference appears to be caused by prelink, adjusting
expectations<br>
<br>
warning: .dynamic section for "/usr/lib/libk5crypto.so.3" is not at the
expected address<br>
<br>
warning: difference appears to be caused by prelink, adjusting
expectations<br>
<br>
warning: .dynamic section for "/lib/libresolv.so.2" is not at the
expected address<br>
<br>
warning: difference appears to be caused by prelink, adjusting
expectations<br>
<br>
warning: .dynamic section for "/usr/lib/libkrb5support.so.0" is not at
the expected address<br>
<br>
warning: difference appears to be caused by prelink, adjusting
expectations<br>
<br>
warning: .dynamic section for "/lib/libkeyutils.so.1" is not at the
expected address<br>
<br>
warning: difference appears to be caused by prelink, adjusting
expectations<br>
<br>
warning: .dynamic section for "/lib/libselinux.so.1" is not at the
expected address<br>
<br>
warning: difference appears to be caused by prelink, adjusting
expectations<br>
<br>
warning: .dynamic section for "/lib/libsepol.so.1" is not at the
expected address<br>
<br>
warning: difference appears to be caused by prelink, adjusting
expectations<br>
<br>
warning: .dynamic section for "/usr/lib/liblber-2.3.so.0" is not at the
expected address<br>
<br>
warning: difference appears to be caused by prelink, adjusting
expectations<br>
Reading symbols from /lib/libm.so.6...done.<br>
Loaded symbols for /lib/libm.so.6<br>
Reading symbols from
/usr/local/httpd-2.2.11/lib/libaprutil-1.so.0...done.<br>
Loaded symbols for /usr/local/httpd-2.2.11/lib/libaprutil-1.so.0<br>
Reading symbols from /lib/libexpat.so.0...done.<br>
Loaded symbols for /lib/libexpat.so.0<br>
Reading symbols from /usr/local/httpd-2.2.11/lib/libapr-1.so.0...done.<br>
Loaded symbols for /usr/local/httpd-2.2.11/lib/libapr-1.so.0<br>
Reading symbols from /lib/libuuid.so.1...done.<br>
Loaded symbols for /lib/libuuid.so.1<br>
Reading symbols from /lib/librt.so.1...done.<br>
Loaded symbols for /lib/librt.so.1<br>
Reading symbols from /lib/libcrypt.so.1...done.<br>
Loaded symbols for /lib/libcrypt.so.1<br>
Reading symbols from /lib/libpthread.so.0...done.<br>
[Thread debugging using libthread_db enabled]<br>
[New Thread 0x135700 (LWP 18421)]<br>
Loaded symbols for /lib/libpthread.so.0<br>
Reading symbols from /lib/libdl.so.2...done.<br>
Loaded symbols for /lib/libdl.so.2<br>
Reading symbols from /lib/libc.so.6...done.<br>
Loaded symbols for /lib/libc.so.6<br>
Reading symbols from /lib/ld-linux.so.2...done.<br>
Loaded symbols for /lib/ld-linux.so.2<br>
Reading symbols from /lib/libnss_files.so.2...done.<br>
Loaded symbols for /lib/libnss_files.so.2<br>
<br>
<br>
(gdb) print PyRun_SimpleString("import traceback;
traceback.print_stact()")<br>
<br>
Program received signal SIGSEGV, Segmentation fault.<br>
PyImport_AddModule (name=0x5596b3 "__main__") at Python/import.c:366<br>
366 PyInterpreterState *interp =
PyThreadState_GET()->interp;<br>
The program being debugged was signaled while in a function called from
GDB.<br>
GDB remains in the frame where the signal was received.<br>
To change this behavior use "set unwindonsignal on"<br>
Evaluation of the expression containing the function
(PyRun_SimpleString) will be abandoned.<br>
(gdb) <br>
<br>
<br>
<br>
<br>
<br>
<br>
Graham Dumpleton wrote:
<blockquote
cite="mid:88e286471003121909ve3ab1c4gda060385c57d21c4-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org"
type="cite">
<pre wrap="">On 13 March 2010 11:28, wayne collier <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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:
<a class="moz-txt-link-freetext" href="http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Debugging_Crashes_With_GDB">http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Debugging_Crashes_With_GDB</a>
This is for mod_wsgi, but same can be done for mod_python.
Graham
</pre>
<blockquote type="cite">
<pre wrap="">Also I ran ldd
and got the following results:
</pre>
<blockquote type="cite">
<pre wrap="">ldd /usr/local/httpd-2.2.11/bin/httpd
</pre>
</blockquote>
<pre wrap=""> 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)
</pre>
<blockquote type="cite">
<pre wrap="">ldd /usr/local/httpd-2.2.11/modules/mod_python.so
</pre>
</blockquote>
<pre wrap=""> 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 <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a> 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:
<a class="moz-txt-link-freetext" href="http://code.google.com/p/modwsgi/wiki/IssuesWithExpatLibrary">http://code.google.com/p/modwsgi/wiki/IssuesWithExpatLibrary</a>
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 <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a> 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
<a class="moz-txt-link-freetext" href="http://www.dscpl.com.au/wiki/ModPython/Articles/ExpatCausingApacheCrash">http://www.dscpl.com.au/wiki/ModPython/Articles/ExpatCausingApacheCrash</a> 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
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
<a class="moz-txt-link-freetext" href="http://mailman.modpython.org/mailman/listinfo/mod_python">http://mailman.modpython.org/mailman/listinfo/mod_python</a>
_______________________________________________
Mod_python mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
<a class="moz-txt-link-freetext" href="http://mailman.modpython.org/mailman/listinfo/mod_python">http://mailman.modpython.org/mailman/listinfo/mod_python</a>
</pre>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
Mod_python mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
<a class="moz-txt-link-freetext" href="http://mailman.modpython.org/mailman/listinfo/mod_python">http://mailman.modpython.org/mailman/listinfo/mod_python</a>
</pre>
</blockquote>
<br>
</body>
</html>
--Boundary_(ID_woBPSIo6zkaVcCEyB+JNgg)--
--===============1237167319==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Mod_python mailing list
[email protected]
http://mailman.modpython.org/mailman/listinfo/mod_python
--===============1237167319==--