Hi Max,
> I am using the hotuser script to trace user functions in the output I
> get some lines that show hex address instead of function:
>
> libc.so.1`0xfe54c080 2375 2.4%
> libc.so.1`0xfe54b884 3254 3.2%
> libc.so.1`0xfe54c364 4210 4.2%
> libdml.so`0xfec766b8 4602 4.6%
When you see output from ustack() that contains hex addresses
like this it means that we can''t resolve the address to a symbol
name. This is usually because the symbol table has been stripped
or we are executing code out of data (e.g. jump tables). As
we don''t strip our system libraries, I suspect that these addresses
are coming from instructions located in data.
To verify where they are coming from you could always attach to
the process in question and disassemble the address in question.
Here''s a simple example of a trivial piece of code that is
spinning calling getpid():
# ./hotuser.pl -p `pgrep spin`
Sampling... Hit Ctrl-C to end.
^C
FUNCTION COUNT PCNT
spin`spin 10 1.1%
spin`0x8050910 11 1.3%
spin`spin1 73 8.3%
libc.so.1`getpid 784 89.3%
# mdb -p `pgrep spin`
Loading modules: [ ld.so.1 ]
> 0x8050910::dis -n 0
PLT=libc_hwcap1.so.1`getpid: jmp *0x8060ae0
> *0x8060ae0::dis -n 0
libc_hwcap1.so.1`getpid: call +0x0
<libc_hwcap1.so.1`getpid+5>
As you can see, spin`0x8050910 is actually located in the
procedure linkage table entry (a jump table) for the getpid() call.
Jon.