apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: Debugging Win32 apr/Apache HANDLES
Date Thu, 14 Feb 2002 13:45:47 GMT
Cool. Definitely saving this away for use later.


----- 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)
> 000000ac 00000037 000006d0 CloseHandle()
> 000000ac 0000005c 000008f4 DuplicateHandle(Target)
> 000000ac 0000005d 000008f4 SetStdHandle()
> 000000ac 00000076 000008f4 GetStdHandle()
> 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

View raw message