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.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:28 UTC