From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130786 invoked by alias); 18 Nov 2018 16:37:18 -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 130773 invoked by uid 89); 18 Nov 2018 16:37:17 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_20,SPF_PASS,T_FILL_THIS_FORM_SHORT autolearn=ham version=3.3.2 spammy=TIA, tia, sk:gdbsou, 2728 X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 18 Nov 2018 16:37:16 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gOQ4M-0003px-Tc for gdb-patches@sourceware.org; Sun, 18 Nov 2018 11:37:14 -0500 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58129) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gOQ4M-0003pt-Qp; Sun, 18 Nov 2018 11:37:10 -0500 Received: from [176.228.60.248] (port=2525 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gOQ4M-0004NA-EM; Sun, 18 Nov 2018 11:37:10 -0500 Date: Sun, 18 Nov 2018 16:37:00 -0000 Message-Id: <83a7m6tk92.fsf@gnu.org> From: Eli Zaretskii To: Simon Marchi CC: gdb-patches@sourceware.org In-reply-to: <100001f1b27aa7d90902a75d5db37710@polymtl.ca> (message from Simon Marchi on Mon, 20 Aug 2018 11:08:27 -0400) Subject: Re: GDB internal error in pc_in_thread_step_range References: <83h8kjr8r6.fsf@gnu.org> <100001f1b27aa7d90902a75d5db37710@polymtl.ca> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-IsSubscribed: yes X-SW-Source: 2018-11/txt/msg00277.txt.bz2 > Date: Mon, 20 Aug 2018 11:08:27 -0400 > From: Simon Marchi > Cc: gdb@sourceware.org A reminder: this is about an internal GDB error that happens on MinGW whenever I step out of the 'main' function. > > Temporary breakpoint 1, main () at hello.c:8 > > 8 printf("hello, world!"); > > (gdb) n > > hello, world!9 return 0; > > (gdb) > > 10 } > > (gdb) > > 0x0040126d in __register_frame_info () > > (gdb) > > Single stepping until exit from function __register_frame_info, > > which has no line number information. > > infrun.c:2728: internal-error: void resume_1(gdb_signal): Assertion > > `pc_in_thread_step_range (pc, tp)' failed. > > A problem internal to GDB has been detected, > > further debugging may prove unreliable. > > Quit this debugging session? (y or n) > > > > Is it a known problem? > > Not that I know of. I finally got to debugging this. It happens because: 2723 gdb_assert (pc_in_thread_step_range (pc, tp)); (top-gdb) p tp->control $22 = {step_resume_breakpoint = 0x0, exception_resume_breakpoint = 0x0, single_step_breakpoints = 0x0, step_range_start = 0x0, step_range_end = 0x1, step_start_function = 0x0, may_range_step = 1, step_frame_id = {stack_addr = 0x28ff70, code_addr = 0x0, special_addr = 0x0, stack_status = FID_STACK_VALID, code_addr_p = 1, special_addr_p = 0, artificial_depth = 0}, step_stack_frame_id = { stack_addr = 0x28ff70, code_addr = 0x0, special_addr = 0x0, stack_status = FID_STACK_VALID, code_addr_p = 1, special_addr_p = 0, artificial_depth = 0}, trap_expected = 0, proceed_to_finish = 0, in_infcall = 0, step_over_calls = STEP_OVER_ALL, stop_step = 0, stop_bpstat = 0x0, stepping_command = 1} The step_range_start is zero and step_range_end is 1, which of course will not match any value of PC. What happens here is that step_1 first zeroes out these members, and then fills them by calling find_pc_line_pc_range, called from prepare_one_step. But when I step out of the main program into the library epilogue code, there's no line information, and prepare_one_step calls find_pc_partial_function, which also doesn't find any addresses. So we fill these members with zero and 1: if (address) { if (pc_in_unmapped_range (pc, section)) *address = overlay_unmapped_address (cache_pc_function_low, section); else *address = cache_pc_function_low; } if (name) *name = cache_pc_function_name; if (endaddr) { if (pc_in_unmapped_range (pc, section)) { /* Because the high address is actually beyond the end of the function (and therefore possibly beyond the end of the overlay), we must actually convert (high - 1) and then add one to that. */ *endaddr = 1 + overlay_unmapped_address (cache_pc_function_high - 1, section); } else *endaddr = cache_pc_function_high; } The cached values are zero and 1, correspondingly. Any suggestions for how to fix this? One way would be to avoid triggering the assertion of the addresses are these two specific bogus values. Alternatively, perhaps the cached values in find_pc_partial_function should be more useful, but in that case I'd need guidance as to where and how are they supposed to be assigned, so that I could look into why they don't in this case. TIA