This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: BUG: add_thread_silent()->switch_to_thread(minus_one_ptid) iswrong
On 07/19, Oleg Nesterov wrote:
>
> I am trying to change ugdb.c to multiprocess mode, and now
> I hit another bug in gdb.
>
> (gdb) target extended-remote /proc/ugdb
> (gdb) attach 980
> (gdb) info threads
>
> results in
>
> thread.c:880: internal-error: switch_to_thread: Assertion `inf != NULL' failed.
>
> Once again, I didn't see this problem in !multiprocess mode.
>
> The immediate reason is clear, add_thread_silent() calls
> switch_to_thread(minus_one_ptid), and find_inferior_pid(-1)
> obviously fails. I guess add_thread_silent() is buggy and
> should be fixed in any case.
Yes, this looks obviously wrong.
> But it is not clear to me what provokes this bug, gdb works
> with gdbserver but not with /proc/ugdb.
>
> Still investigaing...
Not sure my understanding is correct, and definitely it is not complete.
But, afaics. The bug is triggered because, unlike gdbserver, ugdb.ko
doesn't implement "$T..." command, it just replies "$#00" according to
For any COMMAND not supported by the stub, an empty response
(`$#00') should be returned.
from the docs.
However, gdb can't handle this case in multiprocess mode correctly.
update_thread_list()->prune_threads() treats this reply as not-alive
and calls delete_thread() which marks this THREAD_EXITED.
Later then update_thread_list() calls remote_notice_new_inferior()
and hits the "in_thread_list() && is_exited()" case, this implies
remote_add_thread()->add_thread_silent().
I still do not understand why this all works in !multiprocess mode,
but I give up. I added support for 'T' packet, the problem has gone
away.
Oleg.