|
wayne collier
Wayne.Collier at noaa.gov
Mon Mar 22 14:20:58 EDT 2010
Okay Graham. I ran the "thread apply all bt" that dicuss in the link
and got the following:
(gdb) thread apply all bt
Thread 1 (Thread 0x135700 (LWP 28732)):
#0 0x001ef402 in __kernel_vsyscall ()
#1 0x00c735bb in semop () from /lib/libc.so.6
#2 0x0012420a in proc_mutex_sysv_acquire (mutex=0x134934)
at locks/unix/proc_mutex.c:226
#3 0x00123242 in apr_proc_mutex_lock (mutex=0x9123098)
at locks/unix/proc_mutex.c:878
---Type <return> to continue, or q <return> to quit---
#4 0x081ac7a0 in child_main (child_num_arg=<value optimized out>)
at prefork.c:205
#5 0x081acb77 in make_child (s=0x909d9a8, slot=12) at prefork.c:746
#6 0x081ad4d0 in ap_mpm_run (_pconf=0x90960a8, plog=0x90d41a0, s=0x909d9a8)
at prefork.c:881
#7 0x08088945 in main (argc=151601312, argv=0x91d5338) at main.c:740
(gdb)
*The line 740 and 741 of main.c is as follows:
*
740 if (ap_mpm_run(pconf, plog, server_conf))
741 break;
*Here are the lines from prefolk.c:*
881 make_child(ap_server_conf, free_slots[i]);
746 child_main(slot);
205 apr_status_t rv = apr_proc_mutex_lock(accept_mutex);
* Here are the lines from locks/unix/proc_mutex.c :*
876 APR_DECLARE(apr_status_t) apr_proc_mutex_lock(apr_proc_mutex_t *mutex)
877 {
*878 return mutex->meth->acquire(mutex); #<=====line 878*
879 }
static apr_status_t proc_mutex_sysv_acquire(apr_proc_mutex_t *mutex)
{
int rc;
do {
rc = semop(mutex->interproc->filedes, &proc_mutex_op_on,
1); *#<=====line 226*
} while (rc < 0 && errno == EINTR);
if (rc < 0) {
return errno;
}
mutex->curr_locked = 1;
return APR_SUCCESS;
}
Can you detect what might be an issue from?
Wayne
Graham Dumpleton wrote:
> 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
>>
>>
>>
>>
>
> _______________________________________________
> Mod_python mailing list
> Mod_python at modpython.org
> http://mailman.modpython.org/mailman/listinfo/mod_python
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20100322/55c34695/attachment-0001.html
|