| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] [Fwd: [Xen-users] Can't debug Win32 app under Xen, but can u
[Forwarded from xen-users: it was suggested that xen-devel would be a
more appropriate list]
Hi everyone,
This is related to my earlier thread which listed some of the issues I
was having running WinXP under Xen on an AMD X2 3800+ processor, but now
focuses on my one remaining issue: being unable to debug MingW
applications in Xen.
My main OS is Ubuntu 6.06 (32-bit) and I have been using WinXP under Xen
for Win32 application development. A few days ago I came across a C
application that was segfaulting; under Xen 3.0.2 this would crash the
entire dom and cause it to reboot. Taking advice from this list, I
downloaded and compiled the xen-3.0.3-testing.hg repository at
http://xenbits.xensource.com/ and attempted to debug the application
again.
After this upgrade, the segfault in the application did not crash the
dom anymore, but the debugger was unable to attach to the process. Here
is the output from a session debugging my segfaulting program using
MingW's gdb for Win32:
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".
(gdb) file ../loader/pgsql2shp
Reading symbols from C:\msys\1.0\home\mca\postgis\pg82\postgis-1.1.4
\regress/../loader/pgsql2shp.exe...done.
(gdb) set args -f /tmp/pgis_reg_3364/dumper postgis_reg loadedshp
(gdb) run
Starting program: C:\msys\1.0\home\mca\postgis\pg82\postgis-1.1.4
\regress/../loader/pgsql2shp.exe -f /tmp/pgis_reg_3364/dumper
postgis_reg loadedshp
Program received signal SIGTRAP, Trace/breakpoint trap.
0x7c901230 in ntdll!DbgUiConnectToDbg () from ntdll.dll
(gdb) bt
#0 0x7c901230 in ntdll!DbgUiConnectToDbg () from ntdll.dll
#1 0x7c93edc0 in ntdll!RtlInsertElementGenericTableAvl () from
ntdll.dll
#2 0x7ffdf000 in ?? ()
#3 0x7ffd9000 in ?? ()
#4 0x00000000 in ?? () from
#5 0x00000030 in ?? ()
#6 0x00000000 in ?? () from
#7 0x00000000 in ?? () from
#8 0x00000000 in ?? () from
#9 0x00000000 in ?? () from
#10 0x00000000 in ?? () from
#11 0x00000000 in ?? () from
#12 0x00000000 in ?? () from
#13 0x00000000 in ?? () from
#14 0x00000000 in ?? () from
#15 0x00000000 in ?? () from
#16 0x00000000 in ?? () from
#17 0x00000030 in ?? ()
#18 0x00000000 in ?? () from
#19 0x00000000 in ?? () from
#20 0x00000000 in ?? () from
#21 0x00000000 in ?? () from
#22 0x00000000 in ?? () from
#23 0x00000000 in ?? () from
#24 0x00000000 in ?? () from
#25 0x00000000 in ?? () from
#26 0x00000000 in ?? () from
#27 0x00000000 in ?? () from
#28 0x00000000 in ?? () from
#29 0x00000000 in ?? () from
#30 0x001a0018 in ?? ()
#31 0x7c922538 in ntdll!RtlRealSuccessor () from ntdll.dll
#32 0x00000018 in ?? ()
#33 0x000007f4 in ?? ()
#34 0x0022fbc0 in ?? ()
#35 0x00000040 in ?? ()
#36 0x00000000 in ?? () from
#37 0x00000000 in ?? () from
#38 0x0022fd30 in ?? ()
#39 0x00020000 in ?? ()
#40 0x0022fce0 in ?? ()
#41 0x001a0018 in ?? ()
#42 0x7c92250c in ntdll!RtlRealSuccessor () from ntdll.dll
#43 0x001a0019 in ?? ()
#44 0x7c9223bc in ntdll!RtlRealSuccessor () from ntdll.dll
#45 0x00160014 in ?? ()
#46 0x7ffe0030 in ?? ()
#47 0x00140013 in ?? ()
#48 0x7c9223d8 in ntdll!RtlRealSuccessor () from ntdll.dll
#49 0x01060104 in ?? ()
#50 0x00020784 in ?? ()
#51 0x00960094 in ?? ()
#52 0x00241ea0 in ?? ()
#53 0x02080028 in ?? ()
#54 0x7c97dee8 in ntdll!NtAccessCheckByTypeResultListAndAuditAlarm ()
#55 0x00400080 in ?? ()
#56 0x008a0088 in ?? ()
#57 0x000206f8 in ?? ()
#58 0x02080070 in ?? ()
#59 0x00020290 in ?? ()
#60 0x00000002 in ?? ()
#61 0x000007f0 in ?? ()
#62 0x00000000 in ?? () from
#63 0x01000000 in ?? ()
#64 0x7c817443 in RegisterWaitForInputIdle ()
from C:\WINDOWS\system32\kernel32.dll
#65 0x00341eb4 in ?? ()
#66 0x00000020 in ?? ()
#67 0x0022fbf0 in ?? ()
#68 0x00000000 in ?? () from
#69 0x00010352 in ?? ()
#70 0x003f003f in ?? ()
#71 0x003f003f in ?? ()
#72 0x00000000 in ?? () from
#73 0x00000000 in ?? () from
#74 0x00000000 in ?? () from
#75 0x00010000 in ?? ()
#76 0x7ffc101c in ?? ()
#77 0x7ffc1422 in ?? ()
#78 0x7ffc141e in ?? ()
#79 0x00000000 in ?? () from
#80 0x000104e4 in ?? ()
#81 0x003f003f in ?? ()
#82 0x003f003f in ?? ()
#83 0x00000000 in ?? () from
#84 0x00000000 in ?? () from
#85 0x00000000 in ?? () from
#86 0x00000000 in ?? () from
#87 0x7ffb001c in ?? ()
#88 0x7ffb0222 in ?? ()
#89 0x7ffb021e in ?? ()
#90 0x00000000 in ?? () from
#91 0x7ffd2004 in ?? ()
#92 0x7ffd2de6 in ?? ()
#93 0x00004afb in ?? ()
#94 0x0022fd1c in ?? ()
#95 0x7c921639 in ntdll!RtlMapGenericMask () from ntdll.dll
#96 0x0022fd30 in ?? ()
#97 0x7c900000 in ?? ()
#98 0x0022fce0 in ?? ()
#99 0x7c90ee00 in strchr () from ntdll.dll
#100 0x7c91a100 in ntdll!RtlDosSearchPath_Ustr () from ntdll.dll
#101 0x0022fd30 in ?? ()
#102 0x00000000 in ?? () from
#103 0x7ffd9000 in ?? ()
#104 0x00000000 in ?? () from
#105 0x00000000 in ?? () from
#106 0x00000000 in ?? () from
#107 0x00000000 in ?? () from
#108 0x00000000 in ?? () from
#109 0x7c91a120 in ntdll!RtlDosSearchPath_Ustr () from ntdll.dll
#110 0x0022fd30 in ?? ()
#111 0x00000000 in ?? () from
#112 0x7ffd9000 in ?? ()
#113 0x008a0088 in ?? ()
#114 0x000206f8 in ?? ()
#115 0x00000000 in ?? () from
#116 0x7ffdf000 in ?? ()
#117 0x7c90ee00 in strchr () from ntdll.dll
#118 0x7c91a100 in ntdll!RtlDosSearchPath_Ustr () from ntdll.dll
#119 0xffffffff in ?? ()
#120 0x00000000 in ?? () from
#121 0x0092284b in ?? ()
#122 0x0022fcb0 in ?? ()
#123 0x7c922c66 in ntdll!RtlInitString () from ntdll.dll
#124 0xffffffff in ?? ()
#125 0x7c90ee18 in strchr () from ntdll.dll
#126 0x7c918e00 in ntdll!RtlUnicodeStringToOemSize () from ntdll.dll
#127 0x00000001 in ?? ()
#128 0x00000000 in ?? () from
#129 0x7c90eac7 in ntdll!LdrCreateOutOfProcessImage () from ntdll.dll
#130 0x0022fd30 in ?? ()
#131 0x7c900000 in ?? ()
#132 0x00000000 in ?? () from
#133 0x00010017 in ?? ()
#134 0x00000000 in ?? () from
#135 0x00000000 in ?? () from
#136 0x00000000 in ?? () from
#137 0x00000000 in ?? () from
#138 0x00000000 in ?? () from
#139 0x00000000 in ?? () from
#140 0xf6035ab8 in ?? ()
#141 0xf76f84ba in ?? ()
#142 0x8637b008 in ?? ()
#143 0x86432840 in ?? ()
#144 0xf76f84c8 in ?? ()
#145 0x86432850 in ?? ()
#146 0x86795808 in ?? ()
#147 0x863bf7c0 in ?? ()
#148 0x00000001 in ?? ()
#149 0x00000000 in ?? () from
#150 0x00000000 in ?? () from
#151 0x00000000 in ?? () from
#152 0x00000000 in ?? () from
#153 0x00000000 in ?? () from
#154 0x00000000 in ?? () from
#155 0x86000001 in ?? ()
#156 0x00000000 in ?? () from
#157 0x00000000 in ?? () from
#158 0x00000000 in ?? () from
#159 0x00000001 in ?? ()
#160 0xf6035a4c in ?? ()
#161 0x00000004 in ?? ()
#162 0x863bf7c0 in ?? ()
#163 0x867a1100 in ?? ()
#164 0xe1361850 in ?? ()
#165 0x86798868 in ?? ()
#166 0x00000000 in ?? () from
#167 0x00000000 in ?? () from
#168 0x00000000 in ?? () from
#169 0x00000038 in ?? ()
#170 0x00000023 in ?? ()
#171 0x00000023 in ?? ()
#172 0x00000000 in ?? () from
#173 0x00000000 in ?? () from
#174 0x7ffd9000 in ?? ()
#175 0x00000000 in ?? () from
#176 0x00000000 in ?? () from
#177 0x00401220 in __mingw_CRTStartup ()
Notice that the signal caught is a SIGTRAP and repeatedly pressing "c"
to attempt to get the application to continue causes gdb to remain in
"ntdll!DbgUiConnectToDbg" indefinitely.
Out of curiosity, I then loaded the same HD image into qemu 0.8.2 to
see if qemu would allow me to debug the application. Here is the output
of the qemu gdb session:
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".
(gdb) file ../loader/pgsql2shp
Reading symbols from C:\msys\1.0\home\mca\postgis\pg82\postgis-1.1.4
\regress/../loader/pgsql2shp.exe...done.
(gdb) set args -f /tmp/pgis_reg_4060/dumper postgis_reg loadedshp
(gdb) run
Starting program: C:\msys\1.0\home\mca\postgis\pg82\postgis-1.1.4
\regress/../loader/pgsql2shp.exe -f /tmp/pgis_reg_4060/dumper
postgis_reg loadedshp
Initializing...
Program received signal SIGSEGV, Segmentation fault.
0x63512c1c in ?? ()
(gdb) bt
#0 0x63512c1c in ?? ()
#1 0x0040c69c in _fu8__PQntuples () at pgsql2shp.c:2502
#2 0x00408481 in main (ARGC=5, ARGV=0x3d2750) at pgsql2shp.c:243
Compared to the Xen session above, the signal is now SIGSEGV and gdb can
connect to the application and debug it without any problems.
Unfortunately swapping between qemu/Xen is not really an option, as
everytime I switch I need to ring MS to get my copy of XP reactivated as
it detects too many hardware changes!!!
Hopefully people are still with me at this point :) So my questions are:
1) Why is the behaviour of gdb under Xen different from that
under qemu? Is it to do with the way gdb interacts with the
processor when debugging?
2) Can this behaviour be fixed? This is the only barrier
preventing me from doing all of my development work under Xen.
Many thanks,
Mark.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
| <Prev in Thread] |
Current Thread |
[Next in Thread> |
- [Xen-devel] [Fwd: [Xen-users] Can't debug Win32 app under Xen, but can under qemu (gdb)],
Mark Cave-Ayland <=
|
|
|
| |
|
Home