RE: [Xen-users] Issues running WinXP using hvmloader

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----Original Message-----
> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Mark Cave-Ayland
> Sent: 06 October 2006 10:38
> To: Petersson, Mats
> Cc: xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-users] Issues running WinXP using hvmloader
> 
> Hi Mats,
> 
> Thanks for your help so far with this. I took the plunge yesterday of
> using Mercurial to download the latest xen-3.0.3-testing.hg repository
> from http://xenbits.xensource.com/ and it looks as if things have
> definitely improved:
> 
> - WinXP doms now shutdown cleanly without leaving zombies
> - My PC no longer crashes when I do a "shutdown -h now"
> 
> I still can't start up a WinXP dom with "vcpus = 2" in the 
> configuration
> file at the moment; rather than crashing the dom like 3.0.2 did,
> 3.0.3-testing switches back to 1 CPU before loading. Trying 
> to alter the
> vcpus using "xm vcpu-set" doesn't change the vcpu value either.
> 
> The only other issue is that I still can't debug a program 
> using MingW's
> gdb under a WinXP running in a Xen dom, which I think may be 
> related to
> something in the WinXP debug API, or the way that Xen handles 
> segfaults.
> Here is the test program that I am using under MingW/msys:
> 
> 
> #include <stdlib.h>
> 
> int main()
> {
> char buffer[2];
> 
> printf("Hello World!");
> 
> strcpy(buffer, "This is a very long string designed to do bad 
> things");
> }
> 
> 
> If I run this under a Xen WinXP dom then WinXP crashes as expected,
> throwing up the normal MS crash dialog. Normally closing the crash
> dialog results in termination of the program that produced 
> it. Under Xen
> I find I have to manually terminate the crashed program by using Task
> Manager or invoking Ctrl-C from the console that launched it!

No clue why this would happen... 

> 
> The other issue is that gdb still can't attach to a program 
> to debug it;
> attempting to attach gdb to any process results in a SIGTRAP 
> in part of
> the debugging API and it is impossible to get past this point. The
> function where the SIGTRAP occurs is always the same, "ntdll!
> DbgUiConnectToDbg", no matter which process you try and 
> attach to. This
> makes me think that something in this function is raising an exception
> which is being incorrectly handled.
> 
> 
> $ gdb -p 500
> GNU gdb 6.3
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public 
> License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for
> details.
> This GDB was configured as "i686-pc-mingw32".
> Attaching to process 500
> error reading the process's file name: 5
> [Switching to thread 500.0x2e4]
> (gdb) bt
> #0  0x7c901230 in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32
> \ntdll.dll
> #1  0x7c9507a8 in ntdll!KiIntSystemCall () from C:\WINDOWS\system32
> \ntdll.dll
> #2  0x00000005 in ?? ()
> #3  0x00000004 in ?? ()
> #4  0x00000001 in ?? ()
> 
> ...etc...
> 
> 
> Any other thoughts?

Not really - it looks like a problem with reading the other process's
memory - why that should happen, I don't really know. 

Sorry to not be of much help here... 

--
Mats
> 
> 
> Kind regards,
> 
> Mark.
> 
> 
> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
> 
> 
> 



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users