From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22263 invoked by alias); 19 Jul 2010 15:36:17 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 22239 invoked by uid 22791); 19 Jul 2010 15:36:15 -0000 X-SWARE-Spam-Status: No, hits=-6.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Date: Mon, 19 Jul 2010 15:36:00 -0000 From: Oleg Nesterov To: archer@sourceware.org Cc: Roland McGrath Subject: Re: BUG: add_thread_silent()->switch_to_thread(minus_one_ptid) is wrong Message-ID: <20100719153400.GA18789@redhat.com> References: <20100716205147.GA26313@redhat.com> <20100719134135.GA13763@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100719134135.GA13763@redhat.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SW-Source: 2010-q3/txt/msg00037.txt.bz2 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.