1
votes

Apache on a production server of mine is seg faulting intermittently. I have enabled core dump option in apache configuration and have several dumped core files. Unfortunately, since it is a production server, apache or the loaded modules are not compiled with debug symbols. From what I understand, gdb cannot do much without debug symbols.

Can I at least find out which module is causing the seg fault, without debug symbols? If so, how?

[Update] Following is the output from a gdb backtrace

(gdb) bt full
#0  0xb7f1f832 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
No symbol table info available.
#1  0xb7be82bc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
No symbol table info available.
#2  0xb771652a in ?? () from /usr/local/apache/modules/mod_pagespeed.so
No symbol table info available.
#3  0xb75df576 in ?? () from /usr/local/apache/modules/mod_pagespeed.so
No symbol table info available.
#4  0xb7715c20 in ?? () from /usr/local/apache/modules/mod_pagespeed.so
No symbol table info available.
#5  0xb7be4a49 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#6  0xb7b2a63e in clone () from /lib/libc.so.6
No symbol table info available.

Does this mean that /lib/ld-linux.so.2 is causing the seg fault?

1
From the trace provided I'd suspect mod_pagespeed.so being responsible for the segmentation violation. So try running Apache without having loaded the PageSpeed module.alk

1 Answers

1
votes

A quick search for _dl_sysinfo_int80 revealed the following thread ...

http://linux.derkeiler.com/Newsgroups/comp.os.linux.development.apps/2005-02/0462.html

To answer you question I doubt that /lib/ld-linux.so.2 is causing the segmentation fault. This is just one of many threads that is waiting.

Run thread apply all bt full to get stack traces of all the threads running at the time of the crash. It should be then be clear which thread is causing the SEGFAULT. This should provide you with more evidence of what is going on.