Re: pending/2262:Subject=Re%3A%20gdb%2F2238%3A%20assertion%20failure%20in%20linux_nat_attach%28%29%20when%20attaching%20to%20a%20hung%20Xorg%20instance

[Juergen Leising <juergen dot leising at gmx dot de>]

The following reply was made to PR pending/2262; it has been noted by GNATS.

From: Juergen Leising <juergen.leising@gmx.de>
To: gdb-gnats@sources.redhat.com
Cc:  
Subject: Re: pending/2262:
	Subject=Re%3A%20gdb%2F2238%3A%20assertion%20failure%20in%20linux_nat_attach%28%29%20when%20attaching%20to%20a%20hung%20Xorg%20instance
Date: Sun, 20 May 2007 20:21:32 +0200

 > Did you try to resume the program from the GDB that valgrind launched?
 
 Oh yes, I did. And valgrind reported almost immediately, 
 that gdb had detached. Valgrind went on doing its work, 
 reporting further errors, offering me gdb attaching
 and so on. 
 
 I have used this feature for two or three years now. 
 Quite invaluable, I must say:
 Often a SIGSEGV, caused by an invalid write, is actually introduced
 by two or three invalid reads or undefined variables and so on, that
 do not necessarily lead to a crash. So when valgrind provides you
 with an opportunity to look into the stack at this early stage,
 this is very helpful for you, as you can see, how a memory problem
 is in the process of unfolding itself. Curing the very first
 error often solves everything else.
 
 > Valgrind doesn't allow that; GDB is only seeing a mockup of the
 > process, if I understand correctly.
 
 Well, the process image gdb sees under "normal" circumstances may 
 differ a little bit from what it sees when it is called by gdb - but
 not very much. Valgrind does indeed not really simulate each single
 opcode one after the other. Instead, it uses basic blocks and has
 a jitter doing the translation at that level. It is not a 100 %
 simulator, but maybe 99 %. And that's enough for most of us :-)
 
 Above all, you can have your "usual" look at local variables, 
 arguments, different stack frames. At this early stage finding 
 a wrong or unexpected value is easier than
 later, when all kinds of consequences out of that
 error have already been drawn and the core dump finally gets 
 generated.
 
 Now, in the mean time I have not tried much. gdb-6.5, 6.6 and
 6.6.50.20070515 all triggered this assertion in linux-nat.c, whereas
 gdb-6.3 works perfectly. All of that under valgrind 3.2.2 (rpm) and
 valgrind-3.2.3 (tar.bz2). 
 
 I inserted the following lines into all of these
 versions right before the assertion line:
 
 warning (_("%s:%i: pid = %i"), __FILE__, __LINE__, pid);
   warning (_("%s:%i: inferior_ptid = %i"), __FILE__, __LINE__,
 inferior_ptid.pid);
   warning (_("%s:%i: GET_PID (inferior_ptid) = %i"), __FILE__, __LINE__,
 GET_PID (inferior_ptid));
   warning (_("%s:%i: status = %i"), __FILE__, __LINE__, status);
   warning (_("%s:%i: WIFSTOPPED(status) = %i"), __FILE__, __LINE__,
 WIFSTOPPED(status));
   warning (_("%s:%i: WSTOPSIG(status) = %i"), __FILE__, __LINE__,
 WSTOPSIG(status));
   warning (_("%s:%i: SIGSTOP = %i"), __FILE__, __LINE__, SIGSTOP);
 
 
 Under gdb-6.6 I got
 
 warning: linux-nat.c:980: pid = 18189
 
 warning: linux-nat.c:981: inferior_ptid = 18189
 
 warning: linux-nat.c:982: GET_PID (inferior_ptid) = 18189
 
 warning: linux-nat.c:983: status = 127
 
 warning: linux-nat.c:984: WIFSTOPPED(status) = 1
 
 warning: linux-nat.c:985: WSTOPSIG(status) = 0
 
 warning: linux-nat.c:986: SIGSTOP = 19
 
 
 
 Same under gdb-6.5. But under gdb-6.3 linux_nat_attach()
 was not even called.
 
 Best regards,
 
 Juergen
 
 
 P.S.: Sorry for that ruined subject line. That was my fault, when I just
 copied the mailto link into mutt, not changing anything. It should
 have been 
 
 Subject=Re: gdb/2238: assertion failure in linux_nat_attach() when attaching
 to a hung Xorg instance