perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Hay" <Steve...@planit.com>
Subject RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1
Date Wed, 01 Feb 2012 15:15:43 GMT
The crash happens deleting the ptr_table, complaining that the wrong PerlInterpreter is being
used (the "free from wrong pool" error).

There are two PerlInterperters in modperl_svptr_table_clone() -- aTHX (my_perl) and proto_perl.
Looking at the memory addresses, I see that my_perl is the same as used throughout the calls
in the stack trace below, but the value of aTHX in the crashing Perl_safesysfree() is the
other value -- the proto_perl value from our clone call.

Is cleanup->perl being set to the wrong value in modperl_module_config_obj_cleanup_register()?
The call to that from modperl_module_config_merge() plays games with MP_PERL_CONTEXT_STORE_OVERRIDE
/ MP_PERL_CONTEXT_RESTORE, and the orig_perl value that gets saved away is the one that Perl_safesysfree()
was expecting...

Is it relevant that we don't set the proto_perl or new_perl members of the CLONE_PARAMS? And/or
is it related to the fairly recent addition of the new_perl member in http://perl5.git.perl.org/perl.git/commit/1db366cc74
?


-----Original Message-----
From: Steve Hay [mailto:SteveHay@planit.com] 
Sent: 01 February 2012 09:55
To: Torsten Förtsch; dev@perl.apache.org
Cc: Fred Moyer
Subject: RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1

Starting up the server as per "make test", attaching to it in a debugger with a breakpoint
in modperl_response_handler_cgi() and then using lwp-request to GET /apache/add_config I find
that it crashes every time with a "panic: free from wrong pool" error. Stack trace is:

>	perl515.dll!Perl_safesysfree(void * where)  Line 263	C
 	mod_perl.so!modperl_svptr_table_delete(interpreter * my_perl, ptr_tbl * tbl, void * key)
 Line 152 + 0xa bytes	C
 	mod_perl.so!modperl_module_config_obj_cleanup(void * data)  Line 121 + 0x17 bytes	C
 	libapr-1.dll!run_cleanups(cleanup_t * * cref)  Line 2346 + 0xf bytes	C
 	libapr-1.dll!apr_pool_destroy(apr_pool_t * pool)  Line 809 + 0xc bytes	C
 	libhttpd.dll!ap_destroy_sub_req(request_rec * r)  Line 1944	C
 	libhttpd.dll!ap_add_cgi_vars(request_rec * r)  Line 392	C
 	mod_perl.so!modperl_env_request_populate(interpreter * my_perl, request_rec * r)  Line 381
C
 	mod_perl.so!modperl_response_handler_cgi(request_rec * r)  Line 1083 + 0xd bytes	C
 	libhttpd.dll!ap_run_handler(request_rec * r)  Line 158 + 0x50 bytes	C
 	libhttpd.dll!ap_invoke_handler(request_rec * r)  Line 376 + 0x9 bytes	C
 	libhttpd.dll!ap_process_request(request_rec * r)  Line 282 + 0x9 bytes	C
 	libhttpd.dll!ap_process_http_connection(conn_rec * c)  Line 190 + 0x9 bytes	C
 	libhttpd.dll!ap_run_process_connection(conn_rec * c)  Line 43 + 0x50 bytes	C
 	libhttpd.dll!ap_process_connection(conn_rec * c, void * csd)  Line 192	C
 	libhttpd.dll!worker_main(void * thread_num_val)  Line 784	C
 	msvcr100d.dll!_callthreadstartex()  Line 314 + 0xf bytes	C
 	msvcr100d.dll!_threadstartex(void * ptd)  Line 297	C
 	kernel32.dll!760b339a() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]	
 	ntdll.dll!77c09ef2() 	
 	ntdll.dll!77c09ec5() 	


-----Original Message-----
From: Torsten Förtsch [mailto:torsten.foertsch@gmx.net]
Sent: 31 January 2012 17:38
To: dev@perl.apache.org
Cc: Fred Moyer
Subject: Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1

On Tuesday, 31 January 2012 15:32:44 Torsten Förtsch wrote:
> I can also confirm that r1145161 is
> the first commit that shows this behavior.

Working with r1145161, the minimal set of tests to trigger the bug is this (so
far):

t/TEST t/apache/add_config.t \
       t/apache/conftree.t \
       t/apache/constants.t \
       t/apache/content_length_header.t \
       t/apache/daemon.t \
       t/apache/post.t \
       t/apache/read.t \
       t/apache/read2.t \
       t/apache/read3.t \
       t/apache/scanhdrs.t \
       t/apache/scanhdrs2.t \
       t/apache/send_cgi_header.t \
       t/apache/subprocess.t

Now, it chokes in subprocess.t instead of command.t.

It does not fail on every run. If it does I get in the error_log this line:

  Usage: DynaLoader::dl_load_file(filename, flags=0).

I suspect that some piece of code writes to a random location. But I really don't know how
to start to debug that best given the sheer number of tests
(409) in this set.

Torsten Förtsch

--
Need professional modperl support? Hire me! (http://foertsch.name)

Like fantasy? http://kabatinte.net


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


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


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


Mime
View raw message