<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
I thought maybe they'd show a way for us to get away with "preemptive suspend",<br>a way to use SuspendThread/GetThreadContext with confidence.<br><br>So, you agree we want cooperative suspend then?<br>And we should maybe get going on implementing it?<br>Maybe do that before debugging Mika's problem?<br> Well, to repeat myself, I'm ok with looking into 32bit-only Windows for Mika's problem.<br> Though, clearly, as i've said, I have A LOT less time for Modula-3 now and probably ever.<br><br> - Jay<br><br><hr id="stopSpelling">Subject: Re: [M3devel] results of threadtest program on Windows7<br>From: hosking@cs.purdue.edu<br>Date: Sat, 12 Mar 2011 11:23:04 -0500<br>CC: m3devel@elegosoft.com<br>To: jay.krell@cornell.edu<br><br>
<meta http-equiv="Content-Type" content="text/html; charset=unicode">
<meta name="Generator" content="Microsoft SafeHTML"><base>I know they use cooperative suspend.<div>We do in Jikes RVM too.</div><div>That's another code base to look at. Probably easier as it is all in Java.</div><div>
<br><div><div>On Mar 12, 2011, at 4:57 AM, Jay K wrote:</div><br class="ecxApple-interchange-newline"><blockquote><span class="ecxApple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; font-size: medium;"><div class="ecxhmmessage" style="font-size: 10pt; font-family: Tahoma;">There is a lack of evidence that Java does things in a way at all resembling what Modula-3 does, on Win32.<br> There is precious little in the way of calling the Win32 functions SuspendThread and GetThreadContext.<br>There is evidence that they use cooperative suspend.<br>It isn't conclusive, to me..just because there is so much there, it is not immediately clear.<br>That is, pretty clear there is code implementing cooperative suspend, but is that their entire story? I don't know.<br><br> - Jay<br><br><hr id="ecxstopSpelling">From:<span class="ecxApple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>To:<span class="ecxApple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>CC:<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Subject: RE: [M3devel] results of threadtest program on Windows7<br>Date: Thu, 10 Mar 2011 21:03:58 +0000<br><br>I often forget this. Thank you.<br><br> - Jay<br><br><hr id="ecxstopSpelling">From:<span class="ecxApple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>Date: Thu, 10 Mar 2011 11:50:40 -0500<br>To:<span class="ecxApple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>CC:<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Subject: Re: [M3devel] results of threadtest program on Windows7<br><br>Even better perhaps is to look at OpenJDK!<br><br><div><div>On Mar 10, 2011, at 6:05 AM, Jay K wrote:</div><br class="ecxApple-interchange-newline"><blockquote><span class="ecxApple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; font-size: medium;"><div class="ecxhmmessage" style="font-size: 10pt; font-family: Tahoma;">Tony, more and more I think we want "cooperative suspend".<br>That would address this, avoid scanning the entire stack only the live stack on FreeBSD and OpenBSD, and<br>be much more portable, and bigger and slower.<br>I'll see what Mono and Rotor ("sscli") do though.<br><a href="http://en.wikipedia.org/wiki/WoW64" target="_blank">http://en.wikipedia.org/wiki/WoW64</a><br>Apparently the Boehm GC has problems too.<br> <br>We could probably do something like, note the ranges of all Modula-3 .dlls, and check that EIP is in one of them,<br>else let the thread run longer and try suspend again. Maybe..<br> <br> - Jay<br> <br><hr id="ecxstopSpelling">From:<span class="ecxApple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>To:<span class="ecxApple-converted-space"> </span><a href="mailto:rcolebur@scires.com">rcolebur@scires.com</a>;<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Date: Thu, 10 Mar 2011 10:40:58 +0000<br>Subject: Re: [M3devel] results of threadtest program on Windows7<br><br>oh, but to repeat, use of SuspendThread / GetThreadContext makes me nervous<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>some of the talk is only about the wrong esp, but I wonder if it is all wrong sometimes.<br>I think we can range check esp and reject if it is out of range, similar to the hack<br>that was there for Win9x.<br> <br>Maybe stick to 32bit OS while investigating threadtest?<br> <br>Or maybe ignore Win32 for now and find when pthreads worked?<br> <br> - Jay<br> <br><hr id="ecxstopSpelling">From:<span class="ecxApple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>To:<span class="ecxApple-converted-space"> </span><a href="mailto:rcolebur@scires.com">rcolebur@scires.com</a>;<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Date: Thu, 10 Mar 2011 10:09:02 +0000<br>Subject: Re: [M3devel] results of threadtest program on Windows7<br><br>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="ecxstopSpelling">From:<span class="ecxApple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>To:<span class="ecxApple-converted-space"> </span><a href="mailto:rcolebur@scires.com">rcolebur@scires.com</a>;<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Subject: RE: [M3devel] results of threadtest program on Windows7<br>Date: Wed, 9 Mar 2011 20:10:37 +0000<br><br>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:<span class="ecxApple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>To:<span class="ecxApple-converted-space"> </span><a href="mailto:rcolebur@scires.com">rcolebur@scires.com</a>;<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Subject: RE: [M3devel] results of threadtest program on Windows7<br>Date: Mon, 7 Mar 2011 06:58:45 +0000<br><br>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:<span class="ecxApple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>To:<span class="ecxApple-converted-space"> </span><a href="mailto:rcolebur@scires.com">rcolebur@scires.com</a>;<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Date: Mon, 7 Mar 2011 06:53:06 +0000<br>Subject: Re: [M3devel] results of threadtest program on Windows7<br><br>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:<span class="ecxApple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>To:<span class="ecxApple-converted-space"> </span><a href="mailto:rcolebur@scires.com">rcolebur@scires.com</a>;<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Date: Mon, 7 Mar 2011 05:51:32 +0000<br>Subject: Re: [M3devel] results of threadtest program on Windows7<br><br>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:<span class="ecxApple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>To:<span class="ecxApple-converted-space"> </span><a href="mailto:rcolebur@scires.com">rcolebur@scires.com</a>;<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Date: Mon, 7 Mar 2011 05:39:53 +0000<br>Subject: Re: [M3devel] results of threadtest program on Windows7<br><br>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:<span class="ecxApple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>To:<span class="ecxApple-converted-space"> </span><a href="mailto:rcolebur@scires.com">rcolebur@scires.com</a>;<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Date: Mon, 7 Mar 2011 01:25:59 +0000<br>Subject: Re: [M3devel] results of threadtest program on Windows7<br><br>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:<span class="ecxApple-converted-space"> </span><a href="mailto:rcolebur@SCIRES.COM">rcolebur@SCIRES.COM</a><br>To:<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Date: Sat, 5 Mar 2011 20:35:41 -0500<br>Subject: Re: [M3devel] results of threadtest program on Windows7<br><br><div class="ecxWordSection1"><div style="margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding: 0px;"><span style="font-family: Calibri,sans-serif; color: rgb(31, 73, 125); font-size: 11pt;">Jay:</span></div><p class="ecxMsoNormal" style="margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding: 0px;"><span style="font-family: Calibri,sans-serif; color: rgb(31, 73, 125); font-size: 11pt;"> </span></p><div style="margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding: 0px;"><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></div><p class="ecxMsoNormal" style="margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding: 0px;"><span style="font-family: Calibri,sans-serif; color: rgb(31, 73, 125); font-size: 11pt;"> </span></p><div style="margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding: 0px;"><span style="font-family: Calibri,sans-serif; color: rgb(31, 73, 125); font-size: 11pt;">Regards,</span></div><div style="margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding: 0px;"><span style="font-family: Calibri,sans-serif; color: rgb(31, 73, 125); font-size: 11pt;">Randy</span></div><p class="ecxMsoNormal" style="margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding: 0px;"><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; padding: 3pt 0in 0in;"><div style="margin-right: 0px; margin-bottom: 0px; margin-left: 0.5in; padding: 0px;"><b><span style="font-family: Tahoma,sans-serif; font-size: 10pt;">From:</span></b><span style="font-family: Tahoma,sans-serif; font-size: 10pt;"><span class="ecxApple-converted-space"> </span><a href="mailto:jayk123@hotmail.com">jayk123@hotmail.com</a><span class="ecxApple-converted-space"> </span>[mailto:jayk123@hotmail.com]<span class="ecxApple-converted-space"> </span><b>On Behalf Of<span class="ecxApple-converted-space"> </span></b>Jay K<br><b>Sent:</b><span class="ecxApple-converted-space"> </span>Saturday, March 05, 2011 12:38 AM<br><b>To:</b><span class="ecxApple-converted-space"> </span>Coleburn, Randy;<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br><b>Subject:</b><span class="ecxApple-converted-space"> </span>RE: [M3devel] results of threadtest program on Windows7</span></div></div></div><p class="ecxMsoNormal" style="margin-right: 0px; margin-bottom: 0px; margin-left: 0.5in; padding: 0px;"> </p><p class="ecxMsoNormal" style="margin-right: 0in; margin-bottom: 12pt; margin-left: 0.5in; padding: 0px;"><span style="font-family: Tahoma,sans-serif; font-size: 10pt;">Microsoft debuggers are freely downloadable.<span class="ecxApple-converted-space"> </span><br><br>Jay/phone</span></p><div class="ecxMsoNormal" style="text-align: center; margin-left: 0.5in;" align="center"><span style="font-family: Tahoma,sans-serif; font-size: 10pt;"><hr align="center" size="2" width="100%"></span></div></div></div></span></blockquote></div><br></div></span><br class="ecxApple-interchange-newline"></blockquote></div><br></div> </body>
</html>