Bug #1494: Apache segfaults consistently

From: athompso@commerced.com Operating system: RH6.0 PHP version: 3.0.8 PHP Bug Type: Reproduceable crash Bug description: Apache segfaults consistently Attempting to use the "Reload MySQL" feature of phpMyAdmin; httpd dies with a segfault every time. Also dies frequently elsewhere inside phpMyAdmin. Too scared to try any other code :-) (Re)Built MySQL, apache, mod_php3 from SRPMs, added "-g" for Apache and mod_php3; Here's what gdb (ever useful... *sigh*) tells me: [root@triton SPECS]# gdb /usr/sbin/httpd GNU gdb 4.17.0.11 with Linux support [...chop...] This GDB was configured as "i386-redhat-linux"...(no debugging symbols found)... (gdb) run -X Starting program: /usr/sbin/httpd -X Cannot access memory at address 0x696b735f. (gdb) The "cannot access memory" error comes *immediately* after I try to access http://triton.commerced.com/phpMyAdmin/main.php3?server=1&mode=reload and this is reproducible. I can't get httpd to leave a core file if my life depended on it. Doesn't matter what user I run as, doesn't matter where CoreFileDirectory is pointing to... any hints appreciated. Oooops. Re-ran this under gdb, but this time I remembered to use the "bt" command - I'm used to another debugger that does stack traces for me automatically :) (gdb) bt #0 _dl_debug_state () at dl-debug.c:56 #1 0x4000a12b in _dl_catch_error (errstring=0xbfffda30, operate=0x401797a0 <dl_open_worker>, args=0xbfffda34) at dl-error.c:141 #2 0x401799fd in _dl_open (file=0x80852e4 "/etc/httpd/modules/libperl.so", mode=258) at dl-open.c:176 #3 0x4009e058 in dlopen_doit (a=0xbfffdb3c) at dlopen.c:39 #4 0x4000a12b in _dl_catch_error (errstring=0x4009fd00, operate=0x4009e030 <dlopen_doit>, args=0xbfffdb3c) at dl-error.c:141 #5 0x4009e608 in _dlerror_run (operate=0x4009e030 <dlopen_doit>, args=0xbfffdb3c) at dlerror.c:122 #6 0x4009e01d in __dlopen_check (file=0x80852e4 "/etc/httpd/modules/libperl.so", mode=258) at dlopen.c:50 #7 0x806e411 in ap_os_dso_load () #8 0x804e6c8 in ap_get_server_built () #9 0x8053e0e in ap_clear_module_list () #10 0x80546b3 in ap_handle_command () #11 0x8054744 in ap_srm_command_loop () #12 0x8054b50 in ap_process_resource_config () #13 0x8055412 in ap_read_config () #14 0x805e9c1 in ap_child_terminate () #15 0x805f203 in main () #16 0x400b8cb3 in __libc_start_main (main=0x805eedc <main>, argc=2, argv=0xbffffd84, init=0x804dbfc <_init>, fini=0x8071f1c <_fini>, rtld_fini=0x4000a350 <_dl_fini>, ---Type <return> to continue, or q <return> to quit--- stack_end=0xbffffd7c) at ../sysdeps/generic/libc-start.c:78 (gdb) Now, this is really, really weird. I have absolutely no idea why it feels the need to load perl at this precise moment in time... (I'm going to exceed the POST buffersize in a minute here...) After I *removed* mod_perl from my apache config, the same exercise leads to: (gdb) run -X Starting program: /usr/sbin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x400f9634 in chunk_free (ar_ptr=0x40189580, p=0x80e1010) at malloc.c:3009 malloc.c:3009: No such file or directory. (gdb) bt #0 0x400f9634 in chunk_free (ar_ptr=0x40189580, p=0x80e1010) at malloc.c:3009 #1 0x400f9505 in __libc_free (mem=0x80e1018) at malloc.c:2932 #2 0x401ef232 in _efree () #3 0x401ed38b in pval_destructor () #4 0x401edb6f in tc_destroy () #5 0x401edbc3 in tcm_destroy () #6 0x401e6f8b in php3_request_shutdown () #7 0x805038e in ap_run_cleanup () #8 0x804ebbd in ap_clear_pool () #9 0x804ec31 in ap_destroy_pool () #10 0x804ebac in ap_clear_pool () #11 0x805ddaf in ap_child_terminate () #12 0x805e31c in ap_child_terminate () #13 0x805e479 in ap_child_terminate () #14 0x805ea96 in ap_child_terminate () #15 0x805f203 in main () #16 0x400b8cb3 in __libc_start_main (main=0x805eedc <main>, argc=2, argv=0xbffffd84, init=0x804dbfc <_init>, fini=0x8071f1c <_fini>, rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffffd7c) at ../sysdeps/generic/libc-start.c:78 (gdb) Versions: (all rebuilt from SRPM) apache-1.3.6-8 (SPEC file modified to add "-g") mod_php3-3.0.8-1 (SPEC file modified to add "-g") MySQL-3.22.22-1 (pristine, I think...) glibc-2.1.1-6