Re: BUG: add_thread_silent()->switch_to_thread(minus_one_ptid) is wrong

[Oleg Nesterov <oleg@redhat.com>]

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.