From: SourceForge.net <no...@so...> - 2005-05-01 01:52:12
|
Bugs item #1193211, was opened at 2005-05-01 01:52 Message generated for change (Tracker Item Submitted) made by Item Submitter 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: Nobody/Anonymous (nobody) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1193211&group_id=16191 |
From: SourceForge.net <no...@so...> - 2005-05-01 02:05:51
|
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 |
From: SourceForge.net <no...@so...> - 2005-05-01 13:51:56
|
Bugs item #1193211, was opened at 2005-05-01 01:52 Message generated for change (Comment added) made by greenrd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1193211&group_id=16191 Category: None Group: None >Status: Closed >Resolution: Invalid 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: Robin Green (greenrd) Date: 2005-05-01 13:51 Message: Logged In: YES user_id=2202 Having read http://sourceforge.net/tracker/index.php?func=detail&aid=1170794&group_id=16191&atid=116191 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. ---------------------------------------------------------------------- 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 |