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." <[EMAIL PROTECTED]> To: <[email protected]> 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
