| Summary: | [launch] Launch fails when IDynamicVariableReslover.resolveValue() throws an exception. | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Victor Pakhomov <victor> | ||||||
| Component: | Debug | Assignee: | Pawel Piech <pawel.1.piech> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | brett.dellegrazie, cdtdoug, malaperle, marc.khouzam, Michael_Rennie, mlippert, pawel.1.piech | ||||||
| Version: | 3.7.1 | Flags: | Michael_Rennie:
review+
|
||||||
| Target Milestone: | 3.8 M5 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
I've seen something like this before caused by a third-party plugin. But I never found out what the root of the problem was. Looking at the trace here: org.springframework.ide.eclipse.core.BundleVersionVariableResolver.resolveValue(BundleVersionVariableResolver.java:28) it seems that the problem could be caused by spring-framework. I'm closing with NOT_ECLIPSE, however, if we can understand better the root of the problem, maybe we can do something in Eclipse. If that is the case, please re-open. I think DynamicVariable should be more defensive when it calls fResolver.resolveValue Since fResolver comes from an extension maybe it should be wrapped by a SafeRunner? (In reply to comment #2) > I think DynamicVariable should be more defensive when it calls > fResolver.resolveValue > > Since fResolver comes from an extension maybe it should be wrapped by a > SafeRunner? That sounds like a good idea. Is that the usual pattern for such cases? (In reply to comment #3) > (In reply to comment #2) > > I think DynamicVariable should be more defensive when it calls > > fResolver.resolveValue > > > > Since fResolver comes from an extension maybe it should be wrapped by a > > SafeRunner? > > That sounds like a good idea. Is that the usual pattern for such cases? I think so, I read about using SafeRunner in the "Contributing to Eclipse" book. Plus it appears to be used a lot in the presence of extensions. It's also mentioned in this extension point tutorial: http://www.vogella.de/articles/EclipseExtensionPoint/article.html Assigning to Platform for advice and potential fix. It doesn't seem appropriate for platform to be guarding against exceptions when calling into IDynamicVariableResolver.resolveValue(). It would imply that whenever we call into an interface that is backed by an object created through an extension, we have to protect against exceptions. That would mean adding a lot of defensive code in debug. OTOH, there is a real world problem here so it seems appropriate to fix it. Michael, please let me know if you disagree. Victor, if you can verify my fix. http://git.eclipse.org/c/platform/eclipse.platform.debug.git/diff/org.eclipse.core.variables/src/org/eclipse/core/internal/variables/DynamicVariable.java (In reply to comment #5) > It doesn't seem appropriate for platform to be guarding against exceptions when > calling into IDynamicVariableResolver.resolveValue(). It would imply that > whenever we call into an interface that is backed by an object created through > an extension, we have to protect against exceptions. That would mean adding a > lot of defensive code in debug. > > OTOH, there is a real world problem here so it seems appropriate to fix it. > Michael, please let me know if you disagree. > > Victor, if you can verify my fix. > > http://git.eclipse.org/c/platform/eclipse.platform.debug.git/diff/org.eclipse.core.variables/src/org/eclipse/core/internal/variables/DynamicVariable.java Hi Pawel, what I can do to verify it? I see only one java file. I can try, if you might provide some detail guide how to build and deploy it. I'm not familiar with eclipse-platform-development and have no env to build eclipse. I'm just developing java and jni using eclipse. With best regards, Victor The fix makes sense and is low impact, but in general we do not make it a habit to defend against 3rd party code issues. (In reply to comment #6) Hi Victor. You can pick up the next weekly build at http://download.eclipse.org/eclipse/downloads/, then install CDT 8 into it. Thanks, Pawel (In reply to comment #5) > OTOH, there is a real world problem here so it seems appropriate to fix it. > Michael, please let me know if you disagree. Thanks Pawel! Does this fix make sense for the maintenance branch? (In reply to comment #9) > Does this fix make sense for the maintenance branch? Yes, though I'd like to see the defect verified with the 3rd party plugin to make sure it solves the problem. FYI: https://issuetracker.springsource.com/browse/STS-2108 Is Spring IDE defect reference for the same issue The bug in Spring IDE is now fixed and will be available within the nightly builds and the upcoming Spring IDE 2.9.0 release. (In reply to comment #10) > (In reply to comment #9) > > Does this fix make sense for the maintenance branch? > > Yes, though I'd like to see the defect verified with the 3rd party plugin to > make sure it solves the problem. Although we didn't get a confirmation, are we too zonk for the maintenance branch? (In reply to comment #13) > (In reply to comment #10) > > (In reply to comment #9) > > > Does this fix make sense for the maintenance branch? > > > > Yes, though I'd like to see the defect verified with the 3rd party plugin to > > make sure it solves the problem. > > Although we didn't get a confirmation, are we too zonk for the maintenance > branch? How does my phone prefer 'zonk' to 'late'??? (In reply to comment #14) It's too late for SR2 , but we can still commit it to the maintenance branch if it helps you any. (In reply to comment #15) > (In reply to comment #14) > It's too late for SR2 , but we can still commit it to the maintenance branch if > it helps you any. Thanks, but we don't package our own version of the platform. I should have set a reminder for myself. Created attachment 210926 [details]
Test plugin p2 site
I don't think it fully solves the problem at the dsf.gdb level, I tested with 3.8M5. Attached is a p2 site containing a test plugin that reproduces the problem. To test, install the plug-in, create a debug configuration, add to the environment a variable of value ${testDynamicVarException.variable1} (you can use the Variables button). Launching the debug should throw the exception and it will still not launch.
org.eclipse.core.runtime.CoreException: Cannot get environment information
at org.eclipse.cdt.dsf.concurrent.Query.get(Query.java:115)
at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launchDebugSession(GdbLaunchDelegate.java:213)
at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launchDebugger(GdbLaunchDelegate.java:100)
at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launch(GdbLaunchDelegate.java:89)
at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:855)
at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:704)
at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:951)
at org.eclipse.debug.internal.ui.DebugUIPlugin$8.run(DebugUIPlugin.java:1155)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: org.eclipse.core.runtime.CoreException: Error while evaluating variable testDynamicVarException.variable1.
at org.eclipse.core.internal.variables.DynamicVariable.getValue(DynamicVariable.java:57)
at org.eclipse.core.internal.variables.StringSubstitutionEngine.resolve(StringSubstitutionEngine.java:270)
at org.eclipse.core.internal.variables.StringSubstitutionEngine.substitute(StringSubstitutionEngine.java:195)
at org.eclipse.core.internal.variables.StringSubstitutionEngine.performStringSubstitution(StringSubstitutionEngine.java:87)
at org.eclipse.core.internal.variables.StringVariableManager.performStringSubstitution(StringVariableManager.java:574)
at org.eclipse.core.internal.variables.StringVariableManager.performStringSubstitution(StringVariableManager.java:350)
at org.eclipse.debug.internal.core.LaunchManager.getEnvironment(LaunchManager.java:1273)
at org.eclipse.cdt.dsf.gdb.service.GDBBackend.getEnvironmentVariables(GDBBackend.java:323)
Created attachment 210927 [details]
Test plugin source
|
Build Identifier: M20110909-1335 !ENTRY org.eclipse.core.jobs 4 2 2011-12-03 14:57:32.801 !MESSAGE An internal error occurred during: "Launching cxxtetgen". !STACK 0 java.lang.IllegalArgumentException at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.getBundles(PackageAdminImpl.java:582) at org.eclipse.core.internal.runtime.InternalPlatform.getBundle(InternalPlatform.java:183) at org.eclipse.core.runtime.Platform.getBundle(Platform.java:1416) at org.springframework.ide.eclipse.core.BundleVersionVariableResolver.resolveValue(BundleVersionVariableResolver.java:28) at org.eclipse.core.internal.variables.DynamicVariable.getValue(DynamicVariable.java:54) at org.eclipse.cdt.internal.core.cdtvariables.EclipseVariablesVariableSupplier$EclipseVarMacro.loadValue(EclipseVariablesVariableSupplier.java:103) at org.eclipse.cdt.internal.core.cdtvariables.EclipseVariablesVariableSupplier$EclipseVarMacro.getStringValue(EclipseVariablesVariableSupplier.java:90) at org.eclipse.cdt.dsf.gdb.launching.LaunchUtils.getLaunchEnvironment(LaunchUtils.java:414) at org.eclipse.cdt.dsf.gdb.launching.LaunchUtils.getGDBVersion(LaunchUtils.java:295) at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.getGDBVersion(GdbLaunchDelegate.java:270) at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launchDebugSession(GdbLaunchDelegate.java:138) at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launchDebugger(GdbLaunchDelegate.java:98) at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launch(GdbLaunchDelegate.java:87) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:854) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:703) at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:928) at org.eclipse.debug.internal.ui.DebugUIPlugin$8.run(DebugUIPlugin.java:1132) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Reproducible: Always Steps to Reproduce: 0. download and unpack "Oracle Enterprise Pack for Eclipse Beta (12.1.1)" 1. create simple hello world cpp project with hello world application. 2. build and run it. then debug. 3. get pop up dialog with error message. in details>>> "An internal error occurred during: "Launching cxxtetgen". java.lang.IllegalArgumentException" 4. in .log found the stacktrace. 5. I've moved all org.springframework* from plugins and feature eclipse dir to other location. after eclipse restart I don't see the springIDE icon in help/about anymore and can debug the C++ program.