This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

gdb hangs on ^Z [was: Re: 64-bit gdb: invalid decimal " 0x22DBF0"]

On 29/07/2013 7:06 AM, Corinna Vinschen wrote:
On Jul 27 11:30, Daniel Brown wrote:
I have also ran into this problem, in my case though I have managed
to reduce the issue down to an fgets call when reading a pipe.
The following code causes the issue for me if I try and debug it:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char** argv) {
     char out[100] = {0};
     FILE *pipe;

     if ((pipe = popen("uname -r", "rt")) == NULL)
         fprintf(stderr,"Failed to execute popen command");

     if(fgets(out, 100, pipe) == NULL)
         fprintf(stderr,"Failed to read popen buffer");

     printf("%s\n", out);


     return (EXIT_SUCCESS);

I compile with `gcc -g main.c` then `gdb a.exe` and type `run`, the
error `invalid decimal " 0x23DBF0"` then pops up.
I have tried the latest snapshot cygwin1.dll (1.7.23s(0.268/5/3))
and the error is still there.
This is a problem in GDB, not in the Cygwin DLL.  My mistake.  I fetched
the official 7.6 version of GDB since it already contained Cygwin x86_64
support so I thought it's sufficient.  Unfortunately it doesn't handle
special Cygwin strings in terms of Cygwin signal handling correctly.

I'm just uploading a gdb-7.6.50 version build from current CVS which
should fix this.
Confirmed that this problem is fixed [1]... however, my original STC still hangs because gdb somehow interferes with the choreography of SIGTSTP between victim and its owning shell.

With default signal handling (SIGTSTP stop print pass) gdb breaks in when the victim receives ^Z, but both gdb and the victim hang once gdb continues; gdb cannot be interrupted with ^C [2]. Killing gdb allows the victim to finish backgrounding itself, apparently none the worse for wear.

With handle SIGTSTP nostop noprint pass, gdb doesn't break in any more, but both gdb and the victim still hang on ^Z. This time, killing gdb also silently kills the app, with the shell reporting exit code 0 and no job completion notice (presumably because the victim didn't finish backgrounding itself before being killed).

Running under linux/gdb, the STC behaves as expected, breaking in after the shell reports that the victim has backgrounded. You'd want to nostop SIGTSTP, SIGTTIN and SIGCONT to keep the debugger from getting underfoot, though.

(changing the subject line to reflect the new issue, since it's probably not directly related to the original problem)

[1] BTW, did you intend for a gdb release announcement to go out? None came that I can see, though the mirrors seem to have picked it up. [2] As usual, gdb only breaks in response to ^C if you invoke it directly from cmd.exe, but the above hang causes it to ignore ^C even then.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]