From owner-freebsd-current@FreeBSD.ORG Sun May 20 06:03:23 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1800C1065675; Sun, 20 May 2012 06:03:23 +0000 (UTC) (envelope-from listlog2011@gmail.com) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EB9198FC0A; Sun, 20 May 2012 06:03:22 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q4K63JhN064471; Sun, 20 May 2012 06:03:20 GMT (envelope-from listlog2011@gmail.com) Message-ID: <4FB88925.4070008@gmail.com> Date: Sun, 20 May 2012 14:03:17 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Gustau_P=E9rez_i_Querol?= References: <4F9E9E06.4070004@entel.upc.edu> In-Reply-To: <4F9E9E06.4070004@entel.upc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: avilla@freebsd.org, FreeBSD current Subject: Re: RFC: jemalloc: qdbus sigsegv in malloc_init X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidxu@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2012 06:03:23 -0000 On 2012/4/30 22:13, Gustau Pérez i Querol wrote: > > Hi, > > the kde team is seeing some strange problems with the new version > (4.8.1) of devel/dbus-qt4 with current. It does work with stable. I > also suspect that the problem described below is affecting the > experimental cinnamon port (an alternative to gnome3, possible > replacement of gnome2). > > The problem happens with both i386 and amd64 with empty > /etc/malloc.conf and simple /etc/make.conf. Everything compiled with > base gcc (no clang). The kernel was compiled with no debug support, > but it can enable if needed. There are reports from avilla@freebsd.org > of the same behavior with clang compiled world and kernel and with > MALLOC_PRODUCTION=yes. > > When qdbus starts, it segfauts. The backtrace of the problem with > r234769 can be found here: http://pastebin.com/ryBXtqGF. When starting > the qdbus daemon by hand in a X+twm session, we see it calls calloc > many times and after a fixed number of times segfaults. We see it > segfaults at rb_gen (a quite large macro defined at > $SRC_BASE/contrib/jemalloc/include/jemalloc/internal/rb.h). > > If the daemon is started by hand, I'm able to skip all the calls > qdbus makes to calloc till the one causing the segfault. At that > point, at rb_gen, we don't exactly know what is going on or how to > debug the macro. Ktrace are available, but we were unable to find > anything new from them. > > With old versions of current before the jemalloc imports (as of > March 30th) the daemon segfaulted at malloc.c:2426. With revisions > during April 20 to 24th (can be more precise, it was during the > jemalloc imports) the daemon segfaulted at malloc_init. Bts are > available if needed, and if necessary I can go back to those revision > and recompile world+kernel to see its behavior. > > Any help from freebsd-current@ (perhaps Jason Evans can help us) > will be appreciated. Any additional info, like source revisions, can > be provided. I would like to stress that the experimental > devel/dbus-qt4 works fine with recent stable. > qdbus segfaults on my machine too, I tracked it down, and found the problem is in QT, it deleted current_thread_data_key, but it still uses it in some cxa hooks, I applied the following patch, and it works fine. --- qthread_unix.cpp 2012-05-20 13:23:09.000000000 +0800 +++ qthread_unix_new.cpp 2012-05-20 13:22:45.000000000 +0800 @@ -156,7 +156,7 @@ { pthread_key_delete(current_thread_data_key); } -Q_DESTRUCTOR_FUNCTION(destroy_current_thread_data_key) +//Q_DESTRUCTOR_FUNCTION(destroy_current_thread_data_key) // Utility functions for getting, setting and clearing thread specific data. --- the Q_DESTRUCTOR_FUNCTION defined global a C++ object, and in its destructor, it deletes the current_thread_data_key, but in other cxa hooks, the key is still needed. So, finally the QT library crashed. I think the bug depends on linking order in QT library ? if the qthread_unix.cpp is linked as lastest module, the key will be deleted after all cxa hooks run, then it will be fine, otherwise, it would crash. This sounds like a bug in QT. Regards, David Xu