Description of problem: I ran eu-stack with a core dump file generated by gcore. $ sleep 1000 & $ SLEEP_PID=$! $ gcore $SLEEP_PID $ eu-stack --executable=/usr/bin/sleep --core=core.$SLEEP_PID eu-stack: link_map.c:846: dwfl_link_map_report: Assertion `in.d_size == phnum * phent' failed. Aborted (core dumped) Version-Release number of selected component: elfutils-0.166-2.fc25 Additional info: reporter: libreport-2.7.2.6.g6ac1 backtrace_rating: 3 cmdline: eu-stack --executable=/usr/bin/sleep --core=core.6984 executable: /usr/bin/eu-stack global_pid: 7060 kernel: 4.7.0-0.rc7.git4.2.fc25.x86_64 pkg_vendor: Fedora Project runlevel: N 5 type: CCpp uid: 18601 Truncated backtrace: Thread no. 1 (7 frames) #25 ?? #26 dwfl_link_map_report at link_map.c:846 #27 dwfl_core_file_report at core-file.c:531 #28 parse_opt at stack.c:595 #29 parser_parse_arg at argp-parse.c:716 #30 parser_parse_next at argp-parse.c:865 #31 __argp_parse at argp-parse.c:921
Created attachment 1189518 [details] File: backtrace
Created attachment 1189519 [details] File: cgroup
Created attachment 1189520 [details] File: core_backtrace
Created attachment 1189521 [details] File: dso_list
Created attachment 1189522 [details] File: environ
Created attachment 1189523 [details] File: limits
Created attachment 1189524 [details] File: maps
Created attachment 1189525 [details] File: mountinfo
Created attachment 1189526 [details] File: namespaces
Created attachment 1189527 [details] File: open_fds
Created attachment 1189528 [details] File: proc_pid_status
Created attachment 1189529 [details] File: var_log_messages
It is possible to generate backtrace from such a coredump using gdb: $ gdb -batch -ex 'file /usr/bin/sleep' -ex "core-file core.$SLEEP_PID" -ex "bt" [New LWP 22760] Core was generated by `sleep'. #0 0x00007fe59479c810 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:84 84 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) #0 0x00007fe59479c810 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:84 #1 0x000055d61b75845f in rpl_nanosleep () #2 0x000055d61b7582c0 in xnanosleep () #3 0x000055d61b75587d in main ()
The core file generated by gcore is bogus so it is rather a GDB bug: 3 AT_PHDR Program headers for program 0x55848c2b5040 9 AT_ENTRY Entry point of program 0x55848c2b6940 ^^^ it points to nowhere: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000000df8 0x000055848c4bb000 0x0000000000000000 0x0000000000001000 0x0000000000001000 R 1 LOAD 0x0000000000001df8 0x000055848c4bc000 0x0000000000000000 0x0000000000001000 0x0000000000001000 RW 1 LOAD 0x0000000000002df8 0x000055848e3b7000 0x0000000000000000 0x0000000000021000 0x0000000000021000 RW 1
A workaround is: (gdb) shell cat /proc/20477/coredump_filter 00000033 (gdb) shell echo 0x37 >/proc/20477/coredump_filter (gdb) shell cat /proc/20477/coredump_filter 00000037 (gdb) gcore /tmp/sleep.core (gdb) shell echo 0x33 >/proc/20477/coredump_filter This is not a regression, before 'set use-coredump-filter' (gdb >=7.10) GDB also never dumped pages of binary code.
Please create a new bug, or clone this bug for gdb if you want to fix the bogus core file creation by gcore. It would certainly be nice to fix that. But the original bug is real. eu-stack does crash and it shouldn't, even on a bogus core file. The assert should be fixed by some other sanity check that doesn't cause eu-stack to abort.
So the assert is actually a good thing. It does show something was wrong with our assumption that in.d_size == phnum * phent, which we previously explicitly set in.d_size to. It got reset (to zero) by the core reading code when it detected an error in the core file. That is why we now try to reread the phdrs from the executable. Reusing the same buffer and size. So all we really need to do instead of asserting the size is as expected, to actually set the expected size: diff --git a/libdwfl/link_map.c b/libdwfl/link_map.c index 28d7382..604be1b 100644 --- a/libdwfl/link_map.c +++ b/libdwfl/link_map.c @@ -843,7 +843,10 @@ dwfl_link_map_report (Dwfl *dwfl, const void *auxv, size_t auxv_size, } off_t off = ehdr->e_phoff; assert (in.d_buf == NULL); - assert (in.d_size == phnum * phent); + /* Note this in the !in_ok path. That means the memory_callback + failed. But the callback might still have reset the in.d_buf + value (to zero). So explicitly set it here again. */ + in.d_size = phnum * phent; in.d_buf = malloc (in.d_size); if (unlikely (in.d_buf == NULL)) { And with that we get: $ LD_LIBRARY_PATH=backends:libelf:libdw src/stack --core=core.$SLEEP_PID --exec=/bin/sleep PID 9603 - core TID 9603: #0 0x00007f5185837810 __nanosleep #1 0x000055bc65b7f45f rpl_nanosleep #2 0x000055bc65b7f2c0 xnanosleep #3 0x000055bc65b7c87d main #4 0x00007f518578f731 __libc_start_main #5 0x000055bc65b7c969 _start
Patch suggested upstream: https://lists.fedorahosted.org/archives/list/elfutils-devel@lists.fedorahosted.org/message/UP3NBBN7D3DTIABVJEQTGIRDA4HO5D7L/
elfutils-0.167-1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-de1f4e692b
elfutils-0.167-1.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-de1f4e692b
elfutils-0.167-1.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
elfutils-0.167-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-1bc61e8f20
elfutils-0.167-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-1bc61e8f20
elfutils-0.167-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.