Mail Archives: cygwin-developers/2002/05/27/13:04:07
"Christopher Faylor" <cgf AT redhat DOT com> wrote:
> On Mon, May 27, 2002 at 02:19:39AM +0100, Conrad Scott wrote:
> >There is unfortunately a race, since (on w2k at least) the target process
is
> >not being debugged by the time it receives the magic __SIGSTRACE
> >signal.
>
> I'm not sure that I understand how this type of race is possible. It
seems
> like once DebugActiveProcess returns the process in question should
> consider itself to be debugged. However, this wouldn't be the first time
> that I've been surprised by Microsoft.
Yes: it took me several hours to even *consider* the possibility that this
might be the problem. Ah well, I'll put it down as the perfect opportunity
to have learnt about things I didn't even know existed.
> However, I've checked in a fix which should work around your reported
> problem.
Thanks: I've picked that up and it works fine for me.
> Thanks for the detailed analysis.
And now it's in the archives for the next person who mucks around with
strace.
BTW, while I'm here, there was one other issue in strace.exe that I noticed.
In the code to handle the CREATE_PROCESS_DEBUG_EVENT, strace.exe closes the
u.CreateProcessInfo.hFile handle, but the SDK documentation says that this
handle shouldn't be closed by the debugger (not that I've seen any problem
with this):
"When a CREATE_PROCESS_DEBUG_EVENT occurs, the debugger application receives
a handle to the image file of the process being debugged, a handle to the
process being debugged, and a handle to the initial thread of the process
being debugged in the DEBUG_EVENT structure. The DEBUG_EVENT members these
handles are returned in are u.CreateProcessInfo.hFile,
u.CreateProcessInfo.hProcess, and u.CreateProcessInfo.hThread respectively.
The system will close these handles. The debugger should not close these
handles."
Cheers for now.
// Conrad
- Raw text -