Message ID | 5e7031b1-8faa-4951-03eb-94c59bc5f615@codesourcery.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 52570 invoked by alias); 30 Apr 2019 15:33:58 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 52560 invoked by uid 89); 30 Apr 2019 15:33:58 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-19.7 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.1 spammy=prove, H*F:U*sandra, H*r:0700, UD:thread.c 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 ESMTP; Tue, 30 Apr 2019 15:33:57 +0000 Received: from svr-orw-mbx-03.mgc.mentorg.com ([147.34.90.203]) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1hLUlX-0004gf-IH from Sandra_Loosemore@mentor.com for gdb-patches@sourceware.org; Tue, 30 Apr 2019 08:33:55 -0700 Received: from [127.0.0.1] (147.34.91.1) by svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 30 Apr 2019 08:33:53 -0700 To: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org> From: Sandra Loosemore <sandra@codesourcery.com> Subject: [RFC] fix thread.c assertion after stepping past end of program Message-ID: <5e7031b1-8faa-4951-03eb-94c59bc5f615@codesourcery.com> Date: Tue, 30 Apr 2019 09:33:49 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------F2516357837578C304C8C129" |
Commit Message
Sandra Loosemore
April 30, 2019, 3:33 p.m. UTC
We've run into an assertion failure when quitting GDB after stepping past the end of a program that was linked with stripped libraries. Here's how it's triggered, using a simple factorial example for nios2-linux-gnu target with gdbserver: Breakpoint 1, main () at /home/sandra/examples/fact.c:13 13 for (i = 0; i < 10; ++i) { (gdb) advance 17 main () at /home/sandra/examples/fact.c:17 17 return 0; (gdb) s 18 } (gdb) s 0x2aaefffc in __libc_start_main () from /./scratch/sandra/nios2-linux-spring-release/install/opt/codesourcery/nios2-linux-gnu/libc//lib/libc.so.6 (gdb) s Single stepping until exit from function __libc_start_main, which has no line number information. [Inferior 1 (process 15772) exited normally] You can't do that without a process to debug. (gdb) s The program is not being run. (gdb) quit /scratch/sandra/nios2-linux-fsf/obj/gdb-src-mainline-0-nios2-linux-gnu-x86_64-linux-gnu/gdb/inferior.c:287: internal-error: inferior* find_inferior_pid(int): Assertion `pid != 0' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) The attached 1-liner patch fixes it and didn't cause regressions elsewhere. However, I'm not sure if this is really where the bug is. Maybe some other state is not getting cleaned out when the inferior exits? WDYT? -Sandra
Comments
On 4/30/19 9:33 AM, Sandra Loosemore wrote: > We've run into an assertion failure when quitting GDB after stepping > past the end of a program that was linked with stripped libraries. > Here's how it's triggered, using a simple factorial example for > nios2-linux-gnu target with gdbserver: > > Breakpoint 1, main () at /home/sandra/examples/fact.c:13 > 13 for (i = 0; i < 10; ++i) { > (gdb) advance 17 > main () at /home/sandra/examples/fact.c:17 > 17 return 0; > (gdb) s > 18 } > (gdb) s > 0x2aaefffc in __libc_start_main () > from > /./scratch/sandra/nios2-linux-spring-release/install/opt/codesourcery/nios2-linux-gnu/libc//lib/libc.so.6 > > (gdb) s > Single stepping until exit from function __libc_start_main, > which has no line number information. > [Inferior 1 (process 15772) exited normally] > You can't do that without a process to debug. > (gdb) s > The program is not being run. > (gdb) quit > /scratch/sandra/nios2-linux-fsf/obj/gdb-src-mainline-0-nios2-linux-gnu-x86_64-linux-gnu/gdb/inferior.c:287: > internal-error: inferior* find_inferior_pid(int): Assertion `pid != 0' > failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Quit this debugging session? (y or n) > > The attached 1-liner patch fixes it and didn't cause regressions > elsewhere. However, I'm not sure if this is really where the bug is. > Maybe some other state is not getting cleaned out when the inferior > exits? WDYT? Looking at this a little further, it seems that the TARGET_WAITKIND_EXITED case in handle_inferior_event_1 (in infrun.c) is not zeroing inf->pid as exit_inferior_1 (in inferior.c) does. If it did that, kill_or_detach (in top.c) would know the inferior is already dead and not call any_thread_of_inferior on it at all. But, maybe it is not supposed to be completely dead at that point yet? I'm not familiar enough with this code to know what the correct expectations are. :-S -Sandra
diff --git a/gdb/thread.c b/gdb/thread.c index 91741c7..c44b2b0 100644 --- a/gdb/thread.c +++ b/gdb/thread.c @@ -628,8 +628,8 @@ any_thread_of_inferior (inferior *inf) { gdb_assert (inf->pid != 0); - /* Prefer the current thread. */ - if (inf == current_inferior ()) + /* Prefer the current thread, if there is one. */ + if (inf == current_inferior () && inferior_ptid != null_ptid) return inferior_thread (); for (thread_info *tp : inf->non_exited_threads ())