make attaching to stopped processes work under windows

make attaching to stopped processes work under windows

[Oswald Buddenhagen]

[-- Attachment #1: Type: text/plain, Size: 227 bytes --]

hi,

the rationale is in the patch itself; i can factor it out to the commit
message if preferred.

	* windows-nat.c (get_windows_debug_event): If we find the thread
	  from the CREATE_PROCESS_DEBUG_EVENT suspended, resume it.

[-- Attachment #2: _gdb_windows-attach-suspended.diff --]
[-- Type: text/x-diff, Size: 1229 bytes --]

Index: windows-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/windows-nat.c,v
retrieving revision 1.179
diff -U2 -r1.179 windows-nat.c
--- windows-nat.c	6 Feb 2009 22:21:26 -0000	1.179
+++ windows-nat.c	13 Feb 2009 15:39:41 -0000
@@ -1331,4 +1331,21 @@
 	break;
 
+      /* Resume main thread if we are attaching to a suspended
+	 process.
+	 Note that we are not trying to handle multi-threaded
+	 situations, as these are likely to be too complex anyway.
+	 This is primarily meant to cover the case where someone
+	 creates a process in suspended state and hands it over
+	 to gdb (this is an abstraction - you cannot actually do
+	 that due to Windows bugs. You need to start debugging the
+	 process yourself, and once it has started up, you suspend
+	 it and detach from it). */
+      if (SuspendThread (current_event.u.CreateProcessInfo.hThread) == 2)
+	{
+	  printf_unfiltered ("gdb: thawing initially frozen thread.\n");
+	  ResumeThread (current_event.u.CreateProcessInfo.hThread);
+	}
+      CHECK (ResumeThread (current_event.u.CreateProcessInfo.hThread));
+
       current_process_handle = current_event.u.CreateProcessInfo.hProcess;
       if (main_thread_id)

Re: make attaching to stopped processes work under windows

[Christopher Faylor]

On Thu, Feb 26, 2009 at 08:25:52PM +0100, Oswald Buddenhagen wrote:
>hi,
>
>the rationale is in the patch itself; i can factor it out to the commit
>message if preferred.
>
>	* windows-nat.c (get_windows_debug_event): If we find the thread
>	  from the CREATE_PROCESS_DEBUG_EVENT suspended, resume it.

Suspending random threads like this is usually a bad idea.  Do you
actually have a use cause that requires attaching to suspended threads?

cgf

Re: make attaching to stopped processes work under windows

[Oswald Buddenhagen]

hi,

On Fri, Feb 27, 2009 at 07:44:14PM -0500, Christopher Faylor wrote:
> On Thu, Feb 26, 2009 at 08:25:52PM +0100, Oswald Buddenhagen wrote:
> >the rationale is in the patch itself; i can factor it out to the commit
> >message if preferred.
> >
> >	* windows-nat.c (get_windows_debug_event): If we find the thread
> >	  from the CREATE_PROCESS_DEBUG_EVENT suspended, resume it.
> 
> Suspending random threads like this is usually a bad idea.  Do you
> actually have a use cause that requires attaching to suspended threads?
> 
i should point out that the patch contains a comment answering that
question and that i pointed that out in the only sentence the mail
contained. so please be a little bit more attentive, or make it somewhat
clearer that you already are (by relating to previous content when you
ask something). thanks.

Re: make attaching to stopped processes work under windows

[Joel Brobecker]

> > Suspending random threads like this is usually a bad idea.  Do you
> > actually have a use cause that requires attaching to suspended threads?
> > 
> i should point out that the patch contains a comment answering that
> question and that i pointed that out in the only sentence the mail
> contained. so please be a little bit more attentive, or make it somewhat
> clearer that you already are (by relating to previous content when you
> ask something). thanks.

Please, let's remain courteous. Chris is not your employee, he is
a volunteer who maintains, among other things, the Windows ports of GDB.
We're all have very busy lives, and finding time to review patches is
sometimes difficult. As far as I am concerned, if I question the purpose
of a patch, why would I waste time looking at the patch itself?

-- 
Joel

Re: make attaching to stopped processes work under windows

[Oswald Buddenhagen]

On Mon, Mar 02, 2009 at 09:23:05AM -0800, Joel Brobecker wrote:
> As far as I am concerned, if I question the purpose of a patch, why
> would I waste time looking at the patch itself?
> 
because i pointed out that it would be necessary? because somebody who
knows the code certainly would know that the expected size of the patch
would not justify writing a mail rather than simply having a look at it?
not to mention that any reasonably configured reasonable mailer would
display the patch in-line, making the whole mail overviewable without
taking *any* additional action. in that light it certainly appears
rather pointless to argue principles. but the original response didn't
even appear to do that, it rather seemed like cfg didn't read the mail
past the subject line. i don't see how defending that is supposed to
help in any way. i really have problems taking this situation seriously,
even when i am a completely overloaded maintainer of several projects
myself.

Re: make attaching to stopped processes work under windows

[Eli Zaretskii]

> Date: Mon, 2 Mar 2009 09:23:05 -0800
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb-patches@sourceware.org
> 
> > > Suspending random threads like this is usually a bad idea.  Do you
> > > actually have a use cause that requires attaching to suspended threads?
> > > 
> > i should point out that the patch contains a comment answering that
> > question and that i pointed that out in the only sentence the mail
> > contained. so please be a little bit more attentive, or make it somewhat
> > clearer that you already are (by relating to previous content when you
> > ask something). thanks.
> 
> Please, let's remain courteous. Chris is not your employee, he is
> a volunteer who maintains, among other things, the Windows ports of GDB.

100% agreement.  Even if the said comment did answer the question
(which it doesn't, even after I re-read it several times), there's no
justification for such rudeness in response to a simple query.

Re: make attaching to stopped processes work under windows

[Eli Zaretskii]

> Date: Mon, 2 Mar 2009 19:28:26 +0100
> From: Oswald Buddenhagen <oswald.buddenhagen@trolltech.de>
> 
> i really have problems taking this situation seriously, even when i
> am a completely overloaded maintainer of several projects myself.

Well, take our word for it: your response appeared extremely rude for
no good reason.

> but the original response didn't even appear to do that, it rather
> seemed like cfg didn't read the mail past the subject line.

As someone who have certainly read the patch, I can assure you that
Chris's question didn't sound like it was answered in the comment.
Please consider the possibility that you didn't express yourself
clearly enough in that comment, rather than that people don't read
your mail before asking questions.

Re: make attaching to stopped processes work under windows

[Oswald Buddenhagen]

On Fri, Feb 27, 2009 at 07:44:14PM -0500, Christopher Faylor wrote:
> On Thu, Feb 26, 2009 at 08:25:52PM +0100, Oswald Buddenhagen wrote:
> > 
>

> Do you actually have a use cause that requires attaching to suspended
> threads?
>
> > +	 This is primarily meant to cover the case where someone
> > +	 creates a process in suspended state and hands it over
> > +	 to gdb

do you need a use case for that use case? or do i need to explain the
concept?

> Suspending random threads like this is usually a bad idea.
>
> > +	 Note that we are not trying to handle multi-threaded
> > +	 situations, as these are likely to be too complex anyway.

i think that makes it sufficiently clear that i have considered the
risks.

On Mon, Mar 02, 2009 at 09:17:50PM +0200, Eli Zaretskii wrote:
> As someone who have certainly read the patch, I can assure you that
> Chris's question didn't sound like it was answered in the comment.
>
well, then i would be thankful for questions that somehow indicate what
is missing from the comment or why it is entirely irrelevant. i made an
assertion and expect it to be discussed, not ignored. what cgf did
left me with a blank stare and i find *that* rude towards me.

Re: make attaching to stopped processes work under windows

[Eli Zaretskii]

> Date: Mon, 2 Mar 2009 20:56:25 +0100
> From: Oswald Buddenhagen <oswald.buddenhagen@trolltech.de>
> 
> > As someone who have certainly read the patch, I can assure you that
> > Chris's question didn't sound like it was answered in the comment.
> >
> well, then i would be thankful for questions that somehow indicate what
> is missing from the comment or why it is entirely irrelevant.

It is not irrelevant, but its wording is obscure and unclear, at least
to me.  The full comment reads:

  +      /* Resume main thread if we are attaching to a suspended
  +	 process.
  +	 Note that we are not trying to handle multi-threaded
  +	 situations, as these are likely to be too complex anyway.
  +	 This is primarily meant to cover the case where someone
  +	 creates a process in suspended state and hands it over
  +	 to gdb (this is an abstraction - you cannot actually do
  +	 that due to Windows bugs. You need to start debugging the
  +	 process yourself, and once it has started up, you suspend
  +	 it and detach from it). */

Perhaps I read this too naively, but note how you first seem to
describe a use-case:

    This is primarily meant to cover the case where someone
    creates a process in suspended state and hands it over
    to gdb

but then immediately say that it cannot be done:

    this is an abstraction - you cannot actually do
    that due to Windows bugs.

After reading this, I already become confused.

    You need to start debugging the process yourself,
    and once it has started up, you suspend it and detach from it

And now I'm _really_ confused: ``detach''? didn't you say ``attach''
above? why detach from a process if you want to debug it?

Of course, Chris knows much more than I do about debugging on Windows,
so perhaps his difficulty with your concept was different and more
deep.  I will let him speak for himself.

> i made an assertion and expect it to be discussed, not ignored.

When your assertions are not clearly worded, it is customary to ask
questions.  Asking questions is not ignoring; quite the opposite: it
means your work is of interest and of importance.

> what cgf did left me with a blank stare and i find *that* rude
> towards me.

I find nothing rude in Chris's question.

Re: make attaching to stopped processes work under windows

[Christopher Faylor]

On Mon, Mar 02, 2009 at 11:21:20PM +0200, Eli Zaretskii wrote:
>> Date: Mon, 2 Mar 2009 20:56:25 +0100
>> From: Oswald Buddenhagen <oswald.buddenhagen@trolltech.de>
>> 
>> > As someone who have certainly read the patch, I can assure you that
>> > Chris's question didn't sound like it was answered in the comment.
>> >
>> well, then i would be thankful for questions that somehow indicate what
>> is missing from the comment or why it is entirely irrelevant.
>
>It is not irrelevant, but its wording is obscure and unclear, at least
>to me.  The full comment reads:
>
>  +      /* Resume main thread if we are attaching to a suspended
>  +	 process.
>  +	 Note that we are not trying to handle multi-threaded
>  +	 situations, as these are likely to be too complex anyway.
>  +	 This is primarily meant to cover the case where someone
>  +	 creates a process in suspended state and hands it over
>  +	 to gdb (this is an abstraction - you cannot actually do
>  +	 that due to Windows bugs. You need to start debugging the
>  +	 process yourself, and once it has started up, you suspend
>  +	 it and detach from it). */
>
>Perhaps I read this too naively, but note how you first seem to
>describe a use-case:
>
>    This is primarily meant to cover the case where someone
>    creates a process in suspended state and hands it over
>    to gdb
>
>but then immediately say that it cannot be done:
>
>    this is an abstraction - you cannot actually do
>    that due to Windows bugs.
>
>After reading this, I already become confused.
>
>    You need to start debugging the process yourself,
>    and once it has started up, you suspend it and detach from it
>
>And now I'm _really_ confused: ``detach''? didn't you say ``attach''
>above? why detach from a process if you want to debug it?
>
>Of course, Chris knows much more than I do about debugging on Windows,
>so perhaps his difficulty with your concept was different and more
>deep.  I will let him speak for himself.

Thanks, Eli.  You're right.  Part of my concern about the patch was that
I didn't understand the comment.

I thought I would get to that when I understood when and why someone
would start a process in a suspended state and then want to debug it.
In my definition of "use case", you don't just theorize that something
could be done, you explain that "Package X does this all of the time
because of Y and that makes it hard for me to debug things."  You don't
just assert that you want to change the code because it is theoretically
possible.

Once the "use case" was explained, I thought I would try to remember why
I had rejected a concept like this in Cygwin many years ago and see if
this was related.  I know that I had many problems when I arbitrarily
suspeded processes, especially on older versions of Windows.

cgf

Re: make attaching to stopped processes work under windows

[Christopher Faylor]

On Mon, Mar 02, 2009 at 07:28:26PM +0100, Oswald Buddenhagen wrote:
>On Mon, Mar 02, 2009 at 09:23:05AM -0800, Joel Brobecker wrote:
>>As far as I am concerned, if I question the purpose of a patch, why
>>would I waste time looking at the patch itself?
>
>because i pointed out that it would be necessary?  because somebody who
>knows the code certainly would know that the expected size of the patch
>would not justify writing a mail rather than simply having a look at
>it?

I trimmed your message in my response because trimming unnecessary
content is considered a polite thing to do when responding to email.

cgf

Re: make attaching to stopped processes work under windows

[Oswald Buddenhagen]

> On Mon, Mar 02, 2009 at 11:21:20PM +0200, Eli Zaretskii wrote:
> >Perhaps I read this too naively, but note how you first seem to
> >describe a use-case:
> >
> >    This is primarily meant to cover the case where someone
> >    creates a process in suspended state and hands it over
> >    to gdb
> >
> >but then immediately say that it cannot be done:
> >
> >    this is an abstraction - you cannot actually do
> >    that due to Windows bugs.
> >
i don't see how this says it cannot be done. it says you can arrive at
the desired result only by going through additional hoops.

> >After reading this, I already become confused.
> >
> >    You need to start debugging the process yourself,
> >    and once it has started up, you suspend it and detach from it
> >
> >And now I'm _really_ confused: ``detach''? didn't you say ``attach''
> >above? why detach from a process if you want to debug it?
> >
i think the meaning is rather clear when you unnest the sentences
properly; the grammar doesn't leave much room for differing
interpretations. but i accept your request to use simpler language. ;)

On Tue, Mar 03, 2009 at 12:21:30AM -0500, Christopher Faylor wrote:
> In my definition of "use case", you don't just theorize that something
> could be done, you explain that "Package X does this all of the time
> because of Y and that makes it hard for me to debug things."  You don't
> just assert that you want to change the code because it is theoretically
> possible.
> 
well, to me, the idea of being able to attach to a suspended process
seems to have enough merit of its own. after all, why should it matter
whether the process is suspended in the first place?
anyway, i use that to implement a "debug in separate terminal" mode. for
that, i launch a stub with controlled process flags. that stub launches
the debuggee. for gdb to be able to attach to it without a race, the
debuggee needs to be launched in suspended state. once the debuggee
ends, the stub prints a "enter to continue" message, waits and
terminates.
i chose this approach because it is congruent with the xterm + stub
approach i use under unix, so it makes the code quite nice. also, it
seems less scary than using gdb's somewhat fragile (*) shell hack to
start the stub within gdb itself.

(*) if i understood anything, this thing must get confused if the
debuggee launches child processes itself.

> Once the "use case" was explained, I thought I would try to remember
> why I had rejected a concept like this in Cygwin many years ago and
> see if this was related.  I know that I had many problems when I
> arbitrarily suspeded processes, especially on older versions of
> Windows.
> 
but you realize that attaching *is* suspending, not only logically, but
also "physically" (observe the thread suspend count comparison in my
patch)? and given my description of the obscure workaround necessary to
create an "attachable" suspended process you certainly can imagine that
i had my "fun" with "arbitrarily suspended processes". :}  i still
concluded that this case is "safe". fwiw, given that the "startup hack"
works only with WinXP+ (now, you wouldn't expect detaching to be
something M$ would implement before 2003, right?), "older" windows
versions are not particularly interesting to me anyway.

Re: make attaching to stopped processes work under windows

[Christopher Faylor]

On Tue, Mar 03, 2009 at 01:05:04PM +0100, Oswald Buddenhagen wrote:
>On Tue, Mar 03, 2009 at 12:21:30AM -0500, Christopher Faylor wrote:
>>In my definition of "use case", you don't just theorize that something
>>could be done, you explain that "Package X does this all of the time
>>because of Y and that makes it hard for me to debug things." You don't
>>just assert that you want to change the code because it is
>>theoretically possible.
>>
>well, to me, the idea of being able to attach to a suspended process
>seems to have enough merit of its own.  after all, why should it matter
>whether the process is suspended in the first place?

Because you may be debugging a situation where you want precise control
over the process's suspend count.  The process may be suspended for
reasons other than the way that you are specifically using it.

For instance, if this code was invoked at the wrong time on a cygwin
process it could screw up cygwin's signal handling which tries to (very
carefully) use SuspendThread/SetThreadContext/ResumeThread to send
signals when running in user code.

>anyway, i use that to implement a "debug in separate terminal" mode.
>for that, i launch a stub with controlled process flags.  that stub
>launches the debuggee.  for gdb to be able to attach to it without a
>race, the debuggee needs to be launched in suspended state.  once the
>debuggee ends, the stub prints a "enter to continue" message, waits and
>terminates.

Thank you for explaining.

Unfortunately, I am not comfortable accepting this patch as is.  I would
consider a variation of the patch which implemented either a command line
option (assuming that the rest of the gdb developers agree) or a gdb
command ("set always-resume-thread on"?) so that this behavior was not
the default, however.

This would mean that you'd need to have an assignment on file with the
FSF so if you are willing to pursue that alternative it would make sense
to start that process ASAP.

(I'm hoping that someone will provide you with a pointer to the necessary
paperwork since I don't have it handy right now)

cgf

Re: make attaching to stopped processes work under windows

[Joel Brobecker]

> (I'm hoping that someone will provide you with a pointer to the necessary
> paperwork since I don't have it handy right now)

I do - Anyone interested in starting the copyright assignment process
can send me an email and I'll send the reqest form.

-- 
Joel

Re: make attaching to stopped processes work under windows

[Oswald Buddenhagen]

[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]

On Sun, Mar 08, 2009 at 03:32:33PM -0400, Christopher Faylor wrote:
> On Tue, Mar 03, 2009 at 01:05:04PM +0100, Oswald Buddenhagen wrote:
> >after all, why should it matter
> >whether the process is suspended in the first place?
> 
> Because you may be debugging a situation where you want precise control
> over the process's suspend count.  The process may be suspended for
> reasons other than the way that you are specifically using it.
> 
the bad news is that gdb simply hangs without my patch, so your
situation is rather hypothetical.
i guess the right fix (if at all possible) would be making it not hang
and resume the thread from the outside once gdb reports success. but
investigating that is way beyond what my employer is likely willing to
pay for.
if you feel like debugging it, just compile the attachment and run it
like

  process_stub_win debug <somefile> "" "" notepad "press enter..."

then read the pid from <somefile> and use it to attach gdb.

> This would mean that you'd need to have an assignment on file with the
> FSF so if you are willing to pursue that alternative it would make
> sense to start that process ASAP.
> 
i'm covered, the process is rolling (or rather, crawling uphill) for a
few months now ...

[-- Attachment #2: process_stub_win.c --]
[-- Type: text/x-csrc, Size: 6666 bytes --]

/***************************************************************************
**
** This file is part of Qt Creator
**
** Copyright (c) 2008-2009 Nokia Corporation and/or its subsidiary(-ies).
**
** Contact:  Qt Software Information (qt-info@nokia.com)
**
**
** Non-Open Source Usage
**
** Licensees may use this file in accordance with the Qt Beta Version
** License Agreement, Agreement version 2.2 provided with the Software or,
** alternatively, in accordance with the terms contained in a written
** agreement between you and Nokia.
**
** GNU General Public License Usage
**
** Alternatively, this file may be used under the terms of the GNU General
** Public License versions 2.0 or 3.0 as published by the Free Software
** Foundation and appearing in the file LICENSE.GPL included in the packaging
** of this file.  Please review the following information to ensure GNU
** General Public Licensing requirements will be met:
**
** http://www.fsf.org/licensing/licenses/info/GPLv2.html and
** http://www.gnu.org/copyleft/gpl.html.
**
** In addition, as a special exception, Nokia gives you certain additional
** rights. These rights are described in the Nokia Qt GPL Exception
** version 1.3, included in the file GPL_EXCEPTION.txt in this package.
**
***************************************************************************/

#define _WIN32_WINNT 0x0501 /* WinXP, needed for DebugActiveProcessStop() */

#include <windows.h>
#include <string.h>
#include <stdio.h>
#include <errno.h>
#include <direct.h>

static FILE *qtcFd;
static wchar_t *sleepMsg;

/* Print some "press enter" message, wait for that, exit. */
static void doExit(int code)
{
    char buf[2];
    _putws(sleepMsg);
    fgets(buf, 2, stdin); /* Minimal size to make it wait */
    exit(code);
}

/* Print an error message for unexpected Windows system errors, wait, exit. */
static void systemError(const char *str)
{
    fprintf(stderr, str, GetLastError());
    doExit(3);
}

/* Send a message to the master. */
static void sendMsg(const char *msg, int num)
{
    int pidStrLen;
    char pidStr[64];

    pidStrLen = sprintf(pidStr, msg, num);
    if (fwrite(pidStr, pidStrLen, 1, qtcFd) != 1 || fflush(qtcFd)) {
        fprintf(stderr, "Cannot write to creator comm socket: %s\n",
                strerror(errno));
        doExit(3);
    }
}

/* Ignore the first ctrl-c/break within a second. */
static BOOL WINAPI ctrlHandler(DWORD dwCtrlType)
{
    static ULARGE_INTEGER lastTime;
    ULARGE_INTEGER thisTime;
    SYSTEMTIME sysTime;
    FILETIME fileTime;

    if (dwCtrlType == CTRL_C_EVENT || dwCtrlType == CTRL_BREAK_EVENT) {
        GetSystemTime(&sysTime);
        SystemTimeToFileTime(&sysTime, &fileTime);
        thisTime.LowPart = fileTime.dwLowDateTime;
        thisTime.HighPart = fileTime.dwHighDateTime;
        if (lastTime.QuadPart + 10000000 < thisTime.QuadPart) {
            lastTime.QuadPart = thisTime.QuadPart;
            return TRUE;
        }
    }
    return FALSE;
}

enum {
    ArgCmd = 0,
    ArgAction,
    ArgSocket,
    ArgDir,
    ArgEnv,
    ArgCmdLine,
    ArgMsg,
    ArgCount
};

/* syntax: $0 {"run"|"debug"} <pid-socket> <workdir> <env-file> <cmdline> <continuation-msg> */
/* exit codes: 0 = ok, 1 = invocation error, 3 = internal error */
int main()
{
    int argc;
    int creationFlags;
    wchar_t **argv;
    wchar_t *env = 0;
    STARTUPINFOW si;
    PROCESS_INFORMATION pi;
    DEBUG_EVENT dbev;

    argv = CommandLineToArgvW(GetCommandLine(), &argc);

    if (argc != ArgCount) {
        fprintf(stderr, "This is an internal helper of Qt Creator. Do not run it manually.\n");
        return 1;
    }
    sleepMsg = argv[ArgMsg];

    /* Connect to the master, i.e. Creator. */
    if (!(qtcFd = _wfopen(argv[ArgSocket], L"w"))) {
        fprintf(stderr, "Cannot connect creator comm pipe %S: %s\n",
                argv[ArgSocket], strerror(errno));
        doExit(1);
    }

    if (*argv[ArgDir] && !SetCurrentDirectoryW(argv[ArgDir])) {
        /* Only expected error: no such file or direcotry */
        sendMsg("err:chdir %d\n", GetLastError());
        return 1;
    }

    if (*argv[ArgEnv]) {
        FILE *envFd;
        long size;
        if (!(envFd = _wfopen(argv[ArgEnv], L"r"))) {
            fprintf(stderr, "Cannot read creator env file %S: %s\n",
                    argv[ArgEnv], strerror(errno));
            doExit(1);
        }
        fseek(envFd, 0, SEEK_END);
        size = ftell(envFd);
        rewind(envFd);
        env = malloc(size);
        if (fread(env, 1, size, envFd) != size) {
            perror("Failed to read env file");
            doExit(1);
        }
        fclose(envFd);
    }

    ZeroMemory(&pi, sizeof(pi));
    ZeroMemory(&si, sizeof(si));
    si.cb = sizeof(si);

    creationFlags = CREATE_UNICODE_ENVIRONMENT;
    if (!wcscmp(argv[ArgAction], L"debug"))
        creationFlags |= DEBUG_ONLY_THIS_PROCESS;
    if (!CreateProcessW(0, argv[ArgCmdLine], 0, 0, FALSE, creationFlags, env, 0, &si, &pi)) {
        /* Only expected error: no such file or direcotry, i.e. executable not found */
        sendMsg("err:exec %d\n", GetLastError());
        doExit(1);
    }

    /* This is somewhat convoluted. What we actually want is creating a
       suspended process and letting gdb attach to it. Unfortunately,
       the Windows kernel runs amok when we attempt this.
       So instead we start a debugged process, eat all the initial
       debug events, suspend the process and detach from it. If gdb
       tries to attach *now*, everthing goes smoothly. Yay. */
    if (creationFlags & DEBUG_ONLY_THIS_PROCESS) {
        do {
            if (!WaitForDebugEvent (&dbev, INFINITE))
                systemError("Cannot fetch debug event, error %d\n");
            if (dbev.dwDebugEventCode == EXCEPTION_DEBUG_EVENT) {
                /* The first exception to be delivered is a trap
                   which indicates completion of startup. */
                if (SuspendThread(pi.hThread) == (DWORD)-1)
                    systemError("Cannot suspend debugee, error %d\n");
            }
            if (!ContinueDebugEvent(dbev.dwProcessId, dbev.dwThreadId, DBG_CONTINUE))
                systemError("Cannot continue debug event, error %d\n");
        } while (dbev.dwDebugEventCode != EXCEPTION_DEBUG_EVENT);
        if (!DebugActiveProcessStop(dbev.dwProcessId))
            systemError("Cannot detach from debugee, error %d\n");
    }

    SetConsoleCtrlHandler(ctrlHandler, TRUE);

    sendMsg("pid %d\n", pi.dwProcessId);

    if (WaitForSingleObject(pi.hProcess, INFINITE) == WAIT_FAILED)
        systemError("Wait for debugee failed, error %d\n");
    doExit(0);
    return 0;
}

Re: make attaching to stopped processes work under windows

[Christopher Faylor]

On Mon, Mar 09, 2009 at 09:52:19PM +0100, Oswald Buddenhagen wrote:
>On Sun, Mar 08, 2009 at 03:32:33PM -0400, Christopher Faylor wrote:
>>On Tue, Mar 03, 2009 at 01:05:04PM +0100, Oswald Buddenhagen wrote:
>>>after all, why should it matter whether the process is suspended in the
>>>first place?
>>
>>Because you may be debugging a situation where you want precise control
>>over the process's suspend count.  The process may be suspended for
>>reasons other than the way that you are specifically using it.
>>
>>For instance, if this code was invoked at the wrong time on a cygwin
>>process it could screw up cygwin's signal handling which tries to (very
>>carefully) use SuspendThread/SetThreadContext/ResumeThread to send
>>signals when running in user code.
>
>the bad news is that gdb simply hangs without my patch, so your
>situation is rather hypothetical.

I assure you that Cygwin is not hypothetical.  It really does exist.  I
provided you with a specific example so that you would see that this
wasn't hypothetical.

cgf

Re: make attaching to stopped processes work under windows

[Oswald Buddenhagen]

On Mon, Mar 09, 2009 at 10:45:13PM -0400, Christopher Faylor wrote:
> On Mon, Mar 09, 2009 at 09:52:19PM +0100, Oswald Buddenhagen wrote:
> >the bad news is that gdb simply hangs without my patch, so your
> >situation is rather hypothetical.
> 
> I assure you that Cygwin is not hypothetical.  It really does exist.  I
> provided you with a specific example so that you would see that this
> wasn't hypothetical.
> 
and i provided you with a specific explanation why actually _debugging
this with current gdb_ *is* hypothetical. ;)
all i'm saying is that the patch doesn't make things worse, at least
with mingw - i have no idea in how far gdb/cygwin has the same problem -
feel free to verify. once the real problem is fixed, the patch should
become superfluous in the first place. so yes, obviously it is only a
workaround. unfortunately, i don't have the time and motivation to
investigate it properly.

greetings