Bugzilla – Full Text Bug Listing
| Summary: | NullPointerException in TaskItem.updateImage:420 | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Jacek Pospychala <jacek.pospychala> |
| Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | aniefer, eclipse.felipe, irbull, mtpersson, remy.suen, skovatch |
| Version: | 3.6 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X | ||
| Whiteboard: | |||
|
Description
Jacek Pospychala
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.) |