#219 operf problems with PATH env variable

None
closed-fixed
None
5
2013-07-29
2012-09-11
No

There are two problems involving PATH and how operf processes it;
1) If there's an invalid (non-existent) segment to the PATH, operf silently stops processing the rest of the PATH in get_PATH_based_pathname(), so the passed appname won't be found if it hasn't already.
2) If the PATH includes the cwd (i.e., ".") and the passed app is found in the cwd, samples for that app will be stored in the oprofile samples data base without the full pathname. For example, doing
'operf sprintft'
where sprintft is found in the cwd will result in sample files such as the following being created:
oprofile_data/samples/current/{root}/sprintft/{dep}/{kern}/no-vmlinux/CPU_CLK_UNHALTED.100000.0.all.all.all
Note the lack of full pathname for --------^

Then, when using an image spec with post-processing tools, the result is not complete. In the case above, doing
'opreport sprintft' (or even using the full pathname of sprintft as the image spec)
results in the following output:
------------------------------------------
CPU_CLK_UNHALT...|
samples| %|
------------------
7050 100.000 sprintft
CPU_CLK_UNHALT...|
samples| %|
------------------
7050 100.000 sprintft
------------------------------------------

Note the lack of library or kernel image sample info. If using operf to profile a single app, this isn't too much of a problem, as it's unnecessary to use the image spec since the profile data will contain samples for only the one app. But image specs are very often used and needed for analyzing system-wide profiles.

WORKAROUND: Simply put a "/" in front of the image spec you pass to the pp tool; e.g.,
'opreport /sprintft'

The fix for this problem is for get_PATH_based_pathname() to recogize when the passed appname is found in the cwd and then to generate a full pathname for it.

Discussion

  • Maynard Johnson

    Maynard Johnson - 2012-12-10

    I committed a fix for symptom #1 on Nov 21, 2012.

     
  • Maynard Johnson

    Maynard Johnson - 2012-12-21

    Symptom #2 is fixed with commit ID 883c7ce6ccfe4fcd1649f7b5eb45e705258e189e on Dec 21, 2012.

     
  • Maynard Johnson

    Maynard Johnson - 2012-12-21
    • status: open --> open-fixed
     
  • Maynard Johnson

    Maynard Johnson - 2013-07-29
    • status: open-fixed --> closed-fixed
    • Group: -->
     

Log in to post a comment.

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

Sign up for the SourceForge newsletter:





No, thanks