The deletion of the ptr_table uses Safefree(), which picks up the context from
PERL_GET_CONTEXT, so simply assigning cleanup->perl to aTHX (aka my_perl)
before calling modperl_svptr_table_delete() is not sufficient to get Safefree()
to use the same interpreter as was used to allocate the memory originally in
the modperl_module_config_table_get() call in modperl_module_config_merge().
The following patch fixes this by utilizing MP_PERL_CONTEXT_STORE_OVERRIDE /
MP_PERL_CONTEXT_RESTORE as is done by modperl_module_config_merge():
--- modperl_module.c.orig Fri May 13 07:18:04 2011
+++ modperl_module.c Thu Feb 02 14:09:46 2012
@@ -116,9 +116,16 @@
{
config_obj_cleanup_t *cleanup =
(config_obj_cleanup_t *)data;
- dTHXa(cleanup->perl);
+#ifdef USE_ITHREADS
+ MP_PERL_CONTEXT_DECLARE;
+ MP_PERL_CONTEXT_STORE_OVERRIDE(cleanup->perl);
+#endif
modperl_svptr_table_delete(aTHX_ cleanup->table, cleanup->ptr);
+
+#ifdef USE_ITHREADS
+ MP_PERL_CONTEXT_RESTORE;
+#endif
MP_TRACE_c(MP_FUNC, "deleting ptr 0x%lx from table 0x%lx",
(unsigned long)cleanup->ptr,
End of Patch.
That allows the server to get a little further through handling the response,
but it still crashes with another free from wrong pool error a few lines later
:-( The stack trace is now:
> perl515.dll!Perl_safesysfree(void * where) Line 263 C
perl515.dll!S_hsplit(interpreter * my_perl, hv * hv) Line 1157 + 0xc
bytes C
perl515.dll!Perl_hv_common(interpreter * my_perl, hv * hv, sv * keysv,
const char * key, unsigned int klen, int flags, int action, sv * val, unsigned
long hash) Line 813 + 0xd bytes C
perl515.dll!Perl_hv_common_key_len(interpreter * my_perl, hv * hv,
const char * key, long klen_i32, const int action, sv * val, const unsigned
long hash) Line 332 + 0x27 bytes C
mod_perl.so!modperl_env_table_populate(interpreter * my_perl,
apr_table_t * table) Line 132 + 0xb3 bytes C
mod_perl.so!modperl_env_request_populate(interpreter * my_perl,
request_rec * r) Line 381 + 0x13 bytes 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: Steve Hay [mailto:[email protected]]
Sent: 01 February 2012 15:16
To: Torsten Förtsch; [email protected]
Cc: Fred Moyer
Subject: RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1
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:[email protected]]
Sent: 01 February 2012 09:55
To: Torsten Förtsch; [email protected]
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:[email protected]]
Sent: 31 January 2012 17:38
To: [email protected]
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: [email protected] For additional
commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected] For additional
commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected] For additional
commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
