Date: Sun, 20 May 2012 14:03:17 +0800 From: David Xu <listlog2011@gmail.com> To: =?ISO-8859-1?Q?Gustau_P=E9rez_i_Querol?= <gperez@entel.upc.edu> Cc: avilla@freebsd.org, FreeBSD current <freebsd-current@freebsd.org> Subject: Re: RFC: jemalloc: qdbus sigsegv in malloc_init Message-ID: <4FB88925.4070008@gmail.com> In-Reply-To: <4F9E9E06.4070004@entel.upc.edu> References: <4F9E9E06.4070004@entel.upc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FB88925.4070008>