Version-Release number of selected component: gdb-headless-8.0.1-26.fc27 Additional info: reporter: libreport-2.9.2 backtrace_rating: 3 cmdline: /usr/libexec/gdb -batch -iex add-auto-load-safe-path /var/cache/abrt-di/usr/lib/debug -iex add-auto-load-scripts-directory /var/cache/abrt-di/usr/lib/debug -ex set debug-file-directory /usr/lib/debug:/var/cache/abrt-di/usr/lib/debug -ex file /usr/libexec/webkit2gtk-4.0/WebKitWebProcess -ex core-file ./coredump -ex thread apply all -ascending backtrace 1024 full -ex info sharedlib -ex print (char*)__abort_msg -ex print (char*)__glib_assert_msg -ex info all-registers -ex disassemble crash_function: dump_core executable: /usr/libexec/gdb journald_cursor: s=b6dd87543dcb4972a60d870e7358ad91;i=45ce1;b=aa2ccb76c31e412185108ae6ccecb538;m=c7cacce1b;t=55969506c3863;x=32f18a3d027dffaf kernel: 4.13.2-305.fc27.x86_64 rootdir: / runlevel: N 5 type: CCpp uid: 1000 Potential duplicate: bug 1419703
Created attachment 1327054 [details] File: backtrace
Created attachment 1327055 [details] File: cgroup
Created attachment 1327056 [details] File: core_backtrace
Created attachment 1327057 [details] File: cpuinfo
Created attachment 1327058 [details] File: dso_list
Created attachment 1327059 [details] File: environ
Created attachment 1327060 [details] File: limits
Created attachment 1327061 [details] File: maps
Created attachment 1327062 [details] File: open_fds
Created attachment 1327063 [details] File: proc_pid_status
Created attachment 1327064 [details] File: var_log_messages
*** Bug 1529996 has been marked as a duplicate of this bug. ***
Similar problem has been detected: I ran a debug version of GROMACS with the scenario desribed here: https://redmine.gromacs.org/issues/2152 In GDB, I typed "record" and then "cont". reporter: libreport-2.9.3 backtrace_rating: 4 cmdline: gdb --args gmx mdrun -deffnm bd_verlet crash_function: dump_core executable: /usr/libexec/gdb journald_cursor: s=c8ad4445e021464a8d685d6eea1b70ca;i=14e20da;b=f174beb67e29458a82171f1bb03492ec;m=194062f323e;t=5624611acdc6b;x=ac253e2f2dea9e7d kernel: 4.14.6-300.fc27.x86_64 package: gdb-headless-8.0.1-33.fc27 reason: gdb killed by SIGABRT rootdir: / runlevel: N 5 type: CCpp uid: 7057
Created attachment 1378587 [details] File: backtrace
So this bug has been reported quite a few times by a few independent reporters, and even received an EOL on the earlier reports. Given the significance of the affected component (gdb is *the* linux debugger), is there any chance to get this fixed? Should it be reported upstream?
Those are 3 unrelated Bugs. ABRT is confused because GDB uses its own internal error handler. IMO GDB should sort of disable its own handler when running under ABRT but then it has some user convenience drawbacks. Sure anything is best to report upstream but for such case one needs to find a reproducer first which is difficult. Bug 1529996 Comment 1: ../../gdb/breakpoint.c:6387: internal-error: void print_one_breakpoint_location(breakpoint*, bp_location*, int, bp_location**, int): Assertion `b->loc == NULL || b->loc->next == NULL' failed. Bug 1492496 Comment 1: ../../gdb/dwarf2loc.c:2283: internal-error: value* coerce_pieced_ref(const value*): Assertion `closure->n_pieces == 1' failed. Bug 1492496 Comment 14: ../../gdb/nat/x86-linux-dregs.c:146: internal-error: void x86_linux_update_debug_registers(lwp_info*): Assertion `lwp_is_stopped (lwp)' failed.
*** Bug 1539389 has been marked as a duplicate of this bug. ***
*** Bug 1562283 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This bug appears to have been reported against 'rawhide' during the Fedora 30 development cycle. Changing version to '30.
*** Bug 1701136 has been marked as a duplicate of this bug. ***
Similar problem has been detected: Tried to send a problem report with abrt. Exception thrown during local retrace. reporter: libreport-2.10.0 backtrace_rating: 4 cmdline: /usr/libexec/gdb -batch -iex add-auto-load-safe-path /var/cache/abrt-di/usr/lib/debug -iex add-auto-load-scripts-directory /var/cache/abrt-di/usr/lib/debug -ex set debug-file-directory /usr/lib/debug:/var/cache/abrt-di/usr/lib/debug -ex file /usr/bin/gnome-shell -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 crash_function: dump_core executable: /usr/libexec/gdb journald_cursor: s=0c656f464f2f4963982be81f93b27058;i=4e7d;b=15182d6c5db94076be9647c08df37859;m=1b5f34afc;t=587ecbd37d184;x=bd8a77c04ea4b0f2 kernel: 5.0.9-301.fc30.x86_64 package: gdb-headless-8.2.91.20190424-24.fc30 reason: gdb killed by SIGABRT rootdir: / runlevel: N 5 type: CCpp uid: 1000
Similar problem has been detected: I tried to report a bug and the process crashed. reporter: libreport-2.10.0 backtrace_rating: 4 cmdline: /usr/libexec/gdb -batch -iex add-auto-load-safe-path /var/cache/abrt-di/usr/lib/debug -iex add-auto-load-scripts-directory /var/cache/abrt-di/usr/lib/debug -ex set debug-file-directory /usr/lib/debug:/var/cache/abrt-di/usr/lib/debug -ex file /usr/bin/gjs-console -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 crash_function: dump_core executable: /usr/libexec/gdb journald_cursor: s=5d0777751eee4ab4b8072af84df97748;i=10099;b=c6b58db610e44675901b4e450a55cfc9;m=9eb3746c;t=5888b4b4bd45e;x=96ed8e49261f791a kernel: 5.0.11-300.fc30.x86_64 package: gdb-headless-8.2.91.20190424-24.fc30 reason: gdb killed by SIGABRT rootdir: / runlevel: N 5 type: CCpp uid: 1000
*** Bug 1708824 has been marked as a duplicate of this bug. ***
*** Bug 1709762 has been marked as a duplicate of this bug. ***
*** Bug 1710714 has been marked as a duplicate of this bug. ***
Similar problem has been detected: I tried to do a "step" on a position in my code. GDB was connected to qemu. GDB always crashes on this specific position. reporter: libreport-2.10.0 backtrace_rating: 4 cmdline: gdb -x /tmp/tmp.KxbX6ubyq2 ./build/system crash_function: dump_core executable: /usr/libexec/gdb journald_cursor: s=301557483ea04505a95709ba86c54a96;i=f4e45;b=75504e5ff95449788b8e4fae9d573713;m=40fd34d386;t=5897b6d2200cf;x=46d24c8f2a1b3193 kernel: 5.0.13-300.fc30.x86_64 package: gdb-headless-8.3-2.fc30 reason: gdb killed by SIGABRT rootdir: / runlevel: N 5 type: CCpp uid: 1000
(In reply to sedrubal from comment #27) > Similar problem has been detected: > > I tried to do a "step" on a position in my code. GDB was connected to qemu. > GDB always crashes on this specific position. > > reporter: libreport-2.10.0 > backtrace_rating: 4 > cmdline: gdb -x /tmp/tmp.KxbX6ubyq2 ./build/system > crash_function: dump_core > executable: /usr/libexec/gdb > journald_cursor: > s=301557483ea04505a95709ba86c54a96;i=f4e45; > b=75504e5ff95449788b8e4fae9d573713;m=40fd34d386;t=5897b6d2200cf; > x=46d24c8f2a1b3193 > kernel: 5.0.13-300.fc30.x86_64 > package: gdb-headless-8.3-2.fc30 > reason: gdb killed by SIGABRT > rootdir: / > runlevel: N 5 > type: CCpp > uid: 1000 Would you be able to generate a corefile from this failure? Actually, if you're feeling adventurous, you can try compiling upstream GDB with debuginfo and generating a corefile/backtrace from it. Thanks.
*** Bug 1718474 has been marked as a duplicate of this bug. ***
Created attachment 1581232 [details] Gzipped core dump
I attached a gzipped core dump. I'm not sure, if I've done it correctly and if it is still the same issue...
Similar problem has been detected: Crash happened during automatic local strack trace of another crashed app. reporter: libreport-2.11.3 backtrace_rating: 4 cmdline: /usr/libexec/gdb -batch -iex add-auto-load-safe-path /var/cache/abrt-di/usr/lib/debug -iex add-auto-load-scripts-directory /var/cache/abrt-di/usr/lib/debug -ex set debug-file-directory /usr/lib/debug:/var/cache/abrt-di/usr/lib/debug -ex file /usr/bin/nautilus -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 crash_function: dump_core executable: /usr/libexec/gdb journald_cursor: s=6447181e4efb4e378a631ce42aaf141e;i=1e9bb;b=42db3da9cf4e4269ae21013cbbf4dac6;m=1225c807c7;t=599cc5985a053;x=29c1811518e4b75 kernel: 5.3.15-200.fc30.x86_64 package: gdb-headless-8.3-7.fc30 reason: gdb killed by SIGABRT rootdir: / runlevel: N 5 type: CCpp uid: 1000
Created attachment 1667048 [details] Another core dump Another core dump that triggers the crash, when using 'bt full'
(In reply to Jan Kratochvil from comment #16) > Sure anything is best to report upstream but for such case one needs to find > a reproducer first which is difficult. I have a reliable reproducer for this one: > Bug 1492496 Comment 1: ../../gdb/dwarf2loc.c:2283: internal-error: value* > coerce_pieced_ref(const value*): Assertion `closure->n_pieces == 1' failed. This happens 100% when processing the WebKit crash https://bugs.webkit.org/show_bug.cgi?id=200863 with (gdb) bt full. Problem is, that WebKit crash isn't reproducible, so to reproduce the gdb crash we have to use one of the core dumps attached here. And unfortunately the core dump I've attached here was taken when Epiphany crashed when running under flatpak. So while you can definitely use this core dump to reproduce the gdb crash, the process will be a little involved if you're not used to (a) installing flatpak debug extensions, for both application and runtime, [1], and (b) pinning the app and runtime to the ostree revision I was using at the time of the crash, [2]. If anyone's interested in working on this during the next month or two before the old runtime gets pruned from the ostree server (at which point this core dump will no longer be useful), I can walk you through the required steps. [1] http://www.figuiere.net/hub/blog/?2019/10/11/878-getting-a-stack-trace-out-of-a-flatpak [2] https://github.com/flatpak/flatpak/wiki/Tips-&-Tricks#downgrading It'd probably be easier to start with the core dump attached by sedrubal and hope that's still useful, since that wouldn't require using flatpak. This core dump was taken with: org.gnome.Epiphany.Devel//master: 2c9c35761b5ff1876be936132db502387178b08d12c413ff3ec47a362976832d org.gnome.Epiphany.Devel.Debug//master: 23ccb84efceaf38ef8a506ce6066676358bd2cd32e0ff3dd7eefff023030b2f4 org.gnome.Platform//master: 35c7cbc4271bc3e2ee9225b3d8e6e49bda650866a919035c0dec5fba95ae56ca org.gnome.Sdk.Debug//master: 74f1d0c7d9a9f0055e3dc621bedbe4c77019fa439a721b39aba38a7bfda3af7f Note this org.gnome.Sdk contains upstream gdb 8.3 (built by freedesktop-sdk), not Fedora's gdb. The crash looks like this: $ flatpak-coredumpctl -m 80376 org.gnome.Epiphany.Devel Executable /usr/libexec/webkit2gtk-4.0/WebKitWebProcess doesn't seem to be a flatpaked application. Running: `"flatpak" "run" "--filesystem=home" "--filesystem=/tmp" "--command=gdb" "--devel" "org.gnome.Epiphany.Devel" "/usr/libexec/webkit2gtk-4.0/WebKitWebProcess" "/tmp/tmpzk_jr0k_"` GNU gdb (GDB) 8.3 Copyright (C) 2019 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-unknown-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://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 /usr/libexec/webkit2gtk-4.0/WebKitWebProcess... Reading symbols from /usr/lib/debug//usr/libexec/webkit2gtk-4.0/WebKitWebProcess.debug... warning: core file may not match specified executable file. [New LWP 3265] [New LWP 2557] [New LWP 2556] [New LWP 2559] [New LWP 2551] [New LWP 2577] [New LWP 2613] [New LWP 2609] [New LWP 3268] [New LWP 2585] [New LWP 2591] [New LWP 2568] [New LWP 2570] [New LWP 3269] [New LWP 3270] [New LWP 2608] [New LWP 2569] [New LWP 3271] [New LWP 2849] [New LWP 2567] [New LWP 2615] [New LWP 3267] [New LWP 2626] [New LWP 2590] [New LWP 2633] [New LWP 2587] [New LWP 2602] [New LWP 2574] [New LWP 2579] [New LWP 2988] [New LWP 2617] [New LWP 2630] [New LWP 2628] [New LWP 2605] [New LWP 2601] [New LWP 2589] [New LWP 3266] [New LWP 2604] [New LWP 2572] [New LWP 2989] [New LWP 2632] [New LWP 2592] [New LWP 2624] [New LWP 2603] [New LWP 2598] [New LWP 2606] [New LWP 2635] [New LWP 2560] [New LWP 2563] [New LWP 2599] [New LWP 2573] [New LWP 2600] [New LWP 2594] [New LWP 2596] [New LWP 2622] [New LWP 2620] [New LWP 2612] [New LWP 2564] [New LWP 2588] [New LWP 2610] [New LWP 2549] [New LWP 2561] [New LWP 2555] [New LWP 2619] [New LWP 2554] [New LWP 2586] [New LWP 2583] [New LWP 2571] [New LWP 3004] [New LWP 2621] [New LWP 2614] [New LWP 2584] [New LWP 2607] [New LWP 2575] [New LWP 2636] [New LWP 2611] [New LWP 2597] [New LWP 2553] [New LWP 2616] [New LWP 2552] [New LWP 2565] [New LWP 2578] [New LWP 2576] [New LWP 2562] [New LWP 2595] [New LWP 2618] [New LWP 2582] [New LWP 3259] [New LWP 2581] [New LWP 2566] [New LWP 2580] [New LWP 3233] [New LWP 2623] [New LWP 2625] [New LWP 2593] [New LWP 2627] [New LWP 2987] [New LWP 2631] [New LWP 2634] [New LWP 2629] [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/x86_64-linux-gnu/libthread_db.so.1". warning: the debug information found in "/usr/lib/debug//app/lib/libdazzle-1.0.so.0.debug" does not match "/app/lib/libdazzle-1.0.so.0" (CRC mismatch). Core was generated by `/usr/libexec/webkit2gtk-4.0/WebKitWebProcess 143 153'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f3f5bcfabf8 in JSC::SlotVisitor::visitChildren (cell=0x7f3da46f8780, this=0x7f3f559cb2b8) at ../Source/JavaScriptCore/runtime/Structure.h:538 538 const ClassInfo* classInfo() const { return m_classInfo; } [Current thread is 1 (Thread 0x7f3d7ffff700 (LWP 3265))] (gdb) bt full #0 0x00007f3f5bcfabf8 in JSC::SlotVisitor::visitChildren(JSC::JSCell const*) (cell=0x7f3da46f8780, this=0x7f3f559cb2b8) at ../Source/JavaScriptCore/runtime/Structure.h:538 countdown = 38 status = <optimized out> locker = {<WTF::AbstractLocker> = {<No data fields>}, m_lockable = 0x7f3f559cb347} #1 0x00007f3f5bcfabf8 in JSC::SlotVisitor::<lambda(JSC::MarkStackArray&)>::operator() (__closure=<optimized out>, stack=...) at ../Source/JavaScriptCore/heap/SlotVisitor.cpp:520 countdown = 38 status = <optimized out> locker = {<WTF::AbstractLocker> = {<No data fields>}, m_lockable = 0x7f3f559cb347} #2 0x00007f3f5bcfabf8 in JSC::SlotVisitor::forEachMarkStack<JSC::SlotVisitor::drain(WTF::MonotonicTime)::<lambda(JSC::MarkStackArray&)> > (func=..., this=0x7f3f559cb2b8) at ../Source/JavaScriptCore/heap/SlotVisitorInlines.h:190 status = <optimized out> locker = {<WTF::AbstractLocker> = {<No data fields>}, m_lockable = 0x7f3f559cb347} #3 0x00007f3f5bcfabf8 in JSC::SlotVisitor::drain(WTF::MonotonicTime) (this=0x7f3f559cb2b8, timeout=...) at ../Source/JavaScriptCore/heap/SlotVisitor.cpp:510 status = <optimized out> locker = {<WTF::AbstractLocker> = {<No data fields>}, m_lockable = 0x7f3f559cb347} #4 0x00007f3f5bcfb592 in JSC::SlotVisitor::drainFromShared(JSC::SlotVisitor::SharedDrainMode, WTF::MonotonicTime) (this=this@entry=0x7f3f559cb2b8, sharedDrainMode=sharedDrainMode@entry=JSC::SlotVisitor::SlaveDrain, timeout=..., timeout@entry=...) at ../Source/JavaScriptCore/heap/SlotVisitor.cpp:710 bonusTask = <optimized out> isActive = <optimized out> #5 0x00007f3f5bcd08ad in JSC::Heap::<lambda()>::operator() (__closure=0x7f3d8c005f28) at ../Source/JavaScriptCore/heap/Heap.cpp:1313 slotVisitor = 0x7f3f559cb2b8 #6 0x00007f3f5bcd08ad in WTF::SharedTaskFunctor<void(), JSC::Heap::runBeginPhase(JSC::GCConductor)::<lambda()> >::run(void) (this=0x7f3d8c005f18) at DerivedSources/ForwardingHeaders/wtf/SharedTask.h:91 #7 0x00007f3f5c4780eb in WTF::ParallelHelperClient::runTask(WTF::RefPtr<WTF::SharedTask<void ()>, WTF::DumbPtrTraits<WTF::SharedTask<void ()> > > const&) (this=0x7f3ee84003f8, task=...) at ../Source/WTF/wtf/ParallelHelperPool.cpp:112 #8 0x00007f3f5c478fe5 in WTF::ParallelHelperPool::Thread::work() (this=0x7f3e342f7af8) at ../Source/WTF/wtf/ParallelHelperPool.cpp:200 #9 0x00007f3f5c465f5a in WTF::AutomaticThread::<lambda()>::operator() (__closure=<optimized out>) at ../Source/WTF/wtf/AutomaticThread.cpp:223 result = <optimized out> thread = {static isRefPtr = <error reading variable: Missing ELF symbol "WTF::RefPtr<WTF::AutomaticThread, WTF::DumbPtrTraits<WTF::AutomaticThread> >::isRefPtr".>, m_ptr = 0x7f3e342f7af8} stopPermanently = ../../gdb/dwarf2loc.c:2077: internal-error: value* coerce_pieced_ref(const value*): Assertion `closure->pieces.size () == 1' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) y This is a bug, please report it. For instructions, see: <http://www.gnu.org/software/gdb/bugs/>. ../../gdb/dwarf2loc.c:2077: internal-error: value* coerce_pieced_ref(const value*): Assertion `closure->pieces.size () == 1' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) y Traceback (most recent call last): File "/usr/bin/flatpak-coredumpctl", line 83, in <module> coredumper.run() File "/usr/bin/flatpak-coredumpctl", line 58, in run subprocess.check_call(flatpak_command) File "/usr/lib64/python3.7/subprocess.py", line 363, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['flatpak', 'run', '--filesystem=home', '--filesystem=/tmp', '--command=gdb', '--devel', 'org.gnome.Epiphany.Devel', '/usr/libexec/webkit2gtk-4.0/WebKitWebProcess', '/tmp/tmpzk_jr0k_']' returned non-zero exit status 134.
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.