From owner-freebsd-stable@FreeBSD.ORG  Mon Aug 11 10:31:17 2008
Return-Path: <owner-freebsd-stable@FreeBSD.ORG>
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 5BFC61065673
	for <freebsd-stable@freebsd.org>; Mon, 11 Aug 2008 10:31:17 +0000 (UTC)
	(envelope-from kris@FreeBSD.org)
Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28])
	by mx1.freebsd.org (Postfix) with ESMTP id D2DBE8FC27;
	Mon, 11 Aug 2008 10:31:14 +0000 (UTC)
	(envelope-from kris@FreeBSD.org)
Message-ID: <48A014EF.2090108@FreeBSD.org>
Date: Mon, 11 Aug 2008 12:31:11 +0200
From: Kris Kennaway <kris@FreeBSD.org>
User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707)
MIME-Version: 1.0
To: Borja Marcos <BORJAMAR@SARENET.ES>
References: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES>
In-Reply-To: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-stable@freebsd.org
Subject: Re: umtxn and Apache 2.2
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>, 
	<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
	<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Aug 2008 10:31:17 -0000

Borja Marcos wrote:
> Hello,
> 
> I'm running a server with FreeBSD 7-STABLE as of August 8, Apache 2.2 
> with mpm/worker and threads support, and PHP 5.2.6.
> 
> Everything works like a charm, but I see that Apache is leaking 
> processes that get stuck in umtxn state.
> 
> This graph shows it pretty well (I upgraded the system last Friday).
> 
> Attaching gdb to one of the stray processes and doing a backtrace of the 
> active thread, I see this:
> 
> [Switching to Thread 0x8705900 (LWP 100647)]
> 0x382a8789 in _umtx_op () from /lib/libc.so.7
> (gdb) bt
> #0  0x382a8789 in _umtx_op () from /lib/libc.so.7
> #1  0x3825fe0d in __error () from /lib/libthr.so.3
> #2  0x084b2b80 in ?? ()
> #3  0x00000005 in ?? ()
> #4  0x00000000 in ?? ()
> #5  0x00000000 in ?? ()
> #6  0x00000000 in ?? ()
> #7  0x38261914 in ?? () from /lib/libthr.so.3
> #8  0xbe0e5ca8 in ?? ()
> #9  0x3825b818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3
> Previous frame identical to this frame (corrupt stack?)
> (gdb)
> 
> and it seems all the threads in the process are stuck here. Any ideas?

This trace doesn't show anything really.  You need to recompile the 
binaries with debugging symbols as well.

Kris