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
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "amd64-marcel-freebsd"...
Attaching to program: /usr/local/bin/automoc4, process 18636
Reading symbols from /usr/local/lib/qt4/libQtCore.so.4...Reading symbols from
/usr/local/lib/qt4/libQtCore.so.4.7.3.debug...done.
done.
Loaded symbols for /usr/local/lib/qt4/libQtCore.so.4
Reading symbols from /usr/lib/libstdc++.so.6...done.
Loaded symbols for /usr/lib/libstdc++.so.6
Reading symbols from /lib/libm.so.5...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /lib/libz.so.5...done.
Loaded symbols for /lib/libz.so.5
Reading symbols from /usr/local/lib/libgthread-2.0.so.0...done.
Loaded symbols for /usr/local/lib/libgthread-2.0.so.0
Reading symbols from /usr/local/lib/libglib-2.0.so.0...done.
Loaded symbols for /usr/local/lib/libglib-2.0.so.0
Reading symbols from /usr/local/lib/libiconv.so.3...done.
Loaded symbols for /usr/local/lib/libiconv.so.3
Reading symbols from /lib/libthr.so.3...done.
[New Thread 801c0ae40 (LWP 100660/automoc4)]
[New Thread 801c041c0 (LWP 100590/initial thread)]
Loaded symbols for /lib/libthr.so.3
Reading symbols from /usr/local/lib/libintl.so.9...done.
Loaded symbols for /usr/local/lib/libintl.so.9
Reading symbols from /usr/local/lib/libpcre.so.0...done.
Loaded symbols for /usr/local/lib/libpcre.so.0
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
[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
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "amd64-marcel-freebsd"...
Attaching to program: /usr/local/bin/automoc4, process 18640
Reading symbols from /usr/local/lib/qt4/libQtCore.so.4...Reading symbols from
/usr/local/lib/qt4/libQtCore.so.4.7.3.debug...done.
done.
Loaded symbols for /usr/local/lib/qt4/libQtCore.so.4
Reading symbols from /usr/lib/libstdc++.so.6...done.
Loaded symbols for /usr/lib/libstdc++.so.6
Reading symbols from /lib/libm.so.5...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /lib/libz.so.5...done.
Loaded symbols for /lib/libz.so.5
Reading symbols from /usr/local/lib/libgthread-2.0.so.0...done.
Loaded symbols for /usr/local/lib/libgthread-2.0.so.0
Reading symbols from /usr/local/lib/libglib-2.0.so.0...done.
Loaded symbols for /usr/local/lib/libglib-2.0.so.0
Reading symbols from /usr/local/lib/libiconv.so.3...done.
Loaded symbols for /usr/local/lib/libiconv.so.3
Reading symbols from /lib/libthr.so.3...done.
Error while reading shared library symbols:
Cannot get thread info: invalid key
Reading symbols from /usr/local/lib/libintl.so.9...done.
Loaded symbols for /usr/local/lib/libintl.so.9
Reading symbols from /usr/local/lib/libpcre.so.0...done.
Loaded symbols for /usr/local/lib/libpcre.so.0
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
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
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 asmYou 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