automoc4 processes lock again

[Kostik Belousov]

On Mon, May 09, 2011 at 12:40:56PM +0400, Max Brazhnikov wrote:
> Hi,
> 
> After recent Qt-4.7.3 update I can't build KDE4 ports anymore (tested on 8.2-STABLE amd64 only). The problem is always reproduced with x11/kdelibs4. The build stalls with hanging automoc4 processes. Any help is appreciated.
> 
> # ps | grep automoc
> 18636   3  IN+    0:00.02 /usr/local/bin/automoc4 /usr/obj/usr/local/tinderbox/portstrees/FreeBSD/ports/x11/kdelibs4/work/kdelibs-4.6.3/build/kde3support/
> 18640   3  IN+    0:00.00 /usr/local/bin/automoc4 /usr/obj/usr/local/tinderbox/portstrees/FreeBSD/ports/x11/kdelibs4/work/kdelibs-4.6.3/build/kde3support/
> 
> # gdb automoc4 18636
...
> Reading symbols from /lib/libthr.so.3...done.
> [New Thread 801c0ae40 (LWP 100660/automoc4)]
> [New Thread 801c041c0 (LWP 100590/initial thread)]
...
> [Switching to Thread 801c0ae40 (LWP 100660/automoc4)]
> 0x000000080104c99c in select () at select.S:3
> 3       RSYSCALL(select)
> (gdb) bt
> #0  0x000000080104c99c in select () at select.S:3
> #1  0x00000008008502cd in QProcessManager::run (this=0x800b196e0) at io/qprocess_unix.cpp:245
> #2  0x0000000800749bde in QThreadPrivate::start (arg=0x800b196e0) at thread/qthread_unix.cpp:320
> #3  0x00000008017985e1 in thread_start (curthread=0x801c0ae40) at /usr/freebsd/8/src/lib/libthr/thread/thr_create.c:288
> #4  0x0000000000000000 in ?? ()
> Error accessing memory address 0x7fffffbff000: Bad address.
> Current language:  auto; currently asm
> 
> # gdb automoc4 18640
...
> 0x00000008017a24cc in _umtx_op_err () at /usr/freebsd/8/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37
> 37      RSYSCALL_ERR(_umtx_op)
> (gdb) bt
> #0  0x00000008017a24cc in _umtx_op_err () at /usr/freebsd/8/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37
> #1  0x00000008017a21bc in __thr_umutex_lock (mtx=0x8018a7380, id=100590) at /usr/freebsd/8/src/lib/libthr/thread/thr_umtx.c:58
> #2  0x000000080179d04a in init_static (thread=0x801c041c0, mutex=0x801166c78) at thr_umtx.h:88
> #3  0x000000080179d7ad in __pthread_mutex_lock (mutex=0x801166c78) at /usr/freebsd/8/src/lib/libthr/thread/thr_mutex.c:441
> #4  0x000000080104b21e in _flockfile (fp=0x801166be0) at /usr/freebsd/8/src/lib/libc/stdio/_flock_stub.c:70
> #5  0x0000000801021515 in fileno (fp=0x801166be0) at /usr/freebsd/8/src/lib/libc/stdio/fileno.c:52
> #6  0x000000080084f109 in QProcessPrivate::execChild (this=0x801c51600, workingDir=0x0, path=0x0, argv=0x801c5b7c0, envp=0x0) at io/qprocess_unix.cpp:712
> #7  0x0000000800851fc3 in QProcessPrivate::startProcess (this=0x801c51600) at io/qprocess_unix.cpp:665
> #8  0x0000000800802248 in QProcess::start (this=0x7fffffffcd10, program=@0x7fffffffd8f8, arguments=@0x7fffffffcd00, mode=@0x7fffffffcd20)
>     at io/qprocess.cpp:1960
> #9  0x000000000040acd2 in AutoMoc::echoColor (this=0x7fffffffd8d0, msg=@0x7fffffffce80)
>     at /usr/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:73
> #10 0x000000000040517c in AutoMoc::generateMoc (this=0x7fffffffd8d0, sourceFile=@0x801c0f910, mocFileName=@0x801c0f918)
>     at /usr/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:569
> #11 0x0000000000408011 in AutoMoc::run (this=0x7fffffffd8d0) at /usr/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:470
> #12 0x0000000000409135 in main (argc=6, argv=0x7fffffffd9a8) at /usr/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:114
> Current language:  auto; currently asm

You did not supplied enough information.
Which of the processes is parent, which is child ?
Note that there are other threads in the pid 18636. What does they do ?

If you would allow me to make some guess, then I could assume that pid
18640 is the child. Note that the child is waiting for the pthread
mutex locked which protects the stdio' FILE structure. Now, assume
additionally that the parent had the FILE locked in one thread while
another thread did the fork. Then, the child process would never be able
to obtain the lock because the lock was acquired by the thread that
exists no longer (in the child process, only the thread that called
fork is duplicated).

In fact, I believe that you already reported a similar problem with
malloc(3) some time ago. The root of the problem would be an undefined
(and permitted by POSIX) behaviour of calling non-async signal safe
functions in multithreaded process after fork.

For malloc(3), this can be argued to be a quality of the implementation
issue, but there is no reason to specially handle random mutexes, even
from libc. If the mutex was locked during the fork time, the protected
data structure is arguably in the inconsistent state after the fork in
the child.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20110509/a9f75d90/attachment.pgp