perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [mp2] protocol/echo_bbs2 on Win32
Date Thu, 01 Jul 2004 21:06:33 GMT
Randy Kobes wrote:
> The t/protocol/echo_bbs2 test on Win32 causes a crash
> (protocol/echo_bbs passes). The problem appears to be coming
> from apr_brigade_cleanup(), called from
> WrapXS/APR/Brigade/Brigade.xs - here's the output from the
> debugger:

Philippe has posted this a few days ago with the complete trace:

#0  0x002dc26a in apr_brigade_cleanup (data=0x9492090) at apr_brigade.c:47
47      apr_brigade.c: No such file or directory.
         in apr_brigade.c
(gdb)bt
#0  0x002dc26a in apr_brigade_cleanup (data=0x9492090) at apr_brigade.c:47
#1  0x00369616 in XS_APR__Brigade_cleanup (my_perl=0x8ea7d40, cv=0x8d1c230) at 
Brigade.c:54
#2  0x03b0226d in Perl_pp_entersub () from 
/usr/lib/perl5/5.8.3/i386-linux-thread-multi/CORE/libperl.so
#3  0x03ae4bbd in Perl_runops_debug () from 
/usr/lib/perl5/5.8.3/i386-linux-thread-multi/CORE/libperl.so
#4  0x03a94809 in Perl_call_sv () from 
/usr/lib/perl5/5.8.3/i386-linux-thread-multi/CORE/libperl.so
#5  0x03a944d5 in Perl_call_sv () from 
/usr/lib/perl5/5.8.3/i386-linux-thread-multi/CORE/libperl.so
#6  0x0023ab2f in modperl_callback (my_perl=0x8ea7d40, handler=0x9487160, 
p=0x9486c50, r=0x0, s=0x8318530,
     args=0x947f4f0) at modperl_callback.c:99
#7  0x0023b08e in modperl_callback_run_handlers (idx=0, type=1, r=0x0, c=0x0, 
s=0x8318530, pconf=0x0, plog=0x1,
     ptemp=0x1, run_mode=MP_HOOK_RUN_FIRST) at modperl_callback.c:268
#8  0x0023b615 in modperl_callback_connection (idx=1, c=0x9492094, 
run_mode=MP_HOOK_RUN_FIRST)
     at modperl_callback.c:373
#9  0x002515d0 in modperl_process_connection_handler (c=0x1) at modperl_hooks.c:17
#10 0x08074892 in ap_run_process_connection (c=0x9486d60) at connection.c:42
#11 0x08074c81 in ap_process_connection (c=0x9486d60, csd=0x9486c88) at 
connection.c:175
#12 0x0806801f in child_main (child_num_arg=1) at prefork.c:609
#13 0x080681a9 in make_child (s=0x81a6e48, slot=1) at prefork.c:703
#14 0x0806821e in startup_children (number_to_start=1) at prefork.c:721
#15 0x08068627 in ap_mpm_run (_pconf=0x81a50a8, plog=0x81cf150, s=0x81a6e48) 
at prefork.c:940
#16 0x0806f22d in main (argc=9, argv=0xfeeff384) at main.c:617

(gdb) print b
$4 = (apr_bucket_brigade *) 0x9492090
(gdb) print e
$5 = (apr_bucket *) 0x1
(gdb) print *b
$6 = {p = 0x9490f40, list = {next = 0x1, prev = 0x1011007}, bucket_alloc = 
0x9481150}
(gdb) print (*b)->list->prev
$7 = (struct apr_bucket *) 0x1011007
(gdb) print *((*b)->list->prev)
Cannot access memory at address 0x1011007

I don't understand why it doesn't happen on my setup which seems to be pretty 
close to philippe's one. I suppose it just so happens that the freed memory is 
still valid on my machine, due to different compilations.

The problem appears to be in Apache, where some downstream filter decides to 
free the brigade, rendering $bb->cleanup useless, since you can't rely on $bb 
to be valid at all. That just sucks.

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message