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

2012-12-10 Thread Mark Atkinson 
-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.

#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 0x0001 in ?? ()
#16 0x 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
==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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

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

2012-12-10 Thread Konstantin Belousov 
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 0x0001 in ?? ()
 #16 0x 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.
 ==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/

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

2012-12-10 Thread Mark Atkinson 
-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 0x0001 in ?? () #16 0x 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:

#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  0x 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,

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

2012-12-10 Thread Konstantin Belousov 
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 0x0001 in ?? () #16 0x 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  0x 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,

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

2012-12-10 Thread Mark Atkinson 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/10/2012 12:33, Konstantin Belousov wrote:

 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.


It _is_ strange, because I did almost exactly that (dumped a temporary
DEBUG_FLAGS/CFLAGS in /etc/make.conf)

The one I had problems with was libc since It needs a make depend in
there.

$ readelf -w /libexec/ld-elf.so.1 |head
The section .debug_aranges contains:

  Length:   28
  Version:  2
  Offset into .debug_info:  0
  Pointer Size: 4
  Segment Size: 0

AddressLength
0x0e80 0x49
$
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEUEARECAAYFAlDGSeMACgkQrDN5kXnx8yYb6QCfQFO6o/At+srdpuRfI8jGCnqu
ZJMAlir1UvA4mgE0k2ewP43ayPiepCM=
=YVai
-END PGP SIGNATURE-

___
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

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

2012-12-10 Thread Mark Atkinson 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/10/2012 12:45, Mark Atkinson wrote:
 On 12/10/2012 12:33, Konstantin Belousov wrote:
 
 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.
 
 
 It _is_ strange, because I did almost exactly that (dumped a
 temporary DEBUG_FLAGS/CFLAGS in /etc/make.conf)
 
 The one I had problems with was libc since It needs a make depend
 in there.
 
 $ readelf -w /libexec/ld-elf.so.1 |head The section .debug_aranges
 contains:
 
 Length:   28 Version:  2 Offset
 into .debug_info:  0 Pointer Size: 4 Segment Size:
 0
 
 AddressLength 0x0e80 0x49 $

So ignoring this weirdness, running under valgrind always segfaults
and the core seems useful.

#0  0x0061bd59 in handle_signal (actp=0xbf9fd490, sig=20,
info=0xbf9fd7b0, ucp=0x0) at /usr/src/lib/libthr/thread/thr_sig.c:198
#1  0x0061b71c in thr_sighandler (sig=20, info=0xbf9fd7b0, _ucp=0x0)
at /usr/src/lib/libthr/thread/thr_sig.c:182
#2  0x380434dc in ?? ()
#3  0x0014 in ?? ()
#4  0xbf9fd7b0 in ?? ()
#5  0x in ?? ()
(gdb) frame 0
#0  0x0061bd59 in handle_signal (actp=0xbf9fd490, sig=20,
info=0xbf9fd7b0, ucp=0x0) at /usr/src/lib/libthr/thread/thr_sig.c:198
198 SIGSETOR(actp-sa_mask, ucp-uc_sigmask);
(gdb) list
193 int cancel_enable;
194 int in_sigsuspend;
195 int err;
196
197 /* add previous level mask */
198 SIGSETOR(actp-sa_mask, ucp-uc_sigmask);
199
200 /* add this signal's mask */
201 if (!(actp-sa_flags  SA_NODEFER))
202 SIGADDSET(actp-sa_mask, sig);

(gdb) p actp
$1 = (struct sigaction *) 0xbf9fd490
(gdb) p *actp
$2 = {__sigaction_u = {__sa_handler = 0x288310
qt_sa_sigchld_handler(int), __sa_sigaction = 0x288310
qt_sa_sigchld_handler(int)}, sa_flags = 8, sa_mask = {__bits = {0,
0, 0, 0}}}
(gdb) p *ucp
Cannot access memory at address 0x0
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDGUHMACgkQrDN5kXnx8yYBDACfaBBZyDZnQhbxxjw46csLbg7z
X7UAn1ea4LbW8PHXL07BwraiVXakh1bU
=GktK
-END PGP SIGNATURE-

___
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

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

2012-12-10 Thread Konstantin Belousov 
On Mon, Dec 10, 2012 at 01:13:23PM -0800, Mark Atkinson wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 12/10/2012 12:45, Mark Atkinson wrote:
  On 12/10/2012 12:33, Konstantin Belousov wrote:
  
  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.
  
  
  It _is_ strange, because I did almost exactly that (dumped a
  temporary DEBUG_FLAGS/CFLAGS in /etc/make.conf)
  
  The one I had problems with was libc since It needs a make depend
  in there.
  
  $ readelf -w /libexec/ld-elf.so.1 |head The section .debug_aranges
  contains:
  
  Length:   28 Version:  2 Offset
  into .debug_info:  0 Pointer Size: 4 Segment Size:
  0
  
  AddressLength 0x0e80 0x49 $
 
 So ignoring this weirdness, running under valgrind always segfaults
 and the core seems useful.
 
 #0  0x0061bd59 in handle_signal (actp=0xbf9fd490, sig=20,
 info=0xbf9fd7b0, ucp=0x0) at /usr/src/lib/libthr/thread/thr_sig.c:198
 #1  0x0061b71c in thr_sighandler (sig=20, info=0xbf9fd7b0, _ucp=0x0)
 at /usr/src/lib/libthr/thread/thr_sig.c:182
 #2  0x380434dc in ?? ()
 #3  0x0014 in ?? ()
 #4  0xbf9fd7b0 in ?? ()
 #5  0x in ?? ()
 (gdb) frame 0
 #0  0x0061bd59 in handle_signal (actp=0xbf9fd490, sig=20,
 info=0xbf9fd7b0, ucp=0x0) at /usr/src/lib/libthr/thread/thr_sig.c:198
 198 SIGSETOR(actp-sa_mask, ucp-uc_sigmask);
 (gdb) list
 193 int cancel_enable;
 194 int in_sigsuspend;
 195 int err;
 196
 197 /* add previous level mask */
 198 SIGSETOR(actp-sa_mask, ucp-uc_sigmask);
 199
 200 /* add this signal's mask */
 201 if (!(actp-sa_flags  SA_NODEFER))
 202 SIGADDSET(actp-sa_mask, sig);
 
 (gdb) p actp
 $1 = (struct sigaction *) 0xbf9fd490
 (gdb) p *actp
 $2 = {__sigaction_u = {__sa_handler = 0x288310
 qt_sa_sigchld_handler(int), __sa_sigaction = 0x288310
 qt_sa_sigchld_handler(int)}, sa_flags = 8, sa_mask = {__bits = {0,
 0, 0, 0}}}
 (gdb) p *ucp
 Cannot access memory at address 0x0
This looks like a valgrind problem, because kernel correctly passes
fourth argument to the signal handler frame. Or rather, the signal
trampoline and kernel properly pass ucontext to signal handler.

If this appear to be broken, the signal trampoline would cause
the fault on the signal return, even for the single-threaded processes.

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.19 (FreeBSD)
 Comment: Using GnuPG with undefined - http://www.enigmail.net/
 
 iEYEARECAAYFAlDGUHMACgkQrDN5kXnx8yYBDACfaBBZyDZnQhbxxjw46csLbg7z
 X7UAn1ea4LbW8PHXL07BwraiVXakh1bU
 =GktK
 -END PGP SIGNATURE-
 
 ___
 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


pgpM8SHhzBGPy.pgp
Description: PGP signature

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

2012-12-10 Thread Ryan Stone 
On Mon, Dec 10, 2012 at 12:35 PM, Mark Atkinson atkin...@gmail.com wrote:

 vex x86-IR: unhandled instruction bytes: 0xF 0xB 0x90 0x90
 ==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


This sounds like a valgrind bug I reported related to sigreturn:

https://bitbucket.org/stass/valgrind-freebsd/issue/4/crash-in-x86_freebsd_subst_for_sigreturn

Unfortunately I don't understand the mechanics of signal handling well
enough to take this to completion.
___
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

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

2012-12-07 Thread Dimitry Andric 

On 2012-12-06 18:12, Mark Atkinson wrote:

Short backstory, I had recently upgraded my workstation to the latest
current which included clang as default cc now.

...

qdbus under kde segfaults in malloc with a huge recursion stack:

[...]
#44740 0x282f7bd4 in QObject::QObject () from
/usr/local/lib/qt4/libQtCore.so.4
#44741 0x281cb649 in QAdoptedThread::QAdoptedThread () from
/usr/local/lib/qt4/libQtCore.so.4
#44742 0x281ce146 in QThreadData::current () from
/usr/local/lib/qt4/libQtCore.so.4
#44743 0x282f7bd4 in QObject::QObject () from
/usr/local/lib/qt4/libQtCore.so.4
#44744 0x281cb649 in QAdoptedThread::QAdoptedThread () from
/usr/local/lib/qt4/libQtCore.so.4
#44745 0x281ce146 in QThreadData::current () from
/usr/local/lib/qt4/libQtCore.so.4
#44746 0x282f7bd4 in QObject::QObject () from
/usr/local/lib/qt4/libQtCore.so.4
#44747 0x281cb649 in QAdoptedThread::QAdoptedThread () from
/usr/local/lib/qt4/libQtCore.so.4
#44748 0x281ce146 in QThreadData::current () from
/usr/local/lib/qt4/libQtCore.so.4
#44749 0x281cbc05 in QThread::currentThread () from
/usr/local/lib/qt4/libQtCore.so.4
#44750 0x28095d21 in QDBusConnectionPrivate::deleteYourself () from
/usr/local/lib/qt4/libQtDBus.so.4
#44751 0x28089634 in QDBusConnection::~QDBusConnection () from
/usr/local/lib/qt4/libQtDBus.so.4
#44752 0x0804b800 in __dtor__ZL10connection ()
#44753 0x28660417 in __cxa_finalize () from /lib/libc.so.7
#44754 0x2860747a in exit () from /lib/libc.so.7
#44755 0x0804c125 in main ()
(gdb)


This is a bug in qdbus; it uses a global static QDBusConnection object,
and the order in which global destructors are called is undefined:

http://qt.gitorious.org/qt/qttools/blobs/stable/src/qdbus/qdbus/qdbus.cpp#line57

In this particular case, the destructor (__dtor__ZL10connection) is
called *after* all of Qt's internal stuff has already been destroyed:

- QDBusConnectionPrivate::deleteYourself() tries to figure out if it is
  called from the current QThread, and calls QThread::currentThread()
- QThread::currentThread() calls QThreadData::current()
- QThreadData::current() tries to instantiate a QAdoptedThread
- QAdoptedThread descends from QObject, so calls QObject::QObject()
- QObject::QObject() calls QThreadData::current()
- Endless loop results, until the stack is blown, and a new operator
  fails in malloc()

The global static QDBusConnection object should be replaced by a
singleton, as suggested here:

http://techbase.kde.org/Policies/Library_Code_Policy#Static_Objects

but I am not sure how that is normally done in Qt itself.
___
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

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

2012-12-07 Thread Dimitry Andric 

On 2012-12-07 13:59, Dimitry Andric wrote:

On 2012-12-06 18:12, Mark Atkinson wrote:

Short backstory, I had recently upgraded my workstation to the latest
current which included clang as default cc now.

...

qdbus under kde segfaults in malloc with a huge recursion stack:

...

This is a bug in qdbus; it uses a global static QDBusConnection object,
and the order in which global destructors are called is undefined:

...

The global static QDBusConnection object should be replaced by a
singleton, as suggested here:


Here is an alternative solution, where the QDBusConnection object is
just a local variable in main(), and passed around as a const reference.
To make the destructors work properly, I also replaced the exit() calls
in main() with return statements.

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. :)

--- tools/qdbus/qdbus/qdbus.cpp.orig2012-04-26 21:45:51.0 +0200
+++ tools/qdbus/qdbus/qdbus.cpp 2012-12-07 14:46:43.0 +0100
@@ -54,7 +54,6 @@ QT_BEGIN_NAMESPACE
 Q_DBUS_EXPORT extern bool qt_dbus_metaobject_skip_annotations;
 QT_END_NAMESPACE
 
-static QDBusConnection connection(QLatin1String());
 static bool printArgumentsLiterally = false;
 
 static void showUsage()
@@ -111,7 +110,7 @@ static void printArg(const QVariant v)
 }
 }
 
-static void listObjects(const QString service, const QString path)
+static void listObjects(const QString service, const QString path, const 
QDBusConnection connection)
 {
 // make a low-level call, to avoid introspecting the Introspectable 
interface
 QDBusMessage call = QDBusMessage::createMethodCall(service, path.isEmpty() 
? QLatin1String(/) : path,
@@ -144,13 +143,13 @@ static void listObjects(const QString s
 if (child.tagName() == QLatin1String(node)) {
 QString sub = path + QLatin1Char('/') + 
child.attribute(QLatin1String(name));
 printf(%s\n, qPrintable(sub));
-listObjects(service, sub);
+listObjects(service, sub, connection);
 }
 child = child.nextSiblingElement();
 }
 }
 
-static void listInterface(const QString service, const QString path, const 
QString interface)
+static void listInterface(const QString service, const QString path, const 
QString interface, const QDBusConnection connection)
 {
 QDBusInterface iface(service, path, interface, connection);
 if (!iface.isValid()) {
@@ -204,7 +203,7 @@ static void listInterface(const QString 
 }
 }
 
-static void listAllInterfaces(const QString service, const QString path)
+static void listAllInterfaces(const QString service, const QString path, 
const QDBusConnection connection)
 {
 // make a low-level call, to avoid introspecting the Introspectable 
interface
 QDBusMessage call = QDBusMessage::createMethodCall(service, path.isEmpty() 
? QLatin1String(/) : path,
@@ -229,7 +228,7 @@ static void listAllInterfaces(const QStr
 if (child.tagName() == QLatin1String(interface)) {
 QString ifaceName = child.attribute(QLatin1String(name));
 if (QDBusUtil::isValidInterfaceName(ifaceName))
-listInterface(service, path, ifaceName);
+listInterface(service, path, ifaceName, connection);
 else {
 qWarning(Invalid D-BUS interface name '%s' found while 
parsing introspection,
  qPrintable(ifaceName));
@@ -253,7 +252,7 @@ static QStringList readList(QStringList 
 return retval;
 }
 
-static int placeCall(const QString service, const QString path, const 
QString interface,
+static int placeCall(const QString service, const QString path, const 
QString interface, const QDBusConnection connection,
const QString member, const QStringList arguments, bool 
try_prop=true)
 {
 QDBusInterface iface(service, path, interface, connection);
@@ -291,7 +290,7 @@ static int placeCall(const QString serv
 proparg += interface;
 proparg += member;
 proparg += args.first();
-if (!placeCall(service, path, 
org.freedesktop.DBus.Properties, Set, proparg, false))
+if (!placeCall(service, path, 
org.freedesktop.DBus.Properties, connection, Set, proparg, false))
 return 0;
 }
 fprintf(stderr, Cannot find '%s.%s' in object %s at %s\n,
@@ -387,7 +386,7 @@ static int placeCall(const QString serv
 QStringList proparg;
 proparg += interface;
 proparg += member;
-if (!placeCall(service, path, org.freedesktop.DBus.Properties, 
Get, proparg, false))
+if (!placeCall(service, path, org.freedesktop.DBus.Properties, 
connection, Get, proparg, false))
 return 0;
 }
 if (err.type() == QDBusError::ServiceUnknown)
@@ -448,6 +447,7 @@ int main(int argc,

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

2012-12-07 Thread Mark Atkinson 


On 12/7/2012 6:08 AM, Dimitry Andric wrote:
 On 2012-12-07 13:59, Dimitry Andric wrote:
 On 2012-12-06 18:12, Mark Atkinson wrote:
 Short backstory, I had recently upgraded my workstation to the latest
 current which included clang as default cc now.
 ...
 qdbus under kde segfaults in malloc with a huge recursion stack:
 ...
 This is a bug in qdbus; it uses a global static QDBusConnection object,
 and the order in which global destructors are called is undefined:
 ...
 The global static QDBusConnection object should be replaced by a
 singleton, as suggested here:
 
 Here is an alternative solution, where the QDBusConnection object is
 just a local variable in main(), and passed around as a const reference.
 To make the destructors work properly, I also replaced the exit() calls
 in main() with return statements.
 
 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.



___
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

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

2012-12-07 Thread Dimitry Andric 

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.
___
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

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

2012-12-07 Thread Kevin Lo 
Dimitry Andric wrote:
 On 2012-12-07 13:59, Dimitry Andric wrote:
  On 2012-12-06 18:12, Mark Atkinson wrote:
  Short backstory, I had recently upgraded my workstation to the latest
  current which included clang as default cc now.
  ...
  qdbus under kde segfaults in malloc with a huge recursion stack:
 ...
  This is a bug in qdbus; it uses a global static QDBusConnection object,
  and the order in which global destructors are called is undefined:
 ...
  The global static QDBusConnection object should be replaced by a
  singleton, as suggested here:
 
 Here is an alternative solution, where the QDBusConnection object is
 just a local variable in main(), and passed around as a const reference.
 To make the destructors work properly, I also replaced the exit() calls
 in main() with return statements.
 
 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. :)

Works for me, thanks. I think your patch should go in. 

Kevin

___
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