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 > >
