Version-Release number of selected component: gdb-headless-13.1-4.fc38 Additional info: reporter: libreport-2.17.10 type: CCpp reason: gdb killed by SIGSEGV journald_cursor: s=367b75e4fadc40d1b00f77dda0e02609;i=22e30f;b=31fd87bec45849e0b832211dfa6f689e;m=8233efc2c5;t=5fbe4fb1ce98c;x=70ab1672ba787a35 executable: /usr/libexec/gdb cmdline: /usr/libexec/gdb -batch -ex $'set debuginfod enabled on' "" -ex $'file /usr/bin/polybar' -ex $'core-file ./coredump' -ex $'thread apply all -ascending backtrace full 1024' -ex $'info sharedlib' -ex $'print (char*)__abort_msg' -ex $'print (char*)__glib_assert_msg' -ex $'info all-registers' -ex disassemble cgroup: 0::/user.slice/user-1000.slice/session-12.scope rootdir: / uid: 1000 kernel: 6.2.11-300.fc38.x86_64 package: gdb-headless-13.1-4.fc38 runlevel: N 5 backtrace_rating: 4 crash_function: handle_fatal_signal Truncated backtrace: Thread no. 1 (23 frames) #3 handle_fatal_signal at ../../gdb/event-top.c:985 #4 handle_sigsegv at ../../gdb/event-top.c:1035 #6 iterate_thread_list at td_ta_thr_iter.c:62 #7 td_ta_thr_iter at td_ta_thr_iter.c:137 #8 find_new_threads_once at ../../gdb/linux-thread-db.c:1540 #9 thread_db_find_new_threads_2 at ../../gdb/linux-thread-db.c:1594 #10 thread_db_find_new_threads_silently at ../../gdb/linux-thread-db.c:505 #11 try_thread_db_load_1 at ../../gdb/linux-thread-db.c:931 #12 try_thread_db_load at ../../gdb/linux-thread-db.c:1024 #13 try_thread_db_load_from_sdir at ../../gdb/linux-thread-db.c:1108 #14 thread_db_load_search at ../../gdb/linux-thread-db.c:1163 #15 thread_db_load at ../../gdb/linux-thread-db.c:1225 #16 std::function<void (inferior*)>::operator()(inferior*) const at /usr/include/c++/13/bits/std_function.h:591 #17 gdb::observers::observable<inferior*>::notify at ../../gdb/../gdbsupport/observable.h:166 #18 post_create_inferior at ../../gdb/infcmd.c:316 #19 core_target_open at ../../gdb/corelow.c:586 #20 cmd_func at ../../gdb/cli/cli-decode.c:2543 #21 execute_command at ../../gdb/top.c:688 #22 catch_command_errors at ../../gdb/main.c:513 #23 execute_cmdargs at ../../gdb/main.c:608 #24 captured_main_1 at ../../gdb/main.c:1299 #25 captured_main at ../../gdb/main.c:1320 #26 gdb_main at ../../gdb/main.c:1345 Potential duplicate: bug 2144192
Created attachment 1965122 [details] File: proc_pid_status
Created attachment 1965123 [details] File: maps
Created attachment 1965124 [details] File: limits
Created attachment 1965125 [details] File: environ
Created attachment 1965126 [details] File: open_fds
Created attachment 1965127 [details] File: mountinfo
Created attachment 1965128 [details] File: os_info
Created attachment 1965129 [details] File: cpuinfo
Created attachment 1965130 [details] File: core_backtrace
Created attachment 1965131 [details] File: dso_list
Created attachment 1965132 [details] File: backtrace
Are you able to reproduce this GDB problem? If so, can you share the core file from running /usr/bin/polybar ?
Also, FWIW, I don't think that this is a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=2144192 .
I'm not and I agree it doesn't look like a duplicate of #2144192. I think we can close this as it hasn't happened again.
gdb was running, one of the underlying .so libraries for the program being debugged was updated, shortly after this gdb segfaulted. Might be a one off, but it would be better to catch the exception instead of fall over in a heap. reporter: libreport-2.17.10 type: CCpp reason: gdb killed by SIGSEGV journald_cursor: s=6e8d11ec35b34996bf9383d0f4797848;i=5373d2e;b=3eb960f7763b4c73b8d9b0117bbc22f7;m=61454c5c3;t=5fd77010efaf0;x=96ef3a5fd4d23e0 executable: /usr/libexec/gdb cmdline: gdb freedv cgroup: 0::/user.slice/user-1000.slice/user/app.slice/app-org.gnome.Terminal.slice/vte-spawn-1b515bd3-5533-4877-bb1b-88b370186d27.scope rootdir: / uid: 1000 kernel: 6.3.6-200.fc38.x86_64 package: gdb-headless-13.1-4.fc38 runlevel: N 5 backtrace_rating: 4 crash_function: handle_fatal_signal
Hi Brian, do you happen to have a core dump for the SIGSEGV you reported? Thank you, Alexandra
Sorry Alexandra, I have searched the system for anything relevant but I can't find any core or coredump files that appear to be relevant. This happened with a program I often build updated versions of, then I ran sudo dnf upgrade while leaving gdb running with the stopped process still attached. Is there a way to force capture of a core dump in case it happens again?
(In reply to Brian Morrison from comment #17) > Sorry Alexandra, I have searched the system for anything relevant but I > can't find any core or coredump files that appear to be relevant. > > This happened with a program I often build updated versions of, then I ran > sudo dnf upgrade while leaving gdb running with the stopped process still > attached. > > Is there a way to force capture of a core dump in case it happens again? I believe abrt should create core dumps if creating them is not disabled. Try looking for them at /var/spool/abrt/ccpp-_date_something/, on my machine I have ccpp-2023-05-02-14:17:58.588529-473184 for example. These directories are probably being cleaned up regulary so the coredumps you're looking for are not staying there for long.
I found some files in /var/spool/abrt but as you say the one I needed was not there. Sorry I couldn't help.