Home » Eclipse Projects » Linux Tools Project » oprofile problem: "No profiling data is on the system"
oprofile problem: "No profiling data is on the system" [message #541046] |
Fri, 18 June 2010 07:14 |
Jesper Eskilson Messages: 134 Registered: July 2009 |
Senior Member |
|
|
I'm trying to get the oprofile plugin to work, and I think I've gotten
most issues sorted out (getting oprofile to work is a unfortunately a
usability nightmare for a variety of reasons).
First, I'm using Ubuntu 10.04 64-bit, and the OProfile Eclipse plugins
from the nightly builds site:
http://download.eclipse.org/technology/linuxtools/updates-ni ghtly
OProfile seems to work decently when run on the command line:
$ opcontrol --image=...
$ opcontrol --start
$ ... execute my program ...
$ opcontrol --shutdown
$ opreport -l
This spews out a lot of info, but it also complains:
WARNING! The OProfile kernel driver reports sample buffer overflows.
Not sure what to do about that. Looking at the oprofiled.log file it
seems that at least 30k sample were gathered from each of the 4 cores,
and only a single sample lost due to cpu buffer overflow. (The OProfile
documentation about sample rates and buffer size assume deep knowledge
about kernel internals which I don't have.) The output from opreport -l
only shows a handful of samples in my program, despite the program
running for at least 30 seconds. I though the --image option would
restrict profiling to the given image, but opreport -l shows data from
(seemingly) every process on the system.
Running "opxml info" also works fine, and spews out a decent about of XML.
The problem with the Eclipse OProfile view is that I cannot get any data
into it, it just reports "No profiling data is on the system". Where
does it expect the data to go?
(I realize that getting oprofile to work "out-of-the-box" is more or
less an impossible task, but nonetheless I think that "improved
usability" should be on the list of "future plans" at
http://www.eclipse.org/linuxtools/projectPages/oprofile/).
--
Jesper Eskilson
Developer
IAR Systems
|
|
| | | |
Re: oprofile problem: "No profiling data is on the system" [message #550072 is a reply to message #541533] |
Thu, 29 July 2010 04:23 |
Chris Buckley Messages: 8 Registered: July 2010 |
Junior Member |
|
|
I'm getting the same error message I'm running Fedora 13, which comes with Oprofile already installed.
In my case, I've tracked it down to a bad pathname, but I don't know how to change it.
After running the profile run within eclipse, examining the file /root/.oprofile/daemonrc :
SESSION_DIR=/var/lib/oprofile
CHOSEN_EVENTS_0=CPU_CLK_UNHALTED:100000:0:1:1
NR_CHOSEN=1
SEPARATE_LIB=0
SEPARATE_KERNEL=0
SEPARATE_THREAD=0
SEPARATE_CPU=0
VMLINUX=none
IMAGE_FILTER=/home/chrisb/smart/smart/bin/smart
CPU_BUF_SIZE=0
CALLGRAPH=0
XENIMAGE=none
shows that it is expecting the binary at /home/chrisb/smart/smart/bin/smart where /home/chrisb/smart is my workspace name, smart is the project name, and bin/smart is the binary within the project.
However, there's no such binary. I have the workspace and the actual project separated on different filesystems. The actual binary is at /d1/smart/src/bin/smart. The other eclipse commands handle this fine (I'm reasonably new to eclipse, but have been running compile/debug for a couple of months.). The profile configuration simply lists "bin/smart" as the application, which should be correct.
Oprofile works fine when run at the command line with the correct IMAGE_FILTER. But how do I tell eclipse to use the correct pathname?
|
|
| |
Re: oprofile problem: "No profiling data is on the system" [message #550204 is a reply to message #550173] |
Thu, 29 July 2010 14:12 |
Chris Buckley Messages: 8 Registered: July 2010 |
Junior Member |
|
|
Severin Gehwolf wrote on Thu, 29 July 2010 09:02 | Hi Chris,
A few questions:
1.) How did you generate the binary? Did you build/compile it in Eclipse?
2.) Do you have your binaries linked into the workspace? (I.e. are you trying to profile external files; files _not_ in your workspace directory tree). If there is no /home/chrisb/smart/smart/bin/smart how did you attempt to profile it? Usually you would right-click on the binary => Profile as => Oprofile.
3.) You mention that workspace and project are on different filesystems. What's the relationship between /home/chrisb/smart/smart/bin/smart and /d1/smart/src/bin/smart? Is bin/smart (in /home) linked to bin/smart (in /d1).
Could you try profiling your binary by having your project and workspace on the same filesystem (Preferrably on a non-nfs filesystem; see bug above related to NFS)? Any luck with that?
Thanks,
Severin
|
Thanks for the quick reply.
1. binaries built/compiled within Eclipse
2. Binaries are in the namespace. Invoked by either right click on binary or by top menu Run ->profile configurations->select the correct one->profile. The binary was selected in "Profile Configuration" from the project choices offered (ie, is "bin/smart")
3. After setting up workspace, /home/chrisb/smart has only "dot directories" in it, nothing user visible (the pointers to the pre-existing smart directories on /d1/smart are all internal to those "dot directories"). As I said, this all works for compile and debugging, but not for profiling.
After posting my message I tried the obvious work-around and it does actually work. If I manually create a symbolic link in /home/chrisb/smart called smart pointing to /d1/smart/src, then profiling within Eclipse works well (and is quite useful already!) But the only reason I knew to do that was this one pathname in /root/.oprofile/daemonrc - there wasn't anything in Eclipse that suggested I do that. Is there some way I could have found what pathnames Eclipse is using in circumstances like this?
In any case, Eclipse should not have constructed that pathname; the profile binary image was not there. It sounds like the Oprofile code uses a different algorithm to construct the binary location than the debugger does (and that algorithm is incorrect here).
|
|
|
Re: oprofile problem: "No profiling data is on the system" [message #550253 is a reply to message #550204] |
Thu, 29 July 2010 15:54 |
Severin Gehwolf Messages: 40 Registered: June 2010 |
Member |
|
|
Sorry, I'm still a bit confused as to what your filesystem setup is...
Chris Buckley wrote on Thu, 29 July 2010 10:12 |
3. After setting up workspace, /home/chrisb/smart has only "dot directories" in it, nothing user visible (the pointers to the pre-existing smart directories on /d1/smart are all internal to those "dot directories"). As I said, this all works for compile and debugging, but not for profiling.
|
What's your mount setup? What does ls /home/chrisb/smart/smart/ show? Is the binary in there? If yes, you could use the filename of your binary as "C++ Application" location (note this has to be relative to your project) in "Run" => "Profile Configurations" => New Oprofile Config => Tab "Main"
Chris Buckley wrote on Thu, 29 July 2010 10:12 |
After posting my message I tried the obvious work-around and it does actually work. If I manually create a symbolic link in /home/chrisb/smart called smart pointing to /d1/smart/src, then profiling within Eclipse works well (and is quite useful already!)
|
Cool!
Chris Buckley wrote on Thu, 29 July 2010 10:12 |
But the only reason I knew to do that was this one pathname in /root/.oprofile/daemonrc - there wasn't anything in Eclipse that suggested I do that. Is there some way I could have found what pathnames Eclipse is using in circumstances like this?
|
Good point. We might provide some troubleshooting pointers in future. Thanks!
Chris Buckley wrote on Thu, 29 July 2010 10:12 |
In any case, Eclipse should not have constructed that pathname; the profile binary image was not there. It sounds like the Oprofile code uses a different algorithm to construct the binary location than the debugger does (and that algorithm is incorrect here).
|
The only problem I seem to be able to reproduce is that the plugin uses project relative paths in every case. I.e. say you specify "/bin/smart" as "C++ Application" binary to profile and your path to the project is "/home/chrisb/smart/smart". This would lead to a opcontrol --image=/home/chrisb/smart/smart//bin/smart call, which in turn sets IMAGE_FILTER=/home/chrisb/smart/smart/bin/smart in /root/.oprofile/daemonrc. Is that what's happening for you?
I created a bug for this anyway: https://bugs.eclipse.org/bugs/show_bug.cgi?id=321240
Thanks,
Severin
|
|
| | | | | | |
Re: oprofile problem: "No profiling data is on the system" [message #569845 is a reply to message #541533] |
Thu, 29 July 2010 04:25 |
Chris Buckley Messages: 8 Registered: July 2010 |
Junior Member |
|
|
I'm getting the same error message I'm running Fedora 13, which comes with Oprofile already installed.
In my case, I've tracked it down to a bad pathname, but I don't know how to change it.
After running the profile run within eclipse, examining the file /root/.oprofile/daemonrc :
SESSION_DIR=/var/lib/oprofile
CHOSEN_EVENTS_0=CPU_CLK_UNHALTED:100000:0:1:1
NR_CHOSEN=1
SEPARATE_LIB=0
SEPARATE_KERNEL=0
SEPARATE_THREAD=0
SEPARATE_CPU=0
VMLINUX=none
IMAGE_FILTER=/home/chrisb/smart/smart/bin/smart
CPU_BUF_SIZE=0
CALLGRAPH=0
XENIMAGE=none
shows that it is expecting the binary at /home/chrisb/smart/smart/bin/smart where /home/chrisb/smart is my workspace name, smart is the project name, and bin/smart is the binary within the project.
However, there's no such binary. I have the workspace and the actual project separated on different filesystems. The actual binary is at /d1/smart/src/bin/smart. The other eclipse commands handle this fine (I'm reasonably new to eclipse, but have been running compile/debug for a couple of months.). The profile configuration simply lists "bin/smart" as the application, which should be correct.
Oprofile works fine when run at the command line with the correct IMAGE_FILTER. But how do I tell eclipse to use the correct pathname?
|
|
| |
Re: oprofile problem: "No profiling data is on the system" [message #569894 is a reply to message #550173] |
Thu, 29 July 2010 14:12 |
Chris Buckley Messages: 8 Registered: July 2010 |
Junior Member |
|
|
Severin Gehwolf wrote on Thu, 29 July 2010 09:02
> Hi Chris,
>
> A few questions:
>
> 1.) How did you generate the binary? Did you build/compile it in Eclipse?
>
> 2.) Do you have your binaries linked into the workspace? (I.e. are you trying to profile external files; files _not_ in your workspace directory tree). If there is no /home/chrisb/smart/smart/bin/smart how did you attempt to profile it? Usually you would right-click on the binary => Profile as => Oprofile.
>
> 3.) You mention that workspace and project are on different filesystems. What's the relationship between /home/chrisb/smart/smart/bin/smart and /d1/smart/src/bin/smart? Is bin/smart (in /home) linked to bin/smart (in /d1).
>
> Could you try profiling your binary by having your project and workspace on the same filesystem (Preferrably on a non-nfs filesystem; see bug above related to NFS)? Any luck with that?
>
> Thanks,
> Severin
Thanks for the quick reply.
1. binaries built/compiled within Eclipse
2. Binaries are in the namespace. Invoked by either right click on binary or by top menu Run ->profile configurations->select the correct one->profile. The binary was selected in "Profile Configuration" from the project choices offered (ie, is "bin/smart")
3. After setting up workspace, /home/chrisb/smart has only "dot directories" in it, nothing user visible (the pointers to the pre-existing smart directories on /d1/smart are all internal to those "dot directories"). As I said, this all works for compile and debugging, but not for profiling.
After posting my message I tried the obvious work-around and it does actually work. If I manually create a symbolic link in /home/chrisb/smart called smart pointing to /d1/smart/src, then profiling within Eclipse works well (and is quite useful already!) But the only reason I knew to do that was this one pathname in /root/.oprofile/daemonrc - there wasn't anything in Eclipse that suggested I do that. Is there some way I could have found what pathnames Eclipse is using in circumstances like this?
In any case, Eclipse should not have constructed that pathname; the profile binary image was not there. It sounds like the Oprofile code uses a different algorithm to construct the binary location than the debugger does (and that algorithm is incorrect here).
|
|
|
Re: oprofile problem: "No profiling data is on the system" [message #569908 is a reply to message #550204] |
Thu, 29 July 2010 15:54 |
Severin Gehwolf Messages: 40 Registered: June 2010 |
Member |
|
|
Sorry, I'm still a bit confused as to what your filesystem setup is...
Chris Buckley wrote on Thu, 29 July 2010 10:12
> 3. After setting up workspace, /home/chrisb/smart has only "dot directories" in it, nothing user visible (the pointers to the pre-existing smart directories on /d1/smart are all internal to those "dot directories"). As I said, this all works for compile and debugging, but not for profiling.
What's your mount setup? What does ls /home/chrisb/smart/smart/ show? Is the binary in there? If yes, you could use the filename of your binary as "C++ Application" location (note this has to be relative to your project) in "Run" => "Profile Configurations" => New Oprofile Config => Tab "Main"
Chris Buckley wrote on Thu, 29 July 2010 10:12
> After posting my message I tried the obvious work-around and it does actually work. If I manually create a symbolic link in /home/chrisb/smart called smart pointing to /d1/smart/src, then profiling within Eclipse works well (and is quite useful already!)
Cool!
Chris Buckley wrote on Thu, 29 July 2010 10:12
> But the only reason I knew to do that was this one pathname in /root/.oprofile/daemonrc - there wasn't anything in Eclipse that suggested I do that. Is there some way I could have found what pathnames Eclipse is using in circumstances like this?
Good point. We might provide some troubleshooting pointers in future. Thanks!
Chris Buckley wrote on Thu, 29 July 2010 10:12
> In any case, Eclipse should not have constructed that pathname; the profile binary image was not there. It sounds like the Oprofile code uses a different algorithm to construct the binary location than the debugger does (and that algorithm is incorrect here).
The only problem I seem to be able to reproduce is that the plugin uses project relative paths in every case. I.e. say you specify "/bin/smart" as "C++ Application" binary to profile and your path to the project is "/home/chrisb/smart/smart". This would lead to a opcontrol --image=/home/chrisb/smart/smart//bin/smart call, which in turn sets IMAGE_FILTER=/home/chrisb/smart/smart/bin/smart in /root/.oprofile/daemonrc. Is that what's happening for you?
I created a bug for this anyway: https://bugs.eclipse.org/bugs/show_bug.cgi?id=321240
Thanks,
Severin
|
|
| | | |
Goto Forum:
Current Time: Tue Sep 24 11:40:26 GMT 2024
Powered by FUDForum. Page generated in 0.07157 seconds
|