Bugzilla – Full Text Bug Listing
| Summary: | Invalid memory access when using the new shell.getToolBar() | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Thomas Singer <eclipse> | ||||||
| Component: | SWT | Assignee: | Scott Kovatch <skovatch> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | Silenio Quarti <Silenio_Quarti> | ||||||
| Severity: | major | ||||||||
| Priority: | P3 | CC: | eclipse, skovatch | ||||||
| Version: | 3.7 | ||||||||
| Target Milestone: | 3.7 M5 | ||||||||
| Hardware: | Macintosh | ||||||||
| OS: | Mac OS X | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
If you comment the lines
final ToolBar toolBar = shell.getToolBar();
new ToolItem(toolBar, 0).setText("toolbar item");
the crash will not occur.
Can you attach a native stack trace when you crash? I'm having trouble reproducing this on top of tree. I know that sounds crazy since you've given me a nice clean example, but maybe there's some kind of autorelease problem here. Created attachment 185085 [details]
Crash log file
Today I can't reproduce it each time, but it looks like more often I start the sample application, the more likely this bug occurs.
(In reply to comment #3) > Today I can't reproduce it each time, but it looks like more often I start the > sample application, the more likely this bug occurs. Crash log definitely shows I'm over-releasing an autoreleased value. Now I just need to find it. Thanks! Is there a build which I should try to see whether it is fixed? Unfortunately I haven't had time to look into this, so no newer build will help here. I've been working on touch/gesture support full time. I definitely want to fix it by the time M5 ships, though. After some investigation, the problem is that we are dynamically subclassing NSToolbarView at runtime, adding an ivar (SWT_OBJECT) with class_addIvar, and changing the class with objc_setClass. That's going to fail, mainly on the 64-bit runtime. We use class_addIvar when defining all of the cocoa subclasses, but that's different because we aren't doing it dynamically. This excellent blog post <http://cocoasamurai.blogspot.com/2010/01/understanding-objective-c-runtime.html> describes it pretty well. This is going to be nasty to fix. On 10.6 I can use objc_setAssociatedObject to store the JNI pointer instead of adding an ivar. Or, add a dictionary to Display to keep track of these dynamically-subclassed objects. Created attachment 185920 [details]
Fix
Fix that removes the addition of SWT_OBJECT from SWTToolbarView, and also the SWT_OBJECT in the embedded Shell/SWT_AWT case.
Fixed > 20110104. |
Build Identifier: 3.7M4 import org.eclipse.swt.*; import org.eclipse.swt.layout.*; import org.eclipse.swt.widgets.*; public class Main { public static void main(String[] args) { final Display display = Display.getDefault(); final Shell shell = new Shell(display, SWT.SHELL_TRIM); final ToolBar toolBar = shell.getToolBar(); new ToolItem(toolBar, 0).setText("toolbar item"); shell.setLayout(new GridLayout()); final Label label = new Label(shell, 0); label.setText("label"); label.setLayoutData(new GridData(GridData.FILL, GridData.FILL, true, true)); shell.pack(); shell.setMinimumSize(shell.getSize()); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) { display.sleep(); } } display.dispose(); } } I'm getting the error "Invalid memory access of location 0x0 rip=0x7fff8249b979" (the numbers can be different each time) when I launch the above sample on OS X 10.6.5 using Java 1.6.0_22 and org.eclipse.swt.cocoa.macosx.x86_64_3.7.0.v3716.jar Reproducible: Always Steps to Reproduce: 1. launch above sample