Bugzilla – Full Text Bug Listing
| Summary: | [Widgets] eclipse >= 3.5 crash when closing a first level modal window (Install, Run Configurations) | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Alban Browaeys <prahal> | ||||||||||||||
| Component: | SWT | Assignee: | Silenio Quarti <Silenio_Quarti> | ||||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||||
| Severity: | major | ||||||||||||||||
| Priority: | P3 | CC: | ben, eclipse.felipe, enietom, h1055071, juri, nh2-eclipsebugzilla, opensource, overholt, psingh, remy.suen, Silenio_Quarti, siml, vilmar | ||||||||||||||
| Version: | 3.5 | Flags: | eclipse.felipe:
review+
|
||||||||||||||
| Target Milestone: | 3.5.2 | ||||||||||||||||
| Hardware: | PC | ||||||||||||||||
| OS: | Linux | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| Attachments: |
|
||||||||||||||||
|
Description
Alban Browaeys
Created attachment 148593 [details]
Gdb backtrace
Created attachment 148594 [details]
Java backtrace
This backtrace was made by opening "Help">"Install New Software" then "Cancel". Can you make this happen at will? Or was it one time? And can you provide the version information for Eclipse? The java backtrace shows it but this is with gtk 2.18.1, pango 1.26.0, openjdk 6 (I tried sun with exact same result, also fedora openjdk same result). glib 2.22.1 , libc6 2.9, eclipse 3.5.0, eclipse 3.5.1 and 3.6M2. At will , all the time. Sorry for the "the hserror" shows it . I found out it was missing and mid air collision leads to quiproquo. The trace was done against 3.5.0. been a while I have not pursued eclipse issue , forgot about the build id : Build id: 20090920-1017 Also I got an Build id: N20081102-2000 that does not shows the issue (same libraries gtk and the like underneath). Quite old still . 3.4 (tasktop 1.5) does not shows the issue (I am using it to interact with bugs). This fact leads me to the idea that at least a change in swt/jface made eclipse crash ... there may also be an issue with gtk libraries . Created attachment 148597 [details]
Java trace with eclipse 3.6M2
Hum tenth comment. I forgot to mention I added perror once in pango_layout_new and the error at this crash point was error 11, resource temporarly unavailable while doing g_object_new (PANGO_TYPE_LAYOUT, NULL); which return null and then the segfault happens in layout->context = context; .
I have a hard time understanding what this means in this context.
Seeking.
PangoLayout *
pango_layout_new (PangoContext *context)
{
PangoLayout *layout;
g_return_val_if_fail (context != NULL, NULL);
layout = g_object_new (PANGO_TYPE_LAYOUT, NULL);
layout->context = context;
g_object_ref (context);
return layout;
}
Are there any repro steps for me to try? Steps . Open "Help">"Install New Software" and press cancel or close the window. There is another case I mentioned earlier but I already mentionned those. Though this happens only if the first level modal window has a scrolled widget inside? This I implied from reading the gdb backtrace. Sorry I have not tested a lot of use cases. My point was to see if the upgrade was working in 3.5 and above as it was not in 3.4 (due to emf digest.zip missing from the download.eclipse.org I am feed with). Thus this is the first thing I tried. Then the second thing was the PDE export to try my modified version ... crashed. I managed to workaround the issue : by disabling the code in SWT gtk Display.java initializeSubclasses, ie the override of the PangoLayout constructor. I don't know why but the callback defined there fails to be called back from the C code in any cases. Do you have any clue ? The callback is defined when eclipse start and destroyed when it stop but nothing touch the callback on the java side. I also modified pango to return NULL instead of segfaulting locally and this leaded to Pango errors on the console but still pango was failling to call the java callbacks only for a few calls when closing first level modal window. After surviving those few calls pango resumes calling this callback successfully . What s specific about those few calls is that they happens when the gtk widgets are destroyed recursively as shown byt he gdb backtrace and that they stumble on a scroleld widget to destroy. Before annihilating it it resize the scrollable area to 0 and thus triggers gtk_text_view_value_changed which via calls create a new pango_layout by itself. Created attachment 148731 [details]
same issue but java trace from closing via window manager instead of cancel
I rebuild swt native libraries against my system and openjdk. The issue disappeared it seems (my perror does not appear anymore). This I did because the issue was in jni callback.c as the issue was that the pangoLayoutNewProc callback was returning null to the glib gobject class->constructor calls it overrided). Thus I rebuild it with debug printf and the issue dissaperead at the same time . Thus I think the breakage came from a bug in either IBMJava2-141 as the org.eclipse.swt/tasks/build.xml shows as used to build gtk x86 target or gcc version used. I cannot find IBMJava2-141 not could I guess the gcc version used. Could you provide me with those as it seems the issue is not reproducible on your side ? Mind there are other users with the same issue : "pango_layout_new 0x36" search on the web shows the two with the exact same versions of underlying libraries as mine. But there are others without 0x36. (In reply to comment #13) > I cannot find IBMJava2-141 not could I guess the gcc version used. 3.5 is build on Red Hat Enterprise Linux WS release 3 (Taroon Update 9) -sh-2.05b$ gcc --version gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-59) 3.6 is build on Red Hat Enterprise Linux WS release 4 (Nahant Update 8) -sh-3.00$ gcc --version gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-11) ok I have rebuild natives with gcc-3.4.6-9 from lenny (debian). No go. The perror I added in pango/pango-layout.c pango_layout_new when layout is null after g_object_new instanciation. So the callback is working with the local build. Only it does not with the official one (those in cvs for org.eclipse.swt.gtk.linux.x86 starting from eclipse 3.5 to the latest). Do you know if I could get a version of IBMJava2-141 ? I am already registered to ibm and have 142, 5 and 6 but it is pointless as all I need is to get something that crashes to confirm where the bug lays down (it could still be in the gcc toolchain ... I am Sid user so I was able to installed old 3.4.6 from lenny but this has use libc6-2.9-27 and new binutils 2.19.91.20091006-1, new libgcc1 1:4.4.1-6). I could get my hand on a lenny system by erasing one of my system and reinstalling older distribution though this will still no match exactly with RH patches (there is no way to have a Redhat system cheap deal I guess ). Anyway this is a sorry situation . I first encountered it with Aptana, then sitched to PDT all in one, then to 3.5.1 vanilla to end up on 3.6 then 3.6+swt cvs and all those are borken :( Alban, the code that is causing the trouble is the fix for Bug 236513. Does the code in Display#initializeSubclasses() work fine ? If you put a break point in: Display#pangoLayoutNewProc(int, int, int) Does it ever get called ? If it does, can you step over the make it returns a valid value ? (I don't think the version of java we are compiling against matters) I did add a println inside it as one of the first thing. It is not called when the callback is not made (obvious but why the callbakc is not made is another story ...) if I compile with gcc 3.4 and newer ibm jdk it is always called. Not with the native binaries provide though the official build. The fact I do not expand more on the 'when the callbakc is not called' is that I added printf to the callback.c code and recompiled to try and find out why it was not called (the only thing I know from debugging with official binaries is that the callback returns error 11 - resource temporarily unavailable) , it ended up making the bug disappear. By the way I asked pango upstream to not segfault (check null value before dereferencing) and the reply is a wontfix because it ought not to happen and would lead to unpredictable behaviour (which makes sense ). Gnome bugzilla 598348 . The code in Display#initializeSubclasses() works fine in that it register the callback as the pangoLayout clas constructor to glib. The issue is that afterwards not that when it does not work but that Display#pangoLayoutNewProc(int, int, int) is not even called (so the issue happens in the callback.c callback code. Hope it help forward the issue to a meaningful state . I doubt it relates to the fix in ibm jdk 142 about jni and address alignement. But who knows . This is beyond my understanding of java internals (ir the jdk used to compile a jni , here callback.c, is partly statically compiled into the native binary. Or else it is the compiler that have issue producing correct code ... RH back then had a reputation of heavily patching its compiler with new features. See Ubuntu Bug 445009 (https://bugs.launchpad.net/bugs/445009) and Bug 460104 (https://bugs.launchpad.net/bugs/460104 for a possible workaround. If I'm reading the Ubuntu reports clearly (and I have heard reports of the same with Fedora), this only happens if one has GNOME accessibility turned on. Right? @ Andrew: Right. Do you have any recommendations to rebuild anything what might help to avoid this error? I recompiled SWT, but that did not change anything. (In reply to comment #20) > @ Andrew: Right. > Do you have any recommendations to rebuild anything what might help to avoid > this error? I recompiled SWT, but that did not change anything. Did you recompile the java part or the native part (in c). This is the later compile that fixed it for me. Also it could be that latest build of swt fixed it r3617 (though I still have to check if I don't have pango with my workaround to avoid the segfault sitting somewhere where it would hide the issue). @ Alban: I recompiled the complete Eclipse SWT plugin inclusive native files via ANT and copied it over to the Eclipse dir, but libpango still crashed. Could you try that again and tell me if it still works? If yes, could you write down your steps so that I can reproduce it? Thanks. (In reply to comment #22) > @ Alban: > I recompiled the complete Eclipse SWT plugin inclusive native files via ANT and > copied it over to the Eclipse dir, but libpango still crashed. > > Could you try that again and tell me if it still works? If yes, could you write > down your steps so that I can reproduce it? Thanks. The thing is that I don't know how to rebuild swt natives via ant . It calls eclipse internal tasks thus I have only been able to rebuild the natives through eclipse itself. Could you share your recipe to do it via ant so I can try and check the results match my own ? Because I tried back then as it was not easy to rebuild via eclipse with eclipse constantly crashing . I ended up patching pango to enable me to build it (with printf added that were not triggered anymore after the rebuild leading me to conclude that fixed the issue). (In reply to comment #23) > The thing is that I don't know how to rebuild swt natives via ant . It calls > eclipse internal tasks thus I have only been able to rebuild the natives > through eclipse itself. Yes, I had the same problem that I could not build it without Eclipse as http://www.eclipse.org/swt/faq.php#howbuilddll does not give any hint to do it via command line and ANT only. So I did it just like you. I said I built it via ANT since I right-clicked on the build.xml file and chose "Ant build ...". I turned assistive technologies off during the build so that eclipse does not crash anymore. To check my build, I turned it on again, and it kept crashing. So now what I did in detail: - I disabled assistive technologies and restarted my session. - I checked out the org.eclipse.swt and org.eclipse.swt.gtk.linux.x86 CVS repo paths as described in http://www.eclipse.org/swt/cvs.php. - I compiled the JNI natives with build.sh (http://www.eclipse.org/swt/faq.php#howbuilddll / "Building the SWT JNI libraries from the eclipse CVS repository"). - I copied the generated .so files over to org.eclipse.swt.gtk.linux.x86 to replace the .so files in there. - I run the jar.plugin ANT target with Eclipse (http://www.eclipse.org/swt/faq.php#howbuildplugin - I also did step 5 and added "v3617" in the build.xml and MANIFEST.MF files). - I copied the created plugin jar over to my Eclipse's plugin directory (I make a backup of the old one before). - I enabled assistive technologies, restarted my session, started Eclipse, "Help -> Install Software -> Cancel" and it crashed. > I ended up patching pango to enable me to build it (with printf added that were > not triggered anymore after the rebuild leading me to conclude that fixed the > issue). Could you try if it works with the unpatched pango, too? Could you further tell me what exactly you did to patch pango or attach your patch? Thanks! As a workaround until the bug is fixed, deactivate assistive technologies in your OS. Worked for me. (In reply to comment #24) https://bugzilla.gnome.org/show_bug.cgi?id=598348 there is no patch per so but the modification is to replace: PangoLayout * pango_layout_new (PangoContext *context) { PangoLayout *layout; const char * test = "pango layout new"; g_return_val_if_fail (context != NULL, NULL); layout = g_object_new (PANGO_TYPE_LAYOUT, NULL); layout->context = context; g_object_ref (context); return layout; } by: PangoLayout * pango_layout_new (PangoContext *context) { PangoLayout *layout; const char * test = "pango layout new"; g_return_val_if_fail (context != NULL, NULL); layout = g_object_new (PANGO_TYPE_LAYOUT, NULL); if(layout == NULL) { perror(test); return NULL; } layout->context = context; g_object_ref (context); return layout; } as with this eclipse bug layout is null only when destroying widgets this does not hurt too much (compared to an eclipse crash). It is null because the callback defined by swt to handle the PANGO_TYPE_LAYOUT constructor does not returns anything (I was unable to useprintk in swt callback.c to find out as it worked right after I compiled it locally). I should already be using libpango without this workaround as I reinstalled pango via apt over the previous locally compiled libpango). Though a few days ago I deactivated assistive technology for something unrelated . That may be why even after upgrading to latest swt I did not encountered the issue anymore. Trying to reproduce. (In reply to comment #26) @@ -730,8 +752,8 @@ if ((*env)->ExceptionOccurred(env)) { #ifdef DEBUG_CALL_PRINTS fprintf(stderr, "* java exception occurred\n"); - (*env)->ExceptionDescribe(env); #endif + (*env)->ExceptionDescribe(env); result = callbackData[index].errorResult; } should do . I had enabled (defined) DEBUG_CALL_PRINTS thus I did had this code enabled. Don't know if it is supposed to be defined for certain though it looks like it was a mistake. With debug enabled the message is : * java exception occurred Exception in thread "main" org.eclipse.swt.SWTException: Widget is disposed at org.eclipse.swt.SWT.error(SWT.java:4068) at org.eclipse.swt.SWT.error(SWT.java:3983) at org.eclipse.swt.SWT.error(SWT.java:3954) at org.eclipse.swt.widgets.Widget.error(Widget.java:458) at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:396) at org.eclipse.swt.widgets.Text.getText(Text.java:984) at org.eclipse.ui.dialogs.FilteredTree$3.getName(FilteredTree.java:628) at org.eclipse.swt.accessibility.AccessibleObject.atkObject_get_name(AccessibleObject.java:395) at org.eclipse.swt.internal.gtk.OS._gtk_widget_destroy(Native Method) at org.eclipse.swt.internal.gtk.OS.gtk_widget_destroy(OS.java:12287) at org.eclipse.swt.widgets.Widget.destroyWidget(Widget.java:420) at org.eclipse.swt.widgets.Widget.release(Widget.java:1075) at org.eclipse.swt.widgets.Control.release(Control.java:3273) at org.eclipse.swt.widgets.Widget.dispose(Widget.java:454) at org.eclipse.swt.widgets.Shell.dispose(Shell.java:2208) at org.eclipse.jface.window.Window.close(Window.java:335) at org.eclipse.jface.dialogs.Dialog.close(Dialog.java:979) at org.eclipse.jface.dialogs.TrayDialog.close(TrayDialog.java:179) at org.eclipse.jface.wizard.WizardDialog.hardClose(WizardDialog.java:807) at org.eclipse.jface.wizard.WizardDialog.close(WizardDialog.java:427) at org.eclipse.equinox.internal.provisional.p2.ui.dialogs.ProvisioningWizardDialog.close(ProvisioningWizardDialog.java:52) at org.eclipse.jface.wizard.WizardDialog.cancelPressed(WizardDialog.java:414) at org.eclipse.jface.wizard.WizardDialog$1.widgetSelected(WizardDialog.java:293) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:228) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1218) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3521) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3139) at org.eclipse.jface.window.Window.runEventLoop(Window.java:825) at org.eclipse.jface.window.Window.open(Window.java:801) at org.eclipse.equinox.internal.p2.ui.sdk.InstallNewSoftwareHandler.doExecute(InstallNewSoftwareHandler.java:41) at org.eclipse.equinox.internal.p2.ui.sdk.PreloadingRepositoryHandler.doExecuteAndLoad(PreloadingRepositoryHandler.java:101) at org.eclipse.equinox.internal.p2.ui.sdk.PreloadingRepositoryHandler$1.run(PreloadingRepositoryHandler.java:52) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.equinox.internal.p2.ui.sdk.PreloadingRepositoryHandler.execute(PreloadingRepositoryHandler.java:50) at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:294) at org.eclipse.core.commands.Command.executeWithChecks(Command.java:476) at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508) at org.eclipse.ui.internal.handlers.HandlerService.executeCommand(HandlerService.java:169) at org.eclipse.ui.internal.handlers.SlaveHandlerService.executeCommand(SlaveHandlerService.java:241) at org.eclipse.ui.menus.CommandContributionItem.handleWidgetSelection(CommandContributionItem.java:790) at org.eclipse.ui.menus.CommandContributionItem.access$18(CommandContributionItem.java:776) at org.eclipse.ui.menus.CommandContributionItem$5.handleEvent(CommandContributionItem.java:766) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1218) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3521) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3139) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2404) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2368) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2220) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:493) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:194) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:367) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:611) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:566) at org.eclipse.equinox.launcher.Main.run(Main.java:1363) at org.eclipse.equinox.launcher.Main.main(Main.java:1339) Sorry for blaming the toolchain. (In reply to comment #27) > (In reply to comment #26) > @@ -730,8 +752,8 @@ > if ((*env)->ExceptionOccurred(env)) { > #ifdef DEBUG_CALL_PRINTS > fprintf(stderr, "* java exception occurred\n"); > - (*env)->ExceptionDescribe(env); > #endif > + (*env)->ExceptionDescribe(env); > result = callbackData[index].errorResult; > } oups I forgot to tell this is in org.eclipse.swt callback.c (In reply to comment #27) > (In reply to comment #26) > @@ -730,8 +752,8 @@ > if ((*env)->ExceptionOccurred(env)) { > #ifdef DEBUG_CALL_PRINTS > fprintf(stderr, "* java exception occurred\n"); > - (*env)->ExceptionDescribe(env); > #endif > + (*env)->ExceptionDescribe(env); > result = callbackData[index].errorResult; > } > > should do . I had enabled (defined) DEBUG_CALL_PRINTS thus I did had this code > enabled. > > Don't know if it is supposed to be defined for certain though it looks like it > was a mistake. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4067541 and http://forums.sun.com/thread.jspa?threadID=5327237 confirm that ExceptionDescribe indeed clear the exception. I betr the previous code was better in that we only want to print the exception to stderr if in debug mode. And also because the fact that ExceptionDescribe clear the exception could well be implementation specific thus the fix would work only on sun jdk >= 1.5 (or 1.3 the sun report is not clear on that) but still sun only. Maybe the code should clear the exception explicitely. Could anyone explain why I got error 11 resource temporarily unavailable in pango calling the callback when the exception is not cleared ? That would help understand the issue. Same problem running on a ubuntu 9.10 64-bit. I can not disable the assistive technologies because I am blind. By this reason I need run orca. Since disable assistive technologies seems to be a workaround to the problem, I wrote to Li Yuan, responsable to keep at-spy. I pointed him to bug https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/445009 because I didn't know about existence of a reported bug in eclipse. He answered the following: From the trace, I don't find any accessibility code. Although it is not a complete trace, it would be great if we can get the full trace. May I insist with Li Yuan? What information can I send him? Thanks. --- Is this a bug in OpenJDK ? Note that OpenJDK is not officially supported by Eclipse. See http://www.eclipse.org/projects/project-plan.php?projectid=eclipse#target_environments It that is the case, the workaround is to use a different VM. Bogdan, should this be closed as NOT_ECLIPSE ? > Also it could be that latest build of swt fixed > it r3617 (though I still have to check if I don't have pango with my workaround > to avoid the segfault sitting somewhere where it would hide the issue). Alban, can you verify if the fix for Bug 292141 also fixed this problem ? Also, ExceptionDescribe() should not clear the exception. If it does it is bug (apparently in this case it helps but it is wrong code). Thank you (In reply to comment #32) > Is this a bug in OpenJDK ? > No, unfortunately I can reproduce the same problem using the following java environment: # JRE version: 6.0_16-b01 # Java VM: Java HotSpot(TM) 64-Bit Server VM (14.2-b01 mixed mode linux-amd64 > Note that OpenJDK is not officially supported by Eclipse. See > http://www.eclipse.org/projects/project-plan.php?projectid=eclipse#target_environments > > It that is the case, the workaround is to use a different VM. > > Bogdan, should this be closed as NOT_ECLIPSE ? If ExceptionDescribe() clears the exception, we should rethrow it so that we do not have different behavior when the printfs are enabled. We should probably open a separate bug for this. I believe we understand the problem: The problem is caused by the exception from comment#27. callback.c does not call into java if there is an unhandled exception in previous callbacks. See the code: /* If an exception has occurred in previous callbacks do not call into the VM. */ if ((*env)->ExceptionOccurred(env)) { goto done; } The fix is to handle the original exception. I will attach a patch for this. Please could you try it out. Created attachment 153364 [details]
patch
(In reply to comment #33) > > Also it could be that latest build of swt fixed > > it r3617 (though I still have to check if I don't have pango with my workaround > > to avoid the segfault sitting somewhere where it would hide the issue). > > Alban, can you verify if the fix for Bug 292141 also fixed this problem ? > > Also, ExceptionDescribe() should not clear the exception. If it does it is bug > (apparently in this case it helps but it is wrong code). > > Thank you No it cannot. Fixing 292141 indeed help build a as close to vanilla swt but as I found out and told in latest comments the issue is that when assistive technology is on, debug is not on in swt callback.c (and debug on should only help with sun or openjdk as they implement a Ds(In reply to comment #35) > If ExceptionDescribe() clears the exception, we should rethrow it so that we do > not have different behavior when the printfs are enabled. We should probably > open a separate bug for this. > > I believe we understand the problem: > > The problem is caused by the exception from comment#27. callback.c does not > call into java if there is an unhandled exception in previous callbacks. See > the code: > > /* If an exception has occurred in previous callbacks do not call into the > VM. */ > if ((*env)->ExceptionOccurred(env)) { > goto done; > } > > The fix is to handle the original exception. I will attach a patch for this. > Please could you try it out. Tried and it takes car of this exception. Thank you. Though I now believe the fact that exception are not handled in callback.c is a big issue in itself. "It is extremely important to check, handle, and clear a pending exception before calling any subsequent JNI functions. Calling most JNI functions with a pending exception--with an exception that you have not explicitly cleared--may lead to unexpected results" from http://java.sun.com/docs/books/jni/html/exceptions.html . The understanding I have is that callback.c in swt is a bit peculiar. Because it is java that calls native that calls java . the middle steps if not handling exception coming from the first java step "deadlock" calling the third step (java code). Instead of "forwarding the exception from the first step to the third one (as the native code does not and is not supposed to handle java exception from eclipse). >Tried and it takes car of this exception. >Thank you. Does it take care of the crash as well? >Though I now believe the fact that exception are not handled in callback.c is >a big issue in itself. callback.c cannot handle exceptions. Exceptions have to be handled/avoided in java code either before it returns to native code or after it returns from native code to java code. The patch I attached does the former. If callback.c handled exceptions it would be hiding problems from the user/developer. (In reply to comment #38) > Does it take care of the crash as well? Yes. The crash was due to eclipse swt throwing an exception and handling it to callback.c which send it to pango which was well not handling it (as not supposed to). Thus any calls from jni was stuck by the exception pending (that is the pango call to the java constructor swt assign it to). Thus pango was failing to construct its instance of pango_layout_new and crashed lateer on dereferencing it. With the exception gone his issue is gone too. > >Though I now believe the fact that exception are not handled in callback.c is > >a big issue in itself. > > callback.c cannot handle exceptions. Exceptions have to be handled/avoided in > java code either before it returns to native code or after it returns from > native code to java code. The patch I attached does the former. > > If callback.c handled exceptions it would be hiding problems from the > user/developer. I was not implying it should handle it per se but tell the jvm it handle it (to let the jvm proceed when called from the jni here pango). And rethrow it to eclipse for it to warn user/developper. Currently whatever use swt callback as a mean to assign a native library constructor will end up with the same issue as pango_layout_new trying to call its java constructor when it is stuck by an exception thrownn by the application to the jni (application java/jni native/java constructor). Do not know if I was confusingg or plain wrong beforehand. (In reply to comment #39) > (In reply to comment #38) > > Does it take care of the crash as well? > > Yes. The crash was due to eclipse swt throwing an exception and handling it to > callback.c which send it to pango which was well not handling it (as not > supposed to). Thus any calls from jni was stuck by the exception pending (that > is the pango call to the java constructor swt assign it to). Thus pango was > failing to construct its instance of pango_layout_new and crashed lateer on > dereferencing it. > With the exception gone his issue is gone too. > In which version the patch will be applied? I'd like to test too but I can not rebuild eclipse. Thanks. I released the patch today. You could try tonight's N-build or next week's I-build. I do not think there is any reasonable change we can make in callback.c. We could remove the code I mentioned in comment#35, but this will most certainly let more C code run with a pending exception. Fixed > 20091202. (In reply to comment #41) > I released the patch today. You could try tonight's N-build or next week's > I-build. > The patch will be included in eclipse 3.5.2 or only in eclipse 3.6? This is a good candidate fo 3.5.2, but it needs more testing before I can release to that branch. @ Silenio and Alban: Could you please have a look at Bug 229071? Seems to be a problem just like this one (only if Assistiv Technologies are enabled), but the crash is in libgail.so. Perhaps it is just as easy to fix like this one. Thank you. (In reply to comment #43) > This is a good candidate fo 3.5.2, but it needs more testing before I can > release to that branch. I've been using N20091202-2000 for a couple days with accessibility turned on and haven't seen this bug. Thanks for the fix - it would be nice to see this in 3.5.2. Ben (In reply to comment #43) > This is a good candidate fo 3.5.2, but it needs more testing before I can > release to that branch. Actually I am running eclipse 3.6 M4 and the problem has gone. Thanks. We have been bitten by this in our RCP application build for Ubuntu Karmic Koala that is built on 3.5.x. Of course we would like to do a new build for our users that doesn't crash when they close a dialog window. What do we do? We cannot use Eclipse 3.6 M4 because it breaks other things (another story) and yet we cannot wait for a "maybe" on this being in 3.5.2. (In reply to comment #47) > We have been bitten by this in our RCP application build for Ubuntu Karmic > Koala that is built on 3.5.x. Of course we would like to do a new build for our > users that doesn't crash when they close a dialog window. What do we do? We > cannot use Eclipse 3.6 M4 because it breaks other things (another story) and > yet we cannot wait for a "maybe" on this being in 3.5.2. If you are using eclipse packaged in karmic, take a look at: https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/445009 I suspect that you will find the solution. (In reply to comment #48) > (In reply to comment #47) > > We have been bitten by this in our RCP application build for Ubuntu Karmic > > Koala that is built on 3.5.x. Of course we would like to do a new build for our > > users that doesn't crash when they close a dialog window. What do we do? We > > cannot use Eclipse 3.6 M4 because it breaks other things (another story) and > > yet we cannot wait for a "maybe" on this being in 3.5.2. > > If you are using eclipse packaged in karmic, take a look at: > https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/445009 > > I suspect that you will find the solution. No, we are producing Rich Client Platform applications built on Eclipse (like RSSOwl or XMind). This is different to the Eclipse packaged in Karmic. Created attachment 156135 [details]
patch for 3.5.2
This patch is going to be released into 3.5.2.
Patch has been released to R3_5_maintenance. It will go in the release candidate 2 build next week. *** Bug 300637 has been marked as a duplicate of this bug. *** *** Bug 299732 has been marked as a duplicate of this bug. *** |