double fault ...

double fault ...

[Gerd Knorr]

... happens with panics when compiled with debugging.
panic() calls debugger_trap_immediate(), which triggers
do_int3, which calls panic(), which recurses until the
stack is full => bang!

cheers,

  Gerd

-- 
#define printk(args...) fprintf(stderr, ## args)

Re: double fault ...

[Keir Fraser]

On 2 May 2005, at 15:51, Gerd Knorr wrote:

> ... happens with panics when compiled with debugging.
> panic() calls debugger_trap_immediate(), which triggers
> do_int3, which calls panic(), which recurses until the
> stack is full => bang!

You compile with crash_debug=y? The intention is that do_int3() will 
execute DEBUGGER_trap_fatal() before panic(), so you should enter the 
gdb stub rather than infinitely loop. How is that not occurring?

  -- Keir

Re: double fault ...

[Gerd Knorr]

On Mon, May 02, 2005 at 04:23:42PM +0100, Keir Fraser wrote:
> 
> On 2 May 2005, at 15:51, Gerd Knorr wrote:
> 
> >... happens with panics when compiled with debugging.
> >panic() calls debugger_trap_immediate(), which triggers
> >do_int3, which calls panic(), which recurses until the
> >stack is full => bang!
> 
> You compile with crash_debug=y?

Yes.  Mostly to get a xen binary without optimization and with full
debug info, so I can easily lookup stuff using
	"objdump -dS xen-syms | less +/<addr>".

> The intention is that do_int3() will execute DEBUGGER_trap_fatal()
> before panic(), so you should enter the gdb stub rather than
> infinitely loop. How is that not occurring?

I don't actually have a debugger attached, so DEBUGGER_trap_fatal
aka __trap_to_cdb() instantly returns.

  Gerd

-- 
#define printk(args...) fprintf(stderr, ## args)

Re: double fault ...

[Kip Macy]

It shouldn't matter - you can attach the debugger after crash.


			-Kip 

On Mon, 2 May 2005, Gerd Knorr wrote:

> On Mon, May 02, 2005 at 04:23:42PM +0100, Keir Fraser wrote:
> > 
> > On 2 May 2005, at 15:51, Gerd Knorr wrote:
> > 
> > >... happens with panics when compiled with debugging.
> > >panic() calls debugger_trap_immediate(), which triggers
> > >do_int3, which calls panic(), which recurses until the
> > >stack is full => bang!
> > 
> > You compile with crash_debug=y?
> 
> Yes.  Mostly to get a xen binary without optimization and with full
> debug info, so I can easily lookup stuff using
> 	"objdump -dS xen-syms | less +/<addr>".
> 
> > The intention is that do_int3() will execute DEBUGGER_trap_fatal()
> > before panic(), so you should enter the gdb stub rather than
> > infinitely loop. How is that not occurring?
> 
> I don't actually have a debugger attached, so DEBUGGER_trap_fatal
> aka __trap_to_cdb() instantly returns.
> 
>   Gerd
> 
> 

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: double fault ...

[Keir Fraser]

>> You compile with crash_debug=y?
>
> Yes.  Mostly to get a xen binary without optimization and with full
> debug info, so I can easily lookup stuff using
> 	"objdump -dS xen-syms | less +/<addr>".

Probably 'debug=y' should also cause -g compilation. I'll add that in.

I presume you do 'optimize=n' to turn off things like -O3?

>> The intention is that do_int3() will execute DEBUGGER_trap_fatal()
>> before panic(), so you should enter the gdb stub rather than
>> infinitely loop. How is that not occurring?
>
> I don't actually have a debugger attached, so DEBUGGER_trap_fatal
> aka __trap_to_cdb() instantly returns.

I see. I'll check in a fix.

Thanks!

  -- Keir

Re: double fault ...

[Gerd Knorr]

On Mon, May 02, 2005 at 05:07:28PM +0100, Keir Fraser wrote:
> 
> >>You compile with crash_debug=y?
> >
> >Yes.  Mostly to get a xen binary without optimization and with full
> >debug info, so I can easily lookup stuff using
> >	"objdump -dS xen-syms | less +/<addr>".
> 
> Probably 'debug=y' should also cause -g compilation. I'll add that in.

Thanks.

> I presume you do 'optimize=n' to turn off things like -O3?

Yes, "make debug=y crash_debug=y optimize=n" is the command line.

  Gerd

-- 
#define printk(args...) fprintf(stderr, ## args)