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?
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender immediately. The
unauthorized use, disclosure, copying or alteration of this message is strictly
forbidden. Note that any views or opinions presented in this email are solely those
of the author and do not necessarily represent those of Radan Computational Ltd. The
recipient(s) of this message should check it and any attached files for viruses: Radan
Computational will accept no liability for any damage caused by any virus transmitted
by this email.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
