Bug 1535174 - gdb perf - crash
Summary: gdb perf - crash
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 29
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1539239 (view as bug list)
Depends On: 1708786
Blocks: 1614379
TreeView+ depends on / blocked
 
Reported: 2018-01-16 18:52 UTC by Paulo Andrade
Modified: 2019-10-24 12:20 UTC (History)
40 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-09-17 20:04:43 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
File: backtrace (142.62 KB, text/plain)
2018-04-27 21:18 UTC, Niki Guldbrand
no flags Details
perf rhel8 binary before strip (7.46 MB, application/gzip)
2019-01-16 14:26 UTC, Jiri Olsa
no flags Details
perf rpm build log (888.59 KB, text/plain)
2019-01-16 14:27 UTC, Jiri Olsa
no flags Details
perf and perf.debug ppc64le binaries (6.59 MB, application/x-bzip)
2019-01-17 11:04 UTC, Jiri Olsa
no flags Details


Links
System ID Private Priority Status Summary Last Updated
IBM Linux Technology Center 174673 0 None None None 2019-07-20 01:05:22 UTC

Description Paulo Andrade 2018-01-16 18:52:39 UTC
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

Comment 1 Jan Kratochvil 2018-02-07 21:30:19 UTC
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.

Comment 2 Jan Kratochvil 2018-02-08 08:02:45 UTC
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

Comment 3 Jan Kratochvil 2018-03-04 06:41:04 UTC
*** Bug 1539239 has been marked as a duplicate of this bug. ***

Comment 4 Frank Ch. Eigler 2018-04-12 18:53:39 UTC
> 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.

Comment 5 Niki Guldbrand 2018-04-27 21:18:36 UTC
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

Comment 6 Niki Guldbrand 2018-04-27 21:18:44 UTC
Created attachment 1427838 [details]
File: backtrace

Comment 7 Niki Guldbrand 2018-04-27 21:34:24 UTC
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

Comment 8 Ben Cotton 2018-11-27 13:58:08 UTC
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.

Comment 9 Ben Cotton 2018-11-30 23:17:47 UTC
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.

Comment 10 Hanns-Joachim Uhl 2019-01-14 14:34:24 UTC
... per e.g. comment #7 I understand that the problem in this bugzilla is still included in Fedora 29 ... reopening this Red Hat bugzilla ...

Comment 11 Hanns-Joachim Uhl 2019-01-14 14:37:48 UTC
... 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 12 IBM Bug Proxy 2019-01-14 16:00:32 UTC
------- 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.

Comment 13 Mark Wielaard 2019-01-16 14:10:00 UTC
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.

Comment 14 Jiri Olsa 2019-01-16 14:24:56 UTC
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

Comment 15 Jiri Olsa 2019-01-16 14:26:41 UTC
Created attachment 1521053 [details]
perf rhel8 binary before strip

Comment 16 Jiri Olsa 2019-01-16 14:27:10 UTC
Created attachment 1521054 [details]
perf rpm build log

Comment 17 Jiri Olsa 2019-01-16 14:31:40 UTC
(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

Comment 18 Jiri Olsa 2019-01-17 11:04:50 UTC
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
...

Comment 19 Jan Kratochvil 2019-01-17 11:53:10 UTC
(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'.

Comment 20 Jiri Olsa 2019-01-17 13:02:33 UTC
(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

Comment 21 Justin M. Forbes 2019-01-29 16:13:34 UTC
*********** 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 22 IBM Bug Proxy 2019-02-14 06:40:47 UTC
------- Comment From TMRICHT.com 2019-02-14 01:35 EDT-------
Fixed

Comment 23 IBM Bug Proxy 2019-03-13 12:40:56 UTC
------- 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.

Comment 24 Laura Abbott 2019-04-09 20:44:49 UTC
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.

Comment 25 Sergio Durigan Junior 2019-05-09 18:20:37 UTC
*** Bug 1708192 has been marked as a duplicate of this bug. ***

Comment 26 Paulo Andrade 2019-05-09 18:50:36 UTC
  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)

Comment 27 Sergio Durigan Junior 2019-05-10 19:53:31 UTC
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.

Comment 28 Mark Wielaard 2019-05-10 20:47:25 UTC
(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.

Comment 29 Sergio Durigan Junior 2019-05-10 21:11:18 UTC
(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.

Comment 30 Justin M. Forbes 2019-08-20 17:41:15 UTC
*********** 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.

Comment 31 Justin M. Forbes 2019-09-17 20:04:43 UTC
*********** 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.


Note You need to log in before you can comment on or make changes to this bug.