parser-related sigsegv

[Igor Shevchenko <ig...@carcass.ath.cx>]

Hi all,

I'm getting apache coredumps with apache 2.0.54 + mod_perl2 rc5 + apreq2 from 
multi-env-unstable (latest update). The form itself is rather big, and it 
starts with (case #1):

<form method="post" action="/path/to/url.pl" name="editor_form" 
enctype="multipart/form-data">

(case #1)
The form has all kinds of params: text-s, textarea-s, comboboxes, file 
uploads, etc. Apache dies when I call the following:

my $FORM = $apr->param;

Params parsing works with other, simpler forms which also have textareas and 
file uploads. I was going to nail down this to a smallest possible set of 
variables, but then I noticed that it works without the 'method="post"' part 
of form specification (case #2):

<form action="/path/to/url.pl" name="editor_form" 
enctype="multipart/form-data">

Here's the backtrace for core dump for the case #1:

#0  apreq_parse_multipart (parser=0x8f74108, t=0x8f74188, bb=0x8f74128) at 
apreq_param.h:53
#1  0xb7fe676c in apreq_filter_prefetch (f=0x8f73ed0, readbytes=150421704) at 
apreq_parser.h:126
#2  0xb7fe5291 in apache2_body (req=0x8f740c8, t=0x0) at handle.c:169
#3  0xb7fdf21e in apreq_params (req=0x8f73eb0, p=0x8f63d28) at 
apreq_module.h:166
#4  0xb79c2b25 in apreq_xs_apache2_param (my_perl=0x8263ad8, cv=0x8b3738c) at 
APR__Request__Apache2.h:178
#5  0xb7dfea93 in Perl_pp_entersub () 
from /usr/lib/perl5/5.8.6/i686-linux-thread-multi-64int/CORE/libperl.so
#6  0xb7df6a69 in Perl_runops_standard () 
from /usr/lib/perl5/5.8.6/i686-linux-thread-multi-64int/CORE/libperl.so
#7  0xb7d91f29 in S_call_body () 
from /usr/lib/perl5/5.8.6/i686-linux-thread-multi-64int/CORE/libperl.so
#8  0xb7d9762c in Perl_call_sv () 
from /usr/lib/perl5/5.8.6/i686-linux-thread-multi-64int/CORE/libperl.so
#9  0x0807a077 in modperl_callback (my_perl=0x8263ad8, handler=0x81a9e88, 
p=0x8f63d28, r=0x8f63d60, s=0x81ab250, args=0x88a4ddc) at 
modperl_callback.c:100
#10 0x0807a93e in modperl_callback_run_handlers (idx=6, type=4, r=0x8f63d60, 
c=0x0, s=0x81ab250, pconf=0x0, plog=0x0, ptemp=0x0, 
run_mode=MP_HOOK_RUN_FIRST)
    at modperl_callback.c:261
#11 0x0807adf9 in modperl_callback_per_dir (idx=6, r=0x8f63d60, 
run_mode=MP_HOOK_RUN_FIRST) at modperl_callback.c:368
#12 0x080736f3 in modperl_response_handler_run (r=0x8f63d60, finish=1) at 
mod_perl.c:976
#13 0x080737ff in modperl_response_handler (r=0x8f63d60) at mod_perl.c:1016
#14 0x080d5c25 in ap_run_handler (r=0x8f63d60) at config.c:152
#15 0x080d609d in ap_invoke_handler (r=0x8f63d60) at config.c:364
#16 0x080bac58 in ap_process_request (r=0x8f63d60) at http_request.c:249
#17 0x080b5c29 in ap_process_http_connection (c=0x8f5de20) at http_core.c:251
#18 0x080e1095 in ap_run_process_connection (c=0x8f5de20) at connection.c:43
#19 0x080d3e0b in child_main (child_num_arg=0) at prefork.c:610
#20 0x080d3ff8 in make_child (s=0x812ed18, slot=0) at prefork.c:650
#21 0x080d4100 in startup_children (number_to_start=5) at prefork.c:722
#22 0x080d492d in ap_mpm_run (_pconf=0xbffff720, plog=0x8162190, s=0x80d3910) 
at prefork.c:941
#23 0x080db1c0 in main (argc=3, argv=0xbffff8c4) at main.c:618

Hope this will help somehow... I can try to dig further if needed.

-- 
Best Regards,
Igor Shevchenko

Re: parser-related sigsegv

[Joe Schaefer <jo...@sunstarsys.com>]

Igor Shevchenko <ig...@carcass.ath.cx> writes:

[...]

> Hope this will help somehow... I can try to dig further if needed.

Thanks.  I think we need more details about the segfaulting request 
to figure out what's going on here; the mp2 devel docs may help you:

    http://perl.apache.org/docs/2.0/devel/debug/c.html

-- 
Joe Schaefer

Re: parser-related sigsegv

[Joe Schaefer <jo...@sunstarsys.com>]

Igor Shevchenko <ig...@carcass.ath.cx> writes:

> Hi all,
>
> I'm getting apache coredumps with apache 2.0.54 + mod_perl2 rc5 +
> apreq2 from multi-env-unstable (latest update).

Thanks, that branch should be trunk now.

> The form itself is rather big, and it starts with (case #1):

[...]

> Here's the backtrace for core dump for the case #1:
>
> #0  apreq_parse_multipart (parser=0x8f74108, t=0x8f74188,
> bb=0x8f74128) at apreq_param.h:53
> #1  0xb7fe676c in apreq_filter_prefetch (f=0x8f73ed0,
> readbytes=150421704) at  apreq_parser.h:126
> #2  0xb7fe5291 in apache2_body (req=0x8f740c8, t=0x0) at handle.c:169
> #3  0xb7fdf21e in apreq_params (req=0x8f73eb0, p=0x8f63d28) at 
> apreq_module.h:166

Definitely an apreq bug, but it's hard for me to tell what the bug is
from this trace.  Can anyone with a debugging build reproduce it?

-- 
Joe Schaefer