Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Suspended the execution of the firmware in Eclipse. The gdb was connected to JLinkGDBServer with activated FreeRTOS awareness JLink plugin. Version-Release number of selected component: gdb-headless-16.2-3.fc42 Additional info: reporter: libreport-2.17.15 type: CCpp reason: gdb killed by SIGABRT journald_cursor: s=6fd17f62c4b24fa0bc69623370bec387;i=947e60;b=f0fa6cf37e9a40ee8b8bddca30e8658e;m=2ea50c3df4;t=6348c78edc8fe;x=c5f0543103447c60 executable: /usr/libexec/gdb cmdline: arm-none-eabi-gdb --interpreter=mi2 --nx cgroup: 0::/user.slice/user-1000.slice/session-2.scope rootdir: / uid: 1000 kernel: 6.14.4-300.fc42.x86_64 package: gdb-headless-16.2-3.fc42 runlevel: N 5 backtrace_rating: 4 crash_function: dump_core Truncated backtrace: Thread no. 1 (19 frames) #4 dump_core at ../../gdb/utils.c:225 #5 internal_vproblem(internal_problem *, const char *, int, const char *, typedef __va_list_tag __va_list_tag *) at ../../gdb/utils.c:477 #6 internal_verror at ../../gdb/utils.c:503 #7 internal_error_loc at ../../gdbsupport/errors.cc:57 #8 get_thread_regcache at ../../gdb/regcache.c:432 #9 print_signal_received_reason at ../../gdb/infrun.c:9287 #10 mi_interp::on_signal_received at ../../gdb/mi/mi-interp.c:372 #11 interps_notify<void (interp::*)(gdb_signal), gdb_signal&> at ../../gdb/interps.c:369 #12 interps_notify_signal_received at ../../gdb/interps.c:378 #13 notify_signal_received at ../../gdb/infrun.c:6818 #14 normal_stop at ../../gdb/gdbthread.h:432 #15 fetch_inferior_event at ../../gdb/infrun.c:4753 #16 run_async_handler_and_reschedule at ../../gdb/ser-base.c:138 #17 gdb_wait_for_event at ../../gdbsupport/event-loop.cc:694 #18 gdb_do_one_event at ../../gdbsupport/event-loop.cc:263 #19 start_event_loop at ../../gdb/main.c:402 #20 captured_command_loop at ../../gdb/main.c:466 #21 captured_main at ../../gdb/main.c:1343 #22 gdb_main at ../../gdb/main.c:1362 Potential duplicate: bug 1419703
Created attachment 2089917 [details] File: proc_pid_status
Created attachment 2089918 [details] File: maps
Created attachment 2089919 [details] File: limits
Created attachment 2089920 [details] File: open_fds
Created attachment 2089921 [details] File: os_info
Created attachment 2089922 [details] File: cpuinfo
Created attachment 2089923 [details] File: core_backtrace
Created attachment 2089924 [details] File: dso_list
Created attachment 2089925 [details] File: mountinfo
Created attachment 2089926 [details] File: backtrace
Created attachment 2089927 [details] File: environ
Created attachment 2089939 [details] gdb coredump, Thu 2025-05-15 11:05:32, part 1 https://bugzilla.redhat.com/show_bug.cgi?id=2364341#c12 > Can you upload the core file associated with the crash when running "arm-none-eabi-gdb --interpreter=mi2 --nx"? > > To find it, look at the output from running "abrt-cli", then do "abrt-cli info ID" where ID is the hex identifier (left-most field) obtained from looking at the abrt-cli output. > > Output from the "abrt-cli info" command will show a path (most likely starting with /var/spool/abrt). Look in that directory - you should hopefully see a file named coredump.zst. > Upload that file to this bug. > > Thanks! Here is the coredump Id aa99095 Component gdb Count 3 Time 2025-05-07 16:23:09 Command line arm-none-eabi-gdb --interpreter=mi2 --nx Package gdb-headless-16.2-3.fc42 User id 1000 (user) Path /var/spool/abrt/ccpp-2025-05-07-16:23:09.463083-974682 Reported to ABRT Server https://retrace.fedoraproject.org/faf/reports/bthash/358a064097faf691da287557620da00be318c324 Bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=2366461
Created attachment 2089940 [details] gdb coredump, Thu 2025-05-15 11:05:32, part 2
Created attachment 2089941 [details] gdb coredump, Thu 2025-05-15 11:05:32, part 3
Created attachment 2089942 [details] gdb coredump, Thu 2025-05-15 11:05:32, part 4
Created attachment 2089943 [details] gdb coredump, Thu 2025-05-15 11:05:32, part 5
Created attachment 2089944 [details] gdb coredump, Thu 2025-05-15 11:05:32, part 6
Created attachment 2089945 [details] gdb coredump, Thu 2025-05-15 11:05:32, part 7
Hi Aleksandrs, Can you tell me how '/opt/tools/gcc-arm-none-eabi/bin/arm-none-eabi-gdb' was installed? (I.e. if it's a Fedora package, what's the package name? If it's obtained from some other source, I how do I fetch and install it...?) Thanks, Kevin
(In reply to Kevin Buettner from comment #19) > Hi Aleksandrs, > > Can you tell me how '/opt/tools/gcc-arm-none-eabi/bin/arm-none-eabi-gdb' was > installed? (I.e. if it's a Fedora package, what's the package name? If > it's obtained from some other source, I how do I fetch and install it...?) > > Thanks, > > Kevin Hello Kevin, This is merely the soft link to Fedora packaged multiarch gdb: ``` /opt/tools/gcc-arm-none-eabi/bin/arm-none-eabi-gdb -> /usr/bin/gdb ``` ``` /opt/tools/gcc-arm-none-eabi/bin/arm-none-eabi-gdb --version GNU gdb (Fedora Linux) 16.2-3.fc42 Copyright (C) 2024 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. ```
When I attempt to debug https://github.com/Murmele/Gittyup/releases/download/gittyup_v1.4.0/Gittyup-1.4.0-x86_64.AppImage, GDB consistently coredumps. It also crashes the AppImage: > ~~~log > gdb /home/RokeJulianLockhart/Downloads/Gittyup-1.4.0-x86_64.AppImage > GNU gdb (Fedora Linux) 16.3-1.fc42 > Copyright (C) 2024 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "x86_64-redhat-linux-gnu". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <https://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from /home/RokeJulianLockhart/Downloads/Gittyup-1.4.0-x86_64.AppImage... > (No debugging symbols found in /home/RokeJulianLockhart/Downloads/Gittyup-1.4.0-x86_64.AppImage) > (gdb) run > Starting program: /home/RokeJulianLockhart/Downloads/Gittyup-1.4.0-x86_64.AppImage > > This GDB supports auto-downloading debuginfo from the following URLs: > <https://debuginfod.fedoraproject.org/> > Enable debuginfod for this session? (y or [n]) y > Debuginfod has been enabled. > To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit. > [Detaching after fork from child process 377847] > process 377833 is executing new program: /usr/bin/bash > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib64/libthread_db.so.1". > [Detaching after fork from child process 377852] > [Detaching after fork from child process 377854] > [Detaching after fork from child process 377859] > [Detaching after fork from child process 377860] > [Detaching after fork from child process 377861] > [Detaching after fork from child process 377862] > [Detaching after fork from child process 377865] > [Detaching after fork from child process 377868] > [Detaching after fork from child process 377871] > [Detaching after fork from child process 377872] > [Detaching after fork from child process 377873] > process 377833 is executing new program: /tmp/.mount_GittyujbkilI/usr/bin/ld-linux-x86-64.so.2 > warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. > ../../gdb/symfile.c:854: internal-error: sect_index_text not initialized > A problem internal to GDB has been detected, > further debugging may prove unreliable. > ----- Backtrace ----- > 0x55d15994a834 ??? > 0x55d159e4e7ec ??? > 0x55d159e4ebce ??? > 0x55d15a087364 ??? > 0x55d159d5cc28 ??? > 0x55d159d65b68 ??? > 0x55d159d2c1a1 ??? > 0x55d159d2f743 ??? > 0x55d159d2f919 ??? > 0x55d159942d7c ??? > 0x55d159b25b20 ??? > 0x55d159b27527 ??? > 0x55d159b295cf ??? > 0x55d15a087e25 ??? > 0x55d15a088bc6 ??? > 0x55d159b7a809 ??? > 0x55d159b7d9f4 ??? > 0x55d15984c775 ??? > 0x7f32eaa115f4 ??? > 0x7f32eaa116a7 ??? > 0x55d15985e3c4 ??? > 0xffffffffffffffff ??? > --------------------- > ../../gdb/symfile.c:854: internal-error: sect_index_text not initialized > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Quit this debugging session? (y or n) n > > This is a bug, please report it. For instructions, see: > <https://www.gnu.org/software/gdb/bugs/>. > > ../../gdb/symfile.c:854: internal-error: sect_index_text not initialized > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Create a core file of GDB? (y or n) y > Command aborted. > (gdb) run > The program being debugged has been started already. > Start it from the beginning? (y or n) y > warning: BFD: reopening /tmp/.mount_GittyujbkilI/usr/bin/ld-linux-x86-64.so.2: Software caused connection abort > warning: BFD: reopening /tmp/.mount_GittyujbkilI/usr/bin/ld-linux-x86-64.so.2: No such file or directory > warning: `/tmp/.mount_GittyujbkilI/usr/bin/ld-linux-x86-64.so.2' has disappeared; keeping its symbols. > Starting program: /tmp/.mount_GittyujbkilI/usr/bin/ld-linux-x86-64.so.2 > /bin/bash: line 1: /tmp/.mount_GittyujbkilI/usr/bin/ld-linux-x86-64.so.2: No such file or directory > During startup program exited with code 127. > (gdb) bt full > No stack. > (gdb) run > warning: `/tmp/.mount_GittyujbkilI/usr/bin/ld-linux-x86-64.so.2' has disappeared; keeping its symbols. > Starting program: /tmp/.mount_GittyujbkilI/usr/bin/ld-linux-x86-64.so.2 > /bin/bash: line 1: /tmp/.mount_GittyujbkilI/usr/bin/ld-linux-x86-64.so.2: No such file or directory > During startup program exited with code 127. > ~~~ This occurs irrespective of whether DebugInfoD is enabled. reporter: libreport-2.17.15 type: CCpp reason: gdb killed by SIGABRT journald_cursor: s=c1f108f1ef4e48808a377c0a73f168fc;i=570463;b=c6bb945371444d4db4fed95c94da2292;m=a8cb1e31a;t=635fe13978c43;x=843a083920da96be executable: /usr/libexec/gdb cmdline: gdb /home/RokeJulianLockhart/Downloads/Gittyup-1.4.0-x86_64.AppImage cgroup: 0::/user.slice/user-1000.slice/user/app.slice/app-dev.warp.Warp rootdir: / uid: 1000 kernel: 6.14.6-300.fc42.x86_64 package: gdb-headless-16.3-1.fc42 runlevel: N 5 backtrace_rating: 4 crash_function: dump_core
(In reply to Mr. Beedell, Roke Julian Lockhart from comment #21) > When I attempt to debug > https://github.com/Murmele/Gittyup/releases/download/gittyup_v1.4.0/Gittyup- > 1.4.0-x86_64.AppImage, GDB consistently coredumps. It also crashes the > AppImage. `set follow-fork-mode child` [^1] in the GDB CLI remediates this, so GDB appears to not cope with a parent process closing with a child still running, or something similar. Note that LLDB appears to: > lldb /home/RokeJulianLockhart/Downloads/Gittyup-1.4.0-x86_64.AppImage > (lldb) target create "/home/RokeJulianLockhart/Downloads/Gittyup-1.4.0-x86_64.AppImage" > Current executable set to '/home/RokeJulianLockhart/Downloads/Gittyup-1.4.0-x86_64.AppImage' (x86_64). > (lldb) run > Process 382819 launched: '/home/RokeJulianLockhart/Downloads/Gittyup-1.4.0-x86_64.AppImage' (x86_64) > Process 382819 stopped and restarted: thread 1 received signal: SIGCHLD > Process 382819 stopped > * thread #1, name = 'AppRun', stop reason = exec > frame #0: 0x00007ffff7fe3880 ld-linux-x86-64.so.2`_start > ld-linux-x86-64.so.2`_start: > -> 0x7ffff7fe3880 <+0>: movq %rsp, %rdi > 0x7ffff7fe3883 <+3>: callq 0x7ffff7fe4490 ; _dl_start at rtld.c:519:1 > > ld-linux-x86-64.so.2`_dl_start_user: > 0x7ffff7fe3888 <+0>: movq %rax, %r12 > 0x7ffff7fe388b <+3>: movq %rsp, %r13 > error: ld-linux-x86-64.so.2 0x00031a1f: adding range [0x0000000000000dcb-0x0000000000000dea) which has a base that is less than the function's low PC 0x000000000001d490. Please file a bug and attach the file at the start of this error message > error: ld-linux-x86-64.so.2 0x00031ac0: adding range [0x0000000000000dcb-0x0000000000000dea) which has a base that is less than the function's low PC 0x000000000001d490. Please file a bug and attach the file at the start of this error message > error: ld-linux-x86-64.so.2 0x00031afe: adding range [0x0000000000000dcb-0x0000000000000dea) which has a base that is less than the function's low PC 0x000000000001d490. Please file a bug and attach the file at the start of this error message > error: ld-linux-x86-64.so.2 0x00031b19: adding range [0x0000000000000dcb-0x0000000000000dea) which has a base that is less than the function's low PC 0x000000000001d490. Please file a bug and attach the file at the start of this error message > error: ld-linux-x86-64.so.2 0x00031bd6: adding range [0x0000000000000dcb-0x0000000000000dea) which has a base that is less than the function's low PC 0x000000000001d490. Please file a bug and attach the file at the start of this error message > error: ld-linux-x86-64.so.2 0x00031de9: adding range [0x0000000000000cf2-0x0000000000000dcb) which has a base that is less than the function's low PC 0x000000000001d490. Please file a bug and attach the file at the start of this error message > (lldb) thread backtrace all > * thread #1, name = 'AppRun', stop reason = exec > * frame #0: 0x00007ffff7fe3880 ld-linux-x86-64.so.2`_start ...that is, if the "Please file a bug and attach the file at the start of this error message" message isn't from LLDB itself, per https://discussion.fedoraproject.org/t/what-produces-the-please-file-a-bug-and-attach-the-file-at-the-start-of-this-error-message-message-during-debug/154509. [^1]: https://stackoverflow.com/revisions/15127892/3#:~:text=the%20mode%20using-,set%20follow%2Dfork%2Dmode%20child,-However%2C%20now%20only
(In reply to Mr. Beedell, Roke Julian Lockhart (RJLB) from comment #22) > (In reply to Mr. Beedell, Roke Julian Lockhart from comment #21) > > > When I attempt to debug > > https://github.com/Murmele/Gittyup/releases/download/gittyup_v1.4.0/Gittyup- > > 1.4.0-x86_64.AppImage, GDB consistently coredumps. It also crashes the > > AppImage. > > `set follow-fork-mode child` [^1] in the GDB CLI remediates this, so GDB > appears to not cope with a parent process closing with a child still > running, or something similar. Note that LLDB appears to: Hi. I was looking at this bug again. Are messages 21 and 22 about a different crash that the original? The original issue seemed to be about a remote debug issue, while the later messages seem to be about a native debug issue. Can you confirm that these two issues are unrelated? I did eventually get a patch merged to upstream GDB that I think would catch the original remote debug case. My best guess from looking at the backtrace was that when the inferior stopped, and GDB updated the thread list, the remote target was telling GDB that the current thread has gone away, this would lead to the exact crash that you were seeing. Before we look at possible backports though, I'd like to try and understand how comments 21/22 impact this issue. Thanks.
(In reply to Andrew Burgess from comment #23) Per the YAML at the bottom of https://bugzilla.redhat.com/show_bug.cgi?id=2366461#c21, that comment was submitted by `gnome-abrt`. The subsequent comment was merely in response to it. I can't tell you whether they're related, since `libreport`'s RHBZ add-on made that determination. However, it must have had reason to. Apologies for not being of much use.
I think there is a problem with the tool that merges bug reports together. I believe there are two very different bug reports merged together here. The original report, and all the comments up to #20, are for a bug which I believe is addressed by upstream commit 8bd08ee92c4a7bf2ad9e29c4da32a276ef2257fc. Then commits #21 onward are for a different bug, which I believe is addressed by upstream commit cd289df068e39683576f95907b5dd06ae3e4e254.
I created https://src.fedoraproject.org/rpms/gdb/pull-request/208 to merge these two fixes into rawhide. If that goes well then I'll merge them into other Fedora versions too.
Fixes for both the issues raised in this bug have now been backported to F43, F44, and Rawhide. Given how close F42 is to EOL I don't plan to backport to that branch.
FEDORA-2026-26cf29cfa1 (gdb-17.1-6.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-26cf29cfa1
FEDORA-2026-26cf29cfa1 has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-26cf29cfa1` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-26cf29cfa1 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-26cf29cfa1 (gdb-17.1-6.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.