This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
Re: pending/2262:Subject=Re%3A%20gdb%2F2238%3A%20assertion%20failure%20in%20linux_nat_attach%28%29%20when%20attaching%20to%20a%20hung%20Xorg%20instance
- From: Juergen Leising <juergen dot leising at gmx dot de>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 20 May 2007 18:28:01 -0000
- 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
- Reply-to: 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