Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.


#241 JIT dump file is failed to be loaded in opreport.


"opreport" is failed to load JIT dump file in session directory when "--root" option is given and the "root directory" doesn't contain the session directory or the JIT dump file(That means "root directory" and "session directory" is totally separated.)

If '--root' is missed or given root directory contains session directory or JIT dump file, it works fine.


1 2 > >> (Page 1 of 2)
  • Ghacker

    • summary: JIT dump file is failed to load on opreport when "--root=pat --> JIT dump file is failed to be loaded in opreport.
  • Ghacker

    extra_images::locate_image() is patched to load JIT dump object in session directory.

  • Ghacker

    I made and attached a patch for this.
    Please check it out.
    It works fine with mine.

  • The opreport command does not handle jitdump files at all, so your problem description is not making sense to me. The jitdump files are converted to ELF files with filenames of <pid>.jo, and these .jo files are moved into the samples directory for opreport to process later. Please give a more detailed description of the problem, including the exact sequence of commands to reproduce the problem, as well as what version (or git checkout date) of oprofile you are using. Thanks.

    • assigned_to: nobody --> maynardj
  • Ghacker

    There must be misunderstanding about terms..
    I understand the procedure about JIT dump conversion.
    The terms that I used are not suitable for the situation.
    I'm sorry that makes you confusing.
    If you change terms as below from my description, it'll make sense.
    1. Jit dump file --> <pid>.jo ELF file, converted from jit dump
    2. session directory --> samples directory

    I don't have the samples for now. It's on my working sight.
    I'll attach it few days later, if you still want it then.

    For now, let me explain the situation more detailed.
    I using latest version of Oprofile from your git repository for Android kernel based environment.
    Obviously, I need to make some patches to build it with NDK toolchain.
    (BTW, I hope to contribute with these patches later)

    I profiled a process with operf on Android based target device and extract session(sample) directory.
    And there's a (root) directory contains bunch of ELF files which is loaded into the target as stripped.
    Now, consider those directories are listed as below.
    / -+- (root_directory)
    | +- sub-directories and files those are loaded into target device as stripped
    | +- .....
    +- (session_directory)
    +- samples
    | +- ........
    | +- <pid>.jo <-- ELF file from JIT dump
    +- ........
    Then, use opreport to view the result as below.
    1. opreport <options> --session session_directory
    2. opreport <options> --session session_directory --root root_directory
    First case above works fine.
    But, in second case, opreport try to find <absolute path of root_directory>/<absolute path of ".jo" file above>, and it fails obviously.

    I hope these description is enough for you to understand the situation.
    If there's any unclear, let me know.

  • When you say you "extract session(sample) directory", are you meaning to say you pulled the sample data over to a host system and ran opreport there? If so, then the procedure you're following is not recommended or supported. See the man page for the oparchive command for details. This archiving procedure is also documented in NOTE: If you've collected the profile data into a session directory other that the "standard" /var/lib/oprofile, the oparchive command completion message tells you that you must pass that directory to opreport using the --session-dir option. So, after running oparchive, you tar up the output directory created by oparchive, pull it over to your host, untar it and run opreport something like the following:
    opreport archive:<archive_path> [--session-dir=<my-non-standard-sessiondir-from-target> [other options]

    If your host is a different architecture than your Android device, then you will also need to employ the opimport command (see\) before running opreport.

  • Ghacker

    Yes. "extract session(sample) directory" means, "pulled the sample data over to a host system" like you said.
    I understand what's wrong with my situation with your comment.
    I should use oparchive before pull the data. (opimport is not needed in my case.)
    Now, it works mostly fine. I'll expain why it's "mostly" later.

    But, I think it's still a kind of issue (i.e. not a bug) which is not a critical but inconvenience.
    So, I suggest 3 solutions to make better.

    1. Change terms on manual
    Refer to, it's not easy to know it should be used to move sample data to other system.
    I thought that I can use oparchive whenever I want to (literally) archive sample and related data.
    That's why I thought, I don't need it in my situation.
    So, if my procedure was not recommended or supported as you told, it's better to be written that oparchive should be used before move sample data.

    2. Add some more warning message when such a case.
    opreport never gave me any kind of message except "warning: <path-to>/<pid>.jo could not be found. file is not loaded"
    I hardly understood that because, it's exactly located in directory described in the message.
    Because, I offered all necessary information with '--root' and '--session-dir' options to opreport. (It makes the situation after all.)
    Moreover, it works fine only with --session-dir option or with --root options when "root" directory contains "session" directory.
    In my expirence, the problematic situation is occured only when "session" directory contains "<pid>.jo" within its sample
    and 2 options above are used at the same time and "session" directory is not included in "root" directory.
    So, opreport (or libop whatever) can detect and warn such a case is not recommended or supported.

    3. Make it just work.
    I think you already know target device in embedded system has not enought resources.
    So, while I port to oprofile for Android platform, I wanted to post every possible process to be processed on host rather than target.
    If I have to use oparchive all the times when I want to get profile data, it'll be a kind of annying procedure and waist of resources.
    Because, executables from target device is useless since those are usually stripped, and their debug information is already on host.
    So, I have to remove those executables from archive and offer new path that contains executables with debug information with "--root" option.
    I know embedded device situation is not that common. But I thought, it's considerable.
    As I told, it already works almost fine. So, (IMHO), it's able to extend its ability without not that much effort.

    I hope this is not bothering you and please don't get me wrong about this "issue".
    If you guys think that is not a issue, I'll get it.
    I just want to help the project to be get more valuable as a fan.


  • Doc patch for oprofile user manual

  • I absolutely agree that the documentation for oparchive lacked sufficient detail for users such as yourself. I've attached a patch to update the oprofile user manual HTML that adds more detail to both the oparchive and opimport sections. The patch also renames the oparchive section from "6. Archiving measurements (oparchive)" to "6. Analyzing profile data on another system (oparchive)". I tried attaching the built HTML file, but it was too big. If you have the required doc creation packages installed on your system, 'make' will build the oprofile.html file, and 'make install' installs it under <op-install-dir>/share/doc/oprofile.

    If, after reviewing the doc changes, you still feel some code changes are needed, please update this bug with specific suggestions. I may not immediately accept suggestions for code changes. I may ask that you post the issue to the oprofile list and get input from other members of the oprofile community who work in similar host/target environments as you.

1 2 > >> (Page 1 of 2)