From owner-freebsd-current@FreeBSD.ORG Mon Feb 14 01:42:24 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69A2D16A4CE for ; Mon, 14 Feb 2005 01:42:24 +0000 (GMT) Received: from blackwater.lemis.com (wantadilla.lemis.com [192.109.197.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id D593F43D2D for ; Mon, 14 Feb 2005 01:42:22 +0000 (GMT) (envelope-from grog@lemis.com) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 112F1858BB; Mon, 14 Feb 2005 12:12:18 +1030 (CST) Date: Mon, 14 Feb 2005 12:12:18 +1030 From: Greg 'groggy' Lehey To: FreeBSD current users Message-ID: <20050214014217.GB85932@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dTy3Mrz/UPE2dbVg" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Subject: Race condition in debugger? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2005 01:42:24 -0000 --dTy3Mrz/UPE2dbVg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I'm having some problems with userland gdb on recent -CURRENT builds: at some point it hangs. Specifically, I'm setting a conditional breakpoint like this: b Minsert_blockletpointer if I->inode_num == 0x1f0bb inode_num increments for 1, so I hit this breakpoint about 100,000 times. Or I should. What happens is that the debugger hangs at some point on the way. ktrace shows multiple copies of: 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) <-- stops here 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) When it hangs, it's at the call to wait4, as shown. It looks like the completion of the ptrace request isn't being reported back. This is a 4 way SMP box (Pentium II, FWIW). I've tried disabling SMP: # sysctl -w machdep.hlt_cpus=14 machdep.hlt_cpus: 0 -> 14 After that, it seems to work, but it's taking a while on this slow old box. Does anybody have any ideas or suggestions? I can't swear that things like this have ever worked for me, but they certainly don't on this morning's kernel, and they didn't on the previous one, done in mid-December last year. Greg -- See complete headers for address and phone numbers. --dTy3Mrz/UPE2dbVg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFCEAH5IubykFB6QiMRAo3uAJ48DX6nr0BY2C2LV7VNPp/3XK1I1QCgjzMd DPwG1rinTNqCCXaoKoWNVu0= =A6Gn -----END PGP SIGNATURE----- --dTy3Mrz/UPE2dbVg--