Community
Participate
Working Groups
I20130502-0800 (4.3 M7) In the Error Log view, open the drop-down menu of the "Import Log" view toolbar button. Message is written to log: !ENTRY org.eclipse.debug.core 4 120 2013-05-05 16:59:27.910 !MESSAGE Variable references empty selection: ${container_loc}
I couldn't easily reproduce the log message in a new workspace, even after I launched a runtime Eclipse and threw an exception there. The original exception is discarded here (wrong usage of "e.getStatus()"): PDELogFileProvider.getLogSources() line: 61 After some debugging, I found that the affected launch configuration is an Eclipse Application whose program arguments contains "${container_loc}". The bug is that LaunchListener.getMostRecentLogFile(LaunchListener.java:170) calls LaunchArgumentsHelper.getWorkspaceLocation(..), whose Javadoc specifies that it must not be called in this situation. When I have a launch configuration with "${string_prompt}" in the arguments list, I even get a dialog! I don' see a good solution, unless we're willing to drop all substitutions. The basic problem is that IStringVariableManager#performStringSubstitution(String) unconditionally resolves all variables, including IDynamicVariables. There should be a variant of that method that makes sure no dynamic variables are evaluated (or at least non with side-effects, but that's also indistinguishable). The original exception is this: org.eclipse.core.runtime.CoreException: Variable references empty selection: ${container_loc} at org.eclipse.debug.internal.core.variables.ResourceResolver.abort(ResourceResolver.java:111) at org.eclipse.debug.internal.core.variables.ResourceResolver.getSelectedResource(ResourceResolver.java:132) at org.eclipse.debug.internal.core.variables.ResourceResolver.resolveValue(ResourceResolver.java:47) at org.eclipse.core.internal.variables.DynamicVariable.getValue(DynamicVariable.java:55) 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.pde.internal.launching.launcher.LaunchArgumentsHelper.getSubstitutedString(LaunchArgumentsHelper.java:329) at org.eclipse.pde.internal.launching.launcher.LaunchArgumentsHelper.getUserProgramArguments(LaunchArgumentsHelper.java:99) at org.eclipse.pde.internal.launching.launcher.LaunchArgumentsHelper.getUserProgramArgumentArray(LaunchArgumentsHelper.java:78) at org.eclipse.pde.internal.launching.launcher.LaunchArgumentsHelper.getWorkspaceLocation(LaunchArgumentsHelper.java:51) at org.eclipse.pde.internal.launching.launcher.LaunchListener.getMostRecentLogFile(LaunchListener.java:170) at org.eclipse.pde.internal.ui.launcher.PDELogFileProvider.getLogSources(PDELogFileProvider.java:53) at org.eclipse.ui.internal.views.log.LogFilesManager.getLogSources(LogFilesManager.java:51) at org.eclipse.ui.internal.views.log.ImportLogAction.getLogActions(ImportLogAction.java:168) at org.eclipse.ui.internal.views.log.ImportLogAction.menuUpdateNeeded(ImportLogAction.java:130) at org.eclipse.ui.internal.views.log.ImportLogAction.getMenu(ImportLogAction.java:103) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:530)
This problem is being surfaced by Bug 405578, because we are now checking for the -data argument. It is possible that a user might be using a string prompt or another variable to add the -data argument. However, it feels like this should be a very rare occurrence.
I agree it's rare that the "@none" argument will be provided by a variable. So the fix will be to avoid string substitutions in this case?
(In reply to comment #3) > I agree it's rare that the "@none" argument will be provided by a variable. > So the fix will be to avoid string substitutions in this case? The only broken case if we make this change would be if the '-data' argument was provided via variable. I'm proposing that when we look through the program arguments for -data, we do not do any string substitution. If -data is found, the next argument in the array must be a location, so we would perform string substitution on that argument. I am assuming from your comment 1 that the ${container_loc} in the arguments was not being used to fill in -data. Currently we perform string substitution on everything before we even look for -data.
Yes, in my case, ${container_loc} was not used for the -data argument, so comment 4 would solve this problem. I filed bug 407417 for the general problem.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This bug has been marked as stalebug a while ago without any further interaction. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard flag.
