Hmmm. Maybe this mail should have been sent to xen-devel instead, I''m retrying - sorry for the extra noice :-) Hello! I''m using Xen-unstable updated a few days ago, and I''m trying to debug an OS which I''m porting to Xen. I''m using the gdbserver to debug domU, and while this works fine I''m wondering if it is possible to have the debugger catch the domain crashes, i.e., if I crash the domain it would be nice if I could check the backtrace etc from within GDB. Is this possible? -- // Simon _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> I''m using Xen-unstable updated a few days ago, and I''m trying > to debug an OS which I''m porting to Xen. I''m using the > gdbserver to debug domU, and while this works fine I''m > wondering if it is possible to have the debugger catch the > domain crashes, i.e., if I crash the domain it would be nice > if I could check the backtrace etc from within GDB. > > Is this possible?"on_crash = preserve" should keep the domain hanging around -- I''d imagine you''d be able to get gdb to give you a backtrace from there. Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 2005-11-16, 10:42, Ian Pratt wrote:> > I''m using Xen-unstable updated a few days ago, and I''m trying > > to debug an OS which I''m porting to Xen. I''m using the > > gdbserver to debug domU, and while this works fine I''m > > wondering if it is possible to have the debugger catch the > > domain crashes, i.e., if I crash the domain it would be nice > > if I could check the backtrace etc from within GDB. > > > > Is this possible? > > "on_crash = preserve" should keep the domain hanging around -- I''d > imagine you''d be able to get gdb to give you a backtrace from there.Ah, I see. However, I tried adding that to the domain config, and the crashed domain is preserved: [ska@cb mini-os]$ sudo xm list Name ID Mem(MiB) VCPUs State Time(s) Domain-0 0 64 1 r----- 1121.3 test 56 32 1 --p-c- 0.1 and I can also attach the gdbserver to the domain (with gdbserver-xen localhost:9999 --attach 56), but when I try to attach to the gdbserver with GDB I only get (gdb) target remote localhost:9999 Remote debugging using localhost:9999 Couldn''t establish connection to remote target Remote communication error: Connection reset by peer. and the gdbserver then exits with Remote debugging from host 127.0.0.1 Child exited with status 0 GDBserver exiting . Debugging works fine if I attach with the domain paused on startup. I''ve tried both gdb 6.2.1 and Debian Sarge''s 6.3 version and both exhibit the same behaviour. -- // Simon _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > "on_crash = preserve" should keep the domain hanging around -- I''d > > imagine you''d be able to get gdb to give you a backtrace from there. > > Ah, I see. However, I tried adding that to the domain config, > and the crashed domain is preserved: > > [ska@cb mini-os]$ sudo xm list > Name ID Mem(MiB) VCPUs State Time(s) > Domain-0 0 64 1 r----- 1121.3 > test 56 32 1 --p-c- 0.1 > > and I can also attach the gdbserver to the domain (with gdbserver-xen > localhost:9999 --attach 56), but when I try to attach to the > gdbserver with GDB I only get > > (gdb) target remote localhost:9999 > Remote debugging using localhost:9999 > Couldn''t establish connection to remote target > Remote communication error: Connection reset by peer. > > and the gdbserver then exits with > > Remote debugging from host 127.0.0.1 > Child exited with status 0 > GDBserver exiting > > . Debugging works fine if I attach with the domain paused on > startup. I''ve tried both gdb 6.2.1 and Debian Sarge''s 6.3 > version and both exhibit the same behaviour.This sounds like gdbserver getting confused about the crashed domain. Perhaps Kip can suggest a fix... Best, Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 11/16/05, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:> > > > > "on_crash = preserve" should keep the domain hanging around -- I'd > > > imagine you'd be able to get gdb to give you a backtrace from there. > > > > Ah, I see. However, I tried adding that to the domain config, > > and the crashed domain is preserved: > > > > [ska@cb mini-os]$ sudo xm list > > Name ID Mem(MiB) VCPUs State Time(s) > > Domain-0 0 64 1 r----- 1121.3 > > test 56 32 1 --p-c- 0.1 > > > > and I can also attach the gdbserver to the domain (with gdbserver-xen > > localhost:9999 --attach 56), but when I try to attach to the > > gdbserver with GDB I only get > > > > (gdb) target remote localhost:9999 > > Remote debugging using localhost:9999 > > Couldn't establish connection to remote target > > Remote communication error: Connection reset by peer. > > > > and the gdbserver then exits with > > > > Remote debugging from host 127.0.0.1 <http://127.0.0.1> > > Child exited with status 0 > > GDBserver exiting > > > > . Debugging works fine if I attach with the domain paused on > > startup. I've tried both gdb 6.2.1 and Debian Sarge's 6.3 > > version and both exhibit the same behaviour. > > This sounds like gdbserver getting confused about the crashed domain. > Perhaps Kip can suggest a fix... >There are 2 possibilities, either one of the hypercalls used to query the state of domain is returning information that gdbserver doesn't understand / considers invalid or you've run off your stack. I wouldn't expect it to handle the latter with so little grace - but I haven't dealt with that condition in a long time. Could you please try calling the shutdown/crash hypercall from some point where you are in a known good state to try and see if it works there? That would determine whether or not what you're seeing is an artifact of how the domain crashed. If that fails then I can reproduce it here and check in a fix when I submit my patch for SMP support. -Kip _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 2005-11-16, 09:23, Kip Macy wrote:> On 11/16/05, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote: > > > > > > > > > > (gdb) target remote localhost:9999 > > > Remote debugging using localhost:9999 > > > Couldn''t establish connection to remote target > > > Remote communication error: Connection reset by peer. > > > > > > and the gdbserver then exits with > > > > > > Remote debugging from host 127.0.0.1 <http://127.0.0.1> > > > Child exited with status 0 > > > GDBserver exiting > > > > This sounds like gdbserver getting confused about the crashed domain. > > Perhaps Kip can suggest a fix... > > > > There are 2 possibilities, either one of the hypercalls used to query the > state of domain is returning information that gdbserver doesn''t understand / > considers invalid or you''ve run off your stack. I wouldn''t expect it to > handle the latter with so little grace - but I haven''t dealt with that > condition in a long time.Well, the stack should have been OK during the crashes (mostly things like dereferencing NULL-pointers).> Could you please try calling the shutdown/crash hypercall from some point > where you are in a known good state to try and see if it works there? That > would determine whether or not what you''re seeing is an artifact of how the > domain crashed. If that fails then I can reproduce it here and check in a > fix when I submit my patch for SMP support.I tried running HYPERVISOR_sched_op(SCHEDOP_shutdown, SHUTDOWN_crash); and attach the debugger to the domain with the same results as before. Thanks for the help, attaching to the crashed domain would be very helpful! -- // Simon _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> I tried running > > HYPERVISOR_sched_op(SCHEDOP_shutdown, SHUTDOWN_crash); > > and attach the debugger to the domain with the same results as before. > > > Thanks for the help, attaching to the crashed domain would be very > helpful! > >So it is definitely a Xen - gdbserver interaction issue. I'll let you know what I find. I probably won't have any sort of fix until the weekend. -Kip _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
See the changes to linux-xen-low.c in my latest patch. Sorry for not getting
to this sooner.
-Kip
On 11/16/05, Kip Macy <kip.macy@gmail.com> wrote:>
>
> I tried running
> >
> > HYPERVISOR_sched_op(SCHEDOP_shutdown, SHUTDOWN_crash);
> >
> > and attach the debugger to the domain with the same results as before.
> >
> >
> > Thanks for the help, attaching to the crashed domain would be very
> > helpful!
> >
> >
> So it is definitely a Xen - gdbserver interaction issue. I'll let you
know
> what I find. I probably won't have any sort of fix until the weekend.
>
>
> -Kip
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel