<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi all:<br>yes, but perhaps this bug has been there for years, just that any client made it a clear crash for us in reality until now, the only advantage is that we do have some specification tools for doing that sort of checking of hidden bugs beyond underneath its tests.<br>OpenJDK had according to their release notes a huge test suite, which by the way is more appropriate for their uses, but even if their approach works, I don't know how it could make a difference to us. Now the test suite is not in their release. What a shame, I mean it could help to guide a testing of ours building blocks too.<br>Now there are many public interfaces possibly more than half M3 world, without specifications, how can we tackle this in efficient ways, for instance how about the M3 native backend as M3 debugger and even more some of arithmethic lib, perhaps its
documentation is the best way of staring it. Also this will give us freedom of rewriting any parts of RT that are not still very well stabilized if so.<br>Thanks in advance<br><br>--- El <b>jue, 10/3/11, Tony Hosking <i><hosking@cs.purdue.edu></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>De: Tony Hosking <hosking@cs.purdue.edu><br>Asunto: Re: [M3devel] results of threadtest program on Windows7<br>Para: "Jay K" <jay.krell@cornell.edu><br>CC: "m3devel" <m3devel@elegosoft.com><br>Fecha: jueves, 10 de marzo, 2011 11:50<br><br><div id="yiv2036722745"><base>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="yiv2036722745Apple-interchange-newline"><blockquote type="cite"><span class="yiv2036722745Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; font-size: medium;"><div class="yiv2036722745hmmessage" 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 rel="nofollow" target="_blank" href="http://en.wikipedia.org/wiki/WoW64">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="yiv2036722745stopSpelling">From:<span class="yiv2036722745Apple-converted-space"> </span><a rel="nofollow" ymailto="mailto:jay.krell@cornell.edu" target="_blank" href="/mc/compose?to=jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>To:<span class="yiv2036722745Apple-converted-space"> </span><a rel="nofollow" ymailto="mailto:rcolebur@scires.com" target="_blank" href="/mc/compose?to=rcolebur@scires.com">rcolebur@scires.com</a>;<span class="yiv2036722745Apple-converted-space"> </span><a rel="nofollow" ymailto="mailto:m3devel@elegosoft.com" target="_blank" href="/mc/compose?to=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 rel="nofollow" target="_blank" href="http://zachsaw.blogspot.com/2010/11/wow64-bug-getthreadcontext-may-return.html">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="yiv2036722745ecxstopSpelling">From:<span class="yiv2036722745Apple-converted-space"> </span><a rel="nofollow" ymailto="mailto:jay.krell@cornell.edu" target="_blank"
href="/mc/compose?to=jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>To:<span class="yiv2036722745Apple-converted-space"> </span><a rel="nofollow" ymailto="mailto:rcolebur@scires.com" target="_blank" href="/mc/compose?to=rcolebur@scires.com">rcolebur@scires.com</a>;<span class="yiv2036722745Apple-converted-space"> </span><a rel="nofollow" ymailto="mailto:m3devel@elegosoft.com" target="_blank" href="/mc/compose?to=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="yiv2036722745ecxstopSpelling">From:<span class="yiv2036722745Apple-converted-space"> </span><a rel="nofollow" ymailto="mailto:jay.krell@cornell.edu" target="_blank" href="/mc/compose?to=jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>To:<span class="yiv2036722745Apple-converted-space"> </span><a rel="nofollow" ymailto="mailto:rcolebur@scires.com" target="_blank" href="/mc/compose?to=rcolebur@scires.com">rcolebur@scires.com</a>;<span class="yiv2036722745Apple-converted-space"> </span><a rel="nofollow"
ymailto="mailto:m3devel@elegosoft.com" target="_blank" href="/mc/compose?to=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="yiv2036722745ecxstopSpelling">From:<span class="yiv2036722745Apple-converted-space"> </span><a rel="nofollow" ymailto="mailto:jay.krell@cornell.edu" target="_blank" href="/mc/compose?to=jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>To:<span class="yiv2036722745Apple-converted-space"> </span><a rel="nofollow" ymailto="mailto:rcolebur@scires.com" target="_blank" href="/mc/compose?to=rcolebur@scires.com">rcolebur@scires.com</a>;<span
class="yiv2036722745Apple-converted-space"> </span><a rel="nofollow" ymailto="mailto:m3devel@elegosoft.com" target="_blank" href="/mc/compose?to=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="yiv2036722745ecxstopSpelling">From:<span class="yiv2036722745Apple-converted-space"> </span><a rel="nofollow" ymailto="mailto:jay.krell@cornell.edu" target="_blank" href="/mc/compose?to=jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>To:<span class="yiv2036722745Apple-converted-space"> </span><a rel="nofollow" ymailto="mailto:rcolebur@scires.com" target="_blank" href="/mc/compose?to=rcolebur@scires.com">rcolebur@scires.com</a>;<span class="yiv2036722745Apple-converted-space"> </span><a rel="nofollow" ymailto="mailto:m3devel@elegosoft.com" target="_blank" href="/mc/compose?to=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="yiv2036722745ecxstopSpelling">From:<span class="yiv2036722745Apple-converted-space"> </span><a rel="nofollow" ymailto="mailto:jay.krell@cornell.edu" target="_blank" href="/mc/compose?to=jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>To:<span class="yiv2036722745Apple-converted-space"> </span><a rel="nofollow" ymailto="mailto:rcolebur@scires.com" target="_blank" href="/mc/compose?to=rcolebur@scires.com">rcolebur@scires.com</a>;<span class="yiv2036722745Apple-converted-space"> </span><a rel="nofollow" ymailto="mailto:m3devel@elegosoft.com" target="_blank"
href="/mc/compose?to=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 rel="nofollow" target="_blank" href="http://zachsaw.blogspot.com/2010/11/wow64-bug-getthreadcontext-may-return.html">http://zachsaw.blogspot.com/2010/11/wow64-bug-getthreadcontext-may-return.html</a><br> <br> - Jay<br> <br><hr id="yiv2036722745ecxstopSpelling">From:<span class="yiv2036722745Apple-converted-space"> </span><a rel="nofollow" ymailto="mailto:jay.krell@cornell.edu" target="_blank" href="/mc/compose?to=jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>To:<span class="yiv2036722745Apple-converted-space"> </span><a rel="nofollow" ymailto="mailto:rcolebur@scires.com" target="_blank"
href="/mc/compose?to=rcolebur@scires.com">rcolebur@scires.com</a>;<span class="yiv2036722745Apple-converted-space"> </span><a rel="nofollow" ymailto="mailto:m3devel@elegosoft.com" target="_blank" href="/mc/compose?to=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="yiv2036722745ecxstopSpelling">From:<span class="yiv2036722745Apple-converted-space"> </span><a rel="nofollow" ymailto="mailto:jay.krell@cornell.edu" target="_blank" href="/mc/compose?to=jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>To:<span class="yiv2036722745Apple-converted-space"> </span><a rel="nofollow" ymailto="mailto:rcolebur@scires.com" target="_blank" href="/mc/compose?to=rcolebur@scires.com">rcolebur@scires.com</a>;<span class="yiv2036722745Apple-converted-space"> </span><a rel="nofollow" ymailto="mailto:m3devel@elegosoft.com" target="_blank" href="/mc/compose?to=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="yiv2036722745ecxstopSpelling">From:<span class="yiv2036722745Apple-converted-space"> </span><a rel="nofollow" ymailto="mailto:rcolebur@SCIRES.COM" target="_blank" href="/mc/compose?to=rcolebur@SCIRES.COM">rcolebur@SCIRES.COM</a><br>To:<span class="yiv2036722745Apple-converted-space"> </span><a rel="nofollow" ymailto="mailto:m3devel@elegosoft.com" target="_blank" href="/mc/compose?to=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="yiv2036722745ecxWordSection1"><div style="margin: 0px; padding: 0px;"><span style="font-family: Calibri,sans-serif; color: rgb(31, 73, 125); font-size:
11pt;">Jay:</span></div><p class="yiv2036722745ecxMsoNormal" style="margin: 0px; padding: 0px;"><span style="font-family: Calibri,sans-serif; color: rgb(31, 73, 125); font-size: 11pt;"> </span></p><div style="margin: 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="yiv2036722745ecxMsoNormal" style="margin: 0px; padding: 0px;"><span style="font-family: Calibri,sans-serif; color: rgb(31, 73, 125); font-size: 11pt;"> </span></p><div style="margin: 0px; padding: 0px;"><span style="font-family: Calibri,sans-serif; color: rgb(31, 73, 125); font-size: 11pt;">Regards,</span></div><div style="margin: 0px; padding: 0px;"><span style="font-family: Calibri,sans-serif; color: rgb(31, 73, 125); font-size:
11pt;">Randy</span></div><p class="yiv2036722745ecxMsoNormal" style="margin: 0px; padding: 0px;"><span style="font-family: Calibri,sans-serif; color: rgb(31, 73, 125); font-size: 11pt;"> </span></p><div><div style="border-style: solid none none; border-width: 1pt medium medium; border-top: 1pt solid rgb(181, 196, 223); padding: 3pt 0in 0in;"><div style="margin: 0px 0px 0px 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="yiv2036722745Apple-converted-space"> </span><a rel="nofollow" ymailto="mailto:jayk123@hotmail.com" target="_blank" href="/mc/compose?to=jayk123@hotmail.com">jayk123@hotmail.com</a><span class="yiv2036722745Apple-converted-space"> </span>[mailto:jayk123@hotmail.com]<span class="yiv2036722745Apple-converted-space"> </span><b>On Behalf Of<span
class="yiv2036722745Apple-converted-space"> </span></b>Jay K<br><b>Sent:</b><span class="yiv2036722745Apple-converted-space"> </span>Saturday, March 05, 2011 12:38 AM<br><b>To:</b><span class="yiv2036722745Apple-converted-space"> </span>Coleburn, Randy;<span class="yiv2036722745Apple-converted-space"> </span><a rel="nofollow" ymailto="mailto:m3devel@elegosoft.com" target="_blank" href="/mc/compose?to=m3devel@elegosoft.com">m3devel@elegosoft.com</a><br><b>Subject:</b><span class="yiv2036722745Apple-converted-space"> </span>RE: [M3devel] results of threadtest program on Windows7</span></div></div></div><p class="yiv2036722745ecxMsoNormal" style="margin: 0px 0px 0px 0.5in; padding: 0px;"> </p><p class="yiv2036722745ecxMsoNormal" style="margin: 0px 0in 12pt 0.5in; padding: 0px;"><span style="font-family: Tahoma,sans-serif; font-size: 10pt;">Microsoft debuggers are freely downloadable.<span
class="yiv2036722745Apple-converted-space"> </span><br><br>Jay/phone</span></p><div class="yiv2036722745ecxMsoNormal" 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></blockquote></td></tr></table><br>