Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 356201

Summary:

Crash in libgobject-2.0.so.0 g_object_unref

Product:

[Eclipse Project] Platform

Reporter:

Troy Bishop <tjbishop>

Component:

SWT

Assignee:

Platform-SWT-Inbox <platform-swt-inbox>

Status:

CLOSED WORKSFORME

QA Contact:

Severity:

normal

Priority:

CC:

arunkumar.thondapu, eclipse.felipe, ericwill, f.rotondella, melickm, remy.suen, Silenio_Quarti, sptaszkiewicz

Version:

3.6.2

Target Milestone:

---

Hardware:

OS:

Linux

Whiteboard:

Attachments:

Description	Flags
javacore of the crash	none
Another javacore of a similar crash	none
log of crash	none

Description Troy Bishop

2011-08-30 09:57:02 EDT

Build Identifier: Eclipse 3.6.2

Within a product that consumes Eclipse 3.6.2 we provide the ability for our
clients to submit any crashes that occur back to us.  One such crash is the
following (using the IBM JVM):

0SECTION       TITLE subcomponent dump routine
NULL           ===============================
1TISIGINFO     Dump Event "gpf" (00002000) received 
...
1XHEXCPMODULE  Module: /lib/libgobject-2.0.so.0
1XHEXCPMODULE  Module_base_address: 00655000
1XHEXCPMODULE  Symbol: g_object_unref
1XHEXCPMODULE  Symbol_address: 00660080
...
3XMTHREADINFO3           Java callstack:
4XESTACKTRACE                at org/eclipse/swt/internal/gtk/OS._gtk_widget_size_request(Native Method)
4XESTACKTRACE                at org/eclipse/swt/internal/gtk/OS.gtk_widget_size_request(Bytecode PC:9(Compiled Code))
4XESTACKTRACE                at org/eclipse/swt/widgets/Control.gtk_widget_size_request(Bytecode PC:2(Compiled Code))
4XESTACKTRACE                at org/eclipse/swt/widgets/Control.setBounds(Bytecode PC:396(Compiled Code))
4XESTACKTRACE                at org/eclipse/swt/widgets/Label.setBounds(Bytecode PC:53(Compiled Code))
4XESTACKTRACE                at org/eclipse/swt/widgets/Control.setBounds(Bytecode PC:20(Compiled Code))
4XESTACKTRACE                at org/eclipse/swt/layout/FillLayout.layout(Bytecode PC:20(Compiled Code))
...

Below is some environment information that we also capture:

<virtualMachine info="JRE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260sr9-20110324_78506 (JIT enabled, AOT enabled)&#x0A;J9VM - 20110324_078506&#x0A;JIT  - r9_20101028_17488ifx3&#x0A;GC   - 20101027_AA" javaVersion="1.6.0" name="IBM J9 VM" provider="IBM Corporation" uptime="386.824" version="2.4">

<operatingSystem arch="x86" cpus="1" name="Linux" version="2.6.18-238.12.1.el5"/>

<bundle id="org.eclipse.swt" location="reference:file:../SDPShared/plugins/org.eclipse.swt_3.6.3.v3659d.jar" state="resolved" version="3.6.3.v3659d"/>

<bundle id="org.eclipse.swt.gtk.linux.x86" location="reference:file:../SDPShared/plugins/org.eclipse.swt.gtk.linux.x86_3.6.3.v3659d.jar" state="resolved" version="3.6.3.v3659d"/>

Reproducible: Didn't try

Comment 1 Troy Bishop

2011-08-30 09:57:38 EDT

Created attachment 202421 [details]
javacore of the crash

Here's the javacore for the crash.

Comment 2 Szymon Ptaszkiewicz

2013-01-23 10:58:31 EST

Created attachment 225988 [details]
Another javacore of a similar crash

Here is another javacore of a similar crash. It happened also in a product based on Eclipse 3.6.2.

Comment 3 Silenio Quarti

2013-01-30 10:14:14 EST

Szymon, your stack is unrelated with the original stack of this bug.

Note that there is not much we can do without a way to reproduce the crash.

Comment 4 Szymon Ptaszkiewicz

2013-01-30 10:29:52 EST

(In reply to comment #3)
> Szymon, your stack is unrelated with the original stack of this bug.
> 
> Note that there is not much we can do without a way to reproduce the crash.

Thanks, Silenio. Unfortunately, I don't have reproducible steps. I will mark my attachment as obsolete to avoid confusion later on. 

BTW, how can I tell in the future that two javacores are not related even if they look so similar? I guess different stacks for UI thread are not always enough for that, right?

Comment 5 Silenio Quarti

2013-01-30 10:47:12 EST

(In reply to comment #4)
> BTW, how can I tell in the future that two javacores are not related even if
> they look so similar? I guess different stacks for UI thread are not always
> enough for that, right?

If you look at the native stacks of both files, you will see that the top of the stacks do not look alike. One crash is in g_object_unref and the other is in gdk_event_free(). 


Original stack:

4XENATIVESTACK               (0x00783440)
4XENATIVESTACK               (0x0081CBEC [libpango-1.0.so.0+0x18bec])
4XENATIVESTACK               g_object_unref+0x16e (0x006601EE [libgobject-2.0.so.0+0xb1ee])
4XENATIVESTACK               (0x0708E2F8 [libgtk-x11-2.0.so.0+0x1162f8])
4XENATIVESTACK               (0x07094827 [libgtk-x11-2.0.so.0+0x11c827])
4XENATIVESTACK               g_cclosure_marshal_VOID__BOXED+0x59 (0x0066A7D9 [libgobject-2.0.so.0+0x157d9])
4XENATIVESTACK               (0x0065C639 [libgobject-2.0.so.0+0x7639])
4XENATIVESTACK               g_closure_invoke+0x211 (0x0065DF81 [libgobject-2.0.so.0+0x8f81])
4XENATIVESTACK               (0x0066F242 [libgobject-2.0.so.0+0x1a242])
4XENATIVESTACK               g_signal_emit_valist+0x8c7 (0x006702E7 [libgobject-2.0.so.0+0x1b2e7])
4XENATIVESTACK               g_signal_emit_by_name+0xee (0x00671D4E [libgobject-2.0.so.0+0x1cd4e])
4XENATIVESTACK               (0x0710C9C6 [libgtk-x11-2.0.so.0+0x1949c6])
4XENATIVESTACK               (0x0710CC17 [libgtk-x11-2.0.so.0+0x194c17])
4XENATIVESTACK               gtk_widget_size_request+0x4c (0x071C1BDC [libgtk-x11-2.0.so.0+0x249bdc])
4XENATIVESTACK               (0x070665E0 [libgtk-x11-2.0.so.0+0xee5e0])
4XENATIVESTACK               g_cclosure_marshal_VOID__BOXED+0x59 (0x0066A7D9 [libgobject-2.0.so.0+0x157d9])
4XENATIVESTACK               (0x0065C639 [libgobject-2.0.so.0+0x7639])
4XENATIVESTACK               g_closure_invoke+0x211 (0x0065DF81 [libgobject-2.0.so.0+0x8f81])
4XENATIVESTACK               (0x0066F242 [libgobject-2.0.so.0+0x1a242])
4XENATIVESTACK               g_signal_emit_valist+0x8c7 (0x006702E7 [libgobject-2.0.so.0+0x1b2e7])
4XENATIVESTACK               g_signal_emit_by_name+0xee (0x00671D4E [libgobject-2.0.so.0+0x1cd4e])
4XENATIVESTACK               (0x0710C9C6 [libgtk-x11-2.0.so.0+0x1949c6])
4XENATIVESTACK               (0x0710CC17 [libgtk-x11-2.0.so.0+0x194c17])
4XENATIVESTACK               gtk_widget_size_request+0x4c (0x071C1BDC [libgtk-x11-2.0.so.0+0x249bdc])


Second stack:

4XENATIVESTACK               gdk_event_free+0xab (0x7164994B [libgdk-x11-2.0.so.0+0x1b94b])
4XENATIVESTACK               (0x716776E2 [libgdk-x11-2.0.so.0+0x496e2])
4XENATIVESTACK               g_main_context_dispatch+0x1e8 (0x71732A28 [libglib-2.0.so.0+0x39a28])
4XENATIVESTACK               (0x717360E3 [libglib-2.0.so.0+0x3d0e3])
4XENATIVESTACK               g_main_context_iteration+0x71 (0x717362A1 [libglib-2.0.so.0+0x3d2a1])
4XENATIVESTACK               Java_org_eclipse_swt_internal_gtk_OS__1g_1main_1context_1iteration+0x20 (0x70912A6D [libswt-pi-gtk-3659.so+0x36a6d])
4XENATIVESTACK               (0x70205A21 [<unknown>+0x0])
4XENATIVESTACK               (0xB5FFBC92 [libjclse7b_26.so+0x60c92])
4XENATIVESTACK               Java_sun_reflect_NativeMethodAccessorImpl_invoke0+0x32 (0xB5FED77A [libjclse7b_26.so+0x5277a])

Comment 6 Szymon Ptaszkiewicz

2013-01-30 11:07:50 EST

Makes sense. I thought that "GPINFO subcomponent dump routine" gives more accurate data than stacks but it seems it is not true. In fact it points to completely different library other than the one on top of the stack. Weird.

Comment 7 Francesco Rotondella

2013-10-22 07:03:50 EDT

Created attachment 236756 [details]
log of crash

Comment 8 Francesco Rotondella

2013-10-22 07:05:10 EDT

I attached the log of crash.
I open a file with eclipse.
Then I replace globally in the file a string.
Then I close the find/replace window through the button "cancel" and eclipse crashes.
This happens after a distro upgrade of Kubuntu 13.04

Comment 9 Silenio Quarti

2013-10-22 13:29:49 EDT

(In reply to Francesco Rotondella from comment #8)
> I attached the log of crash.
> I open a file with eclipse.
> Then I replace globally in the file a string.
> Then I close the find/replace window through the button "cancel" and eclipse
> crashes.
> This happens after a distro upgrade of Kubuntu 13.04

Which version of Eclipse are you running?

If not running it already, please try the latest (Eclipse 4.3) and let us know whether it still happens.

Comment 10 Francesco Rotondella

2013-10-23 05:04:15 EDT

ok. I installed the new Eclipse version and it seems to work now. Or at lest I checked that eclipse doesn't crash anymore with the sequence I described (usage of find/replace box); the crash was fully reproducible.
Now I'm running the 4.3.1 version.

Comment 11 Francesco Rotondella

2013-10-25 11:37:22 EDT

It seems the crash has moved. Now the involved library is libgtk

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xb66e3a43, pid=10886, tid=3075663552
#
# JRE version: 7.0_07-b10
# Java VM: Java HotSpot(TM) Client VM (23.3-b01 mixed mode linux-x86 )
# Problematic frame:
# C  [libgtk-x11-2.0.so.0+0x262a43]  gtk_widget_queue_draw+0x23
#

but now it's not exactly reproducible: it's randomic

Comment 12 Eric Williams

2016-12-20 11:54:14 EST

I can't reproduce either of these crashes. If the issue pops up again, please file a new bug with updated OS + GTK info.