Description Marti DeMore 2010-09-03 16:07:43 EDT

Build Identifier: Eclipse 3.5/ SWT 3.14

We have a large, complex SWT (not Eclipse) application which crashes randomly under RedHat Linux 5 after many hours of operation, whether the user is interacting with it or not, and whether it is idle or not.  The crash appears to be a memory deallocation or corruption problem that shows up in the libgobject library in either the  g_type_check_instance_is_a() function or the g_object_remove_weak_pointer() function. All of the hotspot logs look virtually alike. We are rebuilding our X libraries with debug to try to get more symbol information, but here is is a snippet typical hotspot log (I will attach others):


#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  SIGSEGV (0xb) at pc=0x034ad159, pid=23430, tid=3086433152
#
# Java VM: Java HotSpot(TM) Server VM (1.5.0_22-b03 mixed mode)
# Problematic frame:
# C  [libgobject-2.0.so.0+0x23159]  g_type_check_instance_is_a+0x49
#

---------------  T H R E A D  ---------------

Current thread (0x08a20470):  JavaThread "main" [_thread_in_native, id=23430]

siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x4630417f

Registers:
EAX=0x46304178, EBX=0x034c8674, ECX=0x676e19b0, EDX=0x00000014
ESP=0xbfd567f8, EBP=0xbfd56820, ESI=0x46304178, EDI=0x0941a434
EIP=0x034ad159, CR2=0x4630417f, EFLAGS=0x00010206

Top of Stack: (sp=0xbfd567f8)
0xbfd567f8:   0000001a 00000010 00000001 00000020
0xbfd56808:   0000002a 08d2b408 00000008 034c8674
0xbfd56818:   5d508798 5d70d7e0 bfd56840 0349582f
0xbfd56828:   5d508798 00000050 bfd56840 035bdb74
0xbfd56838:   5d70d7e0 5d70d7e0 bfd56860 03575a1b
0xbfd56848:   5d508798 5d70d7e0 bfd56870 035bdb74
0xbfd56858:   035bdb74 094d6260 bfd56890 03575baf
0xbfd56868:   bfd56920 689c1b80 bfd56890 03494f63 

Instructions: (pc=0x034ad159)
0x034ad149:   fa fc 03 00 00 76 54 89 d7 83 e7 fc 85 f6 74 28
0x034ad159:   0f b6 46 07 83 e0 40 88 45 ef 74 1c 85 ff 74 18 

Stack: [0xbfb5c000,0xbfd5c000),  sp=0xbfd567f8,  free space=2025k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libgobject-2.0.so.0+0x23159]  g_type_check_instance_is_a+0x49
C  [libgobject-2.0.so.0+0xb82f]  g_object_remove_weak_pointer+0x3f
C  [libgdk-x11-2.0.so.0+0x43a1b]
C  [libgdk-x11-2.0.so.0+0x43baf]
C  [libgdk-x11-2.0.so.0+0x40732]
C  [libgdk-x11-2.0.so.0+0x40e4b]
C  [libgdk-x11-2.0.so.0+0x4124f]
C  [libglib-2.0.so.0+0x2b372]  g_main_context_dispatch+0x182
C  [libglib-2.0.so.0+0x2e366]
C  [libglib-2.0.so.0+0x2e8be]  g_main_context_iteration+0x6e
C  [libswt-pi-gtk-3448.so+0x32827]  Java_org_eclipse_swt_internal_gtk_OS__1g_1main_1context_1iteration+0x20
J  org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(IZ)Z

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J  org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(IZ)Z
J  org.eclipse.swt.widgets.Display.readAndDispatch()Z
J  jpl.gds.core.monitor.app.MonitorApp.showGUI()Z
v  ~OSRAdapter
j  jpl.gds.core.monitor.app.MonitorApp.mainNoKill([Ljava/lang/String;)Z+107
j  jpl.gds.core.monitor.app.MonitorApp.main([Ljava/lang/String;)V+1
v  ~StubRoutines::call_stub


Reproducible: Sometimes

Steps to Reproduce:
We have been unable to reproduce this problem in any simple configuration. To even see it, we must run multiple copies of our client, which is huge, with a spacecraft telemetry system which is even huger, and wait for the random error to occur. If we get a reproducable case, we will update this issue.