While attempting to debug an issue in f27 perf, I found I could not debug it with gdb: $ uname -r 4.14.5-300.fc27.x86_64 $ rpm -q gdb perf perf-debuginfo kernel-debuginfo gdb-8.0.1-33.fc27.x86_64 perf-4.14.13-300.fc27.x86_64 perf-debuginfo-4.14.13-300.fc27.x86_64 kernel-debuginfo-4.14.5-300.fc27.x86_64 $ gdb -q perf Reading symbols from perf...Reading symbols from /usr/lib/debug/usr/bin/perf.debug...done. done. Segmentation fault (imagem do núcleo gravada) $ gdb -q --args gdb -q perf Reading symbols from gdb...Reading symbols from /usr/lib/debug/usr/libexec/gdb-8.0.1-33.fc27.x86_64.debug...done. done. (gdb) r Starting program: /usr/bin/gdb -q perf [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Detaching after vfork from child process 29186. [New Thread 0x7fffeb7f8700 (LWP 29187)] [New Thread 0x7fffeaff7700 (LWP 29188)] [New Thread 0x7fffea7f6700 (LWP 29189)] Reading symbols from perf...Reading symbols from /usr/lib/debug/usr/bin/perf.debug...done. done. Thread 1 "gdb" received signal SIGSEGV, Segmentation fault. 0x000055555587e44d in parse_macro_definition (body=<optimized out>, line=<optimized out>, file=<optimized out>) at ../../gdb/dwarf2read.c:21774 21774 for (p = body; *p; p++) (gdb) p p $1 = 0x0 (gdb) p body $2 = <optimized out> (gdb) frame 1 #1 dwarf_decode_macro_bytes (abfd=abfd@entry=0x5555562ee500, mac_ptr=0x7fffe8a7c82b "\005", mac_ptr@entry=0x7fffe8a7c7f2 "\004", mac_end=mac_end@entry=0x7fffe8af5721 "", current_file=current_file@entry=0x555556b83a70, lh=lh@entry=0x555556a27cd0, section=section@entry=0x555556aa55c0, section_is_gnu=1, section_is_dwz=0, offset_size=<optimized out>, include_hash=0x555556a69ff0) at ../../gdb/dwarf2read.c:22191 22191 parse_macro_definition (current_file, line, body); (gdb) p body $3 = 0x0
BTW the debug info seems really corrupted, even readelf cannot parse it well. I haven't found the details yet why. GDB is known to crash on corrupted debug info.
I do not say it is GCC bug but it is definitely not a GDB bug. rpm2cpio </tmp/perf-debuginfo-4.14.18-300.fc27.x86_64.rpm|cpio -i --to-stdout ./usr/lib/debug/usr/bin/perf.debug >perf.debug;readelf -wm perf.debug 2>&1 >/dev/null|head readelf: perf.debug: Warning: DW_FORM_strp offset too big: ffe9a readelf: perf.debug: Warning: DW_FORM_strp offset too big: ee537 ... When I rebuild kernel-4.14.18-300.fc27.x86_64 locally I get correct perf.debug: -=koji +=local rebuild on F-27 - [32] .debug_info PROGBITS 0000000000000000 0039c0 56894a 00 0 0 1 + [32] .debug_info PROGBITS 0000000000000000 0039c0 567f7e 00 0 0 1 - [33] .debug_abbrev PROGBITS 0000000000000000 56c30a 04e653 00 0 0 1 + [33] .debug_abbrev PROGBITS 0000000000000000 56b93e 04e436 00 0 0 1 - [34] .debug_line PROGBITS 0000000000000000 5ba95d 1561c9 00 0 0 1 + [34] .debug_line PROGBITS 0000000000000000 5b9d74 17072c 00 0 0 1 - [35] .debug_str PROGBITS 0000000000000000 710b26 04b231 01 MS 0 0 1 + [35] .debug_str PROGBITS 0000000000000000 72a4a0 1010e0 01 MS 0 0 1 - [36] .debug_loc PROGBITS 0000000000000000 75bd57 3d8aa1 00 0 0 1 + [36] .debug_loc PROGBITS 0000000000000000 82b580 3d7b5a 00 0 0 1 - [37] .debug_ranges PROGBITS 0000000000000000 b34800 0a5310 00 0 0 16 + [37] .debug_ranges PROGBITS 0000000000000000 c030e0 0a4f70 00 0 0 16 - [38] .debug_macro PROGBITS 0000000000000000 bd9b10 0c6c6f 00 0 0 1 + [38] .debug_macro PROGBITS 0000000000000000 ca8050 0c6f87 00 0 0 1 There are some little differences (I did not have the same NVRA of all packages) but primarily .debug_str from Koji has only 1/4 the size of a local one. I do not see any errors in Koji build log: https://koji.fedoraproject.org/koji/buildinfo?buildID=1030043 https://kojipkgs.fedoraproject.org//packages/kernel/4.14.18/300.fc27/data/logs/x86_64/build.log DWZ or gdb-add-index etc. should not be an issue as kernel.spec disables them: %undefine _include_minidebuginfo %undefine _find_debuginfo_dwz_opts %undefine _include_gdb_index
*** Bug 1539239 has been marked as a duplicate of this bug. ***
> GDB is known to crash on corrupted debug info. > [...] it is definitely not a GDB bug. It may or may not be worth fixing, but as a philosophical matter, crashing on bad input is a bug.
Similar problem has been detected: Tried to load a coredump in gdb reporter: libreport-2.9.3 backtrace_rating: 4 cmdline: gdb pcbnew_18282.core crash_function: parse_macro_definition executable: /usr/libexec/gdb journald_cursor: s=7d2eb75cfeaf430d8226089439b97607;i=8b16b9;b=9da22fe11f8e4bb4a7e80f49e87b0def;m=8c6f552dd0;t=56adafa18f9aa;x=fda8b4a428aa3760 kernel: 4.15.17-300.fc27.x86_64 machineid: systemd=092b753c6a7e448686e037395a7f8228 package: gdb-headless-8.0.1-36.fc27 reason: gdb killed by SIGSEGV rootdir: / runlevel: N 5 type: CCpp uid: 1000
Created attachment 1427838 [details] File: backtrace
Similar problem has been detected: Tried to load a core file reporter: libreport-2.9.3 backtrace_rating: 4 cmdline: gdb --exec /usr/bin/pcbnew --core pcbnew_18282.core crash_function: parse_macro_definition executable: /usr/libexec/gdb journald_cursor: s=7d2eb75cfeaf430d8226089439b97607;i=8b1737;b=9da22fe11f8e4bb4a7e80f49e87b0def;m=8c91cc557e;t=56adb1c902158;x=1cc04457414a4750 kernel: 4.15.17-300.fc27.x86_64 machineid: systemd=092b753c6a7e448686e037395a7f8228 package: gdb-headless-8.0.1-36.fc27 reason: gdb killed by SIGSEGV rootdir: / runlevel: N 5 type: CCpp uid: 1000
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.
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 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.
... per e.g. comment #7 I understand that the problem in this bugzilla is still included in Fedora 29 ... reopening this Red Hat bugzilla ...
... and from my understanding this bugzilla is an issue most likely not in gcc but anywhere in kernel / perf e.g. in the related packaging ... ... moving this Red Hat bugzilla to kernel for now ...
------- Comment From arnez.com 2019-01-14 10:58 EDT------- Problem still exists on FC29: $ readelf -Wwm /usr/lib/debug/usr/bin/perf-4.21.0-20190111.rc0.git0.c1a20b899c84.300.fc29.s390x.debug 1>/dev/null readelf: /usr/lib/debug/usr/bin/perf-4.21.0-20190111.rc0.git0.c1a20b899c84.300.fc29.s390x.debug: Warning: DW_FORM_strp offset too big: 106ca6 readelf: /usr/lib/debug/usr/bin/perf-4.21.0-20190111.rc0.git0.c1a20b899c84.300.fc29.s390x.debug: Warning: DW_FORM_strp offset too big: f8cbb readelf: /usr/lib/debug/usr/bin/perf-4.21.0-20190111.rc0.git0.c1a20b899c84.300.fc29.s390x.debug: Warning: DW_FORM_strp offset too big: f7fc6 readelf: /usr/lib/debug/usr/bin/perf-4.21.0-20190111.rc0.git0.c1a20b899c84.300.fc29.s390x.debug: Warning: DW_FORM_strp offset too big: eeeed As Jan already pointed out, the .debug_str section looks truncated.
I see in some comments readelf -S output that this 'perf' binary has a .debug_macro section, which seems to indicate that it is build with -g3. There debugedit doesn't handle .debug_macro correctly. Would it be possible to post the build/link line for the perf binary? Might it be possible to attach the binary before it has been mangled by debugedit? If the binary is build with -g3 then you could work around it by removing it for now.
the perf binary is mangled by debugedit executed without find-debuginfo.sh during the kernel/perf rpm build it's only the problem if the rpm 4.14 version, the v4.13 version works fine will attach perf binary and perf buildlog jirka
Created attachment 1521053 [details] perf rhel8 binary before strip
Created attachment 1521054 [details] perf rpm build log
(In reply to Mark Wielaard from comment #13) SNIP > If the binary is build with -g3 then you could work around it by removing it > for now. that seems to work.. will make separate BZ for that to get it to rhel8 thanks, jirka
Created attachment 1521261 [details] perf and perf.debug ppc64le binaries perf and perf.debug ppc64le binaries compiled with -g it works with gdb, gdb wouldn't crash anymore but it still spits warnings in the readelf: [root@ibm-p9b-23 ~]# readelf -wm /usr/lib/debug/usr/bin/perf.debug 2>&1 >/dev/null ... readelf: /usr/lib/debug/usr/bin/perf.debug: Warning: DW_FORM_strp offset too big: 57fa9 readelf: /usr/lib/debug/usr/bin/perf.debug: Warning: DW_FORM_strp offset too big: 5858c readelf: /usr/lib/debug/usr/bin/perf.debug: Warning: DW_FORM_strp offset too big: 5e24d readelf: /usr/lib/debug/usr/bin/perf.debug: Warning: DW_FORM_strp offset too big: 5f44f readelf: /usr/lib/debug/usr/bin/perf.debug: Warning: DW_FORM_strp offset too big: 5f271 readelf: /usr/lib/debug/usr/bin/perf.debug: Warning: DW_FORM_strp offset too big: 5f74c readelf: /usr/lib/debug/usr/bin/perf.debug: Warning: DW_FORM_strp offset too big: 5f288 readelf: /usr/lib/debug/usr/bin/perf.debug: Warning: DW_FORM_strp offset too big: 5db43 readelf: /usr/lib/debug/usr/bin/perf.debug: Warning: DW_FORM_strp offset too big: 5e265 readelf: /usr/lib/debug/usr/bin/perf.debug: Warning: DW_FORM_strp offset too big: 5cfef readelf: /usr/lib/debug/usr/bin/perf.debug: Warning: DW_FORM_strp offset too big: 5f4b0 readelf: /usr/lib/debug/usr/bin/perf.debug: Warning: DW_FORM_strp offset too big: 52343 readelf: /usr/lib/debug/usr/bin/perf.debug: Warning: DW_FORM_strp offset too big: 52314 ...
(In reply to Jiri Olsa from comment #18) > Created attachment 1521261 [details] > perf and perf.debug ppc64le binaries .debug_info strings are fine, .debug_macro strings are cut-off. > perf and perf.debug ppc64le binaries compiled with -g Only 'gcc -g' with no postprocessing? Then it is gcc or binutils (ld) bug - you could also check using '-fuse-ld=gold'.
(In reply to Jan Kratochvil from comment #19) > (In reply to Jiri Olsa from comment #18) > > Created attachment 1521261 [details] > > perf and perf.debug ppc64le binaries > > .debug_info strings are fine, .debug_macro strings are cut-off. > > > > perf and perf.debug ppc64le binaries compiled with -g > > Only 'gcc -g' with no postprocessing? Then it is gcc or binutils (ld) bug - > you could also check using '-fuse-ld=gold'. ok, we have 2 more libraries linked statically, which had -ggdb3, after removing that, we're fine.. sry for the noise, the workaround (using -g) seems to be ok jirka
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 29 kernel bugs. Fedora 29 has now been rebased to 4.20.5-200.fc29. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
------- Comment From TMRICHT.com 2019-02-14 01:35 EDT------- Fixed
------- Comment From TMRICHT.com 2019-03-13 08:35 EDT------- I have updated my x86 Fedora 29 installation to the latest level today, and the issue shows up again. Here is my sequence of commands: [root@f29 ~]# uname -a Linux f29 4.20.14-200.fc29.x86_64 #1 SMP Tue Mar 5 19:55:32 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux [root@f29 ~]# gdb -v GNU gdb (GDB) Fedora 8.2-6.fc29 Copyright (C) 2018 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. [root@f29 ~]# gdb perf GNU gdb (GDB) Fedora 8.2-6.fc29 Copyright (C) 2018 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: <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 perf...Reading symbols from /usr/lib/debug/usr/bin/perf-4.20.11-200.fc29.x86_64.debug...done. Segmentation fault (core dumped) [root@f29 ~]# In fact it is the same root cause as before: root@f29 ~]# readelf -wm /usr/lib/debug/usr/bin/perf-4.20.11-200.fc29.x86_64.debug 2>&1 | fgrep 'DW_FORM_strp offset too big' | head -10 readelf: /usr/lib/debug/usr/bin/perf-4.20.11-200.fc29.x86_64.debug: Warning: DW_FORM_strp offset too big: f6e56 readelf: /usr/lib/debug/usr/bin/perf-4.20.11-200.fc29.x86_64.debug: Warning: DW_FORM_strp offset too big: f61d8 readelf: /usr/lib/debug/usr/bin/perf-4.20.11-200.fc29.x86_64.debug: Warning: DW_FORM_strp offset too big: ece82 readelf: /usr/lib/debug/usr/bin/perf-4.20.11-200.fc29.x86_64.debug: Warning: DW_FORM_strp offset too big: f61d8 readelf: /usr/lib/debug/usr/bin/perf-4.20.11-200.fc29.x86_64.debug: Warning: DW_FORM_strp offset too big: ece82 readelf: /usr/lib/debug/usr/bin/perf-4.20.11-200.fc29.x86_64.debug: Warning: DW_FORM_strp offset too big: f6e56 readelf: /usr/lib/debug/usr/bin/perf-4.20.11-200.fc29.x86_64.debug: Warning: DW_FORM_strp offset too big: f10d5 readelf: /usr/lib/debug/usr/bin/perf-4.20.11-200.fc29.x86_64.debug: Warning: DW_FORM_strp offset too big: f267a readelf: /usr/lib/debug/usr/bin/perf-4.20.11-200.fc29.x86_64.debug: Warning: DW_FORM_strp offset too big: f61d8 readelf: /usr/lib/debug/usr/bin/perf-4.20.11-200.fc29.x86_64.debug: Warning: DW_FORM_strp offset too big: ece82 [root@f29 ~]# There are some 13600 lines of these error messages. PS: The issue was fixed in the mean time, but it happens again.
We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 29 kernel bugs. Fedora XX has now been rebased to 5.0.6 Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 30, and are still experiencing this issue, please change the version to Fedora 30. If you experience different issues, please open a new bug report for those.
*** Bug 1708192 has been marked as a duplicate of this bug. ***
Did not yet update to Fedora 30. $ rpm -q gdb gdb-debuginfo perf perf-debuginfo gdb-8.2-6.fc29.x86_64 gdb-debuginfo-8.2-6.fc29.x86_64 perf-5.0.9-200.fc29.x86_64 perf-debuginfo-5.0.9-200.fc29.x86_64 Still crashing unfortunately: $ gdb -q --args gdb -q perf Reading symbols from gdb...Reading symbols from /usr/lib/debug/usr/libexec/gdb-8.2-6.fc29.x86_64.debug...done. done. (gdb) r Starting program: /usr/bin/gdb -q perf warning: Loadable section ".note.gnu.property" outside of ELF segments warning: Loadable section ".note.gnu.property" outside of ELF segments [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". warning: Loadable section ".note.gnu.property" outside of ELF segments warning: Loadable section ".note.gnu.property" outside of ELF segments warning: Loadable section ".note.gnu.property" outside of ELF segments warning: Loadable section ".note.gnu.property" outside of ELF segments warning: Loadable section ".note.gnu.property" outside of ELF segments warning: Loadable section ".note.gnu.property" outside of ELF segments warning: Loadable section ".note.gnu.property" outside of ELF segments [New Thread 0x7fffe9ac6700 (LWP 1276)] [New Thread 0x7fffe92c5700 (LWP 1277)] [New Thread 0x7fffe8ac4700 (LWP 1278)] [Detaching after vfork from child process 1279] Reading symbols from perf...Reading symbols from /usr/lib/debug/usr/bin/perf-5.0.9-200.fc29.x86_64.debug...done. done. Thread 1 "gdb" received signal SIGSEGV, Segmentation fault. dwarf_decode_macro_bytes (dwarf2_per_objfile=dwarf2_per_objfile@entry=0x5555569b8a90, abfd=abfd@entry=0x5555568194c0, mac_ptr=0x7fffe71edacf "\005", mac_ptr@entry=0x7fffe71ed9b8 "\004", mac_end=mac_end@entry=0x7fffe727289b "../../.dwz/kernel-tools-5.0.9-200.fc29.x86_64", current_file=current_file@entry=0x555556e44e80, lh=lh@entry=0x55555696a7c0, section=0x5555569b8b80, section_is_gnu=1, section_is_dwz=0, offset_size=<optimized out>, include_hash=0x555557062640) at ../../gdb/dwarf2read.c:24359 24359 ../../gdb/dwarf2read.c: No such file or directory. Missing separate debuginfos, use: dnf debuginfo-install bzip2-libs-1.0.6-28.fc29.x86_64 elfutils-libelf-0.174-5.fc29.x86_64 elfutils-libs-0.174-5.fc29.x86_64 expat-2.2.6-1.fc29.x86_64 gc-7.6.4-4.fc29.x86_64 glib2-2.58.2-1.fc29.x86_64 gmp-6.1.2-8.fc29.x86_64 guile-2.0.14-12.fc29.x86_64 libatomic_ops-7.6.6-1.fc29.x86_64 libbabeltrace-1.5.6-1.fc29.x86_64 libffi-3.1-18.fc29.x86_64 libgcc-8.2.1-6.fc29.x86_64 libipt-2.0-1.fc29.x86_64 libselinux-2.8-4.fc29.x86_64 libstdc++-8.2.1-6.fc29.x86_64 libunistring-0.9.10-4.fc29.x86_64 libuuid-2.32.1-1.fc29.x86_64 libxcrypt-4.4.2-3.fc29.x86_64 mpfr-3.1.6-2.fc29.x86_64 ncurses-libs-6.1-8.20180923.fc29.x86_64 pcre-8.42-5.fc29.x86_64 pcre2-10.32-4.fc29.x86_64 python3-libs-3.7.1-4.fc29.x86_64 readline-7.0-12.fc29.x86_64 xz-libs-5.2.4-3.fc29.x86_64 zlib-1.2.11-14.fc29.x86_64 (gdb) bt #0 dwarf_decode_macro_bytes (dwarf2_per_objfile=dwarf2_per_objfile@entry=0x5555569b8a90, abfd=abfd@entry=0x5555568194c0, mac_ptr=0x7fffe71edacf "\005", mac_ptr@entry=0x7fffe71ed9b8 "\004", mac_end=mac_end@entry=0x7fffe727289b "../../.dwz/kernel-tools-5.0.9-200.fc29.x86_64", current_file=current_file@entry=0x555556e44e80, lh=lh@entry=0x55555696a7c0, section=0x5555569b8b80, section_is_gnu=1, section_is_dwz=0, offset_size=<optimized out>, include_hash=0x555557062640) at ../../gdb/dwarf2read.c:24359 #1 0x00005555558d3f50 in dwarf_decode_macro_bytes (dwarf2_per_objfile=dwarf2_per_objfile@entry=0x5555569b8a90, abfd=abfd@entry=0x5555568194c0, mac_ptr=0x7fffe71d9640 "\003", mac_ptr@entry=0x7fffe71d9634 "\004", mac_end=mac_end@entry=0x7fffe727289b "../../.dwz/kernel-tools-5.0.9-200.fc29.x86_64", current_file=current_file@entry=0x555556e44e80, lh=lh@entry=0x55555696a7c0, section=0x5555569b8b80, section_is_gnu=1, section_is_dwz=0, offset_size=<optimized out>, include_hash=0x555557062640) at ../../gdb/dwarf2read.c:24475 #2 0x00005555558d466d in dwarf_decode_macros (cu=<optimized out>, offset=263652, section_is_gnu=1) at ../../gdb/dwarf2read.c:24703 #3 0x00005555558e81d4 in read_file_scope (cu=0x555556bb42c0, die=0x555556eb5990) at ../../gdb/dwarf2read.c:11509 #4 process_die (die=0x555556eb5990, cu=0x555556bb42c0) at ../../gdb/dwarf2read.c:10514 #5 0x00005555558ed558 in process_full_comp_unit (pretend_language=<optimized out>, per_cu=<optimized out>) at ../../gdb/dwarf2read.c:10274 #6 process_queue (dwarf2_per_objfile=<optimized out>, dwarf2_per_objfile=<optimized out>) at ../../gdb/dwarf2read.c:9499 #7 dw2_do_instantiate_symtab (per_cu=<optimized out>, skip_partial=<optimized out>) at ../../gdb/dwarf2read.c:2885 #8 0x00005555558eebdf in dwarf2_read_symtab (self=0x555556da4b20, objfile=0x555556a05f30) at ../../gdb/dwarf2read.c:9365 #9 0x000055555598c777 in psymtab_to_symtab (objfile=0x555556a05f30, pst=0x555556da4b20) at ../../gdb/psymtab.c:792 #10 0x0000555555990220 in psym_lookup_symbol (objfile=0x555556a05f30, block_index=0, name=0x5555569ea050 "main", domain=VAR_DOMAIN) at ../../gdb/psymtab.c:522 #11 0x00005555559ec3fc in lookup_symbol_via_quick_fns (domain=VAR_DOMAIN, name=0x5555569ea050 "main", block_index=0, objfile=0x555556a05f30) at ../../gdb/symtab.c:2384 #12 lookup_symbol_in_objfile (objfile=0x555556a05f30, block_index=block_index@entry=0, name=0x5555569ea050 "main", domain=VAR_DOMAIN) at ../../gdb/symtab.c:2559 #13 0x00005555559ec573 in lookup_symbol_global_iterator_cb (objfile=<optimized out>, cb_data=0x7fffffffcf30) at ../../gdb/symtab.c:2641 #14 0x0000555555975b61 in default_iterate_over_objfiles_in_search_order (gdbarch=<optimized out>, cb=0x5555559ec550 <lookup_symbol_global_iterator_cb(objfile*, void*)>, cb_data=0x7fffffffcf30, current_objfile=<optimized out>) at ../../gdb/objfiles.c:1536 #15 0x00005555559f1b51 in lookup_global_symbol (name=0x5555569ea050 "main", block=<optimized out>, domain=VAR_DOMAIN) at ../../gdb/symtab.c:2686 #16 0x00005555559f1727 in lookup_symbol_aux (name=0x5555569ea050 "main", match_type=match_type@entry=symbol_name_match_type::FULL, block=block@entry=0x0, domain=domain@entry=VAR_DOMAIN, language=language@entry=language_c, is_a_field_of_this=is_a_field_of_this@entry=0x0) at ../../gdb/symtab.c:2092 #17 0x00005555559f1963 in lookup_symbol_in_language (name=<optimized out>, block=0x0, domain=VAR_DOMAIN, lang=language_c, is_a_field_of_this=0x0) at ../../gdb/symtab.c:1885 #18 0x00005555559de416 in set_initial_language () at ../../gdb/symfile.c:1622 #19 0x000055555595e528 in catch_command_errors (command=0x55555595e3f0 <symbol_file_add_main_adapter(char const*, int)>, arg=0x7fffffffd729 "perf", from_tty=1) at ../../gdb/main.c:380 #20 0x000055555595fce4 in captured_main_1 (python_script=<synthetic pointer>: <optimized out>, context=0x7fffffffd230) at ../../gdb/main.c:1121 #21 captured_main (data=0x7fffffffd230) at ../../gdb/main.c:1246 #22 gdb_main (args=0x7fffffffd230) at ../../gdb/main.c:1284 #23 0x00005555556af89f in main (argc=<optimized out>, argv=<optimized out>) at ../../gdb/gdb.c:40 (gdb)
This bug seems to be related to the Linux kernel, but the problem is not there. Out of curiosity, is there any open bug against rpm-build that actually tracks the progress of this? I couldn't find any.
(In reply to Sergio Durigan Junior from comment #27) > This bug seems to be related to the Linux kernel, but the problem is not > there. Out of curiosity, is there any open bug against rpm-build that > actually tracks the progress of this? I couldn't find any. There doesn't seem to be a public bug tracking this. So I created bug #1708786 and assigned it to myself.
(In reply to Mark Wielaard from comment #28) > (In reply to Sergio Durigan Junior from comment #27) > > This bug seems to be related to the Linux kernel, but the problem is not > > there. Out of curiosity, is there any open bug against rpm-build that > > actually tracks the progress of this? I couldn't find any. > > There doesn't seem to be a public bug tracking this. So I created bug > #1708786 and assigned it to myself. Thanks, Mark! BTW, I've just submitted a patch upstream to "fix" GDB so that it doesn't crash on invalid DWARF: https://sourceware.org/ml/gdb-patches/2019-05/msg00268.html Not sure how the community will receive it, but it's worth trying. Needless to say, this patch *doesn't* fix the underlying problem.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 29 kernel bugs. Fedora 29 has now been rebased to 5.2.9-100.fc29. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 30, and are still experiencing this issue, please change the version to Fedora 30. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.