[ oprofile-Bugs-1193211 ] opreport outputs apparently impossible addresses

[SourceForge.net <no...@so...>]

Bugs item #1193211, was opened at 2005-05-01 01:52
Message generated for change (Comment added) made by movement
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1193211&group_id=16191

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Robin Green (greenrd)
>Assigned to: John Levon (movement)
Summary: opreport outputs apparently impossible addresses

Initial Comment:
I am trying to profile a Java application compiled to a
native library with gcj. The following command

opreport -d -t 10 -w -l

yields a large number of seemingly impossible
addresses. These addresses appear to be in the .rodata
section of my natively-compiled Java library (and do
_not_ correspond to libgcj.so.6.0.0         
__do_global_ctors_aux, contrary to the claims of
opreport - libgcj.so.6.0.0 is mapped at a much higher
start address, according to pmap.) I have placed a
breakpoint on one of the "hottest" alleged
"instructions" in the same running process with gdb,
and _none_ of the subsequent 4000 hits claimed by
opreport caused this breakpoint to trigger. I have
disassembled the alleged "instruction" and it looks
like data. The alleged "instruction" is not even in an
executable section, according to readelf. Yet the app
is not crashing or segfaulting. It seems to me that
opreport is outputting erroneous data here.

This is using oprofile 0.8.2 on fedora core development.

----------------------------------------------------------------------

>Comment By: John Levon (movement)
Date: 2005-05-01 02:05

Message:
Logged In: YES 
user_id=53034

Please use oparchive to create a tarball  of the sample
files and binaries and send it to me, along with the pmap
output 

John - le...@mo...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1193211&group_id=16191