Bug 1264443 - opreport needs session dir even when compares archives
Summary: opreport needs session dir even when compares archives
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: oprofile
Version: 7.1
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: William Cohen
QA Contact: Michael Petlan
Tomas Capek
Depends On:
TreeView+ depends on / blocked
Reported: 2015-09-18 13:21 UTC by Michael Petlan
Modified: 2016-11-04 05:16 UTC (History)
2 users (show)

Fixed In Version: oprofile-0.9.9-18.el7
Doc Type: Bug Fix
Doc Text:
The *opreport* and *opannote* utilities now properly analyze archive data. Previously, when using *oparchive* to store data, the associated samples were not included in the archive. In addition, the *oprofile* utilities selected data in the current working `oprofile_data` directory rather than in the archive. Consequently, the *opreport* and *opannote* utilities were unable to properly analyze data in an archive generated by *oparchive*. This update provides a fix for storing the profiling samples in the archive and selecting them for use with archives, and *opreport* and *opannote* now work as expected.
Clone Of:
Last Closed: 2016-11-04 05:16:12 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2016:2394 0 normal SHIPPED_LIVE oprofile bug fix and enhancement update 2016-11-03 13:54:43 UTC

Description Michael Petlan 2015-09-18 13:21:29 UTC
Description of problem:

Even when opreport is supposed to compare two archives created previously by oparchive, it still seeks for the original session dir (like ./oprofile_data).

This issue has been pointed out by Henry May's question on oprofile list:

Version-Release number of selected component (if applicable):

The problem occurs on both RHEL oprofile-0.9.9 and upstream 1.1.

How reproducible:

Steps to Reproduce:

1. grab some data by operf and create two archives to compare:

operf ls
oparchive -o archive1
operf ls
oparchive -o archive2

2. try to make a differential report by opreport:

opreport --merge=all -a -l --demangle=smart { archive:archive1 } { archive:archive2 }

3. remove (rename) the session dir:

mv oprofile_data oprofile_data_backup

4. try to make a differential report by opreport again:

opreport --merge=all -a -l --demangle=smart { archive:archive1 } { archive:archive2 }

5. try to make a differential report by opreport giving it the moved dir:

opreport --merge=all -a -l --demangle=smart --session-dir=./oprofile_data_backup { archive:archive1 } { archive:archive2 }

Actual results:

[A] When the oprofile_data dir is available, it shows the report.
[B] When the oprofile_data dir is not available, it ends with an error.
[C] When the oprofile_data dir is not available and it's given to opreport, it ends with an error too.

The B behaviour is caused by the fact that when no session-dir is specified, the ./oprofile_data is assumed as session dir and the function options::spec get_options() tries to stat it (pp/common_option.cpp:187).

The C behaviour is caused by the fact that archives store full paths. So if I rename the session dir to something else and give it to opreport via "--session-dir" option, opreport is happy that the renamed dir exists in the tree, but it does not exist in the archives, since they were created from the original oprofile_data dir.

Expected results:

The opreport tool is satisfied with the data stored in the archives (there should be everything) and does not seek for the original oprofile_data dir.

Additional info:

The same problem happens when only archive is specified and the oprofile_data dir is moved/renamed/removed:

opreport --merge=all -a -l --demangle=smart archive:archive1

Comment 2 William Cohen 2016-01-07 04:16:17 UTC
oparchive was designed to work by pretty much making a tree that is mirrors the original parts of the file system with the samples and the binaries to allow the analysis to be done.  The analysis would start at the root of the generated archive.  The problem is that the oprofile_data could be anywhere in the archive. Will need to do some redesign of oparchive/opreport to make this work properly.

Comment 3 William Cohen 2016-07-06 15:50:39 UTC
Have a patch in oprofile-0.9.9-18 that copies the sample data into the archive and ensures that data is used when archives are being used.  The test in the description should work with this version.

Comment 5 Michael Petlan 2016-07-09 20:50:10 UTC
Tested with oprofile-0.9.9-18.el7 and both usecases pass now (B,C).


Comment 7 errata-xmlrpc 2016-11-04 05:16:12 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.