Most certainly, yes. A stack trace without debugging symbols is not
very useful in trying to pin down the source of a segfault bug.
OK, I compiled mod_perl with MP_DEBUG and MP_TRACE, and
got apache to produce a core dump (kern.sugid_coredump=1 appears to
be needed on FreeBSD):
(gdb) bt
#0 0x28384eb4 in strncpy () from /lib/libc.so.7
#1 0x287af9ee in modperl_perl_global_avcv_clear ()
from /usr/local/libexec/apache22/mod_perl.so
#2 0x287afacf in modperl_perl_global_avcv_clear ()
from /usr/local/libexec/apache22/mod_perl.so
#3 0x287afbed in modperl_perl_global_request_save ()
from /usr/local/libexec/apache22/mod_perl.so
#4 0x2879bf7e in modperl_response_handler_cgi ()
from /usr/local/libexec/apache22/mod_perl.so
#5 0x0807bc66 in ap_run_handler (r=0x28eb6058) at config.c:157
#6 0x0807c42f in ap_invoke_handler (r=0x28eb6058) at config.c:372
#7 0x0808c503 in ap_process_request (r=0x28eb6058) at http_request.c:282
#8 0x080890c1 in ap_process_http_connection (c=0x28afe1f0) at
http_core.c:190
#9 0x080846a6 in ap_run_process_connection (c=0x28afe1f0) at
connection.c:43
#10 0x08084af8 in ap_process_connection (c=0x28afe1f0, csd=0x28afe058)
at connection.c:178
#11 0x08092b7f in child_main (child_num_arg=6) at prefork.c:662
#12 0x08092d6c in make_child (s=0x28410f10, slot=6) at prefork.c:758
#13 0x08092fc4 in perform_idle_server_maintenance (p=0x2840f018) at
prefork.c:893
#14 0x080934e8 in ap_mpm_run (_pconf=0x2840f018, plog=0x2843d018,
s=0x28410f10)
at prefork.c:1097
#15 0x08064389 in main (argc=0, argv=0x0) at main.c:740
