Bugzilla – Full Text Bug Listing
| Summary: | Embedded SWT in Swing (in SWT) breaks between 3.6.x and 3.7 | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | James Peltzer <jpeltzer> | ||||||||
| Component: | SWT | Assignee: | Silenio Quarti <Silenio_Quarti> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | Silenio Quarti <Silenio_Quarti> | ||||||||
| Severity: | critical | ||||||||||
| Priority: | P3 | CC: | lshanmug, pwebster, remy.suen, Silenio_Quarti, skovatch | ||||||||
| Version: | 3.7 | ||||||||||
| Target Milestone: | 3.7.1 | ||||||||||
| Hardware: | Macintosh | ||||||||||
| OS: | Mac OS X | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
Looked in the History view for the changes in Shell.java. The problem in the snippet happens after the fix for Bug 337499. (In reply to comment #1) > Looked in the History view for the changes in Shell.java. The problem in the > snippet happens after the fix for Bug 337499. Does this mean that there is a possible solution available? If so, when might it be accessible? I have confirmed that reverting to the SWT version before Bug 337499 does fix the stack overflow on my main application but does introduce the myriad of NullPointerExceptions that the fix for 337499 is designed to prevent. I'm hoping there might be a patch in the works sometime soon, I don't mind not using a patched 3.7 plug-in but do need something functional before I can release my application. Created attachment 199826 [details] patch The patch modifies the condition check in attachObserversToWindow() to as it was before the fix for Bug 337499. This fixes the StackOverFlow problem. I was unable to test the testcase in Bug 337499 with the exact steps. But, I just ran the test as an applet didn't see any problem. Silenio, can you please review and comment? I applied the patch and it certainly seems to get rid of the stack overflow but there seems to be another major issue either created or in addition to the overflow:
If I remove the embedded Shell's AWT Canvas from the JPanel, the main SWT Shell seems to be disabled (I can't click anything or resize it). The application is still running - the menus are still function, I can open/interact with other dialogs in SWT and AWT, but I can do nothing in the main SWT Shell.
This happens regardless of whether I dispose of the SWT component before or after its parent canvas is removed.
I can post a modified copy of my original snippet to reproduce this part of the issue if you want.
--- what I did in the snippet ---
essentially just added a button to call this removeSWT method
public void removeSWT()
{
if (panel.getComponentCount() > 0)
panel.remove(0);
panel.doLayout();
}
---
James
(In reply to comment #4) I can reproduce the above problem. Adding Scott for expert comments. (In reply to comment #5) > (In reply to comment #4) > I can reproduce the above problem. Adding Scott for expert comments. This problem happens because Shell.removeObserversFromWindow() is calling display.removeWidget(hostWindow) Created attachment 200555 [details]
work in progress
This patch fixes both problems reported here. I am still testing it. I believe there are other problems in the code: for example the HashMap Shell.windowEmbedCounts does not seem to be doing anything since it is a instance var.
(In reply to comment #7) I can confirm that the "work in progress" patch seems to solve the issues I was experiencing. Any idea when the other possible problems in the code you mention will be verified/addressed? Would this patched version be at all safe to include in my RCP distributions? The patch is good. It certainly makes things much better. I released it to 3.8 and 3.7.1 branches. Fixed: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=fa54b4f605142844dcd8f13c6b822dad91c3adfd http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R3_7_maintenance&id=3cb7ea69091f6347ac094780a224b00b52e9fb21 |
Created attachment 198556 [details] Snippet to reproduce the issue I know it's a strange combination. I have an RCP application that uses Swing components for its editors. The Swing component now requires a web browser to be embedded in it. This means that we have an SWT shell with an AWT frame inside of it and a different SWT shell inside of the AWT frame. This all works fine (better than expected) in SWT 3.6.x. I migrated my code to 3.7 and now get non-stop StackOverlowErrors when I try to run this project. StackTrace: Exception in thread "main" java.lang.StackOverflowError at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method) at org.eclipse.swt.widgets.Widget.callSuper(Widget.java:220) at org.eclipse.swt.widgets.Widget.windowSendEvent(Widget.java:2092) at org.eclipse.swt.widgets.Shell.windowSendEvent(Shell.java:2255) at org.eclipse.swt.widgets.Display.windowProc(Display.java:5532) at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method) at org.eclipse.swt.widgets.Widget.callSuper(Widget.java:220) at org.eclipse.swt.widgets.Widget.windowSendEvent(Widget.java:2092) at org.eclipse.swt.widgets.Shell.windowSendEvent(Shell.java:2255) at org.eclipse.swt.widgets.Display.windowProc(Display.java:5532) at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method) I have created a snippet that reproduces this issue. The code runs in SWT 3.6.2 (you launch the shell, resize it, and press the button to create the SWT components). If you press the button in 3.7, you will get a stack overflow. If you press the button in 3.6 and resize the shell, you'll see an embedded SWT component with a red background. java version "1.6.0_24" Java(TM) SE Runtime Environment (build 1.6.0_24-b07-334-10M3326) Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02-334, mixed mode) org.eclipse.swt.cocoa.macosx.x86_64.source_3.7.0.v3735b.jar