From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 1A80B385780D for ; Wed, 24 Mar 2021 22:48:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1A80B385780D 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 12OMmIS9002401 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Mar 2021 18:48:23 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 12OMmIS9002401 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 937621EF5D; Wed, 24 Mar 2021 18:48:18 -0400 (EDT) Subject: Re: Need help with understanding truncated and corrupted backtraces To: Eli Zaretskii , gdb-patches@sourceware.org References: <83lfandydz.fsf@gnu.org> From: Simon Marchi Message-ID: Date: Wed, 24 Mar 2021 18:48:18 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <83lfandydz.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Wed, 24 Mar 2021 22:48:18 +0000 X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2021 22:48:40 -0000 Hi Eli, First, you could try to enable "set debug frame 1" before backtracing, It will show information about each frame unwind, in between each frame. In particular, you should see the reason why unwinding the last shown frame didn't yield any more frame. On 2021-03-16 9:24 a.m., Eli Zaretskii via Gdb-patches wrote: > Here's backtrace #1, which is almost normal (and quite long): > > Thread 1 hit Breakpoint 3, Fskip_chars_backward ( > string=XIL(0x80000000068bbe40), lim=XIL(0)) at syntax.c:1610 > 1610 return skip_chars (0, string, lim, 1); > (gdb) bt > #0 Fskip_chars_backward (string=XIL(0x80000000068bbe40), lim=XIL(0)) > at syntax.c:1610 > #1 0x09980e90 in ?? () > #2 0x012608c9 in funcall_subr (subr=0x75f33a8, numargs=0, args=0x828d10) > at eval.c:3082 > #3 0x01260359 in Ffuncall (nargs=1, args=0x828d08) at eval.c:3009 > #4 0x6d14e5ff in F632d666f6e742d6c6f636b2d636f6d706c65782d6465636c2d70726570617265_c_font_lock_complex_decl_prepare_0 () > from d:\usr\eli\.emacs.d\eln-cache\28.0.50-88a242e7\cc-fonts-d7d8a7f5-b7c359cd.eln > #5 0x01261a74 in funcall_lambda (fun=XIL(0xa000000007779d08), nargs=1, > arg_vector=0x829090) at eval.c:3292 [truncated for brevity] > > And here, by contrast, is backtrace#2. (It doesn't always get so > short, sometimes it has several dozens of frames, but it always stops > short of reaching 'main'.) > > Thread 1 hit Breakpoint 3, Fskip_chars_backward ( > string=XIL(0x80000000068bc060), lim=XIL(0)) at syntax.c:1610 > 1610 return skip_chars (0, string, lim, 1); > (gdb) bt > #0 Fskip_chars_backward (string=XIL(0x80000000068bc060), lim=XIL(0)) > at syntax.c:1610 > #1 0x09977f08 in ?? () > #2 0x01260359 in Ffuncall (nargs=1, args=0x828880) at eval.c:3009 > #3 0x099685bb in ?? () > #4 0x00000000 in ?? () > >From these backtraces, what I notice is that you have debug info for the code written in C, such as Ffuncall: we see the argument values. But the code coming from the JIT (in eln files) doesn't appear to have debug info: we don't see any argument values. Perhaps that's expected for JIT code, I don't know. But there isn't debug info for these frames, GDB will use its own unwinder, which tries to analyze the assembly instructions in the prologue to understand what was saved where and the previous frame address. This is heuristic-ish, so if something goes wrong in one frame, the backtrace will be wrong from there. In comparison, frames for which there is unwind information from the DWARF debug information are unwound very precisely. It would therefore be interesting to know which unwinder is selected for each frame: the unwinder that uses the DWARF debug info or the heuristic unwinder. Unfortunately, "set debug frame 1" doesn't seem to show any information about that. You could always break on the frame_unwind_find_by_frame function to find that out. But I think it would be benificial to everyone to add some debug output in that function, to say things like: Trying unwinder foo for frame 1 -> nope Trying unwinder bar for frame 1 -> yes! Once you know which unwinder is selected for each frame, you can try to find starting at which unwind things went wrong and focus on that one. And if this is indeed what is happening to you (the heuristic unwinder gets things wrong), I see two choices: - make the JIT producer generate DWARF info for the JIT-ed code, which will make GDB use the DWARF-based unwinder - improve the heuristic-based unwinder Simon