ports/72014: Eclipse doesn't work (SigBus 10) if it has been built with GTK

[Oleg Sharoiko]

On Thu, 25 Nov 2004, Craig Boston wrote:

CB>Would it be possible for someone who can reproduce this problem to run the 
CB>process under gdb and use the disassemble command to get the machine code at 
CB>the location of the crash?  You don't need debug symbols for this to work, so 
CB>it doesn't involve recompiling with -g or anything.

It's a problem for me, because eclipse is a java application and it has it's 
own SIGBUS handler and gdb says "programm exited normally".

jdk creates it's own stack trace, here is head of it:

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 10 occurred at PC=0x34DF767A
Function=_gtk_tree_view_queue_draw_node+0x17E8
Library=/usr/X11R6/lib/libgtk-x11-2.0.so.400

Current Java thread:
        at org.eclipse.swt.internal.gtk.OS.gtk_container_add(Native Method)
        - locked <0x308260c8> (a java.lang.Class)
        at org.eclipse.swt.widgets.Table.createHandle(Table.java:417)
        at org.eclipse.swt.widgets.Widget.createWidget(Widget.java:321)
        at org.eclipse.swt.widgets.Control.createWidget(Control.java:306)


Would it be possible for me to get disassebled instructions using following 
information:

Function=_gtk_tree_view_queue_draw_node+0x17E8
Library=/usr/X11R6/lib/libgtk-x11-2.0.so.400

Unfortunately I'm not gdb expert :(

jdk also create java.core, but I suppose it is of no use. Here is bt from that 
core:

(gdb) bt
#0  0x280a2f97 in pthread_testcancel () from /usr/lib/libpthread.so.1
#1  0x28093a93 in sigaction () from /usr/lib/libpthread.so.1
#2  0x2808d495 in pthread_kill () from /usr/lib/libpthread.so.1
#3  0x2808cdd7 in raise () from /usr/lib/libpthread.so.1
#4  0x28168db2 in abort () from /lib/libc.so.5
#5  0x28488716 in os::abort ()
   from /usr/local/jdk1.4.2/jre/lib/i386/client/libjvm.so
#6  0x28486d65 in os::handle_unexpected_exception ()
   from /usr/local/jdk1.4.2/jre/lib/i386/client/libjvm.so
#7  0x2848b518 in JVM_handle_bsd_signal ()
   from /usr/local/jdk1.4.2/jre/lib/i386/client/libjvm.so
#8  0x2848a599 in signalHandler ()
   from /usr/local/jdk1.4.2/jre/lib/i386/client/libjvm.so
#9  0x2809241e in sigaction () from /usr/lib/libpthread.so.1
#10 0x280922a1 in sigaction () from /usr/lib/libpthread.so.1
#11 0x28092f10 in sigaction () from /usr/lib/libpthread.so.1
#12 0x2809b925 in pthread_mutexattr_init () from /usr/lib/libpthread.so.1
#13 0x2809b7f4 in pthread_mutexattr_init () from /usr/lib/libpthread.so.1
#14 0x28152cdb in _ctx_start () from /lib/libc.so.5
[ almost 700 more entries skipped ]

I'm ready to help with debugging this case, but I need some who will tell what 
to do.

-- 
Oleg Sharoiko.
Software and Network Engineer
Computer Center of Rostov State University.