From owner-freebsd-stable@FreeBSD.ORG Mon May 9 13:02:08 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33DCF10656D6 for ; Mon, 9 May 2011 13:02:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id AB7848FC15 for ; Mon, 9 May 2011 13:02:07 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p49Cf5If056744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 May 2011 15:41:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p49Cf5E2075217; Mon, 9 May 2011 15:41:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p49Cf501075216; Mon, 9 May 2011 15:41:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 9 May 2011 15:41:05 +0300 From: Kostik Belousov To: Max Brazhnikov Message-ID: <20110509124104.GF48734@deviant.kiev.zoral.com.ua> References: <201105091240.57785.makc@issp.ac.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ylzTCAJcNegswXN2" Content-Disposition: inline In-Reply-To: <201105091240.57785.makc@issp.ac.ru> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_20, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org Subject: Re: automoc4 processes lock again X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 13:02:08 -0000 --ylzTCAJcNegswXN2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 09, 2011 at 12:40:56PM +0400, Max Brazhnikov wrote: > Hi, >=20 > 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. >=20 > # ps | grep automoc > 18636 3 IN+ 0:00.02 /usr/local/bin/automoc4 /usr/obj/usr/local/tind= erbox/portstrees/FreeBSD/ports/x11/kdelibs4/work/kdelibs-4.6.3/build/kde3su= pport/ > 18640 3 IN+ 0:00.00 /usr/local/bin/automoc4 /usr/obj/usr/local/tind= erbox/portstrees/FreeBSD/ports/x11/kdelibs4/work/kdelibs-4.6.3/build/kde3su= pport/ >=20 > # gdb automoc4 18636 =2E.. > Reading symbols from /lib/libthr.so.3...done. > [New Thread 801c0ae40 (LWP 100660/automoc4)] > [New Thread 801c041c0 (LWP 100590/initial thread)] =2E.. > [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=3D0x800b196e0) at io= /qprocess_unix.cpp:245 > #2 0x0000000800749bde in QThreadPrivate::start (arg=3D0x800b196e0) at th= read/qthread_unix.cpp:320 > #3 0x00000008017985e1 in thread_start (curthread=3D0x801c0ae40) 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 >=20 > # gdb automoc4 18640 =2E.. > 0x00000008017a24cc in _umtx_op_err () at /usr/freebsd/8/src/lib/libthr/ar= ch/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/libth= r/arch/amd64/amd64/_umtx_op_err.S:37 > #1 0x00000008017a21bc in __thr_umutex_lock (mtx=3D0x8018a7380, id=3D1005= 90) at /usr/freebsd/8/src/lib/libthr/thread/thr_umtx.c:58 > #2 0x000000080179d04a in init_static (thread=3D0x801c041c0, mutex=3D0x80= 1166c78) at thr_umtx.h:88 > #3 0x000000080179d7ad in __pthread_mutex_lock (mutex=3D0x801166c78) at /= usr/freebsd/8/src/lib/libthr/thread/thr_mutex.c:441 > #4 0x000000080104b21e in _flockfile (fp=3D0x801166be0) at /usr/freebsd/8= /src/lib/libc/stdio/_flock_stub.c:70 > #5 0x0000000801021515 in fileno (fp=3D0x801166be0) at /usr/freebsd/8/src= /lib/libc/stdio/fileno.c:52 > #6 0x000000080084f109 in QProcessPrivate::execChild (this=3D0x801c51600,= workingDir=3D0x0, path=3D0x0, argv=3D0x801c5b7c0, envp=3D0x0) at io/qproce= ss_unix.cpp:712 > #7 0x0000000800851fc3 in QProcessPrivate::startProcess (this=3D0x801c516= 00) at io/qprocess_unix.cpp:665 > #8 0x0000000800802248 in QProcess::start (this=3D0x7fffffffcd10, program= =3D@0x7fffffffd8f8, arguments=3D@0x7fffffffcd00, mode=3D@0x7fffffffcd20) > at io/qprocess.cpp:1960 > #9 0x000000000040acd2 in AutoMoc::echoColor (this=3D0x7fffffffd8d0, msg= =3D@0x7fffffffce80) > at /usr/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc= .cpp:73 > #10 0x000000000040517c in AutoMoc::generateMoc (this=3D0x7fffffffd8d0, so= urceFile=3D@0x801c0f910, mocFileName=3D@0x801c0f918) > at /usr/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc= .cpp:569 > #11 0x0000000000408011 in AutoMoc::run (this=3D0x7fffffffd8d0) at /usr/ob= j/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:470 > #12 0x0000000000409135 in main (argc=3D6, argv=3D0x7fffffffd9a8) 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. --ylzTCAJcNegswXN2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3H4OAACgkQC3+MBN1Mb4hmmACg0vewlw1L/I1QfdnvsDUgZEIg 4cAAoJjppVwyjVgAN2Ch9rz3kCJSvIDv =qn3v -----END PGP SIGNATURE----- --ylzTCAJcNegswXN2--