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);
pclose(pipe);
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).
Thanks
Ryan
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 64-bit gdb: invalid decimal 0x22DBF0
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);
pclose(pipe);
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.
Thanks for the reports,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
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);
pclose(pipe);
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.
Ryan
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gdb hangs on ^Z [was: Re: 64-bit gdb: invalid decimal 0x22DBF0]
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);
pclose(pipe);
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.
[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.
No. Next time I will.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gdb hangs on ^Z [was: Re: 64-bit gdb: invalid decimal 0x22DBF0]
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);
pclose(pipe);
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.
Ryan
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gdb hangs on ^Z [was: Re: 64-bit gdb: invalid decimal 0x22DBF0]
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);
pclose(pipe);
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
Ryan
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 64-bit gdb: invalid decimal 0x22DBF0
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);
pclose(pipe);
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.
Thanks,
Daniel
On 27/07/2013 04:29, Ryan Johnson wrote:
Hi all,
The latest 64-bit gdb/cygwin combo chokes whenever a process it has
attached to is backgrounded (and also if it blocks on I/O, I think).
To repro with the attached STC:
1. gcc -g bug.c ./a
prints its PID
2. gdb -p PID
3. Continue gdb
4. ^Z the STC
5. STC freezes, gdb gets confused.
An example gdb session is below. Note that, in spite of gdb thinking
the threads are all running, the victim is actually frozen; once this
happens, the only option is to detach from the process.
(gdb) attach 2468
Attaching to program `/home/Ryan/experiments/a.exe', process 3536
[New Thread 3536.0x1134]
[New Thread 3536.0x1284]
[New Thread 3536.0x13e4]
Reading symbols from /home/Ryan/experiments/a.exe...done.
(gdb) c
Continuing.
invalid decimal 0x22DBF0
(gdb) c
Continuing.
Cannot execute this command without a live selected thread.
(gdb) i th
Id Target Id Frame
2Thread 3536.0x1284 (running)
1Thread 3536.0x1134 (running)
The current thread Thread ID 3 has terminated. See `help thread'.
(gdb) t 1
[Switching to thread 1 (Thread 3536.0x1134)](running)
(gdb) c
Continuing.
Cannot execute this command while the selected thread is running.
(gdb) detach
Detaching from program: /home/Ryan/experiments/a.exe, Pid 3536
(gdb)
I first discovered this trying to debug emacs, where I/O and perhaps
other events sometimes also cause the same invalid decimal to pop up
and freeze the program. I'm not sure how to repro those other cases, tho.
Thoughts?
Ryan
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 64-bit gdb: invalid decimal 0x22DBF0
On 27/07/2013 6:30 AM, 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: STC snipped That STC let me get a stack trace of gdb: #0 write (fd=2, ptr=ptr@entry=0x600298c70, len=len@entry=27) at /usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/syscalls.cc:1215 #1 0x0001801aef93 in _write_r (ptr=ptr@entry=0xc2d440, fd=optimized out, buf=buf@entry=0x600298c70, cnt=cnt@entry=27) at /usr/src/debug/cygwin-1.7.22-1/newlib/libc/reent/writer.c:58 #2 0x00018019c2bf in __swrite64 (ptr=0xc2d440, cookie=0x1801cb608 reent_data+1704, buf=0x600298c70 invalid decimal \ 0x22DBF0\, n=27) at /usr/src/debug/cygwin-1.7.22-1/newlib/libc/stdio64/stdio64.c:71 #3 0x00018019bc00 in __sfvwrite_r (ptr=ptr@entry=0xc2d440, fp=fp@entry=0x1801cb608 reent_data+1704, uio=uio@entry=0xc2a690) at /usr/src/debug/cygwin-1.7.22-1/newlib/libc/stdio/fvwrite.c:97 #4 0x0001801752e4 in _fputs_r (ptr=0xc2d440, s=optimized out, fp=0x1801cb608 reent_data+1704) at /usr/src/debug/cygwin-1.7.22-1/newlib/libc/stdio/fputs.c:94 #5 0x0001801130cb in _sigfe () from /usr/bin/cygwin1.dll ... ten frames of garbage... #15 0x000100513f7a in print_exception (file=0x60017c920, file@entry=0x0, e=...) at /usr/src/debug/gdb-7.6-2/gdb/exceptions.c:303 #16 0x0001005144e4 in exception_print (file=0x0, e=...) at /usr/src/debug/gdb-7.6-2/gdb/exceptions.c:333 #17 0x00010051c8bc in start_event_loop () at /usr/src/debug/gdb-7.6-2/gdb/event-loop.c:435 #18 0x0001005160c6 in captured_command_loop (data=data@entry=0x0) at /usr/src/debug/gdb-7.6-2/gdb/main.c:258 #19 0x00010051484a in catch_errors ( func=func@entry=0x1005160b0 captured_command_loop, func_args=func_args@entry=0x0, errstring=errstring@entry=0x100753ea3 __PRETTY_FUNCTION__.13175+221 , mask=mask@entry=6) at /usr/src/debug/gdb-7.6-2/gdb/exceptions.c:546 #20 0x000100516f7d in captured_main (data=data@entry=0xc2aaa0) at /usr/src/debug/gdb-7.6-2/gdb/main.c:1041 #21 0x00010051484a in catch_errors ( func=func@entry=0x1005163a0 captured_main, func_args=func_args@entry=0xc2aaa0, errstring=errstring@entry=0x100753ea3 __PRETTY_FUNCTION__.13175+221 , mask=mask@entry=6) at /usr/src/debug/gdb-7.6-2/gdb/exceptions.c:546 #22 0x0001005174ec in gdb_main (args=args@entry=0xc2aaa0) at /usr/src/debug/gdb-7.6-2/gdb/main.c:1050 #23 0x0001006e0721 in main (argc=2, argv=0xc2ab20) at /usr/src/debug/gdb-7.6-2/gdb/gdb.c:34 Maybe that will help? Ryan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
64-bit gdb: invalid decimal 0x22DBF0
Hi all,
The latest 64-bit gdb/cygwin combo chokes whenever a process it has
attached to is backgrounded (and also if it blocks on I/O, I think). To
repro with the attached STC:
1. gcc -g bug.c ./a
prints its PID
2. gdb -p PID
3. Continue gdb
4. ^Z the STC
5. STC freezes, gdb gets confused.
An example gdb session is below. Note that, in spite of gdb thinking the
threads are all running, the victim is actually frozen; once this
happens, the only option is to detach from the process.
(gdb) attach 2468
Attaching to program `/home/Ryan/experiments/a.exe', process 3536
[New Thread 3536.0x1134]
[New Thread 3536.0x1284]
[New Thread 3536.0x13e4]
Reading symbols from /home/Ryan/experiments/a.exe...done.
(gdb) c
Continuing.
invalid decimal 0x22DBF0
(gdb) c
Continuing.
Cannot execute this command without a live selected thread.
(gdb) i th
Id Target Id Frame
2Thread 3536.0x1284 (running)
1Thread 3536.0x1134 (running)
The current thread Thread ID 3 has terminated. See `help thread'.
(gdb) t 1
[Switching to thread 1 (Thread 3536.0x1134)](running)
(gdb) c
Continuing.
Cannot execute this command while the selected thread is running.
(gdb) detach
Detaching from program: /home/Ryan/experiments/a.exe, Pid 3536
(gdb)
I first discovered this trying to debug emacs, where I/O and perhaps
other events sometimes also cause the same invalid decimal to pop up
and freeze the program. I'm not sure how to repro those other cases, tho.
Thoughts?
Ryan
#include stdio.h
#include unistd.h
int main() {
int c;
printf(pid: %d\n, getpid());
while ( (c=getchar()) 0 )
printf(Received \\%03o\n, c);
return 0;
}
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
