Red Hat Bugzilla – Bug 1264443
opreport needs session dir even when compares archives
Last modified: 2016-11-04 01:16:12 EDT
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: http://marc.info/?l=oprofile-list&m=144241622202345&w=2 Version-Release number of selected component (if applicable): The problem occurs on both RHEL oprofile-0.9.9 and upstream 1.1. How reproducible: 100% 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
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.
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.
Tested with oprofile-0.9.9-18.el7 and both usecases pass now (B,C). VERIFIED.
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. https://rhn.redhat.com/errata/RHEA-2016-2394.html