Date:	Fri, 19 Sep 2008 15:35:44 +0200
From:	Denis Joseph Barrow <D.Barow@...ion.com>
To:	Jason Wessel <jason.wessel@...driver.com>
CC:	KGDB Mailing List <kgdb-bugreport@...ts.sourceforge.net>,
	linux-kernel@...r.kernel.org, gareth@...inux.com,
	markus.t.metzger@...el.com
Subject: Re: getting false SIGTRAP breakpoints in kernel i.e. kernel hung
 unless gdb remotely attached on x86 & cont is issued

Sorry sorry Jason,
Better wipe the cobwebs gathering in my brain.
I just realised that your program is behaving perfectly.
The code I was testing will suspend in the read syscall forever
because it has no bytes to read,
I now also tested it with code that doesn't suspend & it works
perfectly.

The patch gets my full blessing even if my blessing is unimportant.

Jason Wessel wrote:
> Denis Joseph Barrow wrote:
>> Hi Jason,
>> Sorry for nitpicking & a big thanks for your patch.
>> While this patch stops the big problem, the kernel halting, gdb
>> debugging the userland code still doesn't behave correctly
>> now. Trying to stepi over a sysenter call in gdb doesn't return
>> to the gdb debugger ctrl-c in the debugger still works however.
>> Some code probably needs to be also fixed in arch/x86/kernel/ptrace.c
>> or ideally the generic kernel/ptrace.c, seeing as this works
>> with gdb on a normal kernel it's not a gdb issue even if
>> it can be kludge fixed there.
>> I'm running GNU gdb 6.8-debian from ubuntu 8.04 hardy heron
>>
>>
> 
> The patch I sent is not yet included the kgdb stream because I was
> waiting for further comment.  I do not see any issues however in the
> case that you describe, so I will describe how I tested it and then
> perhaps you can explain further the case that does not work.
> 
> Given that I still had your test program, I used it to set a
> breakpoint at read(), after performing an attach as you described
> previous with attaching to the running process.  At this point kgdboc
> is loaded and configured.
> 
> gdb commands:
> 
> att PID_OF_randsleep
> break read
> continue
> 
> At this point to hit the breakpoint, I had to type some input on the
> ttyS0 which randsleep where randsleep was connected.  At that point I
> was able to step the system call with enough "si" commands.  In the
> example shown below I did have to provide some more input after the
> "si" for address 0xffffe419 so that the system call would come out of
> the sleep state because it happened to be a blocking read.
> 
> Example:
> (gdb) continue
> Continuing.
> 
> Breakpoint 1, 0x08056b30 in read ()
> (gdb) si
> 0x08056b38 in read ()
> (gdb)
> 0x08056b3a in __read_nocancel ()
> (gdb)
> 0x08056b3b in __read_nocancel ()
> (gdb)
> 0x08056b3f in __read_nocancel ()
> (gdb)
> 0x08056b43 in __read_nocancel ()
> (gdb)
> 0x08056b47 in __read_nocancel ()
> (gdb)
> 0x08056b4c in __read_nocancel ()
> (gdb)
> 0xffffe414 in __kernel_vsyscall ()
> (gdb) disas $pc $pc+8
> Dump of assembler code from 0xffffe414 to 0xffffe41c:
> 0xffffe414 <__kernel_vsyscall+0>:       push   %ecx
> 0xffffe415 <__kernel_vsyscall+1>:       push   %edx
> 0xffffe416 <__kernel_vsyscall+2>:       push   %ebp
> 0xffffe417 <__kernel_vsyscall+3>:       mov    %esp,%ebp
> 0xffffe419 <__kernel_vsyscall+5>:       sysenter
> 0xffffe41b <__kernel_vsyscall+7>:       nop  
> End of assembler dump.
> (gdb) si
> 0xffffe415 in __kernel_vsyscall ()
> (gdb)
> 0xffffe416 in __kernel_vsyscall ()
> (gdb)
> 0xffffe417 in __kernel_vsyscall ()
> (gdb)
> 0xffffe419 in __kernel_vsyscall ()
> (gdb)
> 0xffffe424 in __kernel_vsyscall ()
> (gdb)
> 
> 
> At least this case appears to work fine with or without kgdb
> loaded.  Perhaps you have a different case you can describe?
> 
> Thanks,
> Jason.
> 
> 
> 
> 
> 


-- 
best regards,
D.J. Barrow
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists