Community
Participate
Working Groups
Prerequisite: >1 performance counters are available. Steps to reproduce: 1. Run => Profile Configurations 2. Create a new oprofile configuration 3. Select "Events" tab 4. Un-check "Use default event" 5. Enable >1 "Ctr"s (e.g. Ctr 0 and Ctr 1) 6. Select the same event for both counters 7. Click "Profile" This results with the attached error dialog popping up.
Created attachment 197183 [details] Error dialog
This is due to oprofile attempting to execute the following command line command (just an example): /path/to/org.eclipse.linuxtools.oprofile.core/natives/linux/scripts/opcontrol --setup --separate=none --no-vmlinux --image=/path/to/binary --callgraph=0 --event=BR_CND_EXEC:63220:0:1:1 --event=BR_CND_EXEC:63220:0:1:1 This is printed to stderr: All events must be distinct. I'm not sure what the correct behaviour for this should be. Does anybody have thoughts on this?
I was able to reproduce this. As far as usage is concerned, specifying 2 events as such seems to be correct. I noticed that If the events vary in something like count (63220,63221), then opcontrol produces an xml that indicates that only one counter was used in the profiling rather than two, which also seems like a bug.
(In reply to comment #3) > I was able to reproduce this. As far as usage is concerned, specifying 2 events > as such seems to be correct. I noticed that If the events vary in something > like count (63220,63221), then opcontrol produces an xml that indicates that > only one counter was used in the profiling rather than two, which also seems > like a bug. Ok. This doesn't seem to be very intuitive. I wonder if there is a way to make it harder for users to run into this?
I think the solution will be to handle errors upon execution by checking the output/error string for a pattern/keyword. In anticipation of future issues like these I'll polish up the error handling as well.
http://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.git/commit/?id=0903372ea297baf8619a84e9971001341549c525 creates an error handler where someone can specify particular errors.
Fixed.
(In reply to comment #7) > Fixed. Thanks. Could you set the relevant target milestone?
Did you intentionally change the version? I'll change the version back to 0.8.0, since it applied to that version and change the milestone to 0.8.1. Please change to 0.9.0 if you do not intend to cherry-pick this to stable-0.8. Thanks!
My mistake. I meant to change the Milestone to 0.9.0, not the version. It's pretty close to the deadline and not a major fix.
