| |
|
 |
|
 |
|
|
|
| |
|
|
xen-users
RE: [Xen-users] Issues running WinXP using hvmloader
> -----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
|
|
|
| |
|
Home