From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16443 invoked by alias); 10 Jan 2020 12:53:26 -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 16421 invoked by uid 89); 10 Jan 2020 12:53:25 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=H*MI:sk:2020011 X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (205.139.110.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 10 Jan 2020 12:53:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1578660801; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gOCjjQL7xMA0RElmOEVa5nHSD1igIUL1S2jNC00L8Nk=; b=T/rpLC6CmSN9WcMOegDNLiG+A/eA2dsKJUpKVlpClhcxppy7lXc9WlPxXuhEzPbPpL9KTQ NEHVlPFMzZ22gMhaDVJANNQ9AjvCG1aAH0iKuvuAVm5QHngLVVZfO4+ZjOc87JgEKIf0Yi R4SUXYtQzC3Kuk5Dao9w+EMhWujc04o= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-342-X5a5xsSTPqma-TVNOnp16A-1; Fri, 10 Jan 2020 07:53:20 -0500 Received: by mail-wm1-f71.google.com with SMTP id y125so1548897wmg.1 for ; Fri, 10 Jan 2020 04:53:20 -0800 (PST) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:4c97:6d52:2cea:997b? ([2001:8a0:f913:f700:4c97:6d52:2cea:997b]) by smtp.gmail.com with ESMTPSA id o129sm2118442wmb.1.2020.01.10.04.53.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Jan 2020 04:53:18 -0800 (PST) Subject: Re: [PATCH v2][PR tui/9765] Fix segfault in asm TUI when reaching end of file To: Shahab Vahedi , gdb-patches@sourceware.org References: <20200110115728.13940-1-shahab.vahedi@gmail.com> Cc: Shahab Vahedi , Andrew Burgess , Tom Tromey , Claudiu Zissulescu , Francois Bedard From: Pedro Alves Message-ID: <8f3c2363-6ab8-ce73-0f4b-b0b9efca6815@redhat.com> Date: Fri, 10 Jan 2020 12:53:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20200110115728.13940-1-shahab.vahedi@gmail.com> X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2020-01/txt/msg00243.txt.bz2 On 1/10/20 11:57 AM, Shahab Vahedi wrote: > From: Shahab Vahedi > > In TUI mode, when the assembly layout reaches the end of a binary, > GDB wants to disassemle the addresses beyond the last valid ones. > This results in a "MEMORY_ERROR" exception to be thrown when > tui_disasm_window::set_contents() invokes tui_disassemble(). When > that happens set_contents() bails out prematurely without filling > the "content" for the valid addresses. This eventually leads to > no assembly lines or termination of GDB when you scroll down to > the last lines of the program. > > With this change, tui_disassemble() catches MEMORY_ERROR exceptions > and ignores them, while filling the rest of "asm_lines" with the > same address (the one just beyond the last PC address). > > The issue has been discussed at length in bug 25345 (and 9765). > > gdb/ChangeLog: > 2020-01-10 Shahab Vahedi > > PR tui/25345 > * tui/tui-disasm.c (tui_disasm_window::tui_disassemble): > Handle MEMORY_ERROR exceptions gracefully. > --- > The behavior of GDB after this fix is illustrated here: > https://sourceware.org/bugzilla/attachment.cgi?id=12178 > > gdb/tui/tui-disasm.c | 14 +++++++++++++- > 1 file changed, 13 insertions(+), 1 deletion(-) > > diff --git a/gdb/tui/tui-disasm.c b/gdb/tui/tui-disasm.c > index 98c691f3387..dffcd257a0d 100644 > --- a/gdb/tui/tui-disasm.c > +++ b/gdb/tui/tui-disasm.c > @@ -114,7 +114,19 @@ tui_disassemble (struct gdbarch *gdbarch, > asm_lines[pos + i].addr_size = new_size; > } > > - pc = pc + gdb_print_insn (gdbarch, pc, &gdb_dis_out, NULL); > + try > + { > + pc = pc + gdb_print_insn (gdbarch, pc, &gdb_dis_out, NULL); > + } > + catch (const gdb_exception &except) > + { > + /* In cases where max_lines is asking tui_disassemble() to fetch > + too much, like when PC goes past the valid address range, a > + MEMORY_ERROR is thrown, but it is alright. */ > + if (except.error != MEMORY_ERROR) > + throw; > + /* fall through: let asm_lines still to be filled. */ > + } > I didn't delve deep into the patch, but, I should point out one thing -- as described in the PR, it's a problem to let exceptions cross ncurses. Any kind of C++ exception. So which ncurses callback/entry point in gdb were we at? We need to look into it and make sure that no exceptions are thrown from it back into ncurses. Above, you're rethrowing non-memory exceptions, which is what made me wonder, since it sounds like for example a Ctrl-C at some "wrong" time may bring down GDB. For readline, we ended up with TRY_SJLJ/CATCH_SJLJ. > asm_lines[pos + i].insn = std::move (gdb_dis_out.string ()); > > Thanks, Pedro Alves