Bug 230108 - dwfl_module_addrname returns incorrect symbol name.
dwfl_module_addrname returns incorrect symbol name.
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: elfutils (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Roland McGrath
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-26 13:03 EST by Nurdin Premji
Modified: 2008-08-02 19:40 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-19 12:26:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nurdin Premji 2007-02-26 13:03:41 EST
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.
Comment 1 Roland McGrath 2007-02-26 15:14:52 EST
Give info about what glibc* rpms are installed.
Comment 2 Nurdin Premji 2007-02-26 17:35:59 EST
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.
Comment 3 Roland McGrath 2007-02-26 18:12:13 EST
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.
Comment 4 Nurdin Premji 2007-02-26 18:49:07 EST
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 ()
Comment 5 Roland McGrath 2007-03-07 05:15:43 EST
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.
Comment 6 Roland McGrath 2007-04-19 12:26:44 EDT
Closing due to lack of indication of any bug or followup by reporter.

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