apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <i...@apache.org>
Subject Re: Debugging Win32 apr/Apache HANDLES
Date Fri, 15 Feb 2002 00:55:38 GMT
shouldn't we just add this to the CVS-HEAD via a #define ?


Bill Stoddard wrote:
> Cool. Definitely saving this away for use later.
> 
> Bill
> 
> ----- Original Message -----
> From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
> To: <dev@apr.apache.org>
> Sent: Tuesday, February 12, 2002 10:51 PM
> Subject: Debugging Win32 apr/Apache HANDLES
> 
> 
> 
>>Ok... took us quite a bit of blood [mostly inflicted on one another],
>>sweat and tears but the bugs are gone again from the Win32 service.
>>The question is how can we tell?
>>
>>"Tell us!"
>>
>>Because WinNT's SCM (Service Control Manager) has very narrow constraints
>>on system startup timing, real 'Debuggers' such as BoundsChecker were
>>not helping any.  Had to write up my own detailed flavor of an strace
>>/ApiSpy32 style utility, with enough feedback of the 'where's' to tie
>>down who was corrupting the handles.  I thought this might interest others,
>>certainly wanted it archvied somewhere for posterity.
>>
>>The attached logging patch traps most handle creation/destruction related
>>calls, and dumps them into a threadsafe logger in the format;
>>
>>  Handle Sequence ThreadID HandleApiCall(flavor) sourcefile:line
>>000000ac 0000000a 00000124 CreatePipe(hRead)
>>
> C:\clean\httpd-2.0\server\mpm\winnt\service.c:637
> 
>>000000ac 00000037 000006d0 CloseHandle()
>>
> C:\clean\httpd-2.0\server\mpm\winnt\service.c:597
> 
>>000000ac 0000005c 000008f4 DuplicateHandle(Target)
>>
> C:\clean\httpd-2.0\srclib\apr\file_io\win32\filedup.c:122
> 
>>000000ac 0000005d 000008f4 SetStdHandle()
>>
> C:\clean\httpd-2.0\srclib\apr\file_io\win32\filedup.c:125
> 
>>000000ac 00000076 000008f4 GetStdHandle()
>>
> C:\clean\httpd-2.0\server\mpm\winnt\mpm_winnt.c:1596
> 
>>The output is logged to ExeImagePathName.### where ### is the pid.
>>
>>The Sequence is incremented across all threads, so you have a single
>>reference point of order-of-execution.  Since I immediately run it through
>>a sort pipe, to get Handle-Major order [I'm looking for twisted and abused
>>handles], I needed a seq in logging output to keep some order.
>>
>>More than one log entry may occur per sequence (e.g. CreatePipe(hRead) and (hWrite)
>>creation events are logged.)  The API is somewhat cryptic, but I'm sure if you
>>stare at it for a minute it will make sense.  I left out the ability to check
>>the return value _as_well_as_ indirect handles, and don't trace the arguments to
>>the various calls.  These wouldn't be difficult, they simply weren't necessary
>>when I hacked this together.
>>
>>Note when looking at DuplicateHandle(EXTERN ---) results that the handle noted
>>doesn't even live in this processes' address space.
>>
>>So it was an interesting exercise, and I was curious if it interested others.
>>I don't see it having a permanent home in the apr source tree, so I'm just
>>tossing it to the list as a patch to play with.
>>
>>Bill
>>
>>
>>
> 




Mime
View raw message