I'm getting a core dump on 2.0.46 that may or may not be tied to a
particular request, but I'm trying to figure out what the request was
that may have caused the core dump. Is there a particular place in the
stack I should be looking? The backtrace looks thusly:

#0 0x00beeb73 in eaccelerator_clean_request ()
at /tmp/chrismcc.rpm/build/eaccelerator-0.9.3/eaccelerator.c:3550
#1 0x00beeeea in eaccelerator_crash_handler (dummy=1752182390)
at /tmp/chrismcc.rpm/build/eaccelerator-0.9.3/eaccelerator.c:3673
#2 <signal handler called>
#3 0x003de887 in _int_realloc () from /lib/tls/libc.so.6
#4 0x003dd3b6 in realloc () from /lib/tls/libc.so.6
#5 0x0116b7d3 in _erealloc (ptr=0xaeea67c, size=6, allow_failure=0)
at /tmp/chrismcc.rpm/build/php-4.4.4/Zend/zend_alloc.c:351
#6 0x0111310b in metaphone (word=0xaf4fdfc "\005", word_len=4,
max_phonemes=0, phoned_word=0xbfff708c, traditional=1)
at /tmp/chrismcc.rpm/build/php-4.4.4/ext/standard/metaphone.c:389
#7 0x01112700 in zif_metaphone (ht=1073741823, return_value=0xafb6484,
this_ptr=0x0, return_value_used=1)
at /tmp/chrismcc.rpm/build/php-4.4.4/ext/standard/metaphone.c:44
#8 0x0118bb38 in execute (op_array=0xadd7708)
at /tmp/chrismcc.rpm/build/php-4.4.4/Zend/zend_execute.c:1675
#9 0x0118b87c in execute (op_array=0xae67c98)
at /tmp/chrismcc.rpm/build/php-4.4.4/Zend/zend_execute.c:1719
#10 0x0118b87c in execute (op_array=0xb2a806c)
at /tmp/chrismcc.rpm/build/php-4.4.4/Zend/zend_execute.c:1719
#11 0x0118d0b7 in execute (op_array=0xaf42474)
at /tmp/chrismcc.rpm/build/php-4.4.4/Zend/zend_execute.c:2272
#12 0x0118d0b7 in execute (op_array=0xaf87f8c)
at /tmp/chrismcc.rpm/build/php-4.4.4/Zend/zend_execute.c:2272
#13 0x0117b440 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /tmp/chrismcc.rpm/build/php-4.4.4/Zend/zend.c:934
#14 0x0114cf9e in php_execute_script (primary_file=0xbfffb170)
at /tmp/chrismcc.rpm/build/php-4.4.4/main/main.c:1752
#15 0x01190d0d in php_output_filter (f=0xae15090, bb=0xae15f68)
at
/tmp/chrismcc.rpm/build/php-4.4.4/sapi/apache2filter/sapi_apache2.c:522
#16 0x080749fc in ap_pass_brigade (next=0xaeea670, bb=0x3fec4d9b)
at /usr/src/debug/httpd-2.0.46/server/util_filter.c:550
#17 0x0807c699 in default_handler (r=0xb00a078)
at /usr/src/debug/httpd-2.0.46/server/core.c:3558
#18 0x08068625 in ap_run_handler (r=0xb00a078)
at /usr/src/debug/httpd-2.0.46/server/config.c:200
#19 0x08068c3f in ap_invoke_handler (r=0xb00a078)
at /usr/src/debug/httpd-2.0.46/server/config.c:406
#20 0x08065266 in ap_process_request (r=0xb00a078)
at /usr/src/debug/httpd-2.0.46/modules/http/http_request.c:288
#21 0x080608dc in ap_process_http_connection (c=0xad391d8)
at /usr/src/debug/httpd-2.0.46/modules/http/http_core.c:293
#22 0x08072355 in ap_run_process_connection (c=0xad391d8)
at /usr/src/debug/httpd-2.0.46/server/connection.c:85
#23 0x08066b01 in child_main (child_num_arg=1073741823)
at /usr/src/debug/httpd-2.0.46/server/mpm/prefork/prefork.c:705
#24 0x08066c54 in make_child (s=0xaeea670, slot=37)
at /usr/src/debug/httpd-2.0.46/server/mpm/prefork/prefork.c:799
#25 0x08066ef9 in perform_idle_server_maintenance (p=0x97040a8)
at /usr/src/debug/httpd-2.0.46/server/mpm/prefork/prefork.c:934
#26 0x080675c0 in ap_mpm_run (_pconf=0x19, plog=0x9730158, s=0x0)
at /usr/src/debug/httpd-2.0.46/server/mpm/prefork/prefork.c:1135
#27 0x0806dbcf in main (argc=3, argv=0xbfffb604)
at /usr/src/debug/httpd-2.0.46/server/main.c:661

I looked at the TODO_SEGFAULTS that shipped with PHP, which mentioned
problems with malloc-related calls as a known source of segfaults;
should I bother tracking this one down further, or is this just a freak
problem?

rlm@pricegrabber.com wrote:

> #15 0x01190d0d in php_output_filter (f=0xae15090, bb=0xae15f68)
> at
> /tmp/chrismcc.rpm/build/php-4.4.4/sapi/apache2filter/sapi_apache2.c:522
> #16 0x080749fc in ap_pass_brigade (next=0xaeea670, bb=0x3fec4d9b)
> at /usr/src/debug/httpd-2.0.46/server/util_filter.c:550
> #17 0x0807c699 in default_handler (r=0xb00a078)
> at /usr/src/debug/httpd-2.0.46/server/core.c:3558

So you're serving a static document and running it through PHP as a
filter. That is how PHP *should* work, but I understand it is not
how PHP *does* work, and that PHP doesn't really work as a filter.

You could use mod_whatkilledus to reconstruct the request that gave
rise to the coredump. See http://people.apache.org/~trawick/

--
Nick Kew

Application Development with Apache - the Apache Modules Book
http://www.prenhallprofessional.com/title/0132409674