|
Graham Dumpleton
graham.dumpleton at gmail.com
Mon Mar 22 21:48:46 EDT 2010
On 23 March 2010 05:20, wayne collier <Wayne.Collier at noaa.gov> wrote: > Okay Graham. I ran the "thread apply all bt" that dicuss in the link and > got the following: That looks to be showing where the process got interrupted when you attached gdb from what I can tell as got nothing to do with your ldap code. If you are going to access running process. You need to configure Apache to only start a single child process. Once attached to the child process, go 'cont' in gdb and then trigger the request which causes it to crash. This will interrupt the gdb session again and then you can generate the stack trace using 'where' for current thread, or 'thread apply all bt' if need be to dump stack for all threads. Is this what you posted the stack trace from after doing the request and it crashing? Graham > (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. |