|
Graham Dumpleton
graham.dumpleton at gmail.com
Sat Mar 20 07:06:38 EDT 2010
On 19 March 2010 07:48, wayne collier <Wayne.Collier at noaa.gov> wrote: > 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 at 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) I don't want a Python stack trace, I want a C stack trace as documented in that page I sent you to. Use: (gdb) thread apply all bt Graham > Graham Dumpleton wrote: > > 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 > > > > > > _______________________________________________ > Mod_python mailing list > Mod_python at modpython.org > http://mailman.modpython.org/mailman/listinfo/mod_python > > >
|