From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126100 invoked by alias); 16 Dec 2018 03:58:16 -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 126068 invoked by uid 89); 16 Dec 2018 03:58:15 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=H*Ad:D*ca, H*r:SSLv3 X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 16 Dec 2018 03:58:13 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id wBG3vw9n011115 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 15 Dec 2018 22:58:03 -0500 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 1BC0C1E4C2; Sat, 15 Dec 2018 22:57:58 -0500 (EST) Subject: Re: GDB internal error in pc_in_thread_step_range To: Eli Zaretskii Cc: gdb-patches@sourceware.org References: <83h8kjr8r6.fsf@gnu.org> <100001f1b27aa7d90902a75d5db37710@polymtl.ca> <83a7m6tk92.fsf@gnu.org> From: Simon Marchi Message-ID: Date: Sun, 16 Dec 2018 03:58:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <83a7m6tk92.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg00176.txt.bz2 Hi Eli, Sorry for the wait. I don't really have an good answer for you, but I thought I'd reply anyway, maybe this will help generate ideas. On 2018-11-18 11:37 a.m., Eli Zaretskii wrote: >> 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. Do you mean that cache_pc_function_low is 0 and cache_pc_function_high is 1? Do these values even make sense? They are supposed to hold a range of program addresses, so 0 and 1 seem bogus. Maybe this is the result of something going wrong before? It would be interesting to understand how they end up with these values. If find_pc_partial_function is unable to determine a proper symbol and some proper bounds, it should return 0. So if it returns 1 but returns some wrong data, something is fishy. Simon