<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
I spoke too soon, alas.<br>5.2.6 Win32:<br><br>..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock<br> 0/0/0)<br>.<br><br>***<br>*** runtime error:<br>*** <*ASSERT*> failed.<br>*** file "..\src\runtime\common\RTCollector.m3", line 1073<br>***<br><br>Stack trace:<br> FP PC Procedure<br>--------- --------- -------------------------------<br>0xbf8f5f0 0x7531f4b3 CleanBetween + 0x48 in ..\src\runtime\common\RTCollector.m3<br>0xbf8f628 0x7531f326 CleanPage + 0x83 in ..\src\runtime\common\RTCollector.m3<br>0xbf8f658 0x7531ebca FinishThreadPages + 0xa2 in ..\src\runtime\common\RTCollector.m3<br>0xbf8f6a0 0x7531eae6 CollectSomeInStateZero + 0x5a3 in ..\src\runtime\common\RTCollector.m3<br>0xbf8f6b4 0x7531e507 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3<br>0xbf8f6cc 0x7531e084 CollectEnough + 0x9c in ..\src\runtime\common\RTCollector.m3<br>0xbf8f714 0x7532015c LongAlloc + 0x74 in ..\src\runtime\common\RTCollector.m3<br>0xbf8f74c 0x75320086 AllocTraced + 0x8a in ..\src\runtime\common\RTCollector.m3<br>0xbf8f790 0x75316fa4 GetOpenArray + 0x8e in ..\src\runtime\common\RTAllocator.m3<br>0xbf8f7c0 0x7531688a AllocateOpenArray + 0x2d in ..\src\runtime\common\RTAllocator.m3<br>......... ......... ... more frames ...<br><br><br>I should double check these results.<br>And then I'm afraid I'm tempted to try 3.6 (DEC release) and 4.1 (commercial release)...<br><br> - Jay<br><br><hr id="stopSpelling">From: jay.krell@cornell.edu<br>To: rcolebur@scires.com; m3devel@elegosoft.com<br>Subject: RE: [M3devel] results of threadtest program on Windows7<br>Date: Wed, 9 Mar 2011 20:10:37 +0000<br><br>
<meta http-equiv="Content-Type" content="text/html; charset=unicode">
<meta name="Generator" content="Microsoft SafeHTML">
<style>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Tahoma;}
</style>
5.2.6 seems to have no problem with the thread test, on Win32.<br>Now to either:<br> search for when the problems started.<br> and/or try replacing current ThreadWin32.m3 with 5.2.6 or vice versa<br><br> - Jay<br><br><hr id="ecxstopSpelling">From: jay.krell@cornell.edu<br>To: rcolebur@scires.com; m3devel@elegosoft.com<br>Subject: RE: [M3devel] results of threadtest program on Windows7<br>Date: Mon, 7 Mar 2011 06:58:45 +0000<br><br>
<style>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Tahoma;}
</style>
Hm.. I think the first change may not be advisable. There are multiple such address range walkers and the interface probably doesn't constrain the order they go on.<br>
So, instead, another change would be to touch every stack page at thread start, so that later walks going "out of order" won't trigger stack overflow exceptions.<br>
This has the side benefit of not needing the backend to learn about chkstk.<br>
<br>
<br>
That is, on Win32, stack pages must be touched in order from highest to lowest.<br>
That is, the first time a stack page is touched, it should be only one lower than the lowest stack page previously touched.<br>
Once some stack pages have been touched, they can later be touched in any order.<br>
Functions with more than a page of locals are supposed to touch all of their frame's pages.<br>
Otherwise function call's pushing a return address suffices.<br>
The Modula-3 backend doesn't do this.<br>
I've never seen this clearly documented, but it is clearly the intent of the C compiler's generated code.<br>
The C compiler generates a call to chkstk for functions with more than a page of locals, and chkstk touches a byte on each page.<br>
And chkstk and alloca are the same function.<br>
If this wasn't the case, the compiler could just inline subtraction.<br>
<br>
<br>
And any GC code that walks the stack could possible violate this, depending on what it uses for stack bounds.<br>
Currently it uses "accurate" bounds on Win32, and so is ok.<br>
<br>
<br>
- Jay<br> <br>
<hr id="ecxstopSpelling">
From: jay.krell@cornell.edu<br>To: rcolebur@scires.com; m3devel@elegosoft.com<br>Date: Mon, 7 Mar 2011 06:53:06 +0000<br>Subject: Re: [M3devel] results of threadtest program on Windows7<br><br>
<style>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Tahoma;}
</style>
I'm going to make one or two changes because of this.<br> <br> - Where we process memory in a range, I'm going to go in stack growth order instead from lowest address to highest. If we don't already.<br> Or possibly recieve a direction parameter and pass it as 1 everywhere except for -1 when processing Win32 stacks.<br> <br> <br> - On Win32 I'm going to process the "entire" stack, instead of just from the current stack pointer to the "initial" stack pointer (highest address).<br> This is wasteful, will avoid reclaiming some garbage, will scan generally far more than needed.<br> However it is also what we do on FreeBSD and OpenBSD (see ThreadOpenBSD.c's use of pthread_stackseg_np and ThreadFreeBSD.c's use of pthread_stackseg_np)<br> <br> <br>I think the main other alternative is the more portable "cooperative" scheme Tony has proposed where each thread has a boolean<br>it checks occasionally as to if suspension is requested. It is a nice scheme, since it would remove a bunch of platform-specific code<br>and posix-specific code (i.e. all signal stuff that isn't for user threads).<br> <br> <br>On the matter of garbage lingering in stack frames that have been popped...should we consider NIL'ing local pointers before turn?<br>Or it is too expensive and doesn't gain much?<br>And they'll tend to get overwritten fairly soon anyway??<br>Seems very gray.<br> <br> <br> - Jay<br> <br> <br>
<hr id="ecxstopSpelling">
From: jay.krell@cornell.edu<br>To: rcolebur@scires.com; m3devel@elegosoft.com<br>Date: Mon, 7 Mar 2011 05:51:32 +0000<br>Subject: Re: [M3devel] results of threadtest program on Windows7<br><br>
<style>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Tahoma;}
</style>
I find this worrisome, and want to understand it, and workaround it, somehow.<br> <br><a href="http://zachsaw.blogspot.com/2010/11/wow64-bug-getthreadcontext-may-return.html" target="_blank">http://zachsaw.blogspot.com/2010/11/wow64-bug-getthreadcontext-may-return.html</a><br> <br> - Jay<br> <br>
<hr id="ecxstopSpelling">
From: jay.krell@cornell.edu<br>To: rcolebur@scires.com; m3devel@elegosoft.com<br>Date: Mon, 7 Mar 2011 05:39:53 +0000<br>Subject: Re: [M3devel] results of threadtest program on Windows7<br><br>
<style>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Tahoma;}
</style>
Ok. I see it fail often on Windows now too. I didn't change anything.<br>I enabled pageheap to try to narrow it down, only to find an operating system bug, which I have worked around.<br>"pageheap" causes heap allocations to be followed immediately by an unused page, to catch heap overruns right away.<br> Modulo alignment restrictions -- i.e. malloc(1) will still have a few bytes you can silently corrupt before the unused page.<br> <br>Here is one instance.<br> <br>0:000> g<br>Writing file...done<br>Creating read threads...done<br>Creating fork threads...done<br>Creating alloc threads...done<br>Creating lock threads...done<br>running...printing oldest/median age/newest<br>.ModLoad: 73b20000 73b6b000 C:\Windows\SysWOW64\apphelp.dll<br>(1028.ca0): Access violation - code c0000005 (first chance)<br>First chance exceptions are reported before any exception handling.<br>This exception may be expected and handled.<br>eax=01155e18 ebx=00200000 ecx=00000005 edx=0111caee esi=001ffffc edi=00a80018<br>eip=0111cb3e esp=06d9f5c4 ebp=06d9f5fc iopl=0 nv up ei pl nz ac pe nc<br>cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010216<br>*** WARNING: Unable to verify checksum for threadtest.exe<br>threadtest!RTCollector__Move+0x50:<br>0111cb3e 8b1e mov ebx,dword ptr [esi] ds:002b:001ffffc=????????<br>0:009> r esi<br>esi=001ffffc<br>0:009> db @esi<br>001ffffc ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????<br>0020000c ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????<br>0020001c ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????<br>0020002c ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????<br>0020003c ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????<br>0020004c ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????<br>0020005c ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????<br>0020006c ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????<br>0:009> ~*k<br> 0 Id: 1028.d60 Suspend: 2 Teb: 7efdd000 Unfrozen<br>ChildEBP RetAddr<br><br>...<br>0045f674 0111a448 KERNELBASE!Sleep+0xf<br>0045f6b4 0111a218 threadtest!ThreadWin32__XPause+0x1cd<br>0045f6d8 010f356e threadtest!Thread__Pause+0x37<br>0045f7cc 01115268 threadtest!Main_M3+0xe67<br>0045f810 01114818 threadtest!RTLinker__RunMainBody+0x257<br>0045f828 011148bf threadtest!RTLinker__AddUnitI+0xf7<br>0045f848 010f1038 threadtest!RTLinker__AddUnit+0x9f<br>0045f864 011515d3 threadtest!main+0x38<br>0045f8a8 75e63677 threadtest!__tmainCRTStartup+0x122<br>0045f8b4 771c9f02 kernel32!BaseThreadInitThunk+0x12<br>...<br> <br> 1 Id: 1028.ab8 Suspend: 2 Teb: 7efda000 Unfrozen<br>ChildEBP RetAddr<br>00f6f680 771c8cc8 ntdll!NtWaitForSingleObject+0x15<br>00f6f6a8 0111b262 ntdll!RtlIntegerToUnicodeString+0x20b<br>00f6f6bc 01117b86 threadtest!RTOS__LockHeap+0x2c<br>00f6f6fc 011171cc threadtest!RTAllocator__AllocTraced+0xcd<br>00f6f730 01116ce6 threadtest!RTAllocator__GetTracedObj+0x89<br>00f6f74c 010f6829 threadtest!RTHooks__AllocateTracedObj+0x15<br>00f6f774 010f1288 threadtest!FileRd__Open+0x19<br>00f6f8ac 01119ca4 threadtest!Main__RApply+0x78<br>00f6f8e8 75e63677 threadtest!ThreadWin32__ThreadBase+0x25a<br>...<br> <br> 2 Id: 1028.d50 Suspend: 2 Teb: 7efd7000 Unfrozen<br>ChildEBP RetAddr<br>...<br>0106f9b0 011188ef threadtest!ThreadWin32__InitMutex+0x56<br>0106f9c8 010f7c08 threadtest!ThreadWin32__LockMutex+0x42<br>0106f9f0 010f12e3 threadtest!Rd__GetChar+0x28<br>0106fb28 01119ca4 threadtest!Main__RApply+0xd3<br>0106fb64 75e63677 threadtest!ThreadWin32__ThreadBase+0x25a<br>...<br> <br> 3 Id: 1028.ef0 Suspend: 2 Teb: 7efaf000 Unfrozen<br>ChildEBP RetAddr<br>...<br>062ff510 01117b86 threadtest!RTOS__LockHeap+0x2c<br>062ff550 011171cc threadtest!RTAllocator__AllocTraced+0xcd<br>062ff584 01116ce6 threadtest!RTAllocator__GetTracedObj+0x89<br>062ff5a0 011076b2 threadtest!RTHooks__AllocateTracedObj+0x15<br>062ff5d8 01106302 threadtest!FileWin32__New+0x52<br>062ff600 010f6839 threadtest!FS__OpenFileReadonly+0x8a<br>062ff628 010f1288 threadtest!FileRd__Open+0x29<br>062ff760 01119ca4 threadtest!Main__RApply+0x78<br>062ff79c 75e63677 threadtest!ThreadWin32__ThreadBase+0x25a<br>...<br> <br> 4 Id: 1028.10c8 Suspend: 2 Teb: 7efa9000 Unfrozen<br>ChildEBP RetAddr<br>...<br>0674fc44 010f17b9 threadtest!Process__Wait+0x8c<br>0674fd00 01119ca4 threadtest!Main__FApply+0xa2<br>0674fd3c 75e63677 threadtest!ThreadWin32__ThreadBase+0x25a<br>...<br> <br> 5 Id: 1028.c54 Suspend: 2 Teb: 7efac000 Unfrozen<br>ChildEBP RetAddr<br>...<br>0646fcc8 010f17b9 threadtest!Process__Wait+0x8c<br>0646fd84 01119ca4 threadtest!Main__FApply+0xa2<br>0646fdc0 75e63677 threadtest!ThreadWin32__ThreadBase+0x25a<br>...<br> 6 Id: 1028.101c Suspend: 2 Teb: 7efa3000 Unfrozen<br>ChildEBP RetAddr<br>...<br>06a1fdac 01117b86 threadtest!RTOS__LockHeap+0x2c<br>06a1fdec 0111772a threadtest!RTAllocator__AllocTraced+0xcd<br>06a1fe28 01116d9b threadtest!RTAllocator__GetOpenArray+0x94<br>06a1fe4c 010f1ada threadtest!RTHooks__AllocateOpenArray+0x19<br>06a1fea8 01119ca4 threadtest!Main__AApply+0x46<br>06a1fee4 75e63677 threadtest!ThreadWin32__ThreadBase+0x25a<br>06a1fef0 771c9f02 kernel32!BaseThreadInitThunk+0x12<br>...<br> 7 Id: 1028.d5c Suspend: 2 Teb: 7efa6000 Unfrozen<br>ChildEBP RetAddr<br>...<br>0684f6d0 01118eb1 threadtest!ThreadWin32__InitCondition+0xb0<br>0684f6f0 0111b328 threadtest!Thread__Broadcast+0x3f<br>0684f70c 01117c31 threadtest!RTOS__UnlockHeap+0xb3<br>0684f728 01117bbe threadtest!RTAllocator_M3_LINE_368+0x15<br>0684f768 011171cc threadtest!RTAllocator__AllocTraced+0x105<br>0684f79c 01116ce6 threadtest!RTAllocator__GetTracedObj+0x89<br>0684f7b8 011410c9 threadtest!RTHooks__AllocateTracedObj+0x15<br>0684f7d4 0112ce59 threadtest!Text8CString__New+0x19<br>0684f7ec 0112b63a threadtest!M3toC__StoT+0x16<br>0684f818 010fb22d threadtest!RTArgs__GetArg+0x70<br>0684f840 010f1776 threadtest!Params__Get+0x5d<br>0684f8fc 01119ca4 threadtest!Main__FApply+0x5f<br>0684f938 75e63677 threadtest!ThreadWin32__ThreadBase+0x25a<br>...<br> 8 Id: 1028.d14 Suspend: 2 Teb: 7efa0000 Unfrozen<br>ChildEBP RetAddr<br>WARNING: Stack unwind information not available. Following frames may be wrong.<br>...<br>06c6f6c8 01117b86 threadtest!RTOS__LockHeap+0x2c<br>06c6f708 0111772a threadtest!RTAllocator__AllocTraced+0xcd<br>06c6f744 01116d9b threadtest!RTAllocator__GetOpenArray+0x94<br>06c6f768 010f1ada threadtest!RTHooks__AllocateOpenArray+0x19<br>06c6f7c4 01119ca4 threadtest!Main__AApply+0x46<br>06c6f800 75e63677 threadtest!ThreadWin32__ThreadBase+0x25a<br>...<br> <br># 9 Id: 1028.ca0 Suspend: 1 Teb: 7ef9d000 Unfrozen<br>ChildEBP RetAddr<br>06d9f5fc 0113e6bd threadtest!RTCollector__Move+0x50<br>06d9f640 0113dfa8 threadtest!RTHeapMap__Walk+0x45a<br>06d9f664 0113df83 threadtest!RTHeapMap__DoWalkRef+0x62<br>06d9f688 0113df83 threadtest!RTHeapMap__DoWalkRef+0x3d<br>06d9f6ac 0113df3e threadtest!RTHeapMap__DoWalkRef+0x3d<br>06d9f6d8 0111e65f threadtest!RTHeapMap__WalkRef+0xfe<br>06d9f6fc 0111e4ad threadtest!RTCollector__CleanBetween+0xeb<br>06d9f724 0111de48 threadtest!RTCollector__CleanPage+0x54<br>06d9f778 0111d8ab threadtest!RTCollector__CollectSomeInStateZero+0x562<br>06d9f788 0111d549 threadtest!RTCollector__CollectSome+0x6e<br>06d9f7cc 01117b8c threadtest!RTHeapRep__CollectEnough+0x9b<br>06d9f80c 0111772a threadtest!RTAllocator__AllocTraced+0xd3<br>06d9f848 01116d9b threadtest!RTAllocator__GetOpenArray+0x94<br>06d9f86c 010f1ada threadtest!RTHooks__AllocateOpenArray+0x19<br>06d9f8c8 01119ca4 threadtest!Main__AApply+0x46<br>06d9f904 75e63677 threadtest!ThreadWin32__ThreadBase+0x25a<br>...<br> 10 Id: 1028.4cc Suspend: 2 Teb: 7ef97000 Unfrozen<br>ChildEBP RetAddr<br>WARNING: Stack unwind information not available. Following frames may be wrong.<br>0664fdec 771c8cc8 ntdll!NtWaitForSingleObject+0x15<br>0664fe14 011188ff ntdll!RtlIntegerToUnicodeString+0x20b<br>0664fe2c 010f1d9b threadtest!ThreadWin32__LockMutex+0x52<br>0664fe74 01119ca4 threadtest!Main__LApply+0x7d<br>0664feb0 75e63677 threadtest!ThreadWin32__ThreadBase+0x25a<br>...<br> <br> 11 Id: 1028.b48 Suspend: 2 Teb: 7ef9a000 Unfrozen<br>ChildEBP RetAddr<br>...<br>06f1fe38 010f1d9b threadtest!ThreadWin32__LockMutex+0x52<br>06f1fe80 01119ca4 threadtest!Main__LApply+0x7d<br>06f1febc 75e63677 threadtest!ThreadWin32__ThreadBase+0x25a<br>...<br> <br> 12 Id: 1028.a0c Suspend: 2 Teb: 7ef94000 Unfrozen<br>ChildEBP RetAddr<br>...<br>06b1fa98 6c2a016a kernel32!HeapFree+0x14<br>06b1faac 0113328d MSVCR100!free+0x1c<br>06b1fab8 01116e2e threadtest!Cstdlib__free+0xd<br>06b1facc 011184fa threadtest!RTHooks__DisposeUntracedRef+0x2c<br>06b1fae0 011185c0 threadtest!ThreadWin32__DelCriticalSection+0x2d<br>06b1fb14 011188ef threadtest!ThreadWin32__InitMutex+0x6e<br>06b1fb2c 010f1d9b threadtest!ThreadWin32__LockMutex+0x42<br>06b1fb74 01119ca4 threadtest!Main__LApply+0x7d<br>06b1fbb0 75e63677 threadtest!ThreadWin32__ThreadBase+0x25a<br>...<br><br> <br>Suggestions?<br> <br><br>That last thread is a bit different, but I guess merely suggesting heavy stress.<br> Init goes to Del only when another thread calls Init at about the same time on the same mutex.<br> <br> <br>Maybe try user threads but with a smaller quanta?<br>Maybe try a much older Win32 thread implementation?<br>Maybe go back to uniproc? Just for anecdotal evidence?<br>I'll try with noinc/nogen/paranoid on Win32 also.<br> <br> <br> - Jay<br><br> <br>
<hr id="ecxstopSpelling">
From: jay.krell@cornell.edu<br>To: rcolebur@scires.com; m3devel@elegosoft.com<br>Date: Mon, 7 Mar 2011 01:25:59 +0000<br>Subject: Re: [M3devel] results of threadtest program on Windows7<br><br>
<style>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Tahoma;}
</style>
Visual Studio should work.<br>You just open the .exe you want to debug, and it should decide you have opened it because you want to debug it.<br>Does it let you set breakpoints by typing in function names?<br>e.g. main or cm3!main or threadtest!main.<br><br>windbg is also very good and a free download.<br>e.g.<br>\bin\x86\windbg threadtest<br>bp threadtest!main<br>bp threadtest!RTError__MsgS<br>g<br><br> - Jay<br><br><br>
<hr id="ecxstopSpelling">
From: rcolebur@SCIRES.COM<br>To: m3devel@elegosoft.com<br>Date: Sat, 5 Mar 2011 20:35:41 -0500<br>Subject: Re: [M3devel] results of threadtest program on Windows7<br><br>
<style>
.ExternalClass .ecxshape
{;}
</style>
<style>
.ExternalClass p.ecxMsoNormal, .ExternalClass li.ecxMsoNormal, .ExternalClass div.ecxMsoNormal
{margin-bottom:.0001pt;font-size:12.0pt;font-family:'Times New Roman','serif';}
.ExternalClass a:link, .ExternalClass span.ecxMsoHyperlink
{color:blue;text-decoration:underline;}
.ExternalClass a:visited, .ExternalClass span.ecxMsoHyperlinkFollowed
{color:purple;text-decoration:underline;}
.ExternalClass p
{margin-right:0in;margin-left:0in;font-size:12.0pt;font-family:'Times New Roman','serif';}
.ExternalClass p.ecxecxmsonormal, .ExternalClass li.ecxecxmsonormal, .ExternalClass div.ecxecxmsonormal
{margin-right:0in;margin-left:0in;font-size:12.0pt;font-family:'Times New Roman','serif';}
.ExternalClass p.ecxecxmsochpdefault, .ExternalClass li.ecxecxmsochpdefault, .ExternalClass div.ecxecxmsochpdefault
{margin-right:0in;margin-left:0in;font-size:12.0pt;font-family:'Times New Roman','serif';}
.ExternalClass span.ecxecxmsohyperlink
{;}
.ExternalClass span.ecxecxmsohyperlinkfollowed
{;}
.ExternalClass span.ecxecxemailstyle19
{;}
.ExternalClass p.ecxecxmsonormal1, .ExternalClass li.ecxecxmsonormal1, .ExternalClass div.ecxecxmsonormal1
{margin-right:0in;margin-bottom:0in;margin-left:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:'Times New Roman','serif';}
.ExternalClass span.ecxecxmsohyperlink1
{color:blue;text-decoration:underline;}
.ExternalClass span.ecxecxmsohyperlinkfollowed1
{color:purple;text-decoration:underline;}
.ExternalClass span.ecxecxemailstyle191
{font-family:'Calibri','sans-serif';color:#1F497D;}
.ExternalClass p.ecxecxmsochpdefault1, .ExternalClass li.ecxecxmsochpdefault1, .ExternalClass div.ecxecxmsochpdefault1
{margin-right:0in;margin-left:0in;font-size:10.0pt;font-family:'Times New Roman','serif';}
.ExternalClass span.ecxecxapple-converted-space
{;}
.ExternalClass span.ecxEmailStyle29
{font-family:'Calibri','sans-serif';color:#1F497D;}
.ExternalClass .ecxMsoChpDefault
{font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;}
.ExternalClass div.ecxWordSection1
{page:WordSection1;}
</style>
<div class="ecxWordSection1">
<p class="ecxMsoNormal"><span style="font-family: 'Calibri','sans-serif'; color: rgb(31, 73, 125); font-size: 11pt;">Jay:</span></p>
<p class="ecxMsoNormal"><span style="font-family: 'Calibri','sans-serif'; color: rgb(31, 73, 125); font-size: 11pt;"> </span></p>
<p class="ecxMsoNormal"><span style="font-family: 'Calibri','sans-serif'; color: rgb(31, 73, 125); font-size: 11pt;">I have Visual Studio Express installed. Can I use its debugger? If so, how do I make it work with cm3? Or, do you suggest something else?</span></p>
<p class="ecxMsoNormal"><span style="font-family: 'Calibri','sans-serif'; color: rgb(31, 73, 125); font-size: 11pt;"> </span></p>
<p class="ecxMsoNormal"><span style="font-family: 'Calibri','sans-serif'; color: rgb(31, 73, 125); font-size: 11pt;">Regards,</span></p>
<p class="ecxMsoNormal"><span style="font-family: 'Calibri','sans-serif'; color: rgb(31, 73, 125); font-size: 11pt;">Randy</span></p>
<p class="ecxMsoNormal"><span style="font-family: 'Calibri','sans-serif'; color: rgb(31, 73, 125); font-size: 11pt;"> </span></p>
<div>
<div style="border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color; padding: 3pt 0in 0in;">
<p style="margin-left: 0.5in;" class="ecxMsoNormal"><b><span style="font-family: 'Tahoma','sans-serif'; font-size: 10pt;">From:</span></b><span style="font-family: 'Tahoma','sans-serif'; font-size: 10pt;"> jayk123@hotmail.com [mailto:jayk123@hotmail.com] <b>On Behalf Of </b>Jay K<br><b>Sent:</b> Saturday, March 05, 2011 12:38 AM<br><b>To:</b> Coleburn, Randy; m3devel@elegosoft.com<br><b>Subject:</b> RE: [M3devel] results of threadtest program on Windows7</span></p></div></div>
<p style="margin-left: 0.5in;" class="ecxMsoNormal"> </p>
<p style="margin-bottom: 12pt; margin-left: 0.5in; margin-right: 0in;" class="ecxMsoNormal"><span style="font-family: 'Tahoma','sans-serif'; font-size: 10pt;">Microsoft debuggers are freely downloadable. <br><br>Jay/phone</span></p>
<div style="text-align: center; margin-left: 0.5in;" class="ecxMsoNormal" align="center"><span style="font-family: 'Tahoma','sans-serif'; font-size: 10pt;">
<hr align="center" size="2" width="100%">
</span></div></div> </body>
</html>