remote gdb failures in recent builds (last 6 months or so.)

[Julian Elischer]

Marcel Moolenaar wrote:
> On Dec 3, 2007, at 9:27 PM, Julian Elischer wrote:
> 
>> It's slowly been getting worse (across many pairs of machines) over 
>> the last few years. finally today it just doesn't work at all. I've 
>> used this pair of machines many times before. usually it takes "luck" 
>> to get synced up but once it's synced, it's solid.
> 
> How do you start the connection? I seem to recall that starting with
> the gdb client is not a good idea, because the gdb client will try
> a couple of commands first to see if the stub supports them. If the
> stub is not ready, then the gdb client may think the stub is not
> capable of certain features.
> 
> I typically have the kernel break into the GDB debugger first and
> then I start the gdb client...
> 

first the kernel panic'd then I was in kdb on the serial console (com1)
then I typed "gdb" followed by 's'. I'm not worried so much about the panic
as its an experimental kernel, but by not being able to debug it..


# panic: Bad tailq NEXT(0xd9f356f8->tqh_last) != NULL
cpuid = 1
KDB: enter: panic
[thread pid 19 tid 100037 ]
Stopped at      kdb_enter+0x32: leave
db> tr
Tracing pid 19 tid 100037 td 0xc5fabc60
kdb_enter(c076ae89,1,c074ea89,ee832c2c,1,...) at kdb_enter+0x32
panic(c074ea89,d9f356f8,c076c29e,1a3,25e,...) at panic+0x124
callout_reset(c08aa700,1,c0636140,0,c5feb000,c5fabc60,ee832c70,3,c08aa634,c08aa9
dummynet_task(0,1,c076f439,50,c61dec9c,...) at dummynet_task+0x332
taskqueue_run(c61dec80,c61dec9c,c0762a86,0,c0769a89,...) at taskqueue_run+0x10b
taskqueue_thread_loop(c08aa5f0,ee832d38,c07673b9,30c,c5fabc60,...) at taskqueue8
fork_exit(c05add90,c08aa5f0,ee832d38) at fork_exit+0x120
fork_trampoline() at fork_trampoline+0x8
--- trap 0, eip = 0, esp = 0xee832d70, ebp = 0 ---
db> gdb
Step to enter the remote GDB backend.
db>