Menu
▾
▴
[Avr-eclipse-user] [ avr-eclipse-Bugs-2872447 ] getWinAVRBasePath throws exception on Vista 64
|
From: SourceForge.net <no...@so...> - 2010-07-22 20:32:25
|
Bugs item #2872447, was opened at 2009-10-04 05:10 Message generated for change (Comment added) made by innot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2872447&group_id=189165 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Behavior Group: v2.3 Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Mitch Mitchell (mitchmitchell) Assigned to: Thomas Holland (innot) Summary: getWinAVRBasePath throws exception on Vista 64 Initial Comment: Whenever getWinAVRBasePath is called on my Windows Vista 64 system, I get the exception below. Creating an AVR project, trying to modify the paths under the AVR plugin etc. I think this is because the WinAVR registry key is not in HKML\Software\WinAVR but rather under HKML\Software\HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\WinAVR java.lang.NullPointerException at de.innot.avreclipse.core.paths.win32.SystemPathsWin32.getWinAVRBasePath(SystemPathsWin32.java:112) at de.innot.avreclipse.core.paths.win32.SystemPathsWin32.getWinAVRPath(SystemPathsWin32.java:89) at de.innot.avreclipse.core.paths.win32.SystemPathsWin32.getSystemPath(SystemPathsWin32.java:64) at de.innot.avreclipse.core.paths.SystemPathHelper.getPath(SystemPathHelper.java:102) at de.innot.avreclipse.core.paths.AVRPathProvider.getPath(AVRPathProvider.java:63) at de.innot.avreclipse.core.toolinfo.AVRDude.getToolPath(AVRDude.java:152) at de.innot.avreclipse.core.toolinfo.AVRDude.loadProgrammersList(AVRDude.java:666) at de.innot.avreclipse.core.toolinfo.AVRDude.getProgrammersList(AVRDude.java:212) at de.innot.avreclipse.ui.preferences.AVRDudeConfigEditor.<init>(AVRDudeConfigEditor.java:137) at de.innot.avreclipse.ui.preferences.ProgConfigListFieldEditor.editButtonAction(ProgConfigListFieldEditor.java:468) at de.innot.avreclipse.ui.preferences.ProgConfigListFieldEditor.access$7(ProgConfigListFieldEditor.java:434) at de.innot.avreclipse.ui.preferences.ProgConfigListFieldEditor$4.widgetSelected(ProgConfigListFieldEditor.java:376) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:228) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1003) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3880) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3473) at org.eclipse.jface.window.Window.runEventLoop(Window.java:825) at org.eclipse.jface.window.Window.open(Window.java:801) at org.eclipse.ui.internal.dialogs.WorkbenchPreferenceDialog.open(WorkbenchPreferenceDialog.java:211) at org.eclipse.ui.internal.OpenPreferencesAction.run(OpenPreferencesAction.java:65) at org.eclipse.jface.action.Action.runWithEvent(Action.java:498) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501) at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1003) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3880) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3473) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2405) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2369) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2221) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:493) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:194) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:368) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514) at org.eclipse.equinox.launcher.Main.run(Main.java:1311) ---------------------------------------------------------------------- >Comment By: Thomas Holland (innot) Date: 2010-07-22 22:32 Message: (Copied from Support Request 3031058) I thought I had this fixed (with 2.3.2), but I noticed that I never fully finished the fix. As I don't have a 64bit Windows I didn't test the fix before releasing it. I try to fix the bug over the weekend. In the meantime you could try the following workarounds: 1. Set the flag "Disable search for system paths at startup" on the AVR -> Paths preference page and manually set the paths. 2. If you can't set the flag due to NullPointerExceptions you could try to hack this flag. With Eclipse *not* running edit the file '{Workspace}\.metadata\.plugins\org.eclipse.core.runtime\.settings\de.innot.avreclipse.core.prefs' and add/edit the following line: 'avrpaths/NoScanAtStartup=true' Once you have done this you can restart Eclipse and again set the paths manually in the preferences. I have just tested this and it seems that with the workaround the offending code does not get called. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-10-14 04:28 Message: A simple failure mode that would allow me to manually enter the path to WinAVR would be all that is needed --- right now, the dialog to enter it gets the exception and nothing can be entered in the path field. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-10-14 04:26 Message: I am using Galileo on both machines. On the 32bit machine is Build id: 20090920-1017 Here is a copy of the exception on the 32bit machine -- I got to this one through a different path, but it is still in getWinAVRBasePath java.lang.NullPointerException at de.innot.avreclipse.core.paths.win32.SystemPathsWin32.getWinAVRBasePath(SystemPathsWin32.java:112) at de.innot.avreclipse.core.paths.win32.SystemPathsWin32.getWinAVRPath(SystemPathsWin32.java:89) at de.innot.avreclipse.core.paths.win32.SystemPathsWin32.getSystemPath(SystemPathsWin32.java:60) at de.innot.avreclipse.core.paths.SystemPathHelper.getPath(SystemPathHelper.java:102) at de.innot.avreclipse.core.preferences.AVRPathsPreferences$1.run(AVRPathsPreferences.java:168) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) ---------------------------------------------------------------------- Comment By: Thomas Holland (innot) Date: 2009-10-14 00:56 Message: BTW what Eclipse version do you use? ---------------------------------------------------------------------- Comment By: Thomas Holland (innot) Date: 2009-10-14 00:55 Message: I have started to work on this Bug and the obvious culprit is not the AVR Plugin but the WindowRegistry Class from CDT. There is already a bug report that this class is not working on 64bit Windows. https://bugs.eclipse.org/bugs/show_bug.cgi?id=236330 To fix the Problem I will need to check the return value of WindowsRegistry.getRegistry() and if it is Null then either fail gracefully or try some other method of getting access to the registry. I have just contacted the author of the above mentioned bug report to see if I can use his patch as a fallback when getRegistry() fails. Why it also fails on your 32 bit XP I have currently no idea. Can you confirm that it is the same NullPointerException or maybe something other Exception? ---------------------------------------------------------------------- Comment By: Mitch Mitchell (mitchmitchell) Date: 2009-10-04 07:52 Message: I have now confirmed that this exception is also thrown on my 32bit Windows XP machine so the difference in the registry data is not the cause of the null pointer exception ---------------------------------------------------------------------- Comment By: Thomas Holland (innot) Date: 2009-10-04 07:11 Message: Thanks for the detailed description. I will fix this in the next release. ---------------------------------------------------------------------- Comment By: Mitch Mitchell (mitchmitchell) Date: 2009-10-04 05:12 Message: Should have read as HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\WinAVR Also under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Free Software Foundation\WinAVR-20090313 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=928231&aid=2872447&group_id=189165 |
