Package: libapache2-mod-fcgid
Version: 2.0-1
Followup-For: Bug #401938
I can confirm the problem. It looks like mod_fcgid doesn't like it when the
server (a Ruby dispatcher in my case) is closing the connection right after
the fastcgi request has been sent (deduced from strace info). I'm on a semi-
production server, I've only recompiled the module with debug symbols:
# gdb /usr/sbin/apache2
...
(gdb) set args -DNO_DETACH -DONE_PROCESS
...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 7814)]
0x00000058 in ?? ()
(gdb) bt
#0 0x00000058 in ?? ()
#1 0x4079aac4 in getsfunc_fcgid_BRIGADE (buf=0xbfffa2d4 "Status", len=8191,
arg=0x82fadf0) at fcgid_bridge.c:212
#2 0x08079afc in ap_scan_script_header_err_core ()
#3 0x4079b289 in handle_request (r=0x82f62b8, argv0=0x82f9da8
"/var/www/sandbox.af83.com/wiki/public/dispatch.fcgi",
wrapper_conf=0x0, output_brigade=0x82fad50) at fcgid_bridge.c:395
#4 0x4079baa6 in bridge_request (r=0x82f62b8, role=1, argv0=0x82f9da8
"/var/www/sandbox.af83.com/wiki/public/dispatch.fcgi",
wrapper_conf=0x0) at fcgid_bridge.c:590
#5 0x4079fdca in fcgid_handler (r=0x82f62b8) at mod_fcgid.c:182
#6 0x08074587 in ap_run_handler ()
#7 0x08077731 in ap_invoke_handler ()
#8 0x080845aa in ap_internal_redirect ()
#9 0x40e29d7c in ?? () from /usr/lib/apache2/modules/mod_rewrite.so
#10 0x082f62a0 in ?? ()
#11 0x082ebd68 in ?? ()
#12 0x00000000 in ?? ()
(gdb) frame 1
#1 0x4079aac4 in getsfunc_fcgid_BRIGADE (buf=0xbfffa2d4 "Status", len=8191,
arg=0x82fadf0) at fcgid_bridge.c:212
(gdb) print *e
$3 = {link = {next = 0x82fadf4, prev = 0x82fadf4}, type = 0x82e9d28, length =
137342304, start = 4613506809820327408,
data = 0x8061060, free = 0x82ebd30, list = 0xc}
(gdb) print *e->type
$8 = {name = 0x82e3ad8 "�v\n\b }.\b�\f\r\b�v\n\b�;.\b", num_func = 137247312,
is_metadata = 137274744, destroy = 0x82e9d10,
read = 0x58, setaside = 0x82e9d28, split = 0x82e9d10, copy = 0}
The module was compiled from CVS, the fcgid_bridge.c:212 line is:
rv = apr_bucket_read(e, &bucket_data, &bucket_data_len, APR_BLOCK_READ);
... where apr_bucket_read() is a macro calling the e->type->read function
which is obviously not initialized (0x58!).
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.19.1
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
