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]

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

On 29/07/2013 3:27 PM, Ryan Johnson wrote:
On 29/07/2013 3:13 PM, Ryan Johnson wrote:
On 29/07/2013 3:11 PM, Corinna Vinschen wrote:
On Jul 29 12:01, Ryan Johnson wrote:
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.
I'm not sure if ^Z can reliably work in the GDB scenario. That's
Chris' domain, but AFAICS, the fact that GDB calls the inferior
process with CreateProcess, the job control facility of the shell
will be broken.
I'm talking about the case where gdb attaches to a running proccess... I don't know how you could ever handle ^Z in a process gdb started.
Just to be extra clear, the scenario is:
1. start STC in terminal A
2. start gdb in terminal B and attach it to the STC
3. type ^Z in terminal A
Is there something I can do to help move this along? It's making it hard to debug the sporadic emacs crashes I've been getting (turns out the same thing happens for SIGINT, so avoiding the temptation to hit ^Z isn't enough).


Problem reports:
Unsubscribe info:

Problem reports:
Unsubscribe info:

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