From grog@lemis.com  Tue Feb 15 00:29:54 2005
Return-Path: <grog@lemis.com>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 019C816A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 15 Feb 2005 00:29:54 +0000 (GMT)
Received: from blackwater.lemis.com (wantadilla.lemis.com [192.109.197.135])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 7CF5843D3F
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 15 Feb 2005 00:29:52 +0000 (GMT)
	(envelope-from grog@lemis.com)
Received: by blackwater.lemis.com (Postfix, from userid 1004)
	id 9201C8564F; Tue, 15 Feb 2005 10:59:50 +1030 (CST)
Message-Id: <20050215002950.9201C8564F@blackwater.lemis.com>
Date: Tue, 15 Feb 2005 10:59:50 +1030 (CST)
From: Greg 'groggy' Lehey <grog@lemis.com>
Reply-To: Greg 'groggy' Lehey <grog@lemis.com>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: Conditional breakpoints hang on SMP machines
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         77537
>Category:       kern
>Synopsis:       [smp] [hang] Conditional breakpoints hang on SMP machines
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Feb 15 00:30:26 GMT 2005
>Closed-Date:    Fri Jan 18 08:13:37 UTC 2008
>Last-Modified:  Fri Jan 18 08:13:37 UTC 2008
>Originator:     Greg 'groggy' Lehey
>Release:        FreeBSD 6.0-CURRENT i386
>Organization:
Rocksoft Ltd
>Environment:
System: FreeBSD quartet.lemis.com 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Mon Feb 14 09:38:49 CST 2005     grog@quartet.lemis.com:/src/FreeBSD/6-CURRENT/src/sys/i386/compile/QUARTET  i386

	Kernels built in mid-December 2004 and mid-February 2005
	exhibit this problem.

>Description:

	During a normal user-level debugging session, I set a
        conditional breakpoint that should run about 125,000 times
        before being hit.  When I did this, it stopped after a while,
        though: the gdb process hung in a WAIT state, repeatedly.

 	I then ran it under ktrace and found that it stopped with:

	 12325 gdb      CALL  ptrace(12,0x3026,0xbfbfd5e0,0)
	 12325 gdb      RET   ptrace 0
	 12325 gdb      CALL  ptrace(PT_STEP,0x3026,0x1,0)
	 12325 gdb      RET   ptrace 0
	 12325 gdb      CALL  wait4(0xffffffff,0xbfbfd808,0,0)

        This is the same sequence that repeats itself thousands of
        times in the trace: it should continue with

	 12325 gdb      RET   wait4 12326/0x3026
	 12325 gdb      CALL  kill(0x3026,0)
	 12325 gdb      RET   kill 0
	 12325 gdb      CALL  ptrace(PT_GETREGS,0x3026,0xbfbfd5c0,0)

        But it didn't: it hung.  I originally ran with a 6-CURRENT of
        mid-December 2005, but upgraded to 6-CURRENT as of 14 February
        2005 and confirmed that the problem remains.
	
>How-To-Repeat:
	As described above.
>Fix:

	Not currently known.  A workaround appears to be to disable
	all except one CPU with sysctl -w machdep.hlt_cpus=14 (this is
	a 4 processor machine).  This also confirms my suspicion that
	it's a race condition.

	If somebody will give me a few clues about where to look, I'm
	happy to take a look at this myself.
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: remko 
State-Changed-When: Sun Dec 9 13:25:39 UTC 2007 
State-Changed-Why:  
Hey Greg, is this still a problem for RELENG_7 ? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=77537 
State-Changed-From-To: feedback->closed 
State-Changed-By: remko 
State-Changed-When: Fri Jan 18 08:13:37 UTC 2008 
State-Changed-Why:  
Feedback timeout. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=77537 
>Unformatted:
