This problem is still there with the latest coolest modperl 2.0.
#0 0x4043a881 in Perl_die_where (my_perl=0x8332c38,
message=0x8bbfc60 "Can't undef active subroutine during global
destruction.\n", msglen=57)
at pp_ctl.c:1276
1276
sv_setpvn(ERRSV, message, msglen);
#1 0x403e0521 in Perl_vcroak (my_perl=0x8332c38, pat=0x4049b394 "Can't
undef active subroutine",
args=0xbfffe6e0) at util.c:1286
#2 0x403e06fb in Perl_croak () at util.c:1345
#3 0x403bd253 in Perl_cv_undef (my_perl=0x40330ad0, cv=0x82aa838) at
op.c:4384
#4 0x4040d0e5 in Perl_sv_clear (my_perl=0x8332c38, sv=0x82aa838) at
sv.c:5037
#5 0x4040d6d2 in Perl_sv_free (my_perl=0x8332c38, sv=0x82aa838) at
sv.c:5215
#6 0x40389ca0 in Perl_gp_free (my_perl=0x8332c38, gv=0x8e976b0) at
gv.c:1241
#7 0x4040d146 in Perl_sv_clear (my_perl=0x8332c38, sv=0x8e976b0) at
sv.c:5049
#8 0x4040d6d2 in Perl_sv_free (my_perl=0x8332c38, sv=0x8e976b0) at
sv.c:5215
#9 0x4040255d in do_clean_all (my_perl=0x8332c38, sv=0x8e976b0) at sv.c:400
#10 0x4040215d in S_visit (my_perl=0x8332c38, f=0x404024f0
<do_clean_all>) at sv.c:292
#11 0x4040259f in Perl_sv_clean_all (my_perl=0x8332c38) at sv.c:418
#12 0x4037ddb7 in perl_destruct (my_perl=0x8332c38) at perl.c:732
#13 0x40351728 in modperl_perl_destruct (perl=0x8332c38) at
modperl_perl.c:121
#14 0x403446e9 in modperl_interp_destroy (interp=0x8117db8) at
modperl_interp.c:94
#15 0x403448e0 in modperl_interp_pool_destroy (data=0x8117d58) at
modperl_interp.c:150
#16 0x400423da in run_cleanups (c=0x814b1d8) at apr_pools.c:1713
#17 0x40041862 in apr_pool_clear (pool=0x814b180) at apr_pools.c:603
#18 0x40343dc1 in modperl_child_exit (data=0x0) at mod_perl.c:471
#19 0x400423da in run_cleanups (c=0x83a6110) at apr_pools.c:1713
-------- Original Message --------
Subject: Re: cvs commit: modperl-2.0/t/protocol/TestProtocol eliza.pm
Date: Fri, 18 Jan 2002 22:51:54 +0800
From: Stas Bekman <[EMAIL PROTECTED]>
Organization: Hope, Humanized
CC: [EMAIL PROTECTED]
References: <Pine.LNX.4.21.0201101025100.9157-100000@localhost>
Doug MacEachern wrote:
> On Fri, 11 Jan 2002, Stas Bekman wrote:
>
>
>>does this work for you? It seems that it doesn't change anything since
>>the last call from $socket->send() never returns, so it doesn't matter
>>what's the value of $last is. I still get the core dump.
>>
>
> it wasn't core dumping on me before the change. i saw the core dump
> just once, and haven't seen it since. after your post i realized
what the
> problem was, or so i thought. since it core dumps for you, i'll leave it
> to you to debug :-)
OK, I think I've found the problem. It happens with eliza, echo or any
other test which happen to run last and just a little bit slow to cleanup.
The problem is that t/TEST kills the server *too early*, when the server
didn't complete the cleanups. This has been exposed when you postponed
the run of the END blocks to the very end. The workaround is to sleep
for a few secs before calling kill:
Index: Apache-Test/lib/Apache/TestServer.pm
===================================================================
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestServer.pm,v
retrieving revision 1.53
diff -u -r1.53 TestServer.pm
--- Apache-Test/lib/Apache/TestServer.pm 17 Jan 2002 04:17:49 -0000
1.53
+++ Apache-Test/lib/Apache/TestServer.pm 18 Jan 2002 14:45:56 -0000
@@ -283,6 +283,10 @@
my $self = shift;
my $aborted = shift;
+ # must sleep for 1 sec, to let the server complete the last
+ # request's cleanups
+ sleep 1;
+
if (Apache::TestConfig::WIN32) {
if ($self->{config}->{win32obj}) {
$self->{config}->{win32obj}->Kill(0);
But this is wrong, 1 sec works for me but may not work for some slower
machine. I'm not sure yet what the right fix but the server shouldn't
abort cleanups on SIGINT, as it does now. FWIW, here is the relevant
part of the core dump:
#16 0x400409aa in run_cleanups (c=0x8369e08) at apr_pools.c:1596
#17 0x4003fdd2 in apr_pool_destroy (pool=0x8369d88) at apr_pools.c:563
#18 0x080b442a in clean_child_exit (code=0) at prefork.c:231
#19 0x402732db in pthread_sighandler (signo=15, ctx=
{gs = 0, __gsh = 0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds =
43, __dsh$#20 0x402ae978 in killpg () from /lib/libc.so.6
#21 0x4003737c in apr_send (sock=0x837c368,
buf=0x87e0170 "\230�&\b8\215;@more about that.\n", len=0xbffff11c)
at sendrecv.c:101
#22 0x406002dc in mpxs_apr_send (my_perl=0x82a8ff0, socket=0x837c368,
sv_buf=0x87abb54, sv_len=0x87af178)
as you can see the thread gets killed just after it completed the
apr_send (in this case I was running protocol/eliza).
This core dump is random, and cannot be reproduced on demand, but it
happens almost every second run, probably depends on how busy is CPU
during the end of the test suite.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
