From owner-freebsd-ports@FreeBSD.ORG Fri Nov 26 09:37:13 2004 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD6CF16A4CE; Fri, 26 Nov 2004 09:37:13 +0000 (GMT) Received: from asterix.rsu.ru (relay.r61.net [195.208.245.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6664E43D2D; Fri, 26 Nov 2004 09:37:12 +0000 (GMT) (envelope-from os@rsu.ru) Received: from brain (brain.cc.rsu.ru [195.208.252.154]) (authenticated bits=0) by asterix.rsu.ru (8.13.1/8.13.1) with ESMTP id iAQ9aTFN032426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Nov 2004 12:36:29 +0300 (MSK) (envelope-from os@rsu.ru) Date: Fri, 26 Nov 2004 12:36:29 +0300 (MSK) From: Oleg Sharoiko To: Craig Boston In-Reply-To: <200411252051.10049.craig@yekse.gank.org> Message-ID: <20041126122138.R67068@brain.cc.rsu.ru> References: <1101414027.84333.43.camel@localhost> <200411252051.10049.craig@yekse.gank.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.80/577/Mon Nov 8 02:32:14 2004 clamav-milter version 0.80j on asterix.rsu.ru X-Virus-Status: Clean X-Spam-Status: No, score=-5.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on asterix.rsu.ru cc: gnome@freebsd.org cc: ports@freebsd.org cc: nlsn@free.fr cc: freebsd-ports@freebsd.org Subject: Re: ports/72014: Eclipse doesn't work (SigBus 10) if it has been built with GTK X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Nov 2004 09:37:14 -0000 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.