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 avi...@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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
