Description of problem: dwfl_module_addrname returns an incorrect symbol name for certain symbols. Version-Release number of selected component (if applicable): 0.126 How reproducible: Always. Steps to Reproduce: 1. Use dwfl_module_addrname to get the method names for a stack backtrace. 2. 3. Actual results: fstack 3257 <-------------- funit-child instance #0 0x00002aaaaaf106da in __tens () <--- what is this? #1 0x000000000040172d in server () from: ../../frysk/frysk-core/frysk/pkglibdir/ funit-child.c#249 #2 0x00000000004020f4 in main () from: ../../frysk/frysk-core/frysk/pkglibdir/ funit-child.c#505 #3 0x00002aaaaaefda44 in __nscd_gethostbyname2_r () <--- what is this? #4 0x0000000000401139 in _start () Expected results: fstack 8563 Task #8563 #0 0x003b6402 in __kernel_vsyscall () #1 0x4f57c27c in sigsuspend () #2 0x0804913a in server () from: /home/yyz/npremji/mainworkspace/frysk/frysk-core/frysk/pkglibdir/funit-child.c#249 #3 0x08049b8e in main () from: /home/yyz/npremji/mainworkspace/frysk/frysk-core/frysk/pkglibdir/funit-child.c#505 #4 0x4f568f2c in __libc_start_main () #5 0x08048c11 in _start () Additional info: This is with the frysk fstack command. To switch back and forth between libunwind and elfutils getMethodName functions use StackFrame.getMethodName and StackFrame.getSymbolName respectively in StackFrame.toPrint(). frysk.rt package.
Give info about what glibc* rpms are installed.
rpm -qa | grep glibc glibc-common-2.5-10.fc6 glibc-2.5-10.fc6 glibc-devel-2.5-10.fc6 glibc-headers-2.5-10.fc6 However I should note that the situation has changed a bit, it seems like now only the first frame is returned as unknown (null), with the rest being returned with proper names: Task #11404 #0 0x00a07402 in [unknown] #1 0x4f57c27c in __libc_sigsuspend () #2 0x0804913a in server () from: /home/yyz/npremji/mainworkspace/frysk/frysk-core/frysk/pkglibdir/funit-child.c#249 #3 0x08049b8e in main () from: /home/yyz/npremji/mainworkspace/frysk/frysk-core/frysk/pkglibdir/funit-child.c#505 #4 0x4f568f2c in __libc_start_main () #5 0x08048c11 in _start () I am unsure as to what version of glibc caused the original problem.
The "actual results" example looks like x86_64, while the others look like i386. 0x00a07402 is very likely the vDSO, which does not exist for x86_64 64-bit. This report is inadequate without proper information on reproducing the problem, including exact binaries involved. Giving the right arch and talking about the same arch twice is the bare minimum, but far from enough info for a bug report.
The original stackframe was copied from a previous bug and as it is no longer reproducable can probably be ignored. Please consider the following actual results and expected results on x86: The binary is funit-child from the frysk testsuite. Also the second inner most frame's also differ. Actual: /notnfs/npremji/build-main/frysk-core/frysk/bindir/fstack 3900 Task #3900 #0 0x00ca3402 in [unknown] #1 0x4f57c27c in __libc_sigsuspend () #2 0x0804913a in server () from: /home/yyz/npremji/mainworkspace/frysk/frysk-core/frysk/pkglibdir/funit-child.c#249 #3 0x08049b8e in main () from: /home/yyz/npremji/mainworkspace/frysk/frysk-core/frysk/pkglibdir/funit-child.c#505 #4 0x4f568f2c in __libc_start_main () #5 0x08048c11 in _start () Expected: fstack 3900 Task #3900 #0 0x00ca3402 in __kernel_vsyscall () #1 0x4f57c27c in sigsuspend () #2 0x0804913a in server () from: /home/yyz/npremji/mainworkspace/frysk/frysk-core/frysk/pkglibdir/funit-child.c#249 #3 0x08049b8e in main () from: /home/yyz/npremji/mainworkspace/frysk/frysk-core/frysk/pkglibdir/funit-child.c#505 #4 0x4f568f2c in __libc_start_main () #5 0x08048c11 in _start ()
Do you have any case of a problem that is not the vDSO? This doesn't look like it's probably anything to do with addrname itself, just that the vDSO module is not getting loaded. You should be able to distinguish that separately (and report such errors more usefully) by using dwfl_addrmodule to get the Dwfl_Module and make sure there is one for that address, then dwfl_module_getelf to see if it was able to load the ELF file for the module, and if not, what dwfl_errmsg (-1) said. I suspect this is nothing more than the known issues with accessing the process memory for the vDSO using the example libdwfl callback hooks. Something like Frysk needs to use its own logic that relies on Frysk's facilities for reading process memory.
Closing due to lack of indication of any bug or followup by reporter.