Re: RFC: jemalloc: qdbus sigsegv in malloc_init

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_at_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_at_ (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
_at__at_ -156,7 +156,7 _at__at_
  {
      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