From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F07E13858012; Fri, 13 Nov 2020 13:02:57 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F07E13858012 From: "tankut.baris.aktemur at intel dot com" To: gdb-prs@sourceware.org Subject: [Bug gdb/26877] New: gdb crashes in tui mode in a multi-process setting at process exit Date: Fri, 13 Nov 2020 13:02:57 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: tankut.baris.aktemur at intel dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 13:02:58 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D26877 Bug ID: 26877 Summary: gdb crashes in tui mode in a multi-process setting at process exit Product: gdb Version: HEAD Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdb Assignee: unassigned at sourceware dot org Reporter: tankut.baris.aktemur at intel dot com Target Milestone: --- Suppose we have the following simple C program: 1 int main() { 2 int a =3D 42; 3 return 0; 4 } Create a two-inferior debug session using the following commands: file ./simple b 3 run add-inferior -exec ./simple inferior 2 run set schedule-multiple on After starting GDB with the script above, run "continue". This will resume both inferiors, and both will exit at about the same time. GDB receives two exit event, but will show only one of them. Switch to the inferior whose exit event was not shown: (gdb) continue Continuing. [Inferior 1 (process 21483) exited normally] (gdb) inferior 2 [Switching to inferior 2 [process 21487](simple)] [Switching to thread 2.1 (process 21487)] Couldn't get registers: No such process. (gdb) i inferiors Num Description Connection Executable 1 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 /nfs/iul/disks/iul_team2/taktemur/temp/simple * 2 process 21487 1 (native)=20=20=20=20=20=20=20=20=20=20 /nfs/iul/disks/iul_team2/taktemur/temp/simple Couldn't get registers: No such process. (gdb) Note the "Couldn't get registers: No such process." messages above. This hints that Inferior 2 is also dead, but the event hasn't been shown to the user, yet. If we stay in the CLI mode, we can remove inferior 1: (gdb) remove-inferiors 1 Couldn't get registers: No such process. (gdb) info inferiors Num Description Connection Executable * 2 process 21487 1 (native)=20=20=20=20=20=20=20=20=20=20 /nfs/iul/disks/iul_team2/taktemur/temp/simple Couldn't get registers: No such process. But, if we were to remove inferior 1 in TUI mode, GDB crashes. Suppose we run the commands above in tui mode: (gdb) tui enable .... (gdb) remove-inferiors 1 terminate called after throwing an instance of 'gdb_exception_error' Aborted Here is the backtrace of the crash: (top-gdb) bt During symbol reading: incomplete CFI data; unspecified registers (e.g., ra= x) at 0x7ffff59aff64 #0 0x00007ffff59aff47 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff59b18b1 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007ffff6014257 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so= .6 #3 0x00007ffff601f606 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so= .6 #4 0x00007ffff601e649 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so= .6 #5 0x00007ffff601eff1 in __gxx_personality_v0 () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #6 0x00007ffff5d71eff in ?? () from /lib/x86_64-linux-gnu/libgcc_s.so.1 #7 0x00007ffff5d728a6 in _Unwind_Resume () from /lib/x86_64-linux-gnu/libgcc_s.so.1 #8 0x0000555555ed7cba in get_frame_address_in_block_if_available (this_frame=3D0x555558298bd0, pc=3D0x7fffffffcbb8) at gdb/frame.c:2706 #9 0x0000555555ed6535 in select_frame (fi=3D0x555558298bd0) at gdb/frame.c= :1926 #10 0x0000555555ed6157 in lookup_selected_frame (a_frame_id=3D..., frame_level=3D-1) at gdb/frame.c:1756 #11 0x0000555555ed63ef in get_selected_frame (message=3D0x0) at gdb/frame.c= :1846 #12 0x0000555555c59c58 in get_current_arch () at gdb/arch-utils.c:804 #13 0x00005555563486fc in tui_get_begin_asm_address (gdbarch_p=3D0x7fffffff= cd50, addr_p=3D0x7fffffffcd60) at gdb/tui/tui-disasm.c:388 #14 0x000055555636baab in tui_display_main () at gdb/tui/tui-winsource.c:54 #15 0x000055555634acc7 in tui_new_objfile_hook (objfile=3D0x0) at gdb/tui/tui-hooks.c:56 #16 0x0000555555c1d7dc in std::_Function_handler::_M_invoke(std::_Any_data const&, objfile*&&) (__functor=3D.= .., __args#0=3D@0x7fffffffcde0: 0x0) at /usr/include/c++/7/bits/std_function.h:316 #17 0x00005555560af023 in std::function::operator()(objfil= e*) const (this=3D0x5555582a93c8, __args#0=3D0x0) at /usr/include/c++/7/bits/std_function.h:706 #18 0x00005555560aea61 in gdb::observers::observable::notify (this=3D0x555557cff260 , args#0=3D0x0) at gdb/../gdbsupport/observable.h:106 #19 0x00005555562b5109 in clear_symtab_users (add_flags=3D...) at gdb/symfile.c:2864 #20 0x00005555561128b9 in program_space::~program_space (this=3D0x55555830a= 070, __in_chrg=3D) at gdb/progspace.c:153 #21 0x0000555555f7e2b0 in delete_inferior (todel=3D0x555557f12fb0) at gdb/inferior.c:179 #22 0x0000555555f80104 in remove_inferior_command (args=3D0x555557d5bf81 "1= ", from_tty=3D1) at gdb/inferior.c:711 #23 0x0000555555d45ddb in do_const_cfunc (c=3D0x55555830b3d0, args=3D0x5555= 57d5bf81 "1", from_tty=3D1) at gdb/cli/cli-decode.c:95 #24 0x0000555555d499b3 in cmd_func (cmd=3D0x55555830b3d0, args=3D0x555557d5= bf81 "1", from_tty=3D1) at gdb/cli/cli-decode.c:2181 #25 0x0000555556327745 in execute_command (p=3D0x555557d5bf81 "1", from_tty= =3D1) at gdb/top.c:668 #26 0x0000555555eb04aa in command_handler (command=3D0x555557d5bf70 "remove-inferiors 1") at gdb/event-top.c:589 #27 0x0000555555eb0922 in command_line_handler (rl=3D...) at gdb/event-top.= c:774 #28 0x0000555555eafb95 in gdb_rl_callback_handler (rl=3D0x55555838d070 "remove-inferiors 1") at gdb/event-top.c:219 #29 0x00005555564238ab in rl_callback_read_char () at readline/readline/callback.c:281 #30 0x0000555555eaf9bd in gdb_rl_callback_read_char_wrapper_noexcept () at gdb/event-top.c:177 #31 0x0000555555eafa67 in gdb_rl_callback_read_char_wrapper (client_data=3D0x555557d576e0) at gdb/event-top.c:194 #32 0x0000555555eb02c2 in stdin_event_handler (error=3D0, client_data=3D0x555557d576e0) at gdb/event-top.c:516 #33 0x0000555556ae75a0 in handle_file_event (file_ptr=3D0x55555841e560, ready_mask=3D1) at gdbsupport/event-loop.cc:575 #34 0x0000555556ae7b4e in gdb_wait_for_event (block=3D1) at gdbsupport/event-loop.cc:701 #35 0x0000555556ae6909 in gdb_do_one_event () at gdbsupport/event-loop.cc:2= 37 #36 0x0000555556010992 in start_event_loop () at gdb/main.c:347 #37 0x0000555556010acd in captured_command_loop () at gdb/main.c:407 #38 0x000055555601233a in captured_main (data=3D0x7fffffffd5d0) at gdb/main.c:1234 #39 0x00005555560123a0 in gdb_main (args=3D0x7fffffffd5d0) at gdb/main.c:12= 49 #40 0x0000555555bde2a3 in main (argc=3D5, argv=3D0x7fffffffd6d8) at gdb/gdb= .c:32 The problem is at: #20 0x00005555561128b9 in program_space::~program_space (this=3D0x55555830a= 070, __in_chrg=3D) at gdb/progspace.c:153 While inside a destructor, GDB wanted to access the frame information of Inferior 2 in a series of calls. But because the process is dead, its registers cannot be read. This raises an error inside a destructor, leading to termination of GDB. --=20 You are receiving this mail because: You are on the CC list for the bug.=