Race condition in debugger?

[Greg 'groggy' Lehey]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20050214/077e2877/attachment.bin