You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2002/02/13 04:51:56 UTC
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
Re: Debugging Win32 apr/Apache HANDLES
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Ian Holsman" <ia...@apache.org>
Sent: Thursday, February 14, 2002 6:55 PM
> shouldn't we just add this to the CVS-HEAD via a #define ?
If you like - but it's terribly special-purpose. I certainly wouldn't
want to polute the include directory with it, full time ... hidden in
include/arch/win32/ perhaps ;)
> Bill Stoddard wrote:
> > Cool. Definitely saving this away for use later.
> >
> > Bill
> >
> > From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
> > Sent: Tuesday, February 12, 2002 10:51 PM
> >
> >>... 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
> >
> >>The output is logged to ExeImagePathName.### where ### is the pid.
> >>...
> >>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.
Re: Debugging Win32 apr/Apache HANDLES
Posted by Ian Holsman <ia...@apache.org>.
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." <wr...@rowe-clan.net>
> To: <de...@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
>>
>>
>>
>
Re: Debugging Win32 apr/Apache HANDLES
Posted by Bill Stoddard <bi...@wstoddard.com>.
Cool. Definitely saving this away for use later.
Bill
----- Original Message -----
From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
To: <de...@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
>
>