Community
Participate
Working Groups
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
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.
