Bug 2207999

Summary: [abrt] gdb-headless: handle_fatal_signal(): gdb killed by SIGSEGV
Product: [Fedora] Fedora Reporter: Ingo Weiss <iweiss>
Component: gdbAssignee: Kevin Buettner <kevinb>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 38CC: ahajkova, bdm, blarsen, fweimer, iweiss, jan, keiths, kevinb, mcermak, mkolar
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/69ee57a47f859d3ed60273fee65ebd7669a897f
Whiteboard: abrt_hash:e375bd974affddd4e91bfb6c956ef8dcb1baec29;VARIANT_ID=;
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-08-08 09:34:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: proc_pid_status
none
File: maps
none
File: limits
none
File: environ
none
File: open_fds
none
File: mountinfo
none
File: os_info
none
File: cpuinfo
none
File: core_backtrace
none
File: dso_list
none
File: backtrace none

Description Ingo Weiss 2023-05-17 15:04:00 UTC 
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
Comment 1 Ingo Weiss 2023-05-17 15:04:04 UTC 
Created attachment 1965122 [details]
File: proc_pid_status
Comment 2 Ingo Weiss 2023-05-17 15:04:06 UTC 
Created attachment 1965123 [details]
File: maps
Comment 3 Ingo Weiss 2023-05-17 15:04:08 UTC 
Created attachment 1965124 [details]
File: limits
Comment 4 Ingo Weiss 2023-05-17 15:04:09 UTC 
Created attachment 1965125 [details]
File: environ
Comment 5 Ingo Weiss 2023-05-17 15:04:11 UTC 
Created attachment 1965126 [details]
File: open_fds
Comment 6 Ingo Weiss 2023-05-17 15:04:12 UTC 
Created attachment 1965127 [details]
File: mountinfo
Comment 7 Ingo Weiss 2023-05-17 15:04:14 UTC 
Created attachment 1965128 [details]
File: os_info
Comment 8 Ingo Weiss 2023-05-17 15:04:16 UTC 
Created attachment 1965129 [details]
File: cpuinfo
Comment 9 Ingo Weiss 2023-05-17 15:04:18 UTC 
Created attachment 1965130 [details]
File: core_backtrace
Comment 10 Ingo Weiss 2023-05-17 15:04:26 UTC 
Created attachment 1965131 [details]
File: dso_list
Comment 11 Ingo Weiss 2023-05-17 15:04:28 UTC 
Created attachment 1965132 [details]
File: backtrace
Comment 12 Kevin Buettner 2023-06-03 18:49:52 UTC 
Are you able to reproduce this GDB problem?

If so, can you share the core file from running /usr/bin/polybar ?
Comment 13 Kevin Buettner 2023-06-03 18:52:00 UTC 
Also, FWIW, I don't think that this is a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=2144192 .
Comment 14 Ingo Weiss 2023-06-05 05:07:36 UTC 
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.
Comment 15 Brian Morrison 2023-06-07 09:56:16 UTC 
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
Comment 16 Alexandra Petlanová Hájková 2023-08-03 08:35:18 UTC 
Hi Brian,

do you happen to have a core dump for the SIGSEGV you reported?

Thank you,
Alexandra
Comment 17 Brian Morrison 2023-08-03 14:22:17 UTC 
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?
Comment 18 Alexandra Petlanová Hájková 2023-08-08 09:30:52 UTC 
(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.
Comment 19 Brian Morrison 2023-08-08 13:30:53 UTC 
I found some files in /var/spool/abrt but as you say the one I needed was not there.

Sorry I couldn't help.