Re: problems with threads/destructors in -current with llvm/clang

From: Konstantin Belousov <kostikbel_at_gmail.com>
Date: Mon, 10 Dec 2012 20:25:26 +0200
On Mon, Dec 10, 2012 at 09:35:29AM -0800, Mark Atkinson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 12/07/2012 09:29, Dimitry Andric wrote:
> > On 2012-12-07 17:43, Mark Atkinson wrote:
> >> On 12/7/2012 6:08 AM, Dimitry Andric wrote:
> > ...
> >>> With this patch (placed in /usr/ports/devel/dbus-qt4/files),
> >>> qdbus starts up and exits normally for me.  I did not do any
> >>> other rigorous testing, though. :)
> >> 
> >> Thanks for the awesome analysis.  I will endeavor to figure out
> >> the bug in automoc4 that keeps it segfaulting randomly during
> >> compilation.
> >> 
> >> Weirdly it segfaults reliably under portmaster, but may work just
> >> fine under just make.
> > 
> > Try running it under valgrind.  If it does undefined things, it may
> > work or not work randomly, and valgrind usually catches this.
> 
> OK, so this one's a bit of a headscratcher, but maybe someone has some
> ideas.  automoc4 always dies in libthr.
Build rtld, libc and libthr with the debug symbols to get useful
backtrace.

> 
> #0  0x2864b1da in swapcontext () from /lib/libthr.so.3
> [New Thread 29003800 (LWP 100960/automoc4.bin)]
> [New Thread 29003080 (LWP 101795/automoc4.bin)]
> (gdb) bt
> #0  0x2864b1da in swapcontext () from /lib/libthr.so.3
> #1  0x2864a046 in pthread_getspecific () from /lib/libthr.so.3
> #2  0x28649e9a in pthread_getspecific () from /lib/libthr.so.3
> #3  0x2864dbfb in pthread_kill () from /lib/libthr.so.3
> #4  0x28064e71 in _rtld_get_stack_prot () from /libexec/ld-elf.so.1
> #5  0x2865d500 in _thread_state_running () from /lib/libthr.so.3
> #6  0x2865d500 in _thread_state_running () from /lib/libthr.so.3
> #7  0x28075e00 in ?? ()
> #8  0x286b4d30 in pipe () from /lib/libc.so.7
> #9  0x280712ac in ?? () from /libexec/ld-elf.so.1
> #10 0xbf9fce2c in ?? ()
> #11 0x2805e505 in r_debug_state () from /libexec/ld-elf.so.1
> #12 0x28071f68 in ?? () from /libexec/ld-elf.so.1
> #13 0xbf9fcde0 in ?? ()
> #14 0xbf9fce18 in ?? ()
> #15 0x00000001 in ?? ()
> #16 0x00000000 in ?? ()
> (gdb) thread 2
> [Switching to thread 2 (Thread 29003080 (LWP 101795/automoc4.bin))]#0
>  0x2876c3a7 in select () from /lib/libc.so.7
> (gdb) bt
> #0  0x2876c3a7 in select () from /lib/libc.so.7
> #1  0x286481ab in select () from /lib/libthr.so.3
> #2  0x28365c49 in qt_safe_select (nfds=17, fdread=0xbfbfa090,
> fdwrite=0xbfbfa010, fdexcept=0x0, orig_timeout=0x0) at
> kernel/qcore_unix.cpp:83
> #3  0x282c23b2 in select_msecs (nfds=17, fdread=0xbfbfa090,
> fdwrite=0xbfbfa010, timeout=-1) at io/qprocess_unix.cpp:998
> #4  0x282c33f3 in QProcessPrivate::waitForFinished (this=0x29089300,
> msecs=-1) at io/qprocess_unix.cpp:1219
> #5  0x28240b50 in QProcess::waitForFinished (this=0xbfbfa1e8,
> msecs=-1) at io/qprocess.cpp:1759
> #6  0x0805487b in AutoMoc::echoColor (this=0xbfbfab00,
> msg=_at_0xbfbfa2e0) at
> /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:74
> #7  0x08052650 in AutoMoc::generateMoc (this=0xbfbfab00,
> sourceFile=_at_0x29011658, mocFileName=_at_0x2901165c) at
> /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:569
> #8  0x0804f13b in AutoMoc::run (this=0xbfbfab00) at
> /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:470
> #9  0x0804aaef in main (argc=6, argv=0xbfbfab98) at
> /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:114
> 
> I noticed that qt_safe_select() used a register bound variable for the
> return value, but removing that didn't alleviate the error.
> 
> The pthread_getspecific() manpage mentions that if the key is deleted
> then the behavior is undefined -- so maybe this?  It's definitely
> seems like a race condition of some kind.
> 
> Valgrind will kill any run of automoc4 and doesn't like some
> instruction after the qt_safe_select() call:
> 
> vex x86->IR: unhandled instruction bytes: 0xF 0xB 0x90 0x90
This is ud2, an instruction which generates a fault on purpose.

So rebuild the system libraries with the debug symbols and show
the backtrace.
> ==33074== valgrind: Unrecognised instruction at address 0x380434e9.
> ==33074==    at 0x380434E9: ??? (in
> /usr/local/lib/valgrind/memcheck-x86-freebsd)
> ==33074==    by 0x323C48: qt_safe_select(int, fd_set*, fd_set*,
> fd_set*, timeval const*) (qcore_unix.cpp:83)
> ==33074==    by 0x2803B1: select_msecs(int, fd_set*, fd_set*, int)
> (qprocess_unix.cpp:998)
> ==33074==    by 0x28021D: QProcessPrivate::waitForStarted(int)
> (qprocess_unix.cpp:1031)
> ==33074==    by 0x1FFA02: QProcess::waitForStarted(int)
> (qprocess.cpp:1687)
> ==33074==    by 0x1FEAEA: QProcess::waitForFinished(int)
> (qprocess.cpp:1752)
> ==33074==    by 0x805487A: AutoMoc::echoColor(QString const&)
> (kde4automoc.cpp:74)
> ==33074==    by 0x805264F: AutoMoc::generateMoc(QString const&,
> QString const&) (kde4automoc.cpp:569)
> ==33074==    by 0x804F13A: AutoMoc::run() (kde4automoc.cpp:470)
> ==33074==    by 0x804AAEE: main (kde4automoc.cpp:114)
> 
> Full valgrind output is at http://pastebin.com/KQTKYGX5
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (FreeBSD)
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
> 
> iEYEARECAAYFAlDGHWEACgkQrDN5kXnx8yZEUwCfXhKBqCJKJcfomG6mHo6ataaw
> x60An36saeyL2b09CR2Z/zL84KzjPjsQ
> =EzG3
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"

Received on Mon Dec 10 2012 - 17:25:32 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:33 UTC