From: Bernardo Innocenti <email address hidden>
To: Daniel Jacobowitz <email address hidden>
Cc: <email address hidden>
Subject: Re: gdb/2238: assertion failure in linux_nat_attach() when attaching
to a hung Xorg instance
Date: Wed, 07 Mar 2007 18:29:21 +0100
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Daniel Jacobowitz wrote:
> Do you get the same results if you use an FSF GDB? I don't know if
> any of the patches Red Hat applies affect this.
Yes, I've rebuilt from gdb's CVS HEAD, hit the same assertion
failure, then removed the assertion to see if gdb could run
anyway (and it did).
>> Maybe Xorg also does something weird with signal masks. This is the stack backtrace I get if I rebuild gdb
>> without the assertion:
>
> Could you check which bit of the assertion failed, and how so?
> Probably the wait status is something unusual.
I can't restart the debug session now because the X server
is now running fine, but I did some tests and I remember
these facts:
pid == GET_PID (inferior_ptid)
This bit was definitely true
&& WIFSTOPPED (status)
This was also true
&& (WSTOPSIG (status) == SIGSTOP
I think this wasn't true, but I don't know what the signal
number was in the debug session for which I provided the
stack trace.
In a different debug session, its value was 29 (SIGIO),
which the X server actually uses to handle protocol
requests.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
From: Bernardo Innocenti <email address hidden>
To: Daniel Jacobowitz <email address hidden>
Cc: <email address hidden>
Subject: Re: gdb/2238: assertion failure in linux_nat_attach() when attaching
to a hung Xorg instance
Date: Wed, 07 Mar 2007 18:29:21 +0100
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Daniel Jacobowitz wrote:
> Do you get the same results if you use an FSF GDB? I don't know if
> any of the patches Red Hat applies affect this.
Yes, I've rebuilt from gdb's CVS HEAD, hit the same assertion
failure, then removed the assertion to see if gdb could run
anyway (and it did).
>> Maybe Xorg also does something weird with signal masks. This is the stack backtrace I get if I rebuild gdb
>> without the assertion:
>
> Could you check which bit of the assertion failed, and how so?
> Probably the wait status is something unusual.
I can't restart the debug session now because the X server
is now running fine, but I did some tests and I remember
these facts:
pid == GET_PID (inferior_ptid)
This bit was definitely true
&& WIFSTOPPED (status)
This was also true
&& (WSTOPSIG (status) == SIGSTOP
I think this wasn't true, but I don't know what the signal
number was in the debug session for which I provided the
stack trace.
In a different debug session, its value was 29 (SIGIO),
which the X server actually uses to handle protocol
requests.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFF7vZxxF EDB3H/S6wRApXGA JoCJGewaZJ9384d 5Iv9xW8pJDj6pQC fWynK 3cQNsqZDA=
YLg+l7FPpSrD3+
=45sh
-----END PGP SIGNATURE-----