Date: Sun, 10 Jun 2012 10:47:43 +0200 From: Matthias Apitz <guru@unixarea.de> To: Max Brazhnikov <makc@freebsd.org> Cc: freebsd-ports@freebsd.org Subject: Re: ports/textproc/stardict3 Message-ID: <20120610084743.GA2999@tinyCurrent> In-Reply-To: <201111221737.04353.makc@freebsd.org> References: <20111118125403.GA1255@tiny> <201111221737.04353.makc@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
El día Tuesday, November 22, 2011 a las 05:37:03PM +0000, Max Brazhnikov escribió: > On Fri, 18 Nov 2011 13:54:04 +0100, Matthias Apitz wrote: > > Hello, > > > > The port (ports tree from CVS) ports/textproc/stardict3 > > > > ports/textproc/stardict3 > > PORTVERSION= 3.0.3 > > MAINTAINER= makc@FreeBSD.org > > > > installs fine on 10-CURRENT, but the application just crahes or runs > > into a CPU loop; if it runs into CPU loop there is a core file of 'troff', > > i.e. it seems that it started for some man page reason the troff(1) and > > after this it loops; > Stardict has plugin for displaying man pages. > > > ... > > I could go back to 3.0.3 and provide more details of the crash, but I > > can't debug or solve this on my own. Or should I file a bug report? > > backtrace would be nice to have. Hi Max, I've installed another fresh 10-CURRENT (r235646, ports from CVS as of May 19) and luckily it crashes again reproduceable; a bt of gdb looks like this: $ gdb /usr/local/bin/stardict stardict.core ... #0 0x2966868b in thr_kill () from /lib/libc.so.7 [New Thread 29c07e00 (LWP 100375/stardict)] [New Thread 29c03300 (LWP 100369/stardict)] [New Thread 29c03080 (LWP 100203/stardict)] (gdb) bt #0 0x2966868b in thr_kill () from /lib/libc.so.7 #1 0x295ffed6 in pthread_sigmask () from /lib/libthr.so.3 #2 0x296005ab in raise () from /lib/libthr.so.3 #3 0x2971ddea in abort () from /lib/libc.so.7 #4 0x291bb6ec in g_assertion_message () from /usr/local/lib/libglib-2.0.so.0 #5 0x291bbd4d in g_assertion_message_expr () from /usr/local/lib/libglib-2.0.so.0 #6 0x08118a6b in HttpClient::on_connected () #7 0x0805a232 in ?? () #8 0x0805e63a in ?? () #9 0x080b8e69 in std::operator+<char, std::char_traits<char>, std::allocator<char> > () #10 0x080b8eab in std::operator+<char, std::char_traits<char>, std::allocator<char> > () #11 0x28965591 in gtk_marshal_BOOLEAN__VOID () from /usr/local/lib/libgtk-x11-2.0.so.0 #12 0x2911bea3 in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.0 #13 0x29133992 in g_signal_handlers_block_matched () from /usr/local/lib/libgobject-2.0.so.0 #14 0x291359f0 in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 #15 0x29135c70 in g_signal_emit_by_name () from /usr/local/lib/libgobject-2.0.so.0 #16 0x289ce2f2 in gtk_target_list_unref () from /usr/local/lib/libgtk-x11-2.0.so.0 #17 0x289ce6a5 in gtk_target_list_unref () from /usr/local/lib/libgtk-x11-2.0.so.0 #18 0x289671c4 in gtk_marshal_BOOLEAN__VOID () from /usr/local/lib/libgtk-x11-2.0.so.0 #19 0x2911a767 in g_ptr_array_get_type () from /usr/local/lib/libgobject-2.0.so.0 #20 0x2911bea3 in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.0 #21 0x29133b58 in g_signal_handlers_block_matched () from /usr/local/lib/libgobject-2.0.so.0 #22 0x29135706 in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 #23 0x29135d45 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0 #24 0x28a8dc66 in gtk_widget_style_attach () from /usr/local/lib/libgtk-x11-2.0.so.0 #25 0x289611e5 in gtk_main_do_event () from /usr/local/lib/libgtk-x11-2.0.so.0 #26 0x28c49f1a in gdk_add_client_message_filter () from /usr/local/lib/libgdk-x11-2.0.so.0 #27 0x291952d7 in g_main_context_dispatch () from /usr/local/lib/libglib-2.0.so.0 #28 0x2919935e in g_main_context_prepare () from /usr/local/lib/libglib-2.0.so.0 #29 0x29199767 in g_main_loop_run () from /usr/local/lib/libglib-2.0.so.0 #30 0x289615c4 in gtk_main () from /usr/local/lib/libgtk-x11-2.0.so.0 #31 0x0806482b in ?? () #32 0x08064db1 in ?? () #33 0x08058a46 in ?? () #34 0x00000001 in ?? () #35 0xbfbfe724 in ?? () #36 0xbfbfe72c in ?? () #37 0xbfbfe6d8 in ?? () #38 0x00000000 in ?? () #39 0x00000000 in ?? () #40 0x00000000 in ?? () #41 0xbfbfe710 in ?? () #42 0xbfbfe720 in ?? () #43 0x00000000 in ?? () #44 0xbfbfe71c in ?? () #45 0x080589c8 in ?? () Previous frame inner to this frame (corrupt stack?) Does this help? Let me know if you need more info or want me test changes in the source. Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e <guru@unixarea.de> - w http://www.unixarea.de/ UNIX since V7 on PDP-11 | UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2 | FreeBSD since 2.2.5
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120610084743.GA2999>