#130 opreport outputs apparently impossible addresses

Robin Green

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.


  • John Levon

    John Levon - 2005-05-01

    Logged In: YES

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

    John - levon@movementarian.org

  • John Levon

    John Levon - 2005-05-01
    • assigned_to: nobody --> movement
  • Robin Green

    Robin Green - 2005-05-01
    • status: open --> closed-invalid
  • Robin Green

    Robin Green - 2005-05-01

    Logged In: YES

    Having read
    and the updated docs from CVS, I now understand what is
    going on. The library is stripped, so the VMAs are relative
    to the start of the library, and the symbol given by
    opreport, __do_global_ctors_aux looks to be the correct one.
    Sorry for wasting your time.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks