From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 61104 invoked by alias); 10 Jan 2020 13:47:41 -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 61087 invoked by uid 89); 10 Jan 2020 13:47:41 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=BAYES_00,FREEMAIL_FROM,FSL_HELO_FAKE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.1 spammy=UD:event-loop.c, H*r:sk:61.2020, event-loop.c, sk:start_e X-HELO: mail-lj1-f196.google.com Received: from mail-lj1-f196.google.com (HELO mail-lj1-f196.google.com) (209.85.208.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 10 Jan 2020 13:47:39 +0000 Received: by mail-lj1-f196.google.com with SMTP id l2so2200178lja.6 for ; Fri, 10 Jan 2020 05:47:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=IHPaXX+QLmLxyX24XZJxtiBgAuxXJDGWLSYmPWkTyCo=; b=s22GjhfXRHn0pDFf93p3oBj5KnNqzNvGDaNoSGstzRVVNQ9h3nAPY3ilVH+05Uvnqt hLpHAVZuaLJu14VYjO4VG1rAAm7KKsy378DrI9ug7GpABkDW5pYUs+OZHmBVioE9Jijt P987gY5p0Q4odnhwgbnh3akL3DdJHvI/uvLayPB/0Qvh0+IMqcp5EKGwMJ568pvUnIrs e98kDTwTmfc7/7jlZCVErOIqdaS84yx9+IVfi43SFMfjp/t9DKMhUz/yOpy5a+FzOHTs BpqAvXVO5+cpvnRrG0WzNxdPnH5uYKYuavtWUabUS6+Kb8OCubBiQTB9eq29wS6dwb6/ +DWQ== Return-Path: Received: from gmail.com ([2a03:1b20:6:f011::2d]) by smtp.gmail.com with ESMTPSA id n3sm1053557lfk.61.2020.01.10.05.47.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jan 2020 05:47:37 -0800 (PST) Date: Fri, 10 Jan 2020 13:47:00 -0000 From: Shahab Vahedi To: Pedro Alves Cc: gdb-patches@sourceware.org, Shahab Vahedi , Andrew Burgess , Tom Tromey , Claudiu Zissulescu , Francois Bedard Subject: Re: [PATCH v2][PR tui/9765] Fix segfault in asm TUI when reaching end of file Message-ID: <20200110134734.GC3815@gmail.com> References: <20200110115728.13940-1-shahab.vahedi@gmail.com> <8f3c2363-6ab8-ce73-0f4b-b0b9efca6815@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8f3c2363-6ab8-ce73-0f4b-b0b9efca6815@redhat.com> X-SW-Source: 2020-01/txt/msg00245.txt.bz2 On Fri, Jan 10, 2020 at 12:53:17PM +0000, Pedro Alves wrote: > 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 I have found two different call stacks with this exception. There can be more. Call stack 1: #0 tui_disassemble (...) at gdb/tui/tui-disasm.c:126 #1 tui_disasm_window::set_contents (...) at gdb/tui/tui-disasm.c:241 #2 tui_source_window_base::update_source_window_as_is (...) at gdb/tui/tui-winsource.c:184 #3 tui_source_window_base::update_source_window (...) at gdb/tui/tui-winsource.c:173 #4 tui_update_source_windows_with_addr (...) at gdb/tui/tui-winsource.c:207 #5 tui_set_layout (layout_type=DISASSEM_COMMAND) at gdb/tui/tui-layout.c:181 #6 tui_layout_command (layout_name="asm", from_tty=1) at gdb/tui/tui-layout.c:287 #7 do_const_cfunc (c=, args="asm", from_tty=1) at gdb/cli/cli-decode.c:107 #8 cmd_func (cmd=, args="asm", from_tty=1) at gdb/cli/cli-decode.c:1952 #9 execute_command (p="m", from_tty=1) at gdb/top.c:653 #10 catch_command_errors (...) at gdb/main.c:401 #11 captured_main_1 (context=) at gdb/main.c:1168 #12 captured_main (data=) at gdb/main.c:1193 #13 gdb_main (args=) at gdb/main.c:1218 #14 main (argc=4, argv=) at gdb/gdb.c:32 call stack 2: #0 tui_disassemble (...) at gdb/tui/tui-disasm.c:126 #1 tui_find_disassembly_address (...) at gdb/tui/tui-disasm.c:157 #2 tui_disasm_window::do_scroll_vertical (this=, num_to_scroll=32) at gdb/tui/tui-disasm.c:348 #3 tui_win_info::forward_scroll (this=, num_to_scroll=31) at gdb/tui/tui-win.c:476 #4 tui_dispatch_ctrl_char (ch=338) at gdb/tui/tui-io.c:921 #5 tui_getc (fp=<_IO_2_1_stdin_>) at gdb/tui/tui-io.c:1005 #6 rl_read_key () at readline/readline/input.c:495 #7 readline_internal_char () at readline/readline/readline.c:573 #8 rl_callback_read_char () at readline/readline/callback.c:262 #9 gdb_rl_callback_read_char_wrapper_noexcept () at gdb/event-top.c:176 #10 gdb_rl_callback_read_char_wrapper (client_data=) at gdb/event-top.c:193 #11 stdin_event_handler (error=0, client_data=) at gdb/event-top.c:515 #12 handle_file_event (file_ptr=, ready_mask=1) at gdb/event-loop.c:731 #13 gdb_wait_for_event (block=1) at gdb/event-loop.c:857 #14 gdb_do_one_event () at gdb/event-loop.c:346 #15 start_event_loop () at gdb/event-loop.c:370 #16 captured_command_loop () at gdb/main.c:360 #17 captured_main (data=) at gdb/main.c:1203 #18 gdb_main (args=) at gdb/main.c:1218 #19 main (argc=4, argv=) at gdb/gdb.c:32 > 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. For "call stack 1", other exceptions end up here: gdb/main.c: catch_command_errors (...) { try { ... } catch (const gdb_exception &e) { return handle_command_errors (e); } ... } "call stack 2" is doomed. Probably in do_scroll_vertical () it aborts. > > > Thanks, > Pedro Alves >