Bugzilla – Full Text Bug Listing
| Summary: | [Widgets] segfault in pango_layout_new when closing a dialog | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Martin Oberhuber <mober.at+eclipse> | ||||||||||
| Component: | SWT | Assignee: | Silenio Quarti <Silenio_Quarti> | ||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||
| Severity: | normal | ||||||||||||
| Priority: | P3 | CC: | Alexis.Muller, bhunt, eclipse.felipe, eclipseBugs, gheorghe, ivanceras, ivyho, jacek.pospychala, jtk499, kane.mx, kane.zhu, lshanmug, medelin, mik01aj, overholt, pinnamur, pwebster, remy.suen, rgunther, rock, shaidar.haran, Silenio_Quarti, thatnitind | ||||||||||
| Version: | 3.5.2 | Flags: | eclipse.felipe:
review+
|
||||||||||
| Target Milestone: | 3.6.1 | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | |||||||||||||
| Bug Depends on: | 285749 | ||||||||||||
| Bug Blocks: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Martin Oberhuber
Created attachment 176231 [details]
hs_err_pid490.log from RHEL5.5 machine
Created attachment 176232 [details]
hs_err_pid15475.log from RHEL4
Here is a different crash log from a different machine (Eclipse Helios, again). This time it crashed in
# C [libglib-2.0.so.0+0x12a92] g_datalist_id_get_data+0x2c
[...] [libpango-1.0.so.0+0x16d57] pango_layout_new+0x30
[...] [libgtk-x11-2.0.so.0+0x194b03] gtk_text_layout_get_line_display+0xac1
[...] [libgobject-2.0.so.0+0x9347] g_closure_invoke+0xf6
J org.eclipse.swt.internal.gtk.OS._gtk_main_do_event(I)V
J org.eclipse.swt.widgets.Display.eventProc(II)I
v ~I2CAdapter
Java: Sun 1.5.0_11
OS: Red Hat Enterprise Linux WS release 4 (Nahant Update 8)
GTK: gtk2-2.4.13-24.el4 / gtk+-1.2.10-36
Pango: pango-1.6.0-14.4_7
Also see bug 291128 but that should've been fixed. Created attachment 176233 [details]
Screenshot of Dialog
CQ:WIND00227312
Here is a screenshot of the dialog which crashes Eclipse when I close it while an operation is ongoing that's supposed to fill the progress bar at the bottom.
(In reply to comment #3) > Also see bug 291128 but that should've been fixed. Yes, I checked bug 291128 and cannot get Eclipse to crash in the "Install New Software" dialog, so that seems to be fixed. This issue seems to be somehow related to the way background tasks / progress reporting are done in this dialog. When the dialog is in a slightly different state, trying to "close" opens a subdialog "The application does not respond ... cancel or force quit". But with a given set of steps, the issue is 100% reproducable on all GTK versions I tried (RHEL4, RHEL5 as well as Solaris 10 GTK). *** Bug 285749 has been marked as a duplicate of this bug. *** Martin, do you have a set of steps that can reproduce the issue? *** Bug 319609 has been marked as a duplicate of this bug. *** I started to gather all crashes in pango_layout_new and close them as duplicate of bug 322222 (Bug 319609 and Bug 321929 are also crashes in pango_layout_new) But I changed my mind in the process, the code in the reports are raising a exception during the execution of the event handler, and return from it without handling the exception. These are bugs, and they all need to be fixed one by one. That said, SWT should not crash. Silenio, to solve this problem, can we created two classes of callback ? for example user callbacks and system callbacks. When there is an expection pending in the VM we do not call user callbacks but we still call system callbacks ? I think this way we avoid the crash in pango_layout_new, but I'm afraid this will be a big change in your callback code. (In reply to comment #7) > Martin, do you have a set of steps that can reproduce the issue? I do, in our commercial IDE, and if you'd like to buy a WR ICE2 Hardware :) But not in plain open source at this time, unfortunately. (In reply to comment #9) > But I changed my mind in the process, the code in the reports are raising a > exception during the execution of the event handler, and return from it without > handling the exception. Are you saying that potentially our Java code throws an exception, but since that Java code is called from the Event Handler the exception leads to a SEGV rather than being handled by Java? If that's true then I could probably debug the App with a Java Exception Breakpoint set on Throwable, to see where the exception is thrown and why. Or do you have any other suggestion how I could find out what's going wrong? (In reply to comment #11) > (In reply to comment #9) > Are you saying that potentially our Java code throws an exception, but since > that Java code is called from the Event Handler the exception leads to a SEGV > rather than being handled by Java? That is correct. > If that's true then I could probably debug the App with a Java Exception > Breakpoint set on Throwable, to see where the exception is thrown and why. Exactly, and that is what you should do. Note: even if I fix the SEGV the real exception will still cause a walkback (if not handled) somewhere else. So... in my case, debugged on Eclipse 3.5.2-GTK, the culprit was a NullPointerException here:
Thread [main] (Suspended (exception NullPointerException))
WRSFTP.isConnected() line: 196
[...]
Window$3.shellClosed(ShellEvent) line: 687
TypedListener.handleEvent(Event) line: 92
EventTable.sendEvent(Event) line: 84
Shell(Widget).sendEvent(Event) line: 1176
Shell(Widget).sendEvent(int, Event, boolean) line: 1200
Shell(Widget).sendEvent(int, Event) line: 1185
Shell.closeWidget() line: 612
Shell.gtk_delete_event(int, int) line: 1087
Shell(Widget).windowProc(int, int, int) line: 1562
Shell(Control).windowProc(int, int, int) line: 4594
Display.windowProc(int, int, int) line: 4191
OS._gtk_main_do_event(int) line: not available [native method]
OS.gtk_main_do_event(int) line: 7603
Display.eventProc(int, int) line: 1185
[...]
Followed by another NullPointerException here:
Thread [main] (Suspended (exception NullPointerException))
EventTable.sendEvent(Event) line: 104
Shell(Widget).sendEvent(Event) line: 1176
Shell(Widget).sendEvent(int, Event, boolean) line: 1200
Shell(Widget).sendEvent(int, Event) line: 1185
Shell.closeWidget() line: 612
Shell.gtk_delete_event(int, int) line: 1087
Shell(Widget).windowProc(int, int, int) line: 1562
Shell(Control).windowProc(int, int, int) line: 4594
Display.windowProc(int, int, int) line: 4191
OS._gtk_main_do_event(int) line: not available [native method]
OS.gtk_main_do_event(int) line: 7603
Display.eventProc(int, int) line: 1185
[...]
FWIW, after a bit of experimentation, I was succesful finding this with a Java Exception Breakpoint on class "Exception" with "also break on subclasses enabled", and using a "Filter" to restrict to the "main" Thread only. This special type of Java Exception Breakpoint can only be created by editing breakpoint properties after creating the breakpoint. Without the Filter, you'd see exceptions thrown all the time.
I'm posting these stack's in the hope that it's helpful for SWT developers to see whether this case could have been caught by an exception handler inside SWT (similar to the general exception handler which sometimes logs "Uncaught Event Loop Exception" to the errorlog.
Created attachment 176585 [details]
fix
With this patch the application will not segment fault when pango_layout_new() is called while there is a pending exception in callin.
Felipe, please review for 3.6.1 *** Bug 316527 has been marked as a duplicate of this bug. *** *** Bug 321929 has been marked as a duplicate of this bug. *** Fixed in HEAD (> 20100813) *** Bug 320590 has been marked as a duplicate of this bug. *** *** Bug 303389 has been marked as a duplicate of this bug. *** *** Bug 318623 has been marked as a duplicate of this bug. *** *** Bug 261627 has been marked as a duplicate of this bug. *** *** Bug 283024 has been marked as a duplicate of this bug. *** Awesome! I tested this fix for Bug 321929, which was marked as a duplicate of this bug. Bug 321929 exists in N20100812-2000; SWT now works as expected in N20100813-2000. This fix will be very helpful. Fix released to R3_6_maintenance. Note that (for the bugs that were marked as duplicate) there may be still some uncaught exception somewhere that needs to be fixed. The difference is that now the exception should be logged instead of crashing the VM. *** Bug 323107 has been marked as a duplicate of this bug. *** *** Bug 325238 has been marked as a duplicate of this bug. *** we had a user who got RAD to crash consistently by using the wsdl editor. GNOME 2.28.2 OS: SUSE Linux Enterprise Desktop 11 (x86_64) RAD: Version: 8.0.4.2 eclipse 3.6.2 0SECTION GPINFO subcomponent dump routine NULL ================================ 2XHOSLEVEL OS Level : Linux 2.6.27.19-5-default 2XHCPUS Processors - 3XHCPUARCH Architecture : x86 3XHNUMCPUS How Many : 4 3XHNUMASUP NUMA is either not supported or has been disabled by user NULL 1XHEXCPCODE J9Generic_Signal_Number: 00000004 1XHEXCPCODE Signal_Number: 0000000B 1XHEXCPCODE Error_Value: 00000000 1XHEXCPCODE Signal_Code: 00000001 1XHEXCPCODE Handler1: F7CE043B 1XHEXCPCODE Handler2: F7D835D1 1XHEXCPCODE InaccessibleAddress: 0000000C NULL 1XHEXCPMODULE Module: /usr/lib/libpango-1.0.so.0 1XHEXCPMODULE Module_base_address: B1C18000 1XHEXCPMODULE Symbol: pango_layout_new 1XHEXCPMODULE Symbol_address: B1C3B440 1XMCURTHDINFO Current thread NULL ---------------------- 3XMTHREADINFO "Thread-4" J9VMThread:0x08321A00, j9thread_t:0x082ED8A4, java/lang/Thread:0xB6DB40D8, state:R, prio=5 3XMTHREADINFO1 (native thread ID:0x7F7A, native priority:0x5, native policy:UNKNOWN) 3XMTHREADINFO2 (native stack address range from:0xB217E000, to:0xB21BF000, size:0x41000) 3XMTHREADINFO3 Java callstack: 4XESTACKTRACE at org/eclipse/equinox/launcher/JNIBridge._takedown_splash(Native Method) 4XESTACKTRACE at org/eclipse/equinox/launcher/JNIBridge.takeDownSplash(Bytecode PC:1) 4XESTACKTRACE at org/eclipse/equinox/launcher/Main.takeDownSplash(Bytecode PC:20) 4XESTACKTRACE at org/eclipse/equinox/launcher/Main$SplashHandler.run(Bytecode PC:4) 3XMTHREADINFO3 Native callstack: 4XENATIVESTACK (0xF7D77652 [libj9prt24.so+0x0]) 4XENATIVESTACK (0xF7D82C1C [libj9prt24.so+0x0]) 4XENATIVESTACK (0xF7D776DF [libj9prt24.so+0x0]) 4XENATIVESTACK (0xF7D777FD [libj9prt24.so+0x0]) 4XENATIVESTACK (0xF7D77484 [libj9prt24.so+0x0]) 4XENATIVESTACK (0xF7D82C1C [libj9prt24.so+0x0]) 4XENATIVESTACK (0xF7D774F8 [libj9prt24.so+0x0]) 4XENATIVESTACK (0xF7D73E9A [libj9prt24.so+0x0]) 4XENATIVESTACK (0xF7D7426B [libj9prt24.so+0x0]) 4XENATIVESTACK (0xF73173B9 [libj9dmp24.so+0x0]) 4XENATIVESTACK (0xF7D82C1C [libj9prt24.so+0x0]) 4XENATIVESTACK (0xF7313859 [libj9dmp24.so+0x0]) 4XENATIVESTACK (0xF73172D1 [libj9dmp24.so+0x0]) 4XENATIVESTACK (0xF7D82C1C [libj9prt24.so+0x0]) 4XENATIVESTACK (0xF7311908 [libj9dmp24.so+0x0]) 4XENATIVESTACK (0xF73174C5 [libj9dmp24.so+0x0]) 4XENATIVESTACK (0xF7307C2A [libj9dmp24.so+0x0]) 4XENATIVESTACK (0xF730AF74 [libj9dmp24.so+0x0]) 4XENATIVESTACK (0xF7D82C1C [libj9prt24.so+0x0]) 4XENATIVESTACK (0xF730AF3A [libj9dmp24.so+0x0]) 4XENATIVESTACK (0xF730AC2B [libj9dmp24.so+0x0]) 4XENATIVESTACK (0xF731875C [libj9dmp24.so+0x0]) 4XENATIVESTACK (0xF7CE0E16 [libj9vm24.so+0x0]) 4XENATIVESTACK (0xF7D82C1C [libj9prt24.so+0x0]) 4XENATIVESTACK (0xF7CE05DB [libj9vm24.so+0x0]) 4XENATIVESTACK (0xF7D83749 [libj9prt24.so+0x0]) 4XENATIVESTACK (0xFFFFE410) 4XENATIVESTACK gtk_widget_create_pango_layout+0x78 not sure if this is same issue. Thanks |