Description of problem: Running eu-addr2line returns correct source code file path and line number but no function name, only '??'. Version-Release number of selected component (if applicable): elfutils-0.154-2.fc17.x86_64 How reproducible: Always Steps to Reproduce: 1. yum install --enablerepo=updates-debuginfo will-crash-debuginfo 2. eu-addr2line --executable=$( which will_abort ) --functions 4195427 Actual results: ?? /usr/src/debug/sorki-will-crash-d08dd71/src/will_abort.c:6 Expected results: main /usr/src/debug/sorki-will-crash-d08dd71/src/will_abort.c:6 Additional info: This happens quite a lot for various packages, I can provide a list of these failures for further investigation.
Please do provide a concreate example package and steps to reproduce with that package so we can investigate.
Install these packages: yum install http://kojipkgs.fedoraproject.org//packages/will-crash/0.2/1.fc17/x86_64/will-crash-debuginfo-0.2-1.fc17.x86_64.rpm http://kojipkgs.fedoraproject.org//packages/will-crash/0.2/1.fc17/x86_64/will-crash-0.2-1.fc17.x86_64.rpm Run: eu-addr2line --executable=$( which will_abort ) --functions 4195427
aha, thanks, sorry I wasn't aware there was an actual package called will-crash, I assumed it was a made up example.
Any news on this? Our bug de-duplication logic relies on this, so it's quite important for us.
The instruction that the address 4195427 points at is part of no function. 4195426 is part of main, 4195428 is part of _start. The one NOP in between those two is just a padding. The reason for this, I assume, is that gcc knows that abort never returns, and doesn't bother adding any code after the call to abort. But the callq instruction stores to a stack trace a PC of the next instruction, which is the NOP in question, and that's what the unwinder sees. This might manifest itself also as functions that are categorized wrongly, if there's no padding between the functions. I'm not at all sure how to solve this. Perhaps assuming that this phenomenon exists and subtracting one from the deeper layers of stack trace?
... subtracting one from _addresses found in_ the deeper layers that is.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. 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 WONTFIX if it remains open with a Fedora 'version' of '17'. 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 prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 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 to Fedora 17's end of life. 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 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 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. Thank you for reporting this bug and we are sorry it could not be fixed.
This is still not fixed: $ eu-readelf -a libgtk-3.so.0.1400.13 ... [ a0ea0] FDE length=44 cie=[ 0] CIE_pointer: 659108 initial_location: +0x0000000000335f70 <gtk_window_enable_csd> (offset: 0x335f70) address_range: 0x76 (end offset: 0x335fe6) Program: advance_loc 1 to 0x335f71 def_cfa_offset 16 offset r6 (rbp) at cfa-16 advance_loc 1 to 0x335f72 def_cfa_offset 24 offset r3 (rbx) at cfa-24 advance_loc 7 to 0x335f79 def_cfa_offset 32 advance_loc 52 to 0x335fad remember_state def_cfa_offset 24 advance_loc 11 to 0x335fb8 def_cfa_offset 16 advance_loc 1 to 0x335fb9 def_cfa_offset 8 advance_loc 7 to 0x335fc0 restore_state nop nop nop nop nop nop ... $ eu-addr2line --executable libgtk-3.so.0.1400.13 --debuginfo-path /home/jfilak/tmp/brew/tmp/debug --functions -i 0x335fe6 ?? /usr/src/debug/gtk+-3.14.13/gtk/gtkwindow.c:3933
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'.
(In reply to Jakub Filak from comment #9) > This is still not fixed: > > $ eu-readelf -a libgtk-3.so.0.1400.13 > ... > [ a0ea0] FDE length=44 cie=[ 0] > CIE_pointer: 659108 > initial_location: +0x0000000000335f70 <gtk_window_enable_csd> > (offset: 0x335f70) > address_range: 0x76 (end offset: 0x335fe6) > > Program: > advance_loc 1 to 0x335f71 > def_cfa_offset 16 > offset r6 (rbp) at cfa-16 > advance_loc 1 to 0x335f72 > def_cfa_offset 24 > offset r3 (rbx) at cfa-24 > advance_loc 7 to 0x335f79 > def_cfa_offset 32 > advance_loc 52 to 0x335fad > remember_state > def_cfa_offset 24 > advance_loc 11 to 0x335fb8 > def_cfa_offset 16 > advance_loc 1 to 0x335fb9 > def_cfa_offset 8 > advance_loc 7 to 0x335fc0 > restore_state > nop > nop > nop > nop > nop > nop > ... > > $ eu-addr2line --executable libgtk-3.so.0.1400.13 --debuginfo-path > /home/jfilak/tmp/brew/tmp/debug --functions -i 0x335fe6 > ?? > /usr/src/debug/gtk+-3.14.13/gtk/gtkwindow.c:3933 Why are you using 0x335fe6 as address? As your example shows that address is beyond the description of gtk_window_enable_csd (there might be another CIE that covers it, but I assume if there was one, you would have shown it). I don't think there is anything to fix. You seem to provide an address that doesn't have an associated function. But maybe I am misunderstanding what you expect. If you provide an address that is inside the function (e.g. 0x335fe5) does it work as expected?
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. 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 '25'. 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 25 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 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 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.