Community
Participate
Working Groups
When starting an adopter Eclipse product, we're getting lots of NullPointerExceptions in the error log. Our product is based on Eclipse Helios. This happens only on Mac, and not on Windows or Linux. Full stack trace: Thread [main] (Suspended (exception NullPointerException)) TaskItem.updateImage() line: 420 TaskItem.setProgress(int) line: 348 Workbench$TaskBarDelegatingProgressMontior.handleTaskBarProgressUpdated() line: 322 Workbench$TaskBarDelegatingProgressMontior.worked(int) line: 264 Workbench$StartupProgressBundleListener.bundleChanged(BundleEvent) line: 416 BundleContextImpl.dispatchEvent(Object, Object, int, Object) line: 919 EventManager.dispatchEvent(Set, EventDispatcher, int, Object) line: 227 ListenerQueue.dispatchEventSynchronous(int, Object) line: 149 Framework.publishBundleEventPrivileged(BundleEvent) line: 1349 Framework.publishBundleEvent(int, Bundle) line: 1300 BundleHost.startWorker(int) line: 380 BundleHost(AbstractBundle).start(int) line: 284 SecureAction.start(Bundle, int) line: 417 BundleLoader.setLazyTrigger() line: 265 EclipseLazyStarter.postFindLocalClass(String, Class, ClasspathManager) line: 106 ClasspathManager.findLocalClass(String) line: 453 DefaultClassLoader.findLocalClass(String) line: 216 BundleLoader.findLocalClass(String) line: 393 BundleLoader.findClassInternal(String, boolean, ClassLoader) line: 469 BundleLoader.findClass(String, boolean) line: 422 BundleLoader.findClass(String) line: 410 DefaultClassLoader.loadClass(String, boolean) line: 107 DefaultClassLoader(ClassLoader).loadClass(String) line: 248 BundleLoader.loadClass(String) line: 338 BundleHost.loadClass(String, boolean) line: 232 BundleHost(AbstractBundle).loadClass(String) line: 1197 EquinoxRegistryStrategy(RegistryStrategyOSGI).createExecutableExtension(RegistryContributor, String, String) line: 174 ExtensionRegistry.createExecutableExtension(RegistryContributor, String, String) line: 904 ConfigurationElement.createExecutableExtension(String) line: 243 ConfigurationElementHandle.createExecutableExtension(String) line: 55 WorkbenchPlugin$1.run() line: 267 BusyIndicator.showWhile(Display, Runnable) line: 70 WorkbenchPlugin.createExtension(IConfigurationElement, String) line: 263 ViewDescriptor.createView() line: 63 ViewReference.createPartHelper() line: 327 ViewReference.createPart() line: 229 ViewReference(WorkbenchPartReference).getPart(boolean) line: 595 WorkbenchPage$ActivationList.setActive(IWorkbenchPartReference) line: 4218 WorkbenchPage$18.runWithException() line: 3277 WorkbenchPage$18(StartupThreading$StartupRunnable).run() line: 31 RunnableLock.run() line: 35 UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 134 Display.runAsyncMessages(boolean) line: 3586 Display.readAndDispatch() line: 3279 IDEWorkbenchAdvisor(WorkbenchAdvisor).openWindows() line: 803 Workbench$31.runWithException() line: 1566 Workbench$31(StartupThreading$StartupRunnable).run() line: 31 RunnableLock.run() line: 35 UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 134 Display.runAsyncMessages(boolean) line: 3586 Display.readAndDispatch() line: 3279 Workbench.runUI() line: 2537 Workbench.access$4(Workbench) line: 2427 Workbench$7.run() line: 670 Realm.runWithDefault(Realm, Runnable) line: 332 Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 663 PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 149 IDEApplication.start(IApplicationContext) line: 115 EclipseAppHandle.run(Object) line: 196 EclipseAppLauncher.runApplication(Object) line: 110 EclipseAppLauncher.start(Object) line: 79 EclipseStarter.run(Object) line: 369 EclipseStarter.run(String[], Runnable) line: 179 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25 Method.invoke(Object, Object...) line: 597 Main.invokeFramework(String[], URL[]) line: 619 Main.basicRun(String[]) line: 574 Main.run(String[]) line: 1407
This is Cocoa, right?
yes, it's cocoa, 3.6.0.v3650b
If I'm looking correctly, the NPE is caused by NULL from rep.initWithBitmapDataPlanes(...). Now under what circumstances this method can return null? Is this caused by some wrong shape of the image we use as icon?
Please attach the image and a snippet if possible. The same code (rep.initWithBitmapDataPlanes) is used in several places.
sorry, but I can't provide a snippet, because this is happening in an Eclipse-based product, crated from PDE product configuration, so it's PDE/Platform code, not mine. the product can be downloaded from http://www.zend.com/en/products/studio/download-8-beta altough it requires registration.
There are also a lot of messages in Console.app: 8/23/10 10:13:26 AM /Applications/Zend Studio.app/Contents/MacOS/ZendStudio[6140] Unrecognized Java VM option ignored: -XstartOnFirstThread 8/23/10 10:13:26 AM /Applications/Zend Studio.app/Contents/MacOS/ZendStudio[6140] Unrecognized Java VM option ignored: -Xdock:icon=../Resources/ 8/23/10 10:13:26 AM /Applications/Zend Studio.app/Contents/MacOS/ZendStudio[6140] Unrecognized Java VM option ignored: mac.icns 8/23/10 10:14:00 AM ZendStudio[6140] Inconsistent set of values to create NSBitmapImageRep (last line repeated over and over) The problem is the broken line at the end of ZendStudio.ini: -Xdock:icon=../Resources/ mac.icns For some reason this is throwing off the VM argument parser, and we aren't able to set up defaultImage properly. A simple fix is to remove the newline after "/Resources/", but the better fix is to remove "-XstartOnFirstThread" and "-Xdock:icon=../Resources/mac.icns" from the .ini file. The -X arguments are only understood by the java command-line too, and Eclipse uses JNI to launch the app. The Eclipse launcher already knows to start the JVM on thread 0, and the icon is specified in the Info.plist, so they don't need to be in the .ini file as well. Eclipse.app also has these unnecessary lines, so I'm sending this bug to PDE for resolution.
On second thought, I filed bug 323419. PDE should fix the generation of the application bundle, but you can fix this yourself until PDE fixes that bug. I don't think we should change the SWT to handle this, as it's configuration-related.
See also bug 209722 regarding unrecognized vm arguments, the eclipse launcher needs to remove some VM args before starting the vm through JNI.
Actually I think this could be handled much better by validating the icon path early. What happens now is the following, in Display.createDisplay(DeviceData): * The icon path is retrieved from the environment variable (set by the executable). * An NSImage is allocated and initialized by using initByReferencingFile(NSString). Note that this is a lazy initialization that doesn't even check that the file exists, until information about the image is needed. This where SWT should do basic error checking. Either by verifying the constructed NSImage by sending isValid(), or change the initialization to use initWithContentsOfFile(NSString), which then would return null. Only if the NSImage is valid should it be used to set the dockImage and for NSApplication.setApplicationIconImage(NSImage). If not, SWT should log an error message, release the NSImage, and then proceed as if no icon was specified. Otherwise, and what happened in this bug, was that the Dock mostly ignored the invalid NSImage, but it was eventually passed into the TaskItem.defaultImage instance variable. From there it was used in TaskItem.updateImage() to obtain a NSSize, with which to initialize a NSBitmapImageRep. This is problematic. NSImage.getSize() returns a resolution independent size (in points, not pixels), and as a result it may not always be possible to determine from the image representations. In that case, a size of (0, 0) is returned, unless a size has been explicitly set. An invalid NSImage, as in this bug, also returns (0, 0) as the size. Now, quite reasonably, you cannot create a NSBitmapImageRep with size (0, 0). So NSBitmapImageRep.initWithBitmapDataPlanes(...) returns null, causing the NPE. (By the way, creating a bitmap with pixel dimensions equal to the dimension in points, as TaskItem tries to do, isn't optimal on HiDPI displays. But that is another bug.)
