Community
Participate
Working Groups
Build Identifier: M20110210-1200 I am trying out some simple experiments using the OProfile plug-in for Eclipse 3.6.2 for x86_64 on Fedora 14. I have all of the linuxtools plug-ins installed and up-to-date: OProfile Integration (Incubation) 0.3.0.201102160611 Profile Framework (Incubation) 0.7.0.201102160611 When I run my simple test, the OProfile tab shows a red X and "No profiling data is on the system. If after attempting a profile, I right-click on the binary of my little test case, and select Profile As...-> Profiling Configurations..., I get an error dialog with the header "Error with opxml", whose contents says: An error occurred with opxml. Reason: An unexpected error occurred with parsing opxml's output. Please file a bug at http://bugs.eclipse.org/bugs. If I click OK, I get another five or so of the same error dialogs popping up. If I click OK on all of them, I eventually get to the Profiling Configurations dialog. Reproducible: Always Steps to Reproduce: 1. Create simple Hello World C test case 2. Build it. 3. Right click on the executable and select Profile As..-> OProfile 4. Go ahead and run it. Notice the error "No profiling data is on the system." in the OProfile tab , then right-click on the executable and select Profile As..->Profile Configurations... You should now see a number of error dialogs that you have to click "OK" to dismiss, all of which say the same thing about an error in opxml. My version of opcontrol is 0.9.6
Is this still applicable with the latest OProfile plugin? Use of opxml has been phased out.
(In reply to comment #1) > Is this still applicable with the latest OProfile plugin? Use of opxml has > been phased out. I started up Eclipse 3.7RC1, and updated to the most recent oprofile plug-in, and the problem still occurs. I tried running with the latest OProfile packages from master, but I get some Java stack during start-up. I will keep playing with it.
(In reply to comment #2) > (In reply to comment #1) > > Is this still applicable with the latest OProfile plugin? Use of opxml has > > been phased out. > > I started up Eclipse 3.7RC1, and updated to the most recent oprofile plug-in, > and the problem still occurs. > > I tried running with the latest OProfile packages from master, but I get some > Java stack during start-up. I will keep playing with it. Also tried with a fresh copy of Eclipse 3.7RC2 + Linuxtools, and the latest OProfile plug-in from the linuxtools repo.
(In reply to comment #1) > Is this still applicable with the latest OProfile plugin? Use of opxml has > been phased out. I just tried with the latest code from the master branch of the Git tree, and it works correctly there.
Doing a 'git log oprofile and 'git log profiling' doesn't show much that could explain this behaviour since our RC2 contribution was built from b5511d8a4ac613982272f53d8e63bf6f3231e5e8. Also, s/Linuxtools/Linux Tools/ :)
(In reply to comment #5) > Doing a 'git log oprofile and 'git log profiling' doesn't show much that could > explain this behaviour since our RC2 contribution was built from > b5511d8a4ac613982272f53d8e63bf6f3231e5e8. > > Also, s/Linuxtools/Linux Tools/ :) OK. Well, I did start with a fresh copy of Eclipse 3.76RC2 and installed all of the Linux Tools plug-ins, and got that result. Have you tried it, Andrew? I assume you are running some form of Fedora on x86_64 there.
Oh, could this be the nmi_watchdog error? Can you launch oprofile on the commandline?
Created attachment 197042 [details] error dialogue screenshot When I try to profile a Hello World C test case out of the box (steps 1 through 4 above), I get the attached window. If I add my user id to /etc/sudoers I still can't profile, though. Supposedly my kernel's oprofile module is being used (but of course it doesn't tell me by what PIDs [1]). [1] http://www.happyassassin.net/2011/05/25/small-annoyances/
Severin, any ideas here?
(In reply to comment #8) > Created attachment 197042 [details] > error dialogue screenshot > > When I try to profile a Hello World C test case out of the box (steps 1 through > 4 above), I get the attached window. If I add my user id to /etc/sudoers I > still can't profile, though. Supposedly my kernel's oprofile module is being > used (but of course it doesn't tell me by what PIDs [1]). > > [1] > http://www.happyassassin.net/2011/05/25/small-annoyances/ Andrew, AFAIK you are on F15 and you were facing the nmi_watchdog error, hidden under the covers and oprofile showing you bad advice. # opcontrol --deinit # echo 0 > /proc/sys/kernel/nmi_watchdog should fix profiling for you.
(In reply to comment #7) > Oh, could this be the nmi_watchdog error? Can you launch oprofile on the > commandline? It is likely for you, but probably not for Corey, since he is on F14 and I haven't seen that error on F14 (Though, I haven't been using F14 for a while now). I'd need a F14 box to reproduce. I'll have a look and report back what I find.
Corey, have you tried profiling your binary on the command line? Something like: # opcontrol --setup --no-vmlinux --image=/path/to/binary # opcontrol --start run binary # opcontrol --stop # opcontrol --dump # opreport Does this work for you?
(In reply to comment #12) > Corey, have you tried profiling your binary on the command line? Something > like: > > # opcontrol --setup --no-vmlinux --image=/path/to/binary > # opcontrol --start > run binary > # opcontrol --stop > # opcontrol --dump > # opreport > > Does this work for you? Yes it does work for me, and in fact the OProfile plug-in from the master branch works correctly too, so I don't think it's an issue with oprofile.
Severin, Yes, I'm on F15 x86_64 and I tried the nmi_watching fix without success. I even re-started Eclipse more than once.
Using: http://www.eclipse.org/downloads/packages/node/568 Here is what I've found so far. I get the same error Andrew gets. Looking at the terminal, I see that: All events must be distinct. is printed to stderr. Getting this output the plug-in thinks something really bad happened and throws a checked exception, which results in the error dialog showing up as Andrew mentions above. The code seems to behave a bit differently if I manually profile. I.e. if I 1. Use manual profiling (oprofile) 2. Start the daemon using the dialog, which pops up 3. Run the binary 4. Dump session, and stop the daemon 5. Refresh the oprofile view, it appears to have worked. Interestingly, this does not produce the same error dialog than the managed profiling. The questions are a.) why are there duplicate events? b.) why isn't this happening on latest master? More later...
Ok, I faced bug 348026 with the duplicate events message I was getting. Might be totally unrelated. Fixing my profile configurations to use the default event, profiling using http://www.eclipse.org/downloads/packages/node/568 and Indigo SDK with Linux Tools installed from https://hudson.eclipse.org/hudson/job/cbi-linuxtools-Indigo/335/artifact/releng/org.eclipse.linuxtools.releng-site/target/repository/ both works. Not sure what the problem might be. Note: I tested on F15. Corey, could you have a look at bug 348026 and make sure this isn't happening to you. Looking at your original report, I'm not very positive this is what caused your issue. I'll try to reproduce on a F14 box later.
(In reply to comment #16) > Fixing my profile configurations to use the default event, profiling using > http://www.eclipse.org/downloads/packages/node/568 and Indigo SDK with Linux > Tools installed from > https://hudson.eclipse.org/hudson/job/cbi-linuxtools-Indigo/335/artifact/releng/org.eclipse.linuxtools.releng-site/target/repository/ > both works. Not sure what the problem might be. Note: I tested on F15. > > Corey, could you have a look at bug 348026 and make sure this isn't happening > to you. Looking at your original report, I'm not very positive this is what > caused your issue. I'll try to reproduce on a F14 box later. Well, I'm not specifying any events at all, so I don't see how I could be running into that issue. I did try using the repo you mention above, but I get errors when trying to access it - Error 404. I'm using this repo: http://download.eclipse.org/technology/linuxtools/update Should I be using a Ingdigo-specific repo? There aren't any in the list of available repos. Another reason I think I may be using the wrong repo is that the error messages are referring to opxml, which is supposed to be gone in Indigo, right?
p2 repositories will give a 404 in a browser but give contents when used with the update manager. opxml is supposed to be gone, yes. updates-nightly is currently not working due to bug #348022 so you can try the repo from a specific build such as: https://hudson.eclipse.org/hudson/job/cbi-linuxtools-Indigo/337/artifact/releng/org.eclipse.linuxtools.releng-site/target/repository/
Ok, I tried again with totally fresh install of Eclipse 3.7RC2, then installed oprofile from the hudson repo you gave. Everything installed fine, but I still see the same error. I'll add a screenshot of the error dialog I see.
Created attachment 197187 [details] Error with opxml dialog screenshot
http://download.eclipse.org/technology/linuxtools/update is the release repo. Can you think of a good place to put this information? We really don't want end users to be installing from updates-nightly or one of the staging repositories so I don't want to put it on downloads.php. There's this wiki page: http://wiki.eclipse.org/Linux_Tools_Project/Releng#Builds_and_how_they_get_places How do we get this information to developers and contributors without confusing end users?
I don't see that error message text being used in any code in master: [oprofile (master)]$ grep -rl opxmlParse.error.statusMessage * org.eclipse.linuxtools.oprofile.core/bin/org/eclipse/linuxtools/oprofile/core/oprofile.properties org.eclipse.linuxtools.oprofile.core/target/classes/org/eclipse/linuxtools/oprofile/core/oprofile.properties org.eclipse.linuxtools.oprofile.core/target/oprofile-core.jar-classes/org/eclipse/linuxtools/oprofile/core/oprofile.properties org.eclipse.linuxtools.oprofile.core/src/org/eclipse/linuxtools/oprofile/core/oprofile.properties I am leaning more towards this being a Tycho bug of some kind. I really hoped to avoid this but we may have to do a build locally with PDE directly and then push it to eclipse.org ...
I've started a build with the Dash signing plugin to see if that affects things: https://hudson.eclipse.org/hudson/job/cbi-linuxtools-Indigo/338/ Corey, would you be so kind as to try the output of this build when it finishes? Thanks.
(In reply to comment #21) > http://download.eclipse.org/technology/linuxtools/update is the release repo. > I was confused because I'm seeing error messages from what looks to be an older version of the plug-in, so I assumed that the repo I was using was, perhaps, for Helios instead of Indigo. The repo doesn't have "Indigo" in its name anywhere. As a user, if this is the only repo available for the Linux Tools Project code, I would assume that there's some sort of magic going on that Eclipse knows to say, "What do you have for a Eclipse 3.7 install?" > Can you think of a good place to put this information? We really don't want > end users to be installing from updates-nightly or one of the staging > repositories so I don't want to put it on downloads.php. There's this wiki > page: > > http://wiki.eclipse.org/Linux_Tools_Project/Releng#Builds_and_how_they_get_places > > How do we get this information to developers and contributors without confusing > end users? This info is good. I didn't know it was there (I tend not to look at the releng info). I do notice that it refers to an Indigo-specific repo, "http://download.eclipse.org/technology/linuxtools/update-indigo". When I click "Available Software Sites", I don't see this Indigo-specific site, only the one without the -indigo suffix. However, I tried this repo too, and it appears to have the same version of the Oprofile plug-in: org.eclipse.linuxtools.oprofile.core_0.3.1.201102160611 When I look in the org.eclipse.linuxtools.oprofile.core's oprofile-core.jar file, I do see the opxml subdirectory: % ls -R opxml opxml: ./ checkevent/ modeldata/ OpxmlConstants.class ../ EventIdCache.class OprofileSAXHandler.class sessions/ AbstractDataAdapter.class info/ OprofileSAXHandler$ProcessorItem.class XMLProcessor.class opxml/checkevent: ./ ../ CheckEventAdapter.class CheckEventsProcessor.class opxml/info: ./ DefaultsProcessor.class EventListProcessor$MaskProcessor.class InfoAdapter.class ../ EventListProcessor.class EventListProcessor$UnitMaskProcessor.class OpInfoProcessor.class opxml/modeldata: ./ ModelDataAdapter$1.class ModelDataProcessor.class ../ ModelDataAdapter.class SamplesProcessor.class DependentProcessor.class ModelDataProcessor$CallData.class SymbolsProcessor.class opxml/sessions: ./ ../ SessionManager.class SessionsProcessor.class SessionsProcessor$SessionInfo.class
(In reply to comment #23) > I've started a build with the Dash signing plugin to see if that affects > things: > > https://hudson.eclipse.org/hudson/job/cbi-linuxtools-Indigo/338/ > > Corey, would you be so kind as to try the output of this build when it > finishes? Thanks. I'll give it a shot.
Correction on the oprofile.core plug-in that I have. It is: org.eclipse.linuxtools.oprofile.core_0.3.1.201106011805 not org.eclipse.linuxtools.oprofile.core_0.3.1.201102160611
I tried updating to the 338 build and it has the same issue.
(In reply to comment #24) > (In reply to comment #21) > > http://download.eclipse.org/technology/linuxtools/update is the release repo. > > > > I was confused because I'm seeing error messages from what looks to be an older > version of the plug-in, so I assumed that the repo I was using was, perhaps, for > Helios instead of Indigo. The repo doesn't have "Indigo" in its name anywhere. > As a user, if this is the only repo available for the Linux Tools Project code, > I would assume that there's some sort of magic going on that Eclipse knows to > say, "What do you have for a Eclipse 3.7 install?" > > > Can you think of a good place to put this information? We really don't want > > end users to be installing from updates-nightly or one of the staging > > repositories so I don't want to put it on downloads.php. There's this wiki > > page: > > > > > http://wiki.eclipse.org/Linux_Tools_Project/Releng#Builds_and_how_they_get_places > > > > How do we get this information to developers and contributors without > confusing > > end users? > > This info is good. I didn't know it was there (I tend not to look at the releng > info). I do notice that it refers to an Indigo-specific repo, > "http://download.eclipse.org/technology/linuxtools/update-indigo". Yes, that's the staging p2 repository for our Indigo contributions. Its content needs to match what's in our Indigo contribution file until we update that file (and update the content in that repository). > When I click "Available Software Sites", I don't see this Indigo-specific site, > only the one without the -indigo suffix. You'd have to add it :) > When I look in the org.eclipse.linuxtools.oprofile.core's oprofile-core.jar > file, I do see the opxml subdirectory: Hmm. Severin, this should be gone, right? I'm worried that we've uncovered some sort of Tycho bug here where it's taking old content that we've contributed to some repository and re-naming it (well, re-versioning/re-qualifier-ing).
(In reply to comment #22) > I don't see that error message text being used in any code in master: > > [oprofile (master)]$ grep -rl opxmlParse.error.statusMessage * > org.eclipse.linuxtools.oprofile.core/bin/org/eclipse/linuxtools/oprofile/core/oprofile.properties > org.eclipse.linuxtools.oprofile.core/target/classes/org/eclipse/linuxtools/oprofile/core/oprofile.properties > org.eclipse.linuxtools.oprofile.core/target/oprofile-core.jar-classes/org/eclipse/linuxtools/oprofile/core/oprofile.properties > org.eclipse.linuxtools.oprofile.core/src/org/eclipse/linuxtools/oprofile/core/oprofile.properties > > I am leaning more towards this being a Tycho bug of some kind. I really hoped > to avoid this but we may have to do a build locally with PDE directly and then > push it to eclipse.org ... I found that the code that produces this error dialog is still in master. You didn't find the string, because error property name is created dynamically: } catch (IOException e) { e.printStackTrace(); OprofileCorePlugin.showErrorDialog("opxmlParse", null); //$NON-NLS-1$ } the string passed into showErrorDialog is appended with .error.statusMessage in the static method createErrorStatus. So I don't think this is an issue with the release, but rather of the code taking the wrong path, somehow, into the old opxml code.
You could try inserting some debugging statements. Did you say that you cannot make this happen with a child Eclipse workbench?
Yes, when I tried running using an Eclipse child, I didn't experience this error. I will try again later today.
Thanks for all the help and patience on this, Corey. Bug #348030 tracks a change Severin committed [1] to make debugging interactions with OProfile. It will be included in this build when it finishes: https://hudson.eclipse.org/hudson/job/cbi-linuxtools-Indigo/340/ [1] http://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.git/commit/?id=34770cc454334dd8d600690417f9a18f46aed97c
I tried build #340, and it made no difference, as I think you'd expect. I tried running with -debug, but there are no additional error messages. Trying again to replicate using the latest OProfile plug-in source, I was able to reproduce the problem using a child Eclipse. I haven't done much actual debugging to find out why this is happening, but here's the call trace that results in the error dialog: Thread [main] (Suspended (breakpoint at line 751 in OprofileEventConfigTab$CounterSubTab$UnitMaskViewer)) OprofileEventConfigTab$CounterSubTab$UnitMaskViewer.displayEvent(OpEvent) line: 751 OprofileEventConfigTab$CounterSubTab.initializeTab(ILaunchConfiguration) line: 538 OprofileEventConfigTab.initializeFrom(ILaunchConfiguration) line: 131 OprofileLaunchConfigurationTabGroup(AbstractLaunchConfigurationTabGroup).initializeFrom(ILaunchConfiguration) line: 86 LaunchConfigurationTabGroupWrapper.initializeFrom(ILaunchConfiguration) line: 194 LaunchConfigurationTabGroupViewer.displayInstanceTabs(boolean) line: 751 LaunchConfigurationTabGroupViewer$8.run() line: 623 BusyIndicator.showWhile(Display, Runnable) line: 70 LaunchConfigurationTabGroupViewer.inputChanged(Object) line: 640 LaunchConfigurationTabGroupViewer.setInput0(Object) line: 602 LaunchConfigurationTabGroupViewer.setInput(Object) line: 578 LaunchConfigurationsDialog.handleLaunchConfigurationSelectionChanged(SelectionChangedEvent) line: 941 LaunchConfigurationsDialog$3.selectionChanged(SelectionChangedEvent) line: 560 StructuredViewer$3.run() line: 888 SafeRunner.run(ISafeRunnable) line: 42 JFaceUtil$1.run(ISafeRunnable) line: 49 SafeRunnable.run(ISafeRunnable) line: 175 LaunchConfigurationViewer(StructuredViewer).firePostSelectionChanged(SelectionChangedEvent) line: 886 LaunchConfigurationViewer(StructuredViewer).setSelection(ISelection, boolean) line: 1726 LaunchConfigurationViewer(TreeViewer).setSelection(ISelection, boolean) line: 1139 LaunchConfigurationViewer(Viewer).setSelection(ISelection) line: 394 LaunchConfigurationsDialog.doInitialTreeSelection() line: 600 LaunchConfigurationsDialog.initializeContent() line: 1080 LaunchConfigurationsDialog.createContents(Composite) line: 437 LaunchConfigurationsDialog(Window).create() line: 431 LaunchConfigurationsDialog(Dialog).create() line: 1089 LaunchConfigurationsDialog.create() line: 368 LaunchConfigurationsDialog(Window).open() line: 790 LaunchConfigurationsDialog.open() line: 1132 DebugUITools$2.run() line: 579 BusyIndicator.showWhile(Display, Runnable) line: 70 DebugUITools.openLaunchConfigurationDialogOnGroup(Shell, IStructuredSelection, String, IStatus) line: 587 DebugUITools.openLaunchConfigurationDialogOnGroup(Shell, IStructuredSelection, String) line: 521 OpenLaunchDialogAction.run() line: 81 OpenLaunchDialogAction(Action).runWithEvent(Event) line: 498 ActionContributionItem.handleWidgetSelection(Event, boolean) line: 584 ActionContributionItem.access$2(ActionContributionItem, Event, boolean) line: 501 ActionContributionItem$5.handleEvent(Event) line: 411 EventTable.sendEvent(Event) line: 84 MenuItem(Widget).sendEvent(Event) line: 1258 Display.runDeferredEvents() line: 3586 Display.readAndDispatch() line: 3207 Workbench.runEventLoop(Window$IExceptionHandler, Display) line: 2696 Workbench.runUI() line: 2660 Workbench.access$4(Workbench) line: 2494 Workbench$7.run() line: 674 Realm.runWithDefault(Realm, Runnable) line: 332 Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 667 PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 149 IDEApplication.start(IApplicationContext) line: 123 EclipseAppHandle.run(Object) line: 196 EclipseAppLauncher.runApplication(Object) line: 110 EclipseAppLauncher.start(Object) line: 79 EclipseStarter.run(Object) line: 344 EclipseStarter.run(String[], Runnable) line: 179 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 60 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 37 Method.invoke(Object, Object...) line: 611 Main.invokeFramework(String[], URL[]) line: 622 Main.basicRun(String[]) line: 577 Main.run(String[]) line: 1410 Main.main(String[]) line: 1386
(In reply to comment #33) > I tried build #340, and it made no difference, as I think you'd expect. I > tried running with -debug, but there are no additional error messages. FYI: You'd also need the following in an options file, e.g. ~/.options: org.eclipse.linuxtools.oprofile.core/debug Having that in the .options file AND launching eclipse with the -debug switch should give you the desired additional output.
Corey, which JVM are you using? Are you able to reproduce this with openjdk, which ships with Fedora? Just one of those hunches :)
(In reply to comment #35) > Corey, which JVM are you using? Are you able to reproduce this with openjdk, > which ships with Fedora? Just one of those hunches :) I normally use the IBM JRE, but I'm almost certain I tried it with the OpenJDK and got the same results. However, I will repeat that experiment just to be sure.
(In reply to comment #36) > (In reply to comment #35) > > Corey, which JVM are you using? Are you able to reproduce this with openjdk, > > which ships with Fedora? Just one of those hunches :) > > I normally use the IBM JRE, but I'm almost certain I tried it with the OpenJDK > and got the same results. However, I will repeat that experiment just to be > sure. I repeated the experiment and got the exact same results. As I was driving home yesterday, I remembered that at the time I got the plug-in to work using a child Eclipse, it was before I had updated my git tree to the latest master branch. When I tried again, I had updated the git tree and then the problem reproduced in the child Eclipse. So perhaps there's a fairly recent commit which caused this regression. Maybe a "git bisect" approach could identify the commit that broke it. If I have time today, I will try this out.
Ok, I tried the going back to earlier versions of master, and I continue to see the same issue. I even tried going back to stable-0.7, and got the same result. When running as a child Eclipse, I noticed that the Java being used was still the IBM one, so I added the OpenJDK to the run config, and switched to that one, but I still see the same exact error (I double checked that within the child I am running the OpenJDK 1.6). I started getting desperate and decided to reboot my machine. For a little while, I received a different error when I brought up the profile configuration view but it still didn't work. It complained that it cannot initialize the Oprofile class. My next step was to again try to start from scratch again (after the reboot) and erase and re-install Eclipse 3.7RC2, the OProfile plug-in, and EGit. I did that, and it immediately went back to the same old error. I've run out of experiments to try. The next step, I think, is to actually debug the code. I'm not at all familiar with the OProfile plug-in code, though, so I suspect it would take me quite a lot of time to figure out what is going on. The bottom line for me is if no one else is seeing this error, there's probably not much point in me spending much more time on this.
Ok, according to the dialog you get, an opxmlParse error occurs which in turn can only be caused by an IOException. That leads me to the following questions: What is the setup of your machine? Could it be that there is some NFS with root squashing involved? Where is state information of eclipse located? If the answer to questions above turn out to be that no NFS is involved at all, I'd ask you to start eclipse as follows and provide us the resulting oprofile_debug.log file. Thanks! $ cat .options org.eclipse.linuxtools.oprofile.core/debug $ ./eclipse -debug -consolelog 2>&1 | tee oprofile_debug.log
(In reply to comment #39) > Ok, according to the dialog you get, an opxmlParse error occurs which in turn > can only be caused by an IOException. That leads me to the following questions: > > What is the setup of your machine? Could it be that there is some NFS with root > squashing involved? Where is state information of eclipse located? > > If the answer to questions above turn out to be that no NFS is involved at all, > I'd ask you to start eclipse as follows and provide us the resulting > oprofile_debug.log file. Thanks! > > $ cat .options > org.eclipse.linuxtools.oprofile.core/debug > $ ./eclipse -debug -consolelog 2>&1 | tee oprofile_debug.log I wasn't able to try this experiment today, but I will tomorrow. Sorry for the delay. I don't think there's anything unusual about the filesystem on my work laptop. It doesn't have any NFS, AFS, etc. mounts at all. Its configuration is pretty simple, and the state information should all be within my home directory. I did try something else worth noting, though: I installed Eclipse 3.7RC3 and 3.7RC4 on my home machine, which also runs Fedora 14, and I had no problems with it. The OProfile plug-in worked fine. I did try to install 3.7RC2 on my home machine (just so I get an apples-to-apples comparison), but it seems that the release bits are no longer available. One possible difference is that might laptop has a Core i7 processor in it, and I wonder if opxml is having difficulty processing the output of ophelp. Just a thought. My home machine has an older Core 2 duo.
(In reply to comment #36) > (In reply to comment #35) > > Corey, which JVM are you using? Are you able to reproduce this with openjdk, > > which ships with Fedora? Just one of those hunches :) > > I normally use the IBM JRE, but I'm almost certain I tried it with the OpenJDK > and got the same results. However, I will repeat that experiment just to be > sure. Corey, are you using F14 stock openjdk?
Hmm... I cannot reproduce on core i7. I used the standard "Hello World ANSI C Project" and the 'echo 0 > /proc/sys/kernel/nmi_watchdog' fix
(In reply to comment #42) > Hmm... I cannot reproduce on core i7. > I used the standard "Hello World ANSI C Project" > and the 'echo 0 > /proc/sys/kernel/nmi_watchdog' fix Sami, this is on F15, correct? Thanks!
> Sami, this is on F15, correct? Thanks! Yup. x86_64
(In reply to comment #41) > Corey, are you using F14 stock openjdk? Yes. I've tried both F14 stock openjdk and the IBM JDK 1.6.0 and the results are identical. I'm about to try the debug case and get a log.
Created attachment 197554 [details] oprofile_debug.log as requested
I just tried Eclipse 3.7RC4 and there's no change.
(In reply to comment #47) > I just tried Eclipse 3.7RC4 and there's no change. I only now realize that you are getting the error when opening profile configurations and NO error when trying to profile using the default configuration. Having said that, it works for Sami, which has the same processor. No wonder the log doesn't show anything. What's still puzzling is that there are no exception traces in the console output at all. Sorry, unless I can reproduce I can't really help. No more ideas :(
(In reply to comment #48) > (In reply to comment #47) > > I just tried Eclipse 3.7RC4 and there's no change. > > I only now realize that you are getting the error when opening profile > configurations and NO error when trying to profile using the default > configuration. I assumed that since I got all of these errors, that a OProfile would not succeed, but it actually does succeed. So yes, you're right that all of these errors occur only when opening a profile configuration or creating a new one. > > Having said that, it works for Sami, which has the same processor. > > No wonder the log doesn't show anything. What's still puzzling is that there > are no exception traces in the console output at all. Sorry, unless I can > reproduce I can't really help. No more ideas :( I'd like to devote some time to debugging this, but I'm not sure I will be able to anytime soon. I'll put it on the back-burner for now. Thanks for your help.
Created attachment 197653 [details] Video showing the bug I was fiddling around with gtk-recordmydesktop and was able to get a video demonstration of the bug. It's probably not of much use, but it can't hurt.
Some debugging results: I made my own version of ophelp, which always just generates a XML output containing a single event which has no unit masks. With this version of ophelp, the error does not occur. One thing that is really confusing me is that I thought that the opxml code was supposed to be unused and that the "info adapter" which converts the output of ophelp -X into another internal format is now defunct and unused. However, what I find is that a) the code is still there, and b) it is still getting called. For example, InfoAdapter.createXML is getting called: InfoAdapter.createXML() line: 309 InfoAdapter.process() line: 125 OpxmlRunner.run(String[], Object) line: 106 LinuxOpxmlProvider$OpInfoRunner.run(IProgressMonitor) line: 55 LinuxOpxmlProvider$OpInfoRunner.run0(IProgressMonitor) line: 46 OpInfo.getInfo() line: 85 Oprofile._initializeOprofileCore() line: 94 Oprofile.initializeOprofileModule() line: 64 More specifically, opxml is getting run here: public static OpInfo getInfo() { // Run opmxl and get the static information OpInfo info = new OpInfo(); try { OpInfoRunner opxml = (OpInfoRunner) OprofileCorePlugin.getDefault().getOpxmlProvider().info(info); boolean ret = opxml.run0(null); if (ret == false) info = null; Should this still be getting called or not? Should the OProfile plug-in still be using this internal XML format, or not? If I can get answers to these questions, I think it will help me debug this code further.
I tried another experiment which seems to illuminate what's going on a bit. I took the output from my home Core2 Duo machine, and created a little script called ophelp which just outputs the Core2 Duo XML data, and then I ran it on my core i7 laptop, and I get no errors. So there's something about the ophelp -X output on my core i7 that is confusing infoAdapter. Sami, can you run ophelp --version on your Fedora 15 / core i7 machine and tell me what version number you get? On F14, I get 0.9.6. Also, could you post the output of ophelp -X on F15? I will try it on my laptop to see if I still get the error. I will post up my ophelp -X output for you to try, if you want.
Created attachment 197667 [details] output of ophelp -X on Fedora 14 w/ core i7 Note that you can use this XML file by placing it in your home directory and then creating a script: #! /bin/sh cat $HOME/corei7-f14.xml Make sure this script has execute rights, and is on your $PATH ahead of /usr/bin, and then start Eclipse and try right clicking on an executable and click Profile As-> Profile Configurations...
Corey, this was one of my thoughts as well that ophelp -X output is causing problems. Could you do the following on your laptop: $ ophelp -X > ophelp_out.xml && xmllint ophelp_out.xml As far as opxml is concerned, the internal xml format was never meant to be replaced. Perhaps, we should reconsider, though I'm not sure what the benefit would be. I don't think the internal format is related. Rather that the locale you have is interfering or the plug-in is expecting a certain locale (UTF-8, perhaps?), which your system is not using? What was meant to be replaced by the term "opxml removal" is the removal of the opxml native binary. Don't let references to opxml in the code confuse you. As of now, that's a legacy we have to deal with :( That being said, we should remove user visible error strings mentioning opxml and use proper wording for that.
(In reply to comment #54) > Corey, this was one of my thoughts as well that ophelp -X output is causing > problems. Could you do the following on your laptop: > > $ ophelp -X > ophelp_out.xml && xmllint ophelp_out.xml The xml comes up clean. Since I posted the xml file, you can have a look for yourself, and perhaps reproduce the problem. > > As far as opxml is concerned, the internal xml format was never meant to be > replaced. Perhaps, we should reconsider, though I'm not sure what the benefit > would be. I don't think the internal format is related. Rather that the locale > you have is interfering or the plug-in is expecting a certain locale (UTF-8, > perhaps?), which your system is not using? I think I'm using a standard locale. Here are two environment variable settings that I could find that look related: LANG=en_US.utf8 GDM_LANG=en_US.utf8 Is there something else I should check for that? Also, that wouldn't explain why my laptop is able to process the XML from my Core 2 Duo machine just fine, but chokes on my Core i7 XML. > > What was meant to be replaced by the term "opxml removal" is the removal of the > opxml native binary. Don't let references to opxml in the code confuse you. As > of now, that's a legacy we have to deal with :( That being said, we should > remove user visible error strings mentioning opxml and use proper wording for > that. OK, thanks for the explanation.
I'll go ahead and ensure that there are no references to opxml within the code, making necessary changes if needed.
Committed in 7435f7b6b65f16e7c4b586a986ff57c44d6d2053. Resolving this bug as fixed.
