problems with threads/destructors in -current with llvm/clang
Konstantin Belousov
kostikbel at gmail.com
Mon Dec 10 20:33:38 UTC 2012
On Mon, Dec 10, 2012 at 12:29:20PM -0800, Mark Atkinson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/10/2012 10:25, Konstantin Belousov wrote:
> > On Mon, Dec 10, 2012 at 09:35:29AM -0800, Mark Atkinson wrote: 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=@0xbfbfa2e0) at
> > /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:74
> > #7 0x08052650 in AutoMoc::generateMoc (this=0xbfbfab00,
> > sourceFile=@0x29011658, mocFileName=@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.
>
> Hmm. Since I took out -O2 and added -g in rebuilding
> libthr/libc/rtld, I figured I needed to reproduce a new segfault, but
> the rtld side of things seems broken:
Use e.g.
cd src/libexec/rtld-elf && make DEBUG_FLAGS=-g clean all install
This is really FAQ.
>
> #0 0xbf9fd01a in ?? ()
> [New Thread 29003800 (LWP 100652/automoc4.bin)]
> [New Thread 29003080 (LWP 101395/automoc4.bin)]
> (gdb) bt
> #0 0xbf9fd01a in ?? ()
> #1 0xbf9fcd20 in ?? ()
> #2 0x00000000 in ?? ()
> (gdb) info thread
> 2 Thread 29003080 (LWP 101395/automoc4.bin) select () at select.S:3
> * 1 Thread 29003800 (LWP 100652/automoc4.bin) 0xbf9fd01a in ?? ()
> Current language: auto; currently asm
> (gdb) thread 2
> [Switching to thread 2 (Thread 29003080 (LWP 101395/automoc4.bin))]#0
> select () at select.S:3
> 3 RSYSCALL(select)
> (gdb) bt
> #0 select () at select.S:3
> #1 0x28659028 in __select (numfds=17, readfds=0xbfbfc1f0,
> writefds=0xbfbfc170, exceptfds=0x0, timeout=0x0) at
> /usr/src/lib/libthr/thread/thr_syscalls.c:539
> #2 0x28372c49 in qt_safe_select (nfds=17, fdread=0xbfbfc1f0,
> fdwrite=0xbfbfc170, fdexcept=0x0, orig_timeout=0x0) at
> kernel/qcore_unix.cpp:83
> #3 0x282cf3b2 in select_msecs (nfds=17, fdread=0xbfbfc1f0,
> fdwrite=0xbfbfc170, timeout=-1) at io/qprocess_unix.cpp:998
> #4 0x282d03f3 in QProcessPrivate::waitForFinished (this=0x29089300,
> msecs=-1) at io/qprocess_unix.cpp:1219
> #5 0x2824db50 in QProcess::waitForFinished (this=0xbfbfc348,
> msecs=-1) at io/qprocess.cpp:1759
> #6 0x0805487b in AutoMoc::echoColor (this=0xbfbfcc60,
> msg=@0xbfbfc440) at
> /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:74
> #7 0x08052650 in AutoMoc::generateMoc (this=0xbfbfcc60,
> sourceFile=@0x29011638, mocFileName=@0x2901163c) at
> /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:569
> #8 0x0804f13b in AutoMoc::run (this=0xbfbfcc60) at
> /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:470
> #9 0x0804aaef in main (argc=6, argv=0xbfbfccfc) at
> /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:114
> (gdb) thread 1
> [Switching to thread 1 (Thread 29003800 (LWP 100652/automoc4.bin))]#0
> 0xbf9fd01a in ?? ()
> (gdb) bt
> #0 0xbf9fd01a in ?? ()
> #1 0xbf9fcd20 in ?? ()
> #2 0x00000000 in ?? ()
> (gdb) frame 0
> #0 0xbf9fd01a in ?? ()
> (gdb) info reg
> eax 0x0 0
> ecx 0x286d7ddb 678264283
> edx 0x0 0
> ebx 0xbf9fd058 -1080045480
> esp 0xbf9fcd1c 0xbf9fcd1c
> ebp 0x14 0x14
> esi 0x2865c563 677758307
> edi 0x2869f2ec 678032108
> eip 0xbf9fd01a 0xbf9fd01a
> eflags 0x210246 2163270
> cs 0x33 51
> ss 0x3b 59
> ds 0x3b 59
> es 0x3b 59
> fs 0x3b 59
> gs 0x1b 27
>
>
> > ==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
> >
> >>
> >> _______________________________________________
> >> 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"
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (FreeBSD)
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
>
> iEYEARECAAYFAlDGRiAACgkQrDN5kXnx8yYJFQCgkMYOxkIfFibTaPNOkikw+0Ki
> t3YAoJTCIYecBmk7LT1ehsdQzwhm1Uif
> =4Ars
> -----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"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20121210/1c036efc/attachment.sig>
More information about the freebsd-current
mailing list