Stas Bekman wrote:
Steve Hay wrote:
t\filter\in_bbs_inject_header.t always succeeds when run as part of the whole "nmake new" run, and only sometimes crashes Apache when run alone, which was only uncovered by last night's SMOKE run.
After numerous attempts, mine finally failed (running in isolation) too.
You mean, it's a random thing, right?
Yes.
Here's the stacktrace (using perl-5.8.4):
Perl_safesysmalloc(unsigned int 268467750) line 67 + 11 bytes
modperl_input_filter_handler(ap_filter_t * 0x6eec8410 apr_pool_cleanup_null(void *), apr_bucket_brigade * 0x02b3c950, int 45337120, int 0, __int64 10888566729080832) line 905 + 23 bytes
so where is that line 905? what mod_perl code has caused that malloc call?
That was using a release build with (some) debugging symbols. Looks like some stuff was missing from the stacktrace :(
I've now recompiled with 2.0.50 and 5.8.5 in full debug mode, and get a fuller stacktrace like Markus posted:
Perl_safesysmalloc(unsigned int 72) line 67 + 28 bytes
modperl_filter_new(ap_filter_t * 0x009fc490, apr_bucket_brigade * 0x00a28350, int 0, int 1, int 0, __int64 0) line 316 + 7 bytes
modperl_input_filter_handler(ap_filter_t * 0x009fc490, apr_bucket_brigade * 0x00a28350, int 1, int 0, __int64 0) line 905 + 31 bytes
ap_get_brigade(ap_filter_t * 0x009fc490, apr_bucket_brigade * 0x00a28350, int 1, int 0, __int64 0) line 475 + 32 bytes
net_time_filter(ap_filter_t * 0x00a282f0, apr_bucket_brigade * 0x00a28350, int 1, int 0, __int64 0) line 3601
ap_get_brigade(ap_filter_t * 0x00a282f0, apr_bucket_brigade * 0x00a28350, int 1, int 0, __int64 0) line 475 + 32 bytes
ap_rgetline_core(char * * 0x00a27508, unsigned int 8192, unsigned int * 0x04d8fed4, request_rec * 0x00a274f0, int 0, apr_bucket_brigade * 0x00a28350) line 215 + 27 bytes
read_request_line(request_rec * 0x00a274f0, apr_bucket_brigade * 0x00a28350) line 593 + 39 bytes
ap_read_request(conn_rec * 0x009fc138) line 886 + 13 bytes
ap_process_http_connection(conn_rec * 0x009fc138) line 243 + 9 bytes
ap_run_process_connection(conn_rec * 0x009fc138) line 42 + 78 bytes
ap_process_connection(conn_rec * 0x009fc138, void * 0x009fc068) line 177
worker_main(long 1) line 720
_threadstartex(void * 0x0028d560) line 212 + 13 bytes
KERNEL32! 77e7d33b()
The malloc is thus from modperl_filter_new(), which says:
/* we can't allocate memory from the pool here, since potentially * a filter can be called hundreds of times during the same * request/connection resulting in enormous memory demands * (sizeof(*filter)*number of invocations) */ Newz(0, filter, 1, modperl_filter_t);
I can now also see the cause of the access violation: 'my_perl' is NULL in Perl_safesysmalloc().
Is this one of the delightful thread context problems again? Can you reproduce this on Linux? If its related to Win32-specific threads/memory games then do you still have that patch from Jan Dubois a while back to help you get Win32-style behaviour on Linux?
Unfortunately not, I'll need to revive it.
Any ideas why does it happen randomly?
We saw problems before when my_perl was pointing to the wrong interprter, but never NULL.
May be we just drop safemalloc, and use the plain old malloc, or now that we are more educated with apache internals the right solution seems to be to create a sub-pool and use it to allocate memory. Let me try to work on that first.
-- __________________________________________________________________ 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]
