apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Debugging Win32 apr/Apache HANDLES
Date Wed, 13 Feb 2002 03:51:56 GMT
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.


View raw message