Geoffrey Young wrote:

>>I've now got the same problem as you, Randy -- it runs one set of tests 
>>OK (all successful), but then hangs trying to start the server the 
>>second time.
>>    
>>
>
>consistency is good :)
>
>I'm still unclear as to whether this is a fault of the new hook-ordering
>implementation, or a symptom of the way I chose to setup the tests.  does it
>behave the same way against pristine mod_perl CVS?
>
How can I try that?!  If I run it against pristine mp2 CVS then it 
complains "Invalid command 'PerlHookPostReadRequestHandler'" etc ;)

>
>likewise, if you comment out everything in t/TEST save one test (any one
>save the first, which doesn't excercise the new directives) does the
>individual test pass?
>
The first test alone obviously runs OK, and more importantly multiple 
runs of the first test go OK:

Apache::TestRunPerl->new->run(@ARGV, '-defines', '');
Apache::TestRunPerl->new->run(@ARGV, '-defines', '');

The ReallyLast, Last and Mix tests all fail when tried out 
individually.  The ReallyFirst test runs OK on its own, though.

>
>finally, is there something screwy with my IO in t/TEST - if you take out
>all the open and print foo does the problem go away?  that was mostly for my
>debugging information anyway...
>
Removing all the open/print/close stuff makes no difference.

(I'm testing this with "perl -Mblib t/TEST.PL" rather than "nmake test", 
btw.)

Still can't understand where that "Invalid handle" error comes from.  
Here's what's on the call stack when that error comes out:

child_main(apr_pool_t * 0x6ff1d724) line 946
ap_mpm_run(apr_pool_t * 0x0026abd8, apr_pool_t * 0x00848240, server_rec 
* 0x0026ca70) line 1629
main(int 4201858, const char * const * 0x0000000c) line 660 + 13 bytes
APACHE! mainCRTStartup + 227 bytes
KERNEL32! 77e814c7()

The (HANDLE *) child_events that is passed to WaitForMultipleObjects() 
on line 935 of server/mpm/winnt/child.c is a pointer to an array of 
object handles.  The first argument (here, 2) specifies the number of 
object handles in that array.  Here's what the MSVC debugger shows for 
child_events as it is passed to WaitForMultipleObjects:

child_events   0x0006fed4
[0]            0x00000cb0
[1]            0x00000000

The two events are exit_event and max_requests_per_child_event 
respectively.  Is it significant that the latter is NULL and the former 
is not?  Are they both supposed to be NULL or non-NULL?  Maybe the NULL 
one is the "invalid handle", but why does it happen?  There is a comment 
in the code about thread exits not being checked.  I don't know if 
that's relevant or not?

I tried increasing ThreadsPerChild further, and fiddled with 
MaxRequestsPerChild too, but to no avail.

- 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