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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to