You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Steve Hay <st...@uk.radan.com> on 2004/09/15 11:29:44 UTC
MOD_PERL_TRACE crashes apache.exe on Win32
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
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.
- 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: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: MOD_PERL_TRACE crashes apache.exe on Win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
[...]
> OK, the attached patch (against httpd-2.0.50) gets things (mostly)
> working for me.
>
> I dropped the check for (*new_file)->buffered that the unix case has
> because the win32 case always sets it to FALSE so the new if { ... }
> block would not have been entered. (I considered copying ->buffered
> from the old_file like unix does, but it was FALSE on the old_file too.)
>
> I also dropped the !(*new_file)->mutex test that the unix case has
> because on win32 we've always just done a apr_pcalloc() on the
> *new_file, so we know ->mutex is NULL.
>
> There's also a apr_file_dup2() in the win32 file. I don't know if that
> needs fixing up similarly.
Most likely. Look at the unix implementation, it should be similar.
> Should I send this patch somewhere else for consideration?
Yes, to the apr-dev list.
> I tried starting apache.exe with each of the MOD_PERL_TRACE flags in
> turn. Previously d, e, f, g, h, i, o and r all caused a crash. Now
> they all work OK except for g (globals) which still causes a crash:
>
> NTDLL! 77f69ecd()
> NTDLL! 77f5b2e6()
> apr_file_write(apr_file_t * 0x009e0268, const void * 0x009ed6b8,
> unsigned int * 0x0006de94) line 274
> apr_file_puts(const char * 0x009ed6b8, apr_file_t * 0x009e0268) line 399
> apr_file_printf(apr_file_t * 0x009e0268, const char * 0x100363ec
> `string') line 475 + 13 bytes
> modperl_trace(const char * 0x100331b4 `string', const char * 0x100331cc
> `string') line 51 + 22 bytes
> modperl_global_cleanup(void * 0x100373bc MP_global_server_rec) line 79 +
> 34 bytes
> run_cleanups(cleanup_t * * 0x0029acf8) line 1951 + 13 bytes
> apr_pool_clear(apr_pool_t * 0x0029ace8) line 693 + 12 bytes
> main(int 9, const char * const * 0x00292918) line 576
> mainCRTStartup() line 338 + 17 bytes
> KERNEL32! 77e814c7()
>
> Don't know what the top two frames there are. They both show up as
> "Disassembly" in the debugger :( The apr_file_t * in apr_file_write()
> does have a mutex, though.
NT in NTDLL is for native threads? May be something else is broken. Ask at
the apr-dev list?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: MOD_PERL_TRACE crashes apache.exe on Win32
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Steve Hay wrote:
>[...]
>
>
>>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.
>>
>>
>
>Perfect, so you've uncovered a yet another bug in apr, on unix it does
>create the mutex, see: apr/file_io/unix/filedup.c: _file_dup
>
>So fix apr/file_io/win32/filedup.c: apr_file_dup to create the mutex,
>looking at the function above and apr_file_setaside in
>apr/file_io/win32/filedup.c, which does:
>
> if (old_file->mutex) {
> apr_thread_mutex_create(&((*new_file)->mutex),
> APR_THREAD_MUTEX_DEFAULT, p);
> apr_thread_mutex_destroy(old_file->mutex);
> }
>
>
OK, the attached patch (against httpd-2.0.50) gets things (mostly)
working for me.
I dropped the check for (*new_file)->buffered that the unix case has
because the win32 case always sets it to FALSE so the new if { ... }
block would not have been entered. (I considered copying ->buffered
from the old_file like unix does, but it was FALSE on the old_file too.)
I also dropped the !(*new_file)->mutex test that the unix case has
because on win32 we've always just done a apr_pcalloc() on the
*new_file, so we know ->mutex is NULL.
There's also a apr_file_dup2() in the win32 file. I don't know if that
needs fixing up similarly.
Should I send this patch somewhere else for consideration?
I tried starting apache.exe with each of the MOD_PERL_TRACE flags in
turn. Previously d, e, f, g, h, i, o and r all caused a crash. Now
they all work OK except for g (globals) which still causes a crash:
NTDLL! 77f69ecd()
NTDLL! 77f5b2e6()
apr_file_write(apr_file_t * 0x009e0268, const void * 0x009ed6b8,
unsigned int * 0x0006de94) line 274
apr_file_puts(const char * 0x009ed6b8, apr_file_t * 0x009e0268) line 399
apr_file_printf(apr_file_t * 0x009e0268, const char * 0x100363ec
`string') line 475 + 13 bytes
modperl_trace(const char * 0x100331b4 `string', const char * 0x100331cc
`string') line 51 + 22 bytes
modperl_global_cleanup(void * 0x100373bc MP_global_server_rec) line 79 +
34 bytes
run_cleanups(cleanup_t * * 0x0029acf8) line 1951 + 13 bytes
apr_pool_clear(apr_pool_t * 0x0029ace8) line 693 + 12 bytes
main(int 9, const char * const * 0x00292918) line 576
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e814c7()
Don't know what the top two frames there are. They both show up as
"Disassembly" in the debugger :( The apr_file_t * in apr_file_write()
does have a mutex, though.
- 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.
Re: MOD_PERL_TRACE crashes apache.exe on Win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
[...]
> 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.
Perfect, so you've uncovered a yet another bug in apr, on unix it does
create the mutex, see: apr/file_io/unix/filedup.c: _file_dup
So fix apr/file_io/win32/filedup.c: apr_file_dup to create the mutex,
looking at the function above and apr_file_setaside in
apr/file_io/win32/filedup.c, which does:
if (old_file->mutex) {
apr_thread_mutex_create(&((*new_file)->mutex),
APR_THREAD_MUTEX_DEFAULT, p);
apr_thread_mutex_destroy(old_file->mutex);
}
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: MOD_PERL_TRACE crashes apache.exe on Win32
Posted by Steve Hay <st...@uk.radan.com>.
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.
Re: MOD_PERL_TRACE crashes apache.exe on Win32
Posted by Stas Bekman <st...@stason.org>.
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
> 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.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org