Stas Bekman wrote: >Steve Hay wrote: > > >>Attempting to look further into the t/perl/ithreads.t failure using >>MOD_PERL_TRACE, I find that just setting MOD_PERL_TRACE to "i" and then >>trying to start apache.exe in the same way that t/TEST does, I now get >>an Access Violation crash. >> >>Specifically, running: >> >>C:\apache2\bin\Apache.EXE -d C:/Temp/modperl-2.0/t -f >>C:/Temp/modperl-2.0/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS >> >>produces a crash with this stacktrace (current CVS mp2, 2.0.50, 5.8.5): >> >>apr_thread_mutex_lock(apr_thread_mutex_t * 0x00000000) line 82 + 3 bytes >>apr_file_write(apr_file_t * 0x009e0268, const void * 0x009e7610, >>unsigned int * 0x0006de54) line 274 >>apr_file_puts(const char * 0x009e7610, apr_file_t * 0x009e0268) line 399 >>apr_file_printf(apr_file_t * 0x009e0268, const char * 0x100363ec >>`string') line 475 + 13 bytes >> >> > >please print the value of the apr_file_t argument in this frame (thefile). >the mutex is in that structure. so the mutex is in thefile->mutex > >that logfile value is set via: > > modperl_trace_level_set_apache(s, NULL); > >in modperl_config_srv_create call > Attached a screenshot of apr_file_t * (called fptr) in apr_file_printf().
As you can see, the fname member is (presumably correctly) set to the
error_log path, but the mutex member is NULL.
I may be wrong here, but it looks like the apr_file_t *logfile in
modperl_common_log.c is set by modperl_trace_logfile_set(), which is
called from modperl_hook_post_config(). The value being passed to
modperl_trace_logfile_set() is an apr_file_dup() of s->error_log:
apr_file_t *dup;
MP_RUN_CROAK(apr_file_dup(&dup, s->error_log, pconf),
"mod_perl core post_config");
modperl_trace_logfile_set(dup);
I walked through apr_file_dup() and watched what happened. s->error_log
has a (valid) mutex member, but the dup of it does not. Inside
apr_file_dup(), all the members of **new_file are NULL'ed by the
apr_pcalloc() call, and only some are then set to their correct values.
mutex is not one of them, so it just gets left NULL.
- Steve
>
>
>
>>modperl_trace(const char * 0x1002f1a0 `string', const char * 0x1002f1b4
>>`string') line 51 + 22 bytes
>>modperl_init_clones(server_rec * 0x0082c4d8, apr_pool_t * 0x0028af90)
>>line 442 + 35 bytes
>>modperl_hook_post_config(apr_pool_t * 0x0028af90, apr_pool_t *
>>0x0084a518, apr_pool_t * 0x0084c550, server_rec * 0x0082c4d8) line 616 +
>>13 bytes
>>ap_run_post_config(apr_pool_t * 0x0028af90, apr_pool_t * 0x0084a518,
>>apr_pool_t * 0x0084c550, server_rec * 0x0082c4d8) line 88 + 89 bytes
>>main(int 11, const char * const * 0x002884c0) line 564 + 22 bytes
>>mainCRTStartup() line 338 + 17 bytes
>>KERNEL32! 77e814c7()
>>
>>As you can see from the top of the stack, mutex is a NULL pointer, hence
>>the access violation at mutex->type.
>>
>>Any clue what's wrong here? Is it a bug in the libapr? I'm sure
>>MOD_PERL_TRACE has worked on Win32 in the past.
>>
------------------------------------------------
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.
<<inline: apr_file_printf.png>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
