From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108143 invoked by alias); 12 May 2016 17:42:17 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 108116 invoked by uid 89); 12 May 2016 17:42:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=randomly X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 12 May 2016 17:42:14 +0000 Received: from svr-orw-fem-02x.mgc.mentorg.com ([147.34.96.206] helo=SVR-ORW-FEM-02.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1b0ucm-0002pU-JJ from Don_Breazeal@mentor.com ; Thu, 12 May 2016 10:42:12 -0700 Received: from [172.30.5.76] (147.34.91.1) by SVR-ORW-FEM-02.mgc.mentorg.com (147.34.96.168) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 12 May 2016 10:42:12 -0700 Subject: Re: RFH: failed assert debugging threaded+fork program over gdbserver To: Joel Brobecker , References: <20160512171650.GC26324@adacore.com> From: Don Breazeal Message-ID: <5734C06C.8040008@codesourcery.com> Date: Thu, 12 May 2016 17:42:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160512171650.GC26324@adacore.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-05/txt/msg00209.txt.bz2 On 5/12/2016 10:16 AM, Joel Brobecker wrote: > Hello, > > I have noticed the following problem, when debugging a program which > uses both threads and fork. The program is attached in copy, and > it was compiled by simply doing: > > % gnatmake -g a_test > > The issue appears only randomly, but it seems to show up fairly > reliably when using certain versions of GNU/Linux such as RHES7, > or WRSLinux. I also see it on Ubuntu, but less reliably. Here is > what I have found, debugging on WRSLinux (we set it up as a cross, > but it should be the same with native GNU/Linux distros): > > % gdb a_test > (gdb) break a_test.adb:30 > (gdb) break a_test.adb:39 > (gdb) target remote my_board:4444 > (gdb) continue > Continuing. > [...] > [New Thread 866.868] > [New Thread 866.869] > [New Thread 870.870] > /[...]/gdb/thread.c:89: internal-error: thread_info* inferior_thread(): Assertion `tp' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Quit this debugging session? (y or n) > > The error happens because GDBserver returns a list of threads > to GDB where a new thread as a different PID (870 in the case > above, instead of 866). Hi Joel, This is not supposed to happen. In remote.c:remote_update_thread_list there is a call to remove_new_fork_children that is explicitly supposed to prevent this scenario. The new fork child thread should be deleted from the thread list ("context") before we call remote_notice_new_inferior. We don't want the remote to report new threads related to the fork child until after we have handled the fork using infrun.c:follow_fork. (Note: it looks like the function comment for remove_new_fork_children is stale, since there are scenarios other than being stopped at a fork catchpoint where this can occur.) > Any advice on how I should be fixing the issue? It looks like there is a case that remove_new_fork_children isn't handling correctly with your test+target(s). I'd start there to find out how the new thread is getting through. Thanks --Don