[M3devel] results of threadtest program on Windows7

[Tony Hosking]

Even better perhaps is to look at OpenJDK!

On Mar 10, 2011, at 6:05 AM, Jay K wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110310/2aaeed25/attachment-0002.html>