From owner-freebsd-stable@FreeBSD.ORG Mon May 9 15:39:51 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 627621065673 for ; Mon, 9 May 2011 15:39:51 +0000 (UTC) (envelope-from makc@issp.ac.ru) Received: from mail.issp.ac.ru (mail.issp.ac.ru [77.236.34.3]) by mx1.freebsd.org (Postfix) with ESMTP id D07F68FC15 for ; Mon, 9 May 2011 15:39:50 +0000 (UTC) Received: from [62.63.90.99] [62.63.90.99:19887] (HELO/EHLO luna.dio.ru, authenticated with PLAIN) by mail.issp.ac.ru with ESMTP/inet id p49FeID8031261 (using TLSv1/SSLv3, with cipher DHE-RSA-AES256-SHA (256 bits), verified NO) Mon, 9 May 2011 19:40:18 +0400 (MSD) From: Max Brazhnikov Organization: ISSP RAS To: Kostik Belousov Date: Mon, 9 May 2011 19:39:46 +0400 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.2; amd64; ; ) References: <201105091240.57785.makc@issp.ac.ru> <20110509124104.GF48734@deviant.kiev.zoral.com.ua> In-Reply-To: <20110509124104.GF48734@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201105091939.47230.makc@issp.ac.ru> 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 15:39:51 -0000 On Mon, 9 May 2011 15:41:05 +0300, Kostik Belousov wrote: > 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 ? Here is backtraces from all threads http://people.freebsd.org/~makc/automoc4.bt 63373 is a parent now, 63374 is a child. There were no related changes in Qt4 and automoc4 sources, probably my update from 8.2-PRERELEASE to STABLE a week ago triggered the issue. > 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.