From mika at async.caltech.edu  Tue Mar  1 02:49:49 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Mon, 28 Feb 2011 17:49:49 -0800
Subject: [M3devel] Has anyone seen this crash before?
Message-ID: <20110301014949.B70F01A2078@async.async.caltech.edu>


shownew crashing on LINUXLIBC6 (works fine on e.g., AMD64_LINUX):

This GDB was configured as "i386-redhat-linux-gnu"...
(gdb) run
Starting program: /home/user/mnystrom/cm3/bin/shownew 
[Thread debugging using libthread_db enabled]
[New Thread 0xb7fb16c0 (LWP 30122)]

Program received signal SIGSEGV, Segmentation fault.
0x00be406c in ?? () from /usr/lib/libXcursor.so.1
(gdb) where
#0  0x00be406c in ?? () from /usr/lib/libXcursor.so.1
#1  0x00be44ae in ?? () from /usr/lib/libXcursor.so.1
#2  0x00be45de in XcursorLibraryLoadImages () from /usr/lib/libXcursor.so.1
#3  0x00be462b in XcursorShapeLoadImages () from /usr/lib/libXcursor.so.1
#4  0x00be4f63 in XcursorTryShapeCursor () from /usr/lib/libXcursor.so.1
#5  0x00442d02 in XCreateGlyphCursor () from /usr/lib/libX11.so.6
#6  0x0044318d in XCreateFontCursor () from /usr/lib/libX11.so.6
#7  0x00eb5a8c in XScrnCrsr__CursorLookup (orc=0xb7db6f14, name=0xf50ee4)
    at ../src/xvbt/XScrnCrsr.m3:166
#8  0x00ee491d in Cursor__NameApply (cl=0xb7db4da4, st=0xb7db6ae4)
    at ../src/vbt/Cursor.m3:104
#9  0x00ed44d1 in VBTRep__CursorApply (st=0xb7db6ae4, cl=0xb7db4da4, 
    cs={<No data fields>}) at ../src/vbt/VBTRep.m3:82
#10 0x00ee2b5c in Palette__ResolveCursor (st=0xb7db6ae4, 
    curs={<No data fields>}) at ../src/vbt/Palette.m3:294
#11 0x00ed6738 in VBTRep__CursorResolver (self=0xb7dd1aac)
    at ../src/vbt/VBTRep.m3:488
#12 0x00f9d9ed in ThreadPosix__RunThread ()
    at ../src/thread/POSIX/ThreadPosix.m3:1107
#13 0x0097aa1b in makecontext () from /lib/libc.so.6
#14 0x00000000 in ?? ()
(gdb) 

     Mika


From jay.krell at cornell.edu  Tue Mar  1 11:59:29 2011
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 1 Mar 2011 10:59:29 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <20110227231125.3DC611A2078@async.async.caltech.edu>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>,
	<20110227231125.3DC611A2078@async.async.caltech.edu>
Message-ID: <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>


I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Ah, it just doesn't check command-line arguments that carefully.
> 
> I think what you did is equivalent to "-tests STD".
> 
>      Mika
> 
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist:  On Windows 7, I thought I'd see what the command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash.  Then, I trie=
> >d it again and it ran to completion.  Something seems non-deterministic her=
> >e.  See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >***    Attempt to reference an illegal memory location.
> >***    pc =3D 0x77762262
> >***
> >
> >Stack trace:
> >   FP         PC      Procedure
> >---------  ---------  -------------------------------
> > 0xcdf998  0x130351b  SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0  0x77762262  <???>
> > 0xcdf9d8  0x12e83b7  LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00  0x12c7b08  GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38  0x12c12e3  RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74  0x12e971f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80  0x76543677  <???>
> > 0xcdfbc0  0x77779f02  <???>
> >.........  .........  ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete.  Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2.  That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> >     Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008.  This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung.  I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>***    An array subscript was out of range.
> >>***    file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
> >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>***    <*ASSERT*> failed.
> >>***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >>   threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >>   threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >>     Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results.  Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>***    An enumeration or subrange value was out of range.
> >>>***    file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>>   FP         PC      Procedure
> >>>---------  ---------  -------------------------------
> >>>0x30fbd0  0x127218a  PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0  0x1273825  Main_M3 + 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110301/6c051b49/attachment.html>

From jay.krell at cornell.edu  Tue Mar  1 18:27:40 2011
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 1 Mar 2011 17:27:40 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>
Message-ID: <COL101-W6172E969583BD60401B836E6C10@phx.gbl>


I also haven't seen it fail on OpenBSD/x86/4.7. I'm pretty sure using pthreads there.
But on Solaris/5.10/sparc it hangs, for many hours.

-bash-4.1$ ./threadtest 
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
.

Are we guranteed forward progress in suspending all threads?

I do see it fail usually on Darwin. e.g.:
........pthread_mutex_destroy:EBUSY
pthread_mutex_destroy:EBUSY
..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:
***    An array subscript was out of range.
***    file "../src/runtime/common/RTCollector.m3", line 418
***

I haven't tried Linux yet.
Do note that we have some variance in the pthreads implementation.
The "portable" implementation is used on Linux, Solaris, NetBSD.
And then OpenBSD, Darwin, FreeBSD each have slight differences.

Mika are your machines all multiprocessors?
I do wonder if that helps increase the stress and if I should be sure to use multiprocessors.

I'm also considering taking the time to try various historical versions, either releases or dates in CVS.

 - Jay

From: jay.krell at cornell.edu
To: mika at async.caltech.edu; rcolebur at scires.com
Date: Tue, 1 Mar 2011 10:59:29 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] results of threadtest program on Windows7








I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Ah, it just doesn't check command-line arguments that carefully.
> 
> I think what you did is equivalent to "-tests STD".
> 
>      Mika
> 
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist:  On Windows 7, I thought I'd see what the command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash.  Then, I trie=
> >d it again and it ran to completion.  Something seems non-deterministic her=
> >e.  See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >***    Attempt to reference an illegal memory location.
> >***    pc =3D 0x77762262
> >***
> >
> >Stack trace:
> >   FP         PC      Procedure
> >---------  ---------  -------------------------------
> > 0xcdf998  0x130351b  SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0  0x77762262  <???>
> > 0xcdf9d8  0x12e83b7  LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00  0x12c7b08  GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38  0x12c12e3  RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74  0x12e971f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80  0x76543677  <???>
> > 0xcdfbc0  0x77779f02  <???>
> >.........  .........  ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete.  Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2.  That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> >     Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008.  This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung.  I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>***    An array subscript was out of range.
> >>***    file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
> >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>***    <*ASSERT*> failed.
> >>***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >>   threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >>   threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >>     Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results.  Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>***    An enumeration or subrange value was out of range.
> >>>***    file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>>   FP         PC      Procedure
> >>>---------  ---------  -------------------------------
> >>>0x30fbd0  0x127218a  PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0  0x1273825  Main_M3 + 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110301/8f3b432d/attachment.html>

From mika at async.caltech.edu  Tue Mar  1 19:17:18 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Tue, 01 Mar 2011 10:17:18 -0800
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W6172E969583BD60401B836E6C10@phx.gbl> 
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>
	<COL101-W6172E969583BD60401B836E6C10@phx.gbl>
Message-ID: <20110301181718.12EFC1A2078@async.async.caltech.edu>


Hi Jay,

1. I think you should get forward progress no matter what, although it
might be very slow on some systems.

2. Not sure how you could get negative timings.  That would suggest that
Time.Now() is decreasing---which seems contrary to its specification.
Although the code is doing some nasty stuff with the timings, mainly
reading and writing them without locks.  But it's using INTEGER for
the results so I don't think there can be an atomicity problem there.
Even if there were coherence problems between processors (is this
technically possible?) the "now" value has to be coherent since it's
from the thread that prints the results, and the "then" values could
only be getting older, not newer...

3. Note that there are systems (FreeBSD 4 is an example) that have a
"pthreads" library but where the pthreads library is implemented with
user threads.  Could that be related to why OpenBSD is working?

4. Hm.  I think I am only using multiprocessor systems, yes.  Hard to
find single-CPU systems nowadays!  I think actually the only one I have
is PPC_DARWIN, and I haven't tried the code on that.  So yes this is a
possibility as far as explaining differences...

     Mika

Jay K writes:
>--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>I also haven't seen it fail on OpenBSD/x86/4.7. I'm pretty sure using pthre=
>ads there.
>But on Solaris/5.10/sparc it hangs=2C for many hours.
>
>-bash-4.1$ ./threadtest=20
>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
>.
>
>Are we guranteed forward progress in suspending all threads?
>
>I do see it fail usually on Darwin. e.g.:
>........pthread_mutex_destroy:EBUSY
>pthread_mutex_destroy:EBUSY
>..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:
>***    An array subscript was out of range.
>***    file "../src/runtime/common/RTCollector.m3"=2C line 418
>***
>
>I haven't tried Linux yet.
>Do note that we have some variance in the pthreads implementation.
>The "portable" implementation is used on Linux=2C Solaris=2C NetBSD.
>And then OpenBSD=2C Darwin=2C FreeBSD each have slight differences.
>
>Mika are your machines all multiprocessors?
>I do wonder if that helps increase the stress and if I should be sure to us=
>e multiprocessors.
>
>I'm also considering taking the time to try various historical versions=2C =
>either releases or dates in CVS.
>
> - Jay
>
>From: jay.krell at cornell.edu
>To: mika at async.caltech.edu=3B rcolebur at scires.com
>Date: Tue=2C 1 Mar 2011 10:59:29 +0000
>CC: m3devel at elegosoft.com
>Subject: Re: [M3devel] results of threadtest program on Windows7
>
>
>
>
>
>
>
>
>I haven't seen it fail on NT=2C except for PutCard in the test itself getti=
>ng negative numbers.
>I've run it just a few times now. One single and dual processor virtual mac=
>hines.
>Randy=2C has it failed many times for you?
>
> - Jay
>
>> To: rcolebur at SCIRES.COM
>> Date: Sun=2C 27 Feb 2011 15:11:25 -0800
>> From: mika at async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] results of threadtest program on Windows7
>>=20
>> Ah=2C it just doesn't check command-line arguments that carefully.
>>=20
>> I think what you did is equivalent to "-tests STD".
>=20
>>      Mika
>>=20
>> "Coleburn=2C Randy" writes:
>> >Mika:
>> >
>> >No change with "-tests POSIX".
>> >
>> >Interesting twist:  On Windows 7=2C I thought I'd see what the command l=
>ine o=3D
>> >ptions are=2C and I typed "threadtest -help" rather than reading the cod=
>e.
>> >
>> >First time=2C it produced what appears to be a NIL deref crash.  Then=2C=
> I trie=3D
>> >d it again and it ran to completion.  Something seems non-deterministic =
>her=3D
>> >e.  See below.
>> >
>> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
>> >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
>> >.
>> >
>> >***
>> >*** runtime error:
>> >***    Attempt to reference an illegal memory location.
>> >***    pc =3D3D 0x77762262
>> >***
>> >
>> >Stack trace:
>> >   FP         PC      Procedure
>> >---------  ---------  -------------------------------
>> > 0xcdf998  0x130351b  SystemError + 0x64 in ..\src\runtime\NT386\RTSigna=
>l.m=3D
>> >3
>> > 0xcdf9c0  0x77762262  <???>
>> > 0xcdf9d8  0x12e83b7  LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin3=
>2.m=3D
>> >3
>> > 0xcdfa00  0x12c7b08  GetChar + 0x28 in ..\src\rw\Rd.m3
>> > 0xcdfb38  0x12c12e3  RApply + 0xd3 in ..\src\Main.m3
>> > 0xcdfb74  0x12e971f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWi=
>n32=3D
>> >.m3
>> > 0xcdfb80  0x76543677  <???>
>> > 0xcdfbc0  0x77779f02  <???>
>> >.........  .........  ... more frames ...
>> >
>> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
>> >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
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >All tests complete.  Congratulations.
>> >
>> >Regards=2C
>> >Randy Coleburn
>> >
>> >-----Original Message-----
>> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
>> >Sent: Sunday=2C February 27=2C 2011 3:30 PM
>> >To: Coleburn=2C Randy
>> >Cc: m3devel at elegosoft.com
>> >Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
>> >
>> >Hi Randy=2C
>> >
>> >You can try it with -tests POSIX as well.
>> >
>> >I find on user threads it runs very slowly (but it does run) because of =
>how=3D
>> > unfair
>> >the thread scheduler is.
>> >
>> >Next step might be to whittle down the tests and see if you can get a fa=
>ilu=3D
>> >re with
>> >a single test running and -n 2.  That would likely be the simplest scena=
>rio=3D
>> > to
>> >start further debugging from.
>> >
>> >     Mika
>> >
>> >"Coleburn=2C Randy" writes:
>> >>Mika et al:
>> >>
>> >>Thought I would try something else.
>> >>
>> >>I took the sources of your thread test program to an older XP machine t=
>hat=3D
>> > =3D3D
>> >>has CM3 circa August 2008.  This is the machine and implementation I us=
>ed =3D
>> >w=3D3D
>> >>hen building a major project I did a couple years back.
>> >>
>> >>The thread test program does indeed build on this old system=2C but whe=
>n I r=3D
>> >u=3D3D
>> >>n it=2C I get different results than with the latest HEAD branch code. =
>=3D3D20
>> >>
>> >>After it prints "running...printing oldest/median age/newest"=2C on the=
> next=3D
>> > =3D3D
>> >>line I get two periods ".." and now the program seems hung.  I'll let i=
>t "=3D
>> >r=3D3D
>> >>un" for a few more minutes to see if anything else happens before killi=
>ng =3D
>> >i=3D3D
>> >>t.
>> >>
>> >>At least we don't get the subscript and assertion failures on this olde=
>r C=3D
>> >M=3D3D
>> >>3 platform.
>> >>
>> >>Regards=2C
>> >>Randy Coleburn
>> >>
>> >>
>> >>-----Original Message-----
>> >>From: Coleburn=2C Randy=3D3D20
>> >>Sent: Sunday=2C February 27=2C 2011 2:09 PM
>> >>To: m3devel at elegosoft.com
>> >>Subject: Re: [M3devel] results of threadtest program on Windows7
>> >>
>> >>Mika:
>> >>
>> >>Ok=2C I've updated to latest HEAD and I've also built Jay's m3sleep pro=
>gram.
>> >>
>> >>Here is what happens now when I run your threadtest program on Windows =
>7.
>> >>
>> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL=
>=2C-fo=3D
>> >r=3D3D
>> >>k
>> >>Writing file...done
>> >>Creating read threads...done
>> >>Creating nxread threads...done
>> >>Creating tryexcept threads...done
>> >>Creating forktoomuch threads...done
>> >>Creating alloc threads...done
>> >>Creating creat threads...done
>> >>Creating lock threads...done
>> >>running...printing oldest/median age/newest
>> >>
>> >>
>> >>***
>> >>*** runtime error:
>> >>***    An array subscript was out of range.
>> >>***    file "..\src\runtime\common\RTCollector.m3"=2C line 418
>> >>***
>> >>
>> >>
>> >>
>> >>***
>> >>*** runtime error:
>> >>***    <*ASSERT*> failed.
>> >>***    file "..\src\thread\WIN32\ThreadWin32.m3"=2C line 841
>> >>***
>> >>
>> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
>> >>
>> >>I'll send more info on the Windows install of Modula3 in a subsequent p=
>ost=3D
>> >.
>> >>
>> >>Regards=2C
>> >>Randy Coleburn
>> >>
>> >>-----Original Message-----
>> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D3D20
>> >>Sent: Saturday=2C February 26=2C 2011 12:55 PM
>> >>To: Coleburn=2C Randy
>> >>Cc: m3devel at elegosoft.com
>> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D3D20
>> >>
>> >>Hi Randy=2C
>> >>
>> >>Hm yes it looks like my Windows programming skills leave something
>> >>to be desired.
>> >>
>> >>You can run the thread tester while skipping a test as follows
>> >>
>> >>   threadtest -tests ALL=2C-fork
>> >>
>> >>(for instance)
>> >>
>> >>if you just run=3D3D20
>> >>
>> >>   threadtest -sadfassdaf
>> >>
>> >>it'll print the tests that are available.
>> >>
>> >>As it happens=2C I just had to upgrade my windows 2000 system to window=
>s 7.
>> >>Can you give me a very brief description of what you did to install Mod=
>ula=3D
>> >-=3D3D
>> >>3
>> >>on this system?
>> >>
>> >>     Mika
>> >>
>> >>"Coleburn=2C Randy" writes:
>> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
>> >>>Content-Type: text/plain=3B charset=3D3D3D"us-ascii"
>> >>>Content-Transfer-Encoding: quoted-printable
>> >>>
>> >>>Mika:
>> >>>
>> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
>> >>>
>> >>>So=2C I ran your threadtest program.
>> >>>
>> >>>Here are the results.  Note the "..." is where I cut out a bunch of th=
>e r=3D
>> >e=3D3D
>> >>p=3D3D3D
>> >>>eating "ERROR FApply" messages.
>> >>>
>> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
>> >>>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
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>.
>> >>>.
>> >>>.
>> >>>***
>> >>>*** runtime error:
>> >>>***    An enumeration or subrange value was out of range.
>> >>>***    file "..\src\Main.m3"=2C line 340
>> >>>***
>> >>>
>> >>>laziest thread is 0/0/ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: T=
>he sy=3D
>> >ste=3D3D
>> >>m c=3D3D3D
>> >>>annot find the file specified.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>.
>> >>>.
>> >>>.
>> >>>laziest thread is 0/0/ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: T=
>he sy=3D
>> >ste=3D3D
>> >>m c=3D3D3D
>> >>>annot find the file specified.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>.
>> >>>.
>> >>>.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>Stack trace:
>> >>>   FP         PC      Procedure
>> >>>---------  ---------  -------------------------------
>> >>>0x30fbd0  0x127218a  PutStats + 0x1a3 in ..\src\Main.m3
>> >>>0x30fcc0  0x1273825  Main_M3 + 0x11db(!) in ..\src\Main.m3
>> >>>
>> >>>Regards=2C
>> >>>Randy Coleburn
>> >>>
>> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
>> >>>Content-Type: text/html=3B charset=3D3D3D"us-ascii"
>> >>>Content-Transfer-Encoding: quoted-printable
>> >>>
> 		 	   		  =
>
>--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Tahoma
>}
>--></style>
></head>
><body class=3D'hmmessage'>
>I also haven't seen it fail on OpenBSD/x86/4.7. I'm pretty sure using pthre=
>ads there.<br>But on Solaris/5.10/sparc it hangs=2C for many hours.<br><br>=
>-bash-4.1$ ./threadtest <br>Writing file...done<br>Creating read threads...=
>done<br>Creating fork threads...done<br>Creating alloc threads...done<br>Cr=
>eating lock threads...done<br>running...printing oldest/median age/newest<b=
>r>.<br><br>Are we guranteed forward progress in suspending all threads?<br>=
><br>I do see it fail usually on Darwin. e.g.:<br>........pthread_mutex_dest=
>roy:EBUSY<br>pthread_mutex_destroy:EBUSY<br>..laziest thread is 0/0/0 (test=
>s: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)<br>...<br><br>***<br>*** r=
>untime error:<br>***&nbsp=3B&nbsp=3B&nbsp=3B An array subscript was out of =
>range.<br>***&nbsp=3B&nbsp=3B&nbsp=3B file "../src/runtime/common/RTCollect=
>or.m3"=2C line 418<br>***<br><br>I haven't tried Linux yet.<br>Do note that=
> we have some variance in the pthreads implementation.<br>The "portable" im=
>plementation is used on Linux=2C Solaris=2C NetBSD.<br>And then OpenBSD=2C =
>Darwin=2C FreeBSD each have slight differences.<br><br>Mika are your machin=
>es all multiprocessors?<br>I do wonder if that helps increase the stress an=
>d if I should be sure to use multiprocessors.<br><br>I'm also considering t=
>aking the time to try various historical versions=2C either releases or dat=
>es in CVS.<br><br>&nbsp=3B- Jay<br><br><hr id=3D"stopSpelling">From: jay.kr=
>ell at cornell.edu<br>To: mika at async.caltech.edu=3B rcolebur at scires.com<br>Dat=
>e: Tue=2C 1 Mar 2011 10:59:29 +0000<br>CC: m3devel at elegosoft.com<br>Subject=
>: Re: [M3devel] results of threadtest program on Windows7<br><br>
>
><meta http-equiv=3D"Content-Type" content=3D"text/html=3B charset=3Dunicode=
>">
><meta name=3D"Generator" content=3D"Microsoft SafeHTML">
><style>
>.ExternalClass .ecxhmmessage P
>{padding:0px=3B}
>.ExternalClass body.ecxhmmessage
>{font-size:10pt=3Bfont-family:Tahoma=3B}
>
></style>
>
>
>I haven't seen it fail on NT=2C except for PutCard in the test itself getti=
>ng negative numbers.<br>I've run it just a few times now. One single and du=
>al processor virtual machines.<br>Randy=2C has it failed many times for you=
>?<br><br>&nbsp=3B- Jay<br><br>&gt=3B To: rcolebur at SCIRES.COM<br>&gt=3B Date=
>: Sun=2C 27 Feb 2011 15:11:25 -0800<br>&gt=3B From: mika at async.caltech.edu<=
>br>&gt=3B CC: m3devel at elegosoft.com<br>&gt=3B Subject: Re: [M3devel] result=
>s of threadtest program on Windows7<br>&gt=3B <br>&gt=3B Ah=2C it just does=
>n't check command-line arguments that carefully.<br>&gt=3B <br>&gt=3B I thi=
>nk what you did is equivalent to "-tests STD".<br>&gt=3B <br>&gt=3B      Mi=
>ka<br>&gt=3B <br>&gt=3B "Coleburn=2C Randy" writes:<br>&gt=3B &gt=3BMika:<b=
>r>&gt=3B &gt=3B<br>&gt=3B &gt=3BNo change with "-tests POSIX".<br>&gt=3B &g=
>t=3B<br>&gt=3B &gt=3BInteresting twist:  On Windows 7=2C I thought I'd see =
>what the command line o=3D<br>&gt=3B &gt=3Bptions are=2C and I typed "threa=
>dtest -help" rather than reading the code.<br>&gt=3B &gt=3B<br>&gt=3B &gt=
>=3BFirst time=2C it produced what appears to be a NIL deref crash.  Then=2C=
> I trie=3D<br>&gt=3B &gt=3Bd it again and it ran to completion.  Something =
>seems non-deterministic her=3D<br>&gt=3B &gt=3Be.  See below.<br>&gt=3B &gt=
>=3B<br>&gt=3B &gt=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bt=
>hreadtest.exe -help<br>&gt=3B &gt=3BWriting file...done<br>&gt=3B &gt=3BCre=
>ating read threads...done<br>&gt=3B &gt=3BCreating fork threads...done<br>&=
>gt=3B &gt=3BCreating alloc threads...done<br>&gt=3B &gt=3BCreating lock thr=
>eads...done<br>&gt=3B &gt=3Brunning...printing oldest/median age/newest<br>=
>&gt=3B &gt=3B.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B***<br>&gt=3B &gt=3B*** run=
>time error:<br>&gt=3B &gt=3B***    Attempt to reference an illegal memory l=
>ocation.<br>&gt=3B &gt=3B***    pc =3D3D 0x77762262<br>&gt=3B &gt=3B***<br>=
>&gt=3B &gt=3B<br>&gt=3B &gt=3BStack trace:<br>&gt=3B &gt=3B   FP         PC=
>      Procedure<br>&gt=3B &gt=3B---------  ---------  ---------------------=
>----------<br>&gt=3B &gt=3B 0xcdf998  0x130351b  SystemError + 0x64 in ..\s=
>rc\runtime\NT386\RTSignal.m=3D<br>&gt=3B &gt=3B3<br>&gt=3B &gt=3B 0xcdf9c0 =
> 0x77762262  &lt=3B???&gt=3B<br>&gt=3B &gt=3B 0xcdf9d8  0x12e83b7  LockMute=
>x + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=3D<br>&gt=3B &gt=3B3<br>&gt=
>=3B &gt=3B 0xcdfa00  0x12c7b08  GetChar + 0x28 in ..\src\rw\Rd.m3<br>&gt=3B=
> &gt=3B 0xcdfb38  0x12c12e3  RApply + 0xd3 in ..\src\Main.m3<br>&gt=3B &gt=
>=3B 0xcdfb74  0x12e971f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWi=
>n32=3D<br>&gt=3B &gt=3B.m3<br>&gt=3B &gt=3B 0xcdfb80  0x76543677  &lt=3B???=
>&gt=3B<br>&gt=3B &gt=3B 0xcdfbc0  0x77779f02  &lt=3B???&gt=3B<br>&gt=3B &gt=
>=3B.........  .........  ... more frames ...<br>&gt=3B &gt=3B<br>&gt=3B &gt=
>=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest.exe -he=
>lp<br>&gt=3B &gt=3BWriting file...done<br>&gt=3B &gt=3BCreating read thread=
>s...done<br>&gt=3B &gt=3BCreating fork threads...done<br>&gt=3B &gt=3BCreat=
>ing alloc threads...done<br>&gt=3B &gt=3BCreating lock threads...done<br>&g=
>t=3B &gt=3Brunning...printing oldest/median age/newest<br>&gt=3B &gt=3B....=
>......laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=3D<=
>br>&gt=3B &gt=3B lock 0/0/0)<br>&gt=3B &gt=3B..........laziest thread is 0/=
>0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/=
>0)<br>&gt=3B &gt=3B..........laziest thread is 0/0/0 (tests: read 0/0/0 for=
>k 0/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/0)<br>&gt=3B &gt=3B.......=
>...laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=3D<br>=
>&gt=3B &gt=3B lock 0/0/0)<br>&gt=3B &gt=3B..........laziest thread is 0/0/0=
> (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/0)<=
>br>&gt=3B &gt=3B..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0=
>/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/0)<br>&gt=3B &gt=3B..........=
>laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=3D<br>&gt=
>=3B &gt=3B lock 0/0/0)<br>&gt=3B &gt=3B..........laziest thread is 0/0/0 (t=
ests: read 0/0/0 fork 0/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/0)<br>=
>&gt=3B &gt=3B..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/=
>0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/0)<br>&gt=3B &gt=3B..........laz=
>iest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=3D<br>&gt=3B=
> &gt=3B lock 0/0/0)<br>&gt=3B &gt=3BAll tests complete.  Congratulations.<b=
>r>&gt=3B &gt=3B<br>&gt=3B &gt=3BRegards=2C<br>&gt=3B &gt=3BRandy Coleburn<b=
>r>&gt=3B &gt=3B<br>&gt=3B &gt=3B-----Original Message-----<br>&gt=3B &gt=3B=
>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20<br>&gt=3B &gt=3BSen=
>t: Sunday=2C February 27=2C 2011 3:30 PM<br>&gt=3B &gt=3BTo: Coleburn=2C Ra=
>ndy<br>&gt=3B &gt=3BCc: m3devel at elegosoft.com<br>&gt=3B &gt=3BSubject: Re: =
>[M3devel] results of threadtest program on Windows7=3D20<br>&gt=3B &gt=3B<b=
>r>&gt=3B &gt=3BHi Randy=2C<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BYou can try it =
>with -tests POSIX as well.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BI find on user =
>threads it runs very slowly (but it does run) because of how=3D<br>&gt=3B &=
>gt=3B unfair<br>&gt=3B &gt=3Bthe thread scheduler is.<br>&gt=3B &gt=3B<br>&=
>gt=3B &gt=3BNext step might be to whittle down the tests and see if you can=
> get a failu=3D<br>&gt=3B &gt=3Bre with<br>&gt=3B &gt=3Ba single test runni=
>ng and -n 2.  That would likely be the simplest scenario=3D<br>&gt=3B &gt=
>=3B to<br>&gt=3B &gt=3Bstart further debugging from.<br>&gt=3B &gt=3B<br>&g=
>t=3B &gt=3B     Mika<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B"Coleburn=2C Randy" w=
>rites:<br>&gt=3B &gt=3B&gt=3BMika et al:<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &=
>gt=3B&gt=3BThought I would try something else.<br>&gt=3B &gt=3B&gt=3B<br>&g=
>t=3B &gt=3B&gt=3BI took the sources of your thread test program to an older=
> XP machine that=3D<br>&gt=3B &gt=3B =3D3D<br>&gt=3B &gt=3B&gt=3Bhas CM3 ci=
>rca August 2008.  This is the machine and implementation I used =3D<br>&gt=
>=3B &gt=3Bw=3D3D<br>&gt=3B &gt=3B&gt=3Bhen building a major project I did a=
> couple years back.<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3BThe thread=
> test program does indeed build on this old system=2C but when I r=3D<br>&g=
>t=3B &gt=3Bu=3D3D<br>&gt=3B &gt=3B&gt=3Bn it=2C I get different results tha=
>n with the latest HEAD branch code. =3D3D20<br>&gt=3B &gt=3B&gt=3B<br>&gt=
>=3B &gt=3B&gt=3BAfter it prints "running...printing oldest/median age/newes=
>t"=2C on the next=3D<br>&gt=3B &gt=3B =3D3D<br>&gt=3B &gt=3B&gt=3Bline I ge=
>t two periods ".." and now the program seems hung.  I'll let it "=3D<br>&gt=
>=3B &gt=3Br=3D3D<br>&gt=3B &gt=3B&gt=3Bun" for a few more minutes to see if=
> anything else happens before killing =3D<br>&gt=3B &gt=3Bi=3D3D<br>&gt=3B =
>&gt=3B&gt=3Bt.<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3BAt least we don=
>'t get the subscript and assertion failures on this older C=3D<br>&gt=3B &g=
>t=3BM=3D3D<br>&gt=3B &gt=3B&gt=3B3 platform.<br>&gt=3B &gt=3B&gt=3B<br>&gt=
>=3B &gt=3B&gt=3BRegards=2C<br>&gt=3B &gt=3B&gt=3BRandy Coleburn<br>&gt=3B &=
>gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B-----Original Mess=
>age-----<br>&gt=3B &gt=3B&gt=3BFrom: Coleburn=2C Randy=3D3D20<br>&gt=3B &gt=
>=3B&gt=3BSent: Sunday=2C February 27=2C 2011 2:09 PM<br>&gt=3B &gt=3B&gt=3B=
>To: m3devel at elegosoft.com<br>&gt=3B &gt=3B&gt=3BSubject: Re: [M3devel] resu=
>lts of threadtest program on Windows7<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=
>=3B&gt=3BMika:<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3BOk=2C I've upda=
>ted to latest HEAD and I've also built Jay's m3sleep program.<br>&gt=3B &gt=
>=3B&gt=3B<br>&gt=3B &gt=3B&gt=3BHere is what happens now when I run your th=
>readtest program on Windows 7.<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
>=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest -tests =
>ALL=2C-fo=3D<br>&gt=3B &gt=3Br=3D3D<br>&gt=3B &gt=3B&gt=3Bk<br>&gt=3B &gt=
>=3B&gt=3BWriting file...done<br>&gt=3B &gt=3B&gt=3BCreating read threads...=
>done<br>&gt=3B &gt=3B&gt=3BCreating nxread threads...done<br>&gt=3B &gt=3B&=
>gt=3BCreating tryexcept threads...done<br>&gt=3B &gt=3B&gt=3BCreating forkt=
>oomuch threads...done<br>&gt=3B &gt=3B&gt=3BCreating alloc threads...done<b=
>r>&gt=3B &gt=3B&gt=3BCreating creat threads...done<br>&gt=3B &gt=3B&gt=3BCr=
>eating lock threads...done<br>&gt=3B &gt=3B&gt=3Brunning...printing oldest/=
>median age/newest<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &=
>gt=3B&gt=3B***<br>&gt=3B &gt=3B&gt=3B*** runtime error:<br>&gt=3B &gt=3B&gt=
>=3B***    An array subscript was out of range.<br>&gt=3B &gt=3B&gt=3B***   =
> file "..\src\runtime\common\RTCollector.m3"=2C line 418<br>&gt=3B &gt=3B&g=
>t=3B***<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
>=3B<br>&gt=3B &gt=3B&gt=3B***<br>&gt=3B &gt=3B&gt=3B*** runtime error:<br>&=
>gt=3B &gt=3B&gt=3B***    &lt=3B*ASSERT*&gt=3B failed.<br>&gt=3B &gt=3B&gt=
>=3B***    file "..\src\thread\WIN32\ThreadWin32.m3"=2C line 841<br>&gt=3B &=
>gt=3B&gt=3B***<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3BThe last error =
>repeats ad infinitum until I press CNTRL-C to abort.<br>&gt=3B &gt=3B&gt=3B=
><br>&gt=3B &gt=3B&gt=3BI'll send more info on the Windows install of Modula=
>3 in a subsequent post=3D<br>&gt=3B &gt=3B.<br>&gt=3B &gt=3B&gt=3B<br>&gt=
>=3B &gt=3B&gt=3BRegards=2C<br>&gt=3B &gt=3B&gt=3BRandy Coleburn<br>&gt=3B &=
>gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B-----Original Message-----<br>&gt=3B &gt=
>=3B&gt=3BFrom: Mika Nystrom [mailto:mika at async.caltech.edu]=3D3D20<br>&gt=
>=3B &gt=3B&gt=3BSent: Saturday=2C February 26=2C 2011 12:55 PM<br>&gt=3B &g=
>t=3B&gt=3BTo: Coleburn=2C Randy<br>&gt=3B &gt=3B&gt=3BCc: m3devel at elegosoft=
>.com<br>&gt=3B &gt=3B&gt=3BSubject: Re: [M3devel] results of threadtest pro=
>gram on Windows7=3D3D20<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3BHi Ran=
>dy=2C<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3BHm yes it looks like my =
>Windows programming skills leave something<br>&gt=3B &gt=3B&gt=3Bto be desi=
>red.<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3BYou can run the thread te=
>ster while skipping a test as follows<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=
>=3B&gt=3B   threadtest -tests ALL=2C-fork<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B =
>&gt=3B&gt=3B(for instance)<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3Bif =
>you just run=3D3D20<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B   threadt=
>est -sadfassdaf<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3Bit'll print th=
>e tests that are available.<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3BAs=
> it happens=2C I just had to upgrade my windows 2000 system to windows 7.<b=
>r>&gt=3B &gt=3B&gt=3BCan you give me a very brief description of what you d=
>id to install Modula=3D<br>&gt=3B &gt=3B-=3D3D<br>&gt=3B &gt=3B&gt=3B3<br>&=
>gt=3B &gt=3B&gt=3Bon this system?<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&g=
>t=3B     Mika<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B"Coleburn=2C Ran=
>dy" writes:<br>&gt=3B &gt=3B&gt=3B&gt=3B--_000_D67F02DDC62F7545A6B84C285F88=
>F3E6EE25C849atlex02srv_<br>&gt=3B &gt=3B&gt=3B&gt=3BContent-Type: text/plai=
>n=3B charset=3D3D3D"us-ascii"<br>&gt=3B &gt=3B&gt=3B&gt=3BContent-Transfer-=
>Encoding: quoted-printable<br>&gt=3B &gt=3B&gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
>=3B&gt=3BMika:<br>&gt=3B &gt=3B&gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B&gt=3BI'v=
>e finally managed to get cm3 rebuilt on Windows 7 again.<br>&gt=3B &gt=3B&g=
>t=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B&gt=3BSo=2C I ran your threadtest program.=
><br>&gt=3B &gt=3B&gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B&gt=3BHere are the resu=
>lts.  Note the "..." is where I cut out a bunch of the r=3D<br>&gt=3B &gt=
>=3Be=3D3D<br>&gt=3B &gt=3B&gt=3Bp=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Beating=
> "ERROR FApply" messages.<br>&gt=3B &gt=3B&gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
>=3B&gt=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest.e=
>xe<br>&gt=3B &gt=3B&gt=3B&gt=3BWriting file...done<br>&gt=3B &gt=3B&gt=3B&g=
>t=3BCreating read threads...done<br>&gt=3B &gt=3B&gt=3B&gt=3BCreating fork =
>threads...done<br>&gt=3B &gt=3B&gt=3B&gt=3BCreating alloc threads...done<br=
>>&gt=3B &gt=3B&gt=3B&gt=3BCreating lock threads...done<br>&gt=3B &gt=3B&gt=
>=3B&gt=3Brunning...printing oldest/median age/newest<br>&gt=3B &gt=3B&gt=3B=
>&gt=3BERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find=
> the f=3D<br>&gt=3B &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B sp=3D3D3D<br>&gt=
>=3B &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B &gt=3B&gt=3B&gt=3BERROR FApply: OS=
>Error.E:  ErrorCode=3D3D3D3D2: The system cannot find the f=3D<br>&gt=3B &g=
>t=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B sp=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Be=
>cified.<br>&gt=3B &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E:  ErrorCode=3D3=
>D3D3D2: The system cannot find the f=3D<br>&gt=3B &gt=3Bile=3D3D<br>&gt=3B =
>&gt=3B&gt=3B sp=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B &gt=
>=3B&gt=3B&gt=3B.<br>&gt=3B &gt=3B&gt=3B&gt=3B.<br>&gt=3B &gt=3B&gt=3B&gt=3B=
>.<br>&gt=3B &gt=3B&gt=3B&gt=3B***<br>&gt=3B &gt=3B&gt=3B&gt=3B*** runtime e=
>rror:<br>&gt=3B &gt=3B&gt=3B&gt=3B***    An enumeration or subrange value w=
>as out of range.<br>&gt=3B &gt=3B&gt=3B&gt=3B***    file "..\src\Main.m3"=
>=2C line 340<br>&gt=3B &gt=3B&gt=3B&gt=3B***<br>&gt=3B &gt=3B&gt=3B&gt=3B<b=
>r>&gt=3B &gt=3B&gt=3B&gt=3Blaziest thread is 0/0/ERROR FApply: OSError.E:  =
>ErrorCode=3D3D3D3D2: The sy=3D<br>&gt=3B &gt=3Bste=3D3D<br>&gt=3B &gt=3B&gt=
>=3Bm c=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Bannot find the file specified.<br=
>>&gt=3B &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: Th=
>e system cannot find the f=3D<br>&gt=3B &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=
>=3B sp=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B &gt=3B&gt=3B&g=
>t=3BERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find t=
>he f=3D<br>&gt=3B &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B sp=3D3D3D<br>&gt=3B=
> &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B &gt=3B&gt=3B&gt=3BERROR FApply: OSErr=
>or.E:  ErrorCode=3D3D3D3D2: The system cannot find the f=3D<br>&gt=3B &gt=
>=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B sp=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Bec=
>ified.<br>&gt=3B &gt=3B&gt=3B&gt=3B.<br>&gt=3B &gt=3B&gt=3B&gt=3B.<br>&gt=
>=3B &gt=3B&gt=3B&gt=3B.<br>&gt=3B &gt=3B&gt=3B&gt=3Blaziest thread is 0/0/E=
>RROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The sy=3D<br>&gt=3B &gt=3Bste=
>=3D3D<br>&gt=3B &gt=3B&gt=3Bm c=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Bannot fi=
>nd the file specified.<br>&gt=3B &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E:=
>  ErrorCode=3D3D3D3D2: The system cannot find the f=3D<br>&gt=3B &gt=3Bile=
>=3D3D<br>&gt=3B &gt=3B&gt=3B sp=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Becified.=
><br>&gt=3B &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2:=
> The system cannot find the f=3D<br>&gt=3B &gt=3Bile=3D3D<br>&gt=3B &gt=3B&=
>gt=3B sp=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B &gt=3B&gt=3B=
>&gt=3BERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find=
> the f=3D<br>&gt=3B &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B sp=3D3D3D<br>&gt=
>=3B &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B &gt=3B&gt=3B&gt=3B.<br>&gt=3B &gt=
>=3B&gt=3B&gt=3B.<br>&gt=3B &gt=3B&gt=3B&gt=3B.<br>&gt=3B &gt=3B&gt=3B&gt=3B=
>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find the f=
>=3D<br>&gt=3B &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B sp=3D3D3D<br>&gt=3B &gt=
>=3B&gt=3B&gt=3Becified.<br>&gt=3B &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E=
>:  ErrorCode=3D3D3D3D2: The system cannot find the f=3D<br>&gt=3B &gt=3Bile=
>=3D3D<br>&gt=3B &gt=3B&gt=3B sp=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Becified.=
><br>&gt=3B &gt=3B&gt=3B&gt=3BStack trace:<br>&gt=3B &gt=3B&gt=3B&gt=3B   FP=
>         PC      Procedure<br>&gt=3B &gt=3B&gt=3B&gt=3B---------  ---------=
>  -------------------------------<br>&gt=3B &gt=3B&gt=3B&gt=3B0x30fbd0  0x1=
>27218a  PutStats + 0x1a3 in ..\src\Main.m3<br>&gt=3B &gt=3B&gt=3B&gt=3B0x30=
>fcc0  0x1273825  Main_M3 + 0x11db(!) in ..\src\Main.m3<br>&gt=3B &gt=3B&gt=
>=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B&gt=3BRegards=2C<br>&gt=3B &gt=3B&gt=3B&gt=
>=3BRandy Coleburn<br>&gt=3B &gt=3B&gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B&gt=3B=
>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_<br>&gt=3B &gt=3B=
>&gt=3B&gt=3BContent-Type: text/html=3B charset=3D3D3D"us-ascii"<br>&gt=3B &=
>gt=3B&gt=3B&gt=3BContent-Transfer-Encoding: quoted-printable<br>&gt=3B &gt=
>=3B&gt=3B&gt=3B<br> 		 	   		  </body>
></html>=
>
>--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_--


From dabenavidesd at yahoo.es  Tue Mar  1 23:10:55 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 1 Mar 2011 22:10:55 +0000 (GMT)
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <20110301181718.12EFC1A2078@async.async.caltech.edu>
Message-ID: <452042.5906.qm@web29706.mail.ird.yahoo.com>

Hi all:
but you could still run a *nix image with uniprocessor support kernel and try on the vbox, qemu, etc.
Perhaps you would get enough simulation to detect that the problem is on the hardware layer (either physically or its abstraction) rather than the execution model (the pthreads scheduling policy), if it does no work may be there is a problem in ThreadPthread implementation of pthreads (don't need to switch its default is - smp 1).
commands i.e in qemu:
qemu -cdrom /path/to/system.iso -smp 2 
and run threadtest from there

Thanks in advance


 



--- El mar, 1/3/11, Mika Nystrom <mika at async.caltech.edu> escribi?:

> De: Mika Nystrom <mika at async.caltech.edu>
> Asunto: Re: [M3devel] results of threadtest program on Windows7
> Para: "Jay K" <jay.krell at cornell.edu>
> CC: m3devel at elegosoft.com
> Fecha: martes, 1 de marzo, 2011 13:17
> 
> Hi Jay,
> 
> 1. I think you should get forward progress no matter what,
> although it
> might be very slow on some systems.
> 
> 2. Not sure how you could get negative timings.  That
> would suggest that
> Time.Now() is decreasing---which seems contrary to its
> specification.
> Although the code is doing some nasty stuff with the
> timings, mainly
> reading and writing them without locks.  But it's
> using INTEGER for
> the results so I don't think there can be an atomicity
> problem there.
> Even if there were coherence problems between processors
> (is this
> technically possible?) the "now" value has to be coherent
> since it's
> from the thread that prints the results, and the "then"
> values could
> only be getting older, not newer...
> 
> 3. Note that there are systems (FreeBSD 4 is an example)
> that have a
> "pthreads" library but where the pthreads library is
> implemented with
> user threads.  Could that be related to why OpenBSD is
> working?
> 
> 4. Hm.  I think I am only using multiprocessor
> systems, yes.  Hard to
> find single-CPU systems nowadays!  I think actually
> the only one I have
> is PPC_DARWIN, and I haven't tried the code on that. 
> So yes this is a
> possibility as far as explaining differences...
> 
>      Mika
> 
> Jay K writes:
> >--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_
> >Content-Type: text/plain; charset="iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
> >
> >
> >I also haven't seen it fail on OpenBSD/x86/4.7. I'm
> pretty sure using pthre=
> >ads there.
> >But on Solaris/5.10/sparc it hangs=2C for many hours.
> >
> >-bash-4.1$ ./threadtest=20
> >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
> >.
> >
> >Are we guranteed forward progress in suspending all
> threads?
> >
> >I do see it fail usually on Darwin. e.g.:
> >........pthread_mutex_destroy:EBUSY
> >pthread_mutex_destroy:EBUSY
> >..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:
> >***    An array subscript was out of range.
> >***    file
> "../src/runtime/common/RTCollector.m3"=2C line 418
> >***
> >
> >I haven't tried Linux yet.
> >Do note that we have some variance in the pthreads
> implementation.
> >The "portable" implementation is used on Linux=2C
> Solaris=2C NetBSD.
> >And then OpenBSD=2C Darwin=2C FreeBSD each have slight
> differences.
> >
> >Mika are your machines all multiprocessors?
> >I do wonder if that helps increase the stress and if I
> should be sure to us=
> >e multiprocessors.
> >
> >I'm also considering taking the time to try various
> historical versions=2C =
> >either releases or dates in CVS.
> >
> > - Jay
> >
> >From: jay.krell at cornell.edu
> >To: mika at async.caltech.edu=3B
> rcolebur at scires.com
> >Date: Tue=2C 1 Mar 2011 10:59:29 +0000
> >CC: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on
> Windows7
> >
> >
> >
> >
> >
> >
> >
> >
> >I haven't seen it fail on NT=2C except for PutCard in
> the test itself getti=
> >ng negative numbers.
> >I've run it just a few times now. One single and dual
> processor virtual mac=
> >hines.
> >Randy=2C has it failed many times for you?
> >
> > - Jay
> >
> >> To: rcolebur at SCIRES.COM
> >> Date: Sun=2C 27 Feb 2011 15:11:25 -0800
> >> From: mika at async.caltech.edu
> >> CC: m3devel at elegosoft.com
> >> Subject: Re: [M3devel] results of threadtest
> program on Windows7
> >>=20
> >> Ah=2C it just doesn't check command-line arguments
> that carefully.
> >>=20
> >> I think what you did is equivalent to "-tests
> STD".
> >=20
> >>      Mika
> >>=20
> >> "Coleburn=2C Randy" writes:
> >> >Mika:
> >> >
> >> >No change with "-tests POSIX".
> >> >
> >> >Interesting twist:  On Windows 7=2C I
> thought I'd see what the command l=
> >ine o=3D
> >> >ptions are=2C and I typed "threadtest -help"
> rather than reading the cod=
> >e.
> >> >
> >> >First time=2C it produced what appears to be a
> NIL deref crash.  Then=2C=
> > I trie=3D
> >> >d it again and it ran to completion. 
> Something seems non-deterministic =
> >her=3D
> >> >e.  See below.
> >> >
> >>
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> -help
> >> >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
> >> >.
> >> >
> >> >***
> >> >*** runtime error:
> >> >***    Attempt to reference an
> illegal memory location.
> >> >***    pc =3D3D 0x77762262
> >> >***
> >> >
> >> >Stack trace:
> >> >   FP     
>    PC      Procedure
> >> >---------  --------- 
> -------------------------------
> >> > 0xcdf998  0x130351b  SystemError +
> 0x64 in ..\src\runtime\NT386\RTSigna=
> >l.m=3D
> >> >3
> >> > 0xcdf9c0  0x77762262  <???>
> >> > 0xcdf9d8  0x12e83b7  LockMutex +
> 0x4f in ..\src\thread\WIN32\ThreadWin3=
> >2.m=3D
> >> >3
> >> > 0xcdfa00  0x12c7b08  GetChar + 0x28
> in ..\src\rw\Rd.m3
> >> > 0xcdfb38  0x12c12e3  RApply + 0xd3
> in ..\src\Main.m3
> >> > 0xcdfb74  0x12e971f  ThreadBase +
> 0x254 in ..\src\thread\WIN32\ThreadWi=
> >n32=3D
> >> >.m3
> >> > 0xcdfb80  0x76543677  <???>
> >> > 0xcdfbc0  0x77779f02  <???>
> >> >.........  .........  ... more
> frames ...
> >> >
> >>
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> -help
> >> >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
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >All tests complete.  Congratulations.
> >> >
> >> >Regards=2C
> >> >Randy Coleburn
> >> >
> >> >-----Original Message-----
> >> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >> >Sent: Sunday=2C February 27=2C 2011 3:30 PM
> >> >To: Coleburn=2C Randy
> >> >Cc: m3devel at elegosoft.com
> >> >Subject: Re: [M3devel] results of threadtest
> program on Windows7=3D20
> >> >
> >> >Hi Randy=2C
> >> >
> >> >You can try it with -tests POSIX as well.
> >> >
> >> >I find on user threads it runs very slowly
> (but it does run) because of =
> >how=3D
> >> > unfair
> >> >the thread scheduler is.
> >> >
> >> >Next step might be to whittle down the tests
> and see if you can get a fa=
> >ilu=3D
> >> >re with
> >> >a single test running and -n 2.  That
> would likely be the simplest scena=
> >rio=3D
> >> > to
> >> >start further debugging from.
> >> >
> >> >     Mika
> >> >
> >> >"Coleburn=2C Randy" writes:
> >> >>Mika et al:
> >> >>
> >> >>Thought I would try something else.
> >> >>
> >> >>I took the sources of your thread test
> program to an older XP machine t=
> >hat=3D
> >> > =3D3D
> >> >>has CM3 circa August 2008.  This is
> the machine and implementation I us=
> >ed =3D
> >> >w=3D3D
> >> >>hen building a major project I did a
> couple years back.
> >> >>
> >> >>The thread test program does indeed build
> on this old system=2C but whe=
> >n I r=3D
> >> >u=3D3D
> >> >>n it=2C I get different results than with
> the latest HEAD branch code. =
> >=3D3D20
> >> >>
> >> >>After it prints "running...printing
> oldest/median age/newest"=2C on the=
> > next=3D
> >> > =3D3D
> >> >>line I get two periods ".." and now the
> program seems hung.  I'll let i=
> >t "=3D
> >> >r=3D3D
> >> >>un" for a few more minutes to see if
> anything else happens before killi=
> >ng =3D
> >> >i=3D3D
> >> >>t.
> >> >>
> >> >>At least we don't get the subscript and
> assertion failures on this olde=
> >r C=3D
> >> >M=3D3D
> >> >>3 platform.
> >> >>
> >> >>Regards=2C
> >> >>Randy Coleburn
> >> >>
> >> >>
> >> >>-----Original Message-----
> >> >>From: Coleburn=2C Randy=3D3D20
> >> >>Sent: Sunday=2C February 27=2C 2011 2:09
> PM
> >> >>To: m3devel at elegosoft.com
> >> >>Subject: Re: [M3devel] results of
> threadtest program on Windows7
> >> >>
> >> >>Mika:
> >> >>
> >> >>Ok=2C I've updated to latest HEAD and I've
> also built Jay's m3sleep pro=
> >gram.
> >> >>
> >> >>Here is what happens now when I run your
> threadtest program on Windows =
> >7.
> >> >>
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest
> -tests ALL=
> >=2C-fo=3D
> >> >r=3D3D
> >> >>k
> >> >>Writing file...done
> >> >>Creating read threads...done
> >> >>Creating nxread threads...done
> >> >>Creating tryexcept threads...done
> >> >>Creating forktoomuch threads...done
> >> >>Creating alloc threads...done
> >> >>Creating creat threads...done
> >> >>Creating lock threads...done
> >> >>running...printing oldest/median
> age/newest
> >> >>
> >> >>
> >> >>***
> >> >>*** runtime error:
> >> >>***    An array subscript was
> out of range.
> >> >>***    file
> "..\src\runtime\common\RTCollector.m3"=2C line 418
> >> >>***
> >> >>
> >> >>
> >> >>
> >> >>***
> >> >>*** runtime error:
> >> >>***    <*ASSERT*> failed.
> >> >>***    file
> "..\src\thread\WIN32\ThreadWin32.m3"=2C line 841
> >> >>***
> >> >>
> >> >>The last error repeats ad infinitum until
> I press CNTRL-C to abort.
> >> >>
> >> >>I'll send more info on the Windows install
> of Modula3 in a subsequent p=
> >ost=3D
> >> >.
> >> >>
> >> >>Regards=2C
> >> >>Randy Coleburn
> >> >>
> >> >>-----Original Message-----
> >> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D3D20
> >> >>Sent: Saturday=2C February 26=2C 2011
> 12:55 PM
> >> >>To: Coleburn=2C Randy
> >> >>Cc: m3devel at elegosoft.com
> >> >>Subject: Re: [M3devel] results of
> threadtest program on Windows7=3D3D20
> >> >>
> >> >>Hi Randy=2C
> >> >>
> >> >>Hm yes it looks like my Windows
> programming skills leave something
> >> >>to be desired.
> >> >>
> >> >>You can run the thread tester while
> skipping a test as follows
> >> >>
> >> >>   threadtest -tests
> ALL=2C-fork
> >> >>
> >> >>(for instance)
> >> >>
> >> >>if you just run=3D3D20
> >> >>
> >> >>   threadtest -sadfassdaf
> >> >>
> >> >>it'll print the tests that are available.
> >> >>
> >> >>As it happens=2C I just had to upgrade my
> windows 2000 system to window=
> >s 7.
> >> >>Can you give me a very brief description
> of what you did to install Mod=
> >ula=3D
> >> >-=3D3D
> >> >>3
> >> >>on this system?
> >> >>
> >> >>     Mika
> >> >>
> >> >>"Coleburn=2C Randy" writes:
> >>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >> >>>Content-Type: text/plain=3B
> charset=3D3D3D"us-ascii"
> >> >>>Content-Transfer-Encoding:
> quoted-printable
> >> >>>
> >> >>>Mika:
> >> >>>
> >> >>>I've finally managed to get cm3
> rebuilt on Windows 7 again.
> >> >>>
> >> >>>So=2C I ran your threadtest program.
> >> >>>
> >> >>>Here are the results.  Note the
> "..." is where I cut out a bunch of th=
> >e r=3D
> >> >e=3D3D
> >> >>p=3D3D3D
> >> >>>eating "ERROR FApply" messages.
> >> >>>
> >>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >> >>>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
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>.
> >> >>>.
> >> >>>.
> >> >>>***
> >> >>>*** runtime error:
> >> >>>***    An enumeration or
> subrange value was out of range.
> >> >>>***    file
> "..\src\Main.m3"=2C line 340
> >> >>>***
> >> >>>
> >> >>>laziest thread is 0/0/ERROR FApply:
> OSError.E:  ErrorCode=3D3D3D3D2: T=
> >he sy=3D
> >> >ste=3D3D
> >> >>m c=3D3D3D
> >> >>>annot find the file specified.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>.
> >> >>>.
> >> >>>.
> >> >>>laziest thread is 0/0/ERROR FApply:
> OSError.E:  ErrorCode=3D3D3D3D2: T=
> >he sy=3D
> >> >ste=3D3D
> >> >>m c=3D3D3D
> >> >>>annot find the file specified.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>.
> >> >>>.
> >> >>>.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>Stack trace:
> >> >>>   FP   
>      PC      Procedure
> >> >>>---------  --------- 
> -------------------------------
> >> >>>0x30fbd0  0x127218a 
> PutStats + 0x1a3 in ..\src\Main.m3
> >> >>>0x30fcc0  0x1273825  Main_M3
> + 0x11db(!) in ..\src\Main.m3
> >> >>>
> >> >>>Regards=2C
> >> >>>Randy Coleburn
> >> >>>
> >>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >> >>>Content-Type: text/html=3B
> charset=3D3D3D"us-ascii"
> >> >>>Content-Transfer-Encoding:
> quoted-printable
> >> >>>
> >    
>         
>           
>   =
> >
> >--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_
> >Content-Type: text/html; charset="iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
> >
> ><html>
> ><head>
> ><style><!--
> >.hmmessage P
> >{
> >margin:0px=3B
> >padding:0px
> >}
> >body.hmmessage
> >{
> >font-size: 10pt=3B
> >font-family:Tahoma
> >}
> >--></style>
> ></head>
> ><body class=3D'hmmessage'>
> >I also haven't seen it fail on OpenBSD/x86/4.7. I'm
> pretty sure using pthre=
> >ads there.<br>But on Solaris/5.10/sparc it
> hangs=2C for many hours.<br><br>=
> >-bash-4.1$ ./threadtest <br>Writing
> file...done<br>Creating read threads...=
> >done<br>Creating fork
> threads...done<br>Creating alloc
> threads...done<br>Cr=
> >eating lock threads...done<br>running...printing
> oldest/median age/newest<b=
> >r>.<br><br>Are we guranteed forward
> progress in suspending all threads?<br>=
> ><br>I do see it fail usually on Darwin.
> e.g.:<br>........pthread_mutex_dest=
> >roy:EBUSY<br>pthread_mutex_destroy:EBUSY<br>..laziest
> thread is 0/0/0 (test=
> >s: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock
> 0/0/0)<br>...<br><br>***<br>*** r=
> >untime
> error:<br>***&nbsp=3B&nbsp=3B&nbsp=3B An
> array subscript was out of =
> >range.<br>***&nbsp=3B&nbsp=3B&nbsp=3B
> file "../src/runtime/common/RTCollect=
> >or.m3"=2C line 418<br>***<br><br>I
> haven't tried Linux yet.<br>Do note that=
> > we have some variance in the pthreads
> implementation.<br>The "portable" im=
> >plementation is used on Linux=2C Solaris=2C
> NetBSD.<br>And then OpenBSD=2C =
> >Darwin=2C FreeBSD each have slight
> differences.<br><br>Mika are your machin=
> >es all multiprocessors?<br>I do wonder if that
> helps increase the stress an=
> >d if I should be sure to use
> multiprocessors.<br><br>I'm also considering t=
> >aking the time to try various historical versions=2C
> either releases or dat=
> >es in CVS.<br><br>&nbsp=3B-
> Jay<br><br><hr id=3D"stopSpelling">From:
> jay.kr=
> >ell at cornell.edu<br>To:
> mika at async.caltech.edu=3B
> rcolebur at scires.com<br>Dat=
> >e: Tue=2C 1 Mar 2011 10:59:29 +0000<br>CC: m3devel at elegosoft.com<br>Subject=
> >: Re: [M3devel] results of threadtest program on
> Windows7<br><br>
> >
> ><meta http-equiv=3D"Content-Type"
> content=3D"text/html=3B charset=3Dunicode=
> >">
> ><meta name=3D"Generator" content=3D"Microsoft
> SafeHTML">
> ><style>
> >.ExternalClass .ecxhmmessage P
> >{padding:0px=3B}
> >.ExternalClass body.ecxhmmessage
> >{font-size:10pt=3Bfont-family:Tahoma=3B}
> >
> ></style>
> >
> >
> >I haven't seen it fail on NT=2C except for PutCard in
> the test itself getti=
> >ng negative numbers.<br>I've run it just a few
> times now. One single and du=
> >al processor virtual machines.<br>Randy=2C has it
> failed many times for you=
> >?<br><br>&nbsp=3B-
> Jay<br><br>&gt=3B To: rcolebur at SCIRES.COM<br>&gt=3B
> Date=
> >: Sun=2C 27 Feb 2011 15:11:25 -0800<br>&gt=3B
> From: mika at async.caltech.edu<=
> >br>&gt=3B CC: m3devel at elegosoft.com<br>&gt=3B
> Subject: Re: [M3devel] result=
> >s of threadtest program on Windows7<br>&gt=3B
> <br>&gt=3B Ah=2C it just does=
> >n't check command-line arguments that
> carefully.<br>&gt=3B <br>&gt=3B I thi=
> >nk what you did is equivalent to "-tests
> STD".<br>&gt=3B <br>&gt=3B   
>   Mi=
> >ka<br>&gt=3B <br>&gt=3B
> "Coleburn=2C Randy" writes:<br>&gt=3B
> &gt=3BMika:<b=
> >r>&gt=3B &gt=3B<br>&gt=3B
> &gt=3BNo change with "-tests POSIX".<br>&gt=3B
> &g=
> >t=3B<br>&gt=3B &gt=3BInteresting
> twist:  On Windows 7=2C I thought I'd see =
> >what the command line o=3D<br>&gt=3B
> &gt=3Bptions are=2C and I typed "threa=
> >dtest -help" rather than reading the
> code.<br>&gt=3B &gt=3B<br>&gt=3B
> &gt=
> >=3BFirst time=2C it produced what appears to be a NIL
> deref crash.  Then=2C=
> > I trie=3D<br>&gt=3B &gt=3Bd it again and
> it ran to completion.  Something =
> >seems non-deterministic her=3D<br>&gt=3B
> &gt=3Be.  See below.<br>&gt=3B &gt=
> >=3B<br>&gt=3B
> &gt=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bt=
> >hreadtest.exe -help<br>&gt=3B
> &gt=3BWriting file...done<br>&gt=3B
> &gt=3BCre=
> >ating read threads...done<br>&gt=3B
> &gt=3BCreating fork threads...done<br>&=
> >gt=3B &gt=3BCreating alloc
> threads...done<br>&gt=3B &gt=3BCreating lock
> thr=
> >eads...done<br>&gt=3B
> &gt=3Brunning...printing oldest/median
> age/newest<br>=
> >&gt=3B &gt=3B.<br>&gt=3B
> &gt=3B<br>&gt=3B
> &gt=3B***<br>&gt=3B &gt=3B*** run=
> >time error:<br>&gt=3B &gt=3B*** 
>   Attempt to reference an illegal memory l=
> >ocation.<br>&gt=3B &gt=3B***   
> pc =3D3D 0x77762262<br>&gt=3B
> &gt=3B***<br>=
> >&gt=3B &gt=3B<br>&gt=3B
> &gt=3BStack trace:<br>&gt=3B
> &gt=3B   FP     
>    PC=
> >      Procedure<br>&gt=3B
> &gt=3B---------  --------- 
> ---------------------=
> >----------<br>&gt=3B &gt=3B
> 0xcdf998  0x130351b  SystemError + 0x64 in ..\s=
> >rc\runtime\NT386\RTSignal.m=3D<br>&gt=3B
> &gt=3B3<br>&gt=3B &gt=3B 0xcdf9c0 =
> > 0x77762262 
> &lt=3B???&gt=3B<br>&gt=3B &gt=3B
> 0xcdf9d8  0x12e83b7  LockMute=
> >x + 0x4f in
> ..\src\thread\WIN32\ThreadWin32.m=3D<br>&gt=3B
> &gt=3B3<br>&gt=
> >=3B &gt=3B 0xcdfa00  0x12c7b08  GetChar +
> 0x28 in ..\src\rw\Rd.m3<br>&gt=3B=
> > &gt=3B 0xcdfb38  0x12c12e3  RApply +
> 0xd3 in ..\src\Main.m3<br>&gt=3B &gt=
> >=3B 0xcdfb74  0x12e971f  ThreadBase + 0x254
> in ..\src\thread\WIN32\ThreadWi=
> >n32=3D<br>&gt=3B
> &gt=3B.m3<br>&gt=3B &gt=3B 0xcdfb80 
> 0x76543677  &lt=3B???=
> >&gt=3B<br>&gt=3B &gt=3B
> 0xcdfbc0  0x77779f02 
> &lt=3B???&gt=3B<br>&gt=3B &gt=
> >=3B.........  .........  ... more frames
> ...<br>&gt=3B &gt=3B<br>&gt=3B
> &gt=
> >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest.exe
> -he=
> >lp<br>&gt=3B &gt=3BWriting
> file...done<br>&gt=3B &gt=3BCreating read
> thread=
> >s...done<br>&gt=3B &gt=3BCreating fork
> threads...done<br>&gt=3B &gt=3BCreat=
> >ing alloc threads...done<br>&gt=3B
> &gt=3BCreating lock threads...done<br>&g=
> >t=3B &gt=3Brunning...printing oldest/median
> age/newest<br>&gt=3B &gt=3B....=
> >......laziest thread is 0/0/0 (tests: read 0/0/0 fork
> 0/0/0 alloc 0/0/0=3D<=
> >br>&gt=3B &gt=3B lock
> 0/0/0)<br>&gt=3B &gt=3B..........laziest
> thread is 0/=
> >0/0 (tests: read 0/0/0 fork 0/0/0 alloc
> 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/=
> >0)<br>&gt=3B &gt=3B..........laziest
> thread is 0/0/0 (tests: read 0/0/0 for=
> >k 0/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B
> lock 0/0/0)<br>&gt=3B &gt=3B.......=
> >...laziest thread is 0/0/0 (tests: read 0/0/0 fork
> 0/0/0 alloc 0/0/0=3D<br>=
> >&gt=3B &gt=3B lock 0/0/0)<br>&gt=3B
> &gt=3B..........laziest thread is 0/0/0=
> > (tests: read 0/0/0 fork 0/0/0 alloc
> 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/0)<=
> >br>&gt=3B &gt=3B..........laziest thread is
> 0/0/0 (tests: read 0/0/0 fork 0=
> >/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock
> 0/0/0)<br>&gt=3B &gt=3B..........=
> >laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0
> alloc 0/0/0=3D<br>&gt=
> >=3B &gt=3B lock 0/0/0)<br>&gt=3B
> &gt=3B..........laziest thread is 0/0/0 (t=
> ests: read 0/0/0 fork 0/0/0 alloc
> 0/0/0=3D<br>&gt=3B &gt=3B lock
> 0/0/0)<br>=
> >&gt=3B &gt=3B..........laziest thread is 0/0/0
> (tests: read 0/0/0 fork 0/0/=
> >0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock
> 0/0/0)<br>&gt=3B &gt=3B..........laz=
> >iest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0
> alloc 0/0/0=3D<br>&gt=3B=
> > &gt=3B lock 0/0/0)<br>&gt=3B
> &gt=3BAll tests complete.  Congratulations.<b=
> >r>&gt=3B &gt=3B<br>&gt=3B
> &gt=3BRegards=2C<br>&gt=3B &gt=3BRandy
> Coleburn<b=
> >r>&gt=3B &gt=3B<br>&gt=3B
> &gt=3B-----Original Message-----<br>&gt=3B
> &gt=3B=
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20<br>&gt=3B
> &gt=3BSen=
> >t: Sunday=2C February 27=2C 2011 3:30
> PM<br>&gt=3B &gt=3BTo: Coleburn=2C Ra=
> >ndy<br>&gt=3B &gt=3BCc: m3devel at elegosoft.com<br>&gt=3B
> &gt=3BSubject: Re: =
> >[M3devel] results of threadtest program on
> Windows7=3D20<br>&gt=3B &gt=3B<b=
> >r>&gt=3B &gt=3BHi
> Randy=2C<br>&gt=3B &gt=3B<br>&gt=3B
> &gt=3BYou can try it =
> >with -tests POSIX as well.<br>&gt=3B
> &gt=3B<br>&gt=3B &gt=3BI find on user =
> >threads it runs very slowly (but it does run) because
> of how=3D<br>&gt=3B &=
> >gt=3B unfair<br>&gt=3B &gt=3Bthe thread
> scheduler is.<br>&gt=3B
> &gt=3B<br>&=
> >gt=3B &gt=3BNext step might be to whittle down the
> tests and see if you can=
> > get a failu=3D<br>&gt=3B &gt=3Bre
> with<br>&gt=3B &gt=3Ba single test runni=
> >ng and -n 2.  That would likely be the simplest
> scenario=3D<br>&gt=3B &gt=
> >=3B to<br>&gt=3B &gt=3Bstart further
> debugging from.<br>&gt=3B
> &gt=3B<br>&g=
> >t=3B &gt=3B 
>    Mika<br>&gt=3B
> &gt=3B<br>&gt=3B &gt=3B"Coleburn=2C Randy"
> w=
> >rites:<br>&gt=3B &gt=3B&gt=3BMika et
> al:<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B &=
> >gt=3B&gt=3BThought I would try something
> else.<br>&gt=3B
> &gt=3B&gt=3B<br>&g=
> >t=3B &gt=3B&gt=3BI took the sources of your
> thread test program to an older=
> > XP machine that=3D<br>&gt=3B &gt=3B
> =3D3D<br>&gt=3B &gt=3B&gt=3Bhas CM3 ci=
> >rca August 2008.  This is the machine and
> implementation I used =3D<br>&gt=
> >=3B &gt=3Bw=3D3D<br>&gt=3B
> &gt=3B&gt=3Bhen building a major project I did a=
> > couple years back.<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3BThe thread=
> > test program does indeed build on this old system=2C
> but when I r=3D<br>&g=
> >t=3B &gt=3Bu=3D3D<br>&gt=3B
> &gt=3B&gt=3Bn it=2C I get different results tha=
> >n with the latest HEAD branch code.
> =3D3D20<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=
> >=3B &gt=3B&gt=3BAfter it prints
> "running...printing oldest/median age/newes=
> >t"=2C on the next=3D<br>&gt=3B &gt=3B
> =3D3D<br>&gt=3B &gt=3B&gt=3Bline I ge=
> >t two periods ".." and now the program seems
> hung.  I'll let it "=3D<br>&gt=
> >=3B &gt=3Br=3D3D<br>&gt=3B
> &gt=3B&gt=3Bun" for a few more minutes to see if=
> > anything else happens before killing
> =3D<br>&gt=3B &gt=3Bi=3D3D<br>&gt=3B
> =
> >&gt=3B&gt=3Bt.<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3BAt least we don=
> >'t get the subscript and assertion failures on this
> older C=3D<br>&gt=3B &g=
> >t=3BM=3D3D<br>&gt=3B &gt=3B&gt=3B3
> platform.<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=
> >=3B &gt=3B&gt=3BRegards=2C<br>&gt=3B
> &gt=3B&gt=3BRandy Coleburn<br>&gt=3B
> &=
> >gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B-----Original Mess=
> >age-----<br>&gt=3B &gt=3B&gt=3BFrom:
> Coleburn=2C Randy=3D3D20<br>&gt=3B &gt=
> >=3B&gt=3BSent: Sunday=2C February 27=2C 2011 2:09
> PM<br>&gt=3B &gt=3B&gt=3B=
> >To: m3devel at elegosoft.com<br>&gt=3B
> &gt=3B&gt=3BSubject: Re: [M3devel] resu=
> >lts of threadtest program on
> Windows7<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B &gt=
> >=3B&gt=3BMika:<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3BOk=2C I've upda=
> >ted to latest HEAD and I've also built Jay's m3sleep
> program.<br>&gt=3B &gt=
> >=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3BHere is what happens now when I run your
> th=
> >readtest program on Windows 7.<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
> >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest
> -tests =
> >ALL=2C-fo=3D<br>&gt=3B
> &gt=3Br=3D3D<br>&gt=3B
> &gt=3B&gt=3Bk<br>&gt=3B &gt=
> >=3B&gt=3BWriting file...done<br>&gt=3B
> &gt=3B&gt=3BCreating read threads...=
> >done<br>&gt=3B &gt=3B&gt=3BCreating
> nxread threads...done<br>&gt=3B &gt=3B&=
> >gt=3BCreating tryexcept
> threads...done<br>&gt=3B
> &gt=3B&gt=3BCreating forkt=
> >oomuch threads...done<br>&gt=3B
> &gt=3B&gt=3BCreating alloc threads...done<b=
> >r>&gt=3B &gt=3B&gt=3BCreating creat
> threads...done<br>&gt=3B &gt=3B&gt=3BCr=
> >eating lock threads...done<br>&gt=3B
> &gt=3B&gt=3Brunning...printing oldest/=
> >median age/newest<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B &=
> >gt=3B&gt=3B***<br>&gt=3B
> &gt=3B&gt=3B*** runtime error:<br>&gt=3B
> &gt=3B&gt=
> >=3B***    An array subscript was out of
> range.<br>&gt=3B
> &gt=3B&gt=3B***   =
> > file "..\src\runtime\common\RTCollector.m3"=2C line
> 418<br>&gt=3B &gt=3B&g=
> >t=3B***<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
> >=3B<br>&gt=3B
> &gt=3B&gt=3B***<br>&gt=3B
> &gt=3B&gt=3B*** runtime error:<br>&=
> >gt=3B &gt=3B&gt=3B***   
> &lt=3B*ASSERT*&gt=3B failed.<br>&gt=3B
> &gt=3B&gt=
> >=3B***    file
> "..\src\thread\WIN32\ThreadWin32.m3"=2C line
> 841<br>&gt=3B &=
> >gt=3B&gt=3B***<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3BThe last error =
> >repeats ad infinitum until I press CNTRL-C to
> abort.<br>&gt=3B &gt=3B&gt=3B=
> ><br>&gt=3B &gt=3B&gt=3BI'll send more
> info on the Windows install of Modula=
> >3 in a subsequent post=3D<br>&gt=3B
> &gt=3B.<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=
> >=3B &gt=3B&gt=3BRegards=2C<br>&gt=3B
> &gt=3B&gt=3BRandy Coleburn<br>&gt=3B
> &=
> >gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B-----Original
> Message-----<br>&gt=3B &gt=
> >=3B&gt=3BFrom: Mika Nystrom [mailto:mika at async.caltech.edu]=3D3D20<br>&gt=
> >=3B &gt=3B&gt=3BSent: Saturday=2C February
> 26=2C 2011 12:55 PM<br>&gt=3B &g=
> >t=3B&gt=3BTo: Coleburn=2C Randy<br>&gt=3B
> &gt=3B&gt=3BCc: m3devel at elegosoft=
> >.com<br>&gt=3B &gt=3B&gt=3BSubject:
> Re: [M3devel] results of threadtest pro=
> >gram on Windows7=3D3D20<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3BHi Ran=
> >dy=2C<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3BHm yes it looks like my =
> >Windows programming skills leave
> something<br>&gt=3B &gt=3B&gt=3Bto be
> desi=
> >red.<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3BYou can run the thread te=
> >ster while skipping a test as
> follows<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B &gt=
> >=3B&gt=3B   threadtest -tests
> ALL=2C-fork<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B =
> >&gt=3B&gt=3B(for instance)<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3Bif =
> >you just run=3D3D20<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B   threadt=
> >est -sadfassdaf<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3Bit'll print th=
> >e tests that are available.<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3BAs=
> > it happens=2C I just had to upgrade my windows 2000
> system to windows 7.<b=
> >r>&gt=3B &gt=3B&gt=3BCan you give me a
> very brief description of what you d=
> >id to install Modula=3D<br>&gt=3B
> &gt=3B-=3D3D<br>&gt=3B
> &gt=3B&gt=3B3<br>&=
> >gt=3B &gt=3B&gt=3Bon this
> system?<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B &gt=3B&g=
> >t=3B     Mika<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B"Coleburn=2C Ran=
> >dy" writes:<br>&gt=3B
> &gt=3B&gt=3B&gt=3B--_000_D67F02DDC62F7545A6B84C285F88=
> >F3E6EE25C849atlex02srv_<br>&gt=3B
> &gt=3B&gt=3B&gt=3BContent-Type: text/plai=
> >n=3B charset=3D3D3D"us-ascii"<br>&gt=3B
> &gt=3B&gt=3B&gt=3BContent-Transfer-=
> >Encoding: quoted-printable<br>&gt=3B
> &gt=3B&gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=
> >=3B&gt=3BMika:<br>&gt=3B
> &gt=3B&gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B&gt=3BI'v=
> >e finally managed to get cm3 rebuilt on Windows 7
> again.<br>&gt=3B &gt=3B&g=
> >t=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B&gt=3BSo=2C I ran your threadtest
> program.=
> ><br>&gt=3B
> &gt=3B&gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B&gt=3BHere are the resu=
> >lts.  Note the "..." is where I cut out a bunch of
> the r=3D<br>&gt=3B &gt=
> >=3Be=3D3D<br>&gt=3B
> &gt=3B&gt=3Bp=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Beating=
> > "ERROR FApply" messages.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=
> >=3B&gt=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest.e=
> >xe<br>&gt=3B
> &gt=3B&gt=3B&gt=3BWriting
> file...done<br>&gt=3B &gt=3B&gt=3B&g=
> >t=3BCreating read threads...done<br>&gt=3B
> &gt=3B&gt=3B&gt=3BCreating fork =
> >threads...done<br>&gt=3B
> &gt=3B&gt=3B&gt=3BCreating alloc
> threads...done<br=
> >>&gt=3B &gt=3B&gt=3B&gt=3BCreating
> lock threads...done<br>&gt=3B &gt=3B&gt=
> >=3B&gt=3Brunning...printing oldest/median
> age/newest<br>&gt=3B &gt=3B&gt=3B=
> >&gt=3BERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find=
> > the f=3D<br>&gt=3B
> &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> sp=3D3D3D<br>&gt=
> >=3B
> &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> &gt=3B&gt=3B&gt=3BERROR FApply: OS=
> >Error.E:  ErrorCode=3D3D3D3D2: The system cannot
> find the f=3D<br>&gt=3B &g=
> >t=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> sp=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Be=
> >cified.<br>&gt=3B
> &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E: 
> ErrorCode=3D3=
> >D3D3D2: The system cannot find the
> f=3D<br>&gt=3B
> &gt=3Bile=3D3D<br>&gt=3B =
> >&gt=3B&gt=3B sp=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> &gt=
> >=3B&gt=3B&gt=3B.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B=
> >.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B***<br>&gt=3B
> &gt=3B&gt=3B&gt=3B*** runtime e=
> >rror:<br>&gt=3B
> &gt=3B&gt=3B&gt=3B***    An
> enumeration or subrange value w=
> >as out of range.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B***    file
> "..\src\Main.m3"=
> >=2C line 340<br>&gt=3B
> &gt=3B&gt=3B&gt=3B***<br>&gt=3B
> &gt=3B&gt=3B&gt=3B<b=
> >r>&gt=3B &gt=3B&gt=3B&gt=3Blaziest
> thread is 0/0/ERROR FApply: OSError.E:  =
> >ErrorCode=3D3D3D3D2: The sy=3D<br>&gt=3B
> &gt=3Bste=3D3D<br>&gt=3B &gt=3B&gt=
> >=3Bm c=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Bannot find the file
> specified.<br=
> >>&gt=3B &gt=3B&gt=3B&gt=3BERROR
> FApply: OSError.E:  ErrorCode=3D3D3D3D2: Th=
> >e system cannot find the f=3D<br>&gt=3B
> &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=
> >=3B sp=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> &gt=3B&gt=3B&g=
> >t=3BERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2:
> The system cannot find t=
> >he f=3D<br>&gt=3B
> &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> sp=3D3D3D<br>&gt=3B=
> >
> &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> &gt=3B&gt=3B&gt=3BERROR FApply: OSErr=
> >or.E:  ErrorCode=3D3D3D3D2: The system cannot find
> the f=3D<br>&gt=3B &gt=
> >=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> sp=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Bec=
> >ified.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B.<br>&gt=
> >=3B &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> &gt=3B&gt=3B&gt=3Blaziest thread is 0/0/E=
> >RROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The
> sy=3D<br>&gt=3B &gt=3Bste=
> >=3D3D<br>&gt=3B &gt=3B&gt=3Bm
> c=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Bannot fi=
> >nd the file specified.<br>&gt=3B
> &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E:=
> >  ErrorCode=3D3D3D3D2: The system cannot find the
> f=3D<br>&gt=3B &gt=3Bile=
> >=3D3D<br>&gt=3B &gt=3B&gt=3B
> sp=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Becified.=
> ><br>&gt=3B
> &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2:=
> > The system cannot find the f=3D<br>&gt=3B
> &gt=3Bile=3D3D<br>&gt=3B &gt=3B&=
> >gt=3B sp=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> &gt=3B&gt=3B=
> >&gt=3BERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find=
> > the f=3D<br>&gt=3B
> &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> sp=3D3D3D<br>&gt=
> >=3B
> &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> &gt=
> >=3B&gt=3B&gt=3B.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B=
> >ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The
> system cannot find the f=
> >=3D<br>&gt=3B
> &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> sp=3D3D3D<br>&gt=3B &gt=
> >=3B&gt=3B&gt=3Becified.<br>&gt=3B
> &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E=
> >:  ErrorCode=3D3D3D3D2: The system cannot find the
> f=3D<br>&gt=3B &gt=3Bile=
> >=3D3D<br>&gt=3B &gt=3B&gt=3B
> sp=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Becified.=
> ><br>&gt=3B
> &gt=3B&gt=3B&gt=3BStack
> trace:<br>&gt=3B
> &gt=3B&gt=3B&gt=3B   FP=
> >         PC   
>   Procedure<br>&gt=3B
> &gt=3B&gt=3B&gt=3B---------  ---------=
> > 
> -------------------------------<br>&gt=3B
> &gt=3B&gt=3B&gt=3B0x30fbd0  0x1=
> >27218a  PutStats + 0x1a3 in
> ..\src\Main.m3<br>&gt=3B
> &gt=3B&gt=3B&gt=3B0x30=
> >fcc0  0x1273825  Main_M3 + 0x11db(!) in
> ..\src\Main.m3<br>&gt=3B &gt=3B&gt=
> >=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B&gt=3BRegards=2C<br>&gt=3B
> &gt=3B&gt=3B&gt=
> >=3BRandy Coleburn<br>&gt=3B
> &gt=3B&gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B&gt=3B=
> >--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_<br>&gt=3B
> &gt=3B=
> >&gt=3B&gt=3BContent-Type: text/html=3B
> charset=3D3D3D"us-ascii"<br>&gt=3B &=
> >gt=3B&gt=3B&gt=3BContent-Transfer-Encoding:
> quoted-printable<br>&gt=3B &gt=
> >=3B&gt=3B&gt=3B<br>    
>         
>           
>   </body>
> ></html>=
> >
> >--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_--
> 


      


From jay.krell at cornell.edu  Wed Mar  2 04:11:49 2011
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Mar 2011 03:11:49 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <452042.5906.qm@web29706.mail.ird.yahoo.com>
References: <20110301181718.12EFC1A2078@async.async.caltech.edu>,
	<452042.5906.qm@web29706.mail.ird.yahoo.com>
Message-ID: <COL101-W3670B74A99994199607C6BE6C00@phx.gbl>


I have still have mostly uniprocessors (though busy selling stuff off...)
  I do have a MacBook Pro and Dell laptop with 2 processors each though.
  It is that MacBook Pro where I can consistently get Darwin to fail, and a 1 and 2 proc Windows virtual machine on the MacBook Pro that consistently works.
  While Modula-3 user threads never run anything truly concurrently, i.e. on multiple prcoessors, there should still be almost arbitrary preemption.
 
 
I'm skeptical of any emulation's or virtualization's ability to simulate more processors than underlying physical processors.
 
 
Most of the runs error or succeed within 10 minutes. The one Solaris/sparc run I made ran for well over 4 hours and didn't get very far. I'd say it was hung forever.
 
 
I didn't debug it.
 
 
Yes, OpenBSD pthreads are user threads and therefore probably only ever use one processor.
But that machine only has one. :)

 
I think this will quite difficult to track down.
It might be useful to find an old starting point that succeeds and upgrade forward looking for when things fail.
That is tedious and has its own set of difficulties, granted.
 There are many points in time that don't compile, many are my fault, and there are also many combinations of starting/ending points that don't compile due to some mismatches between start/end.
 
 
I have to try Linux and/or FreeBSD still.
 
 
The errors on Darwin imply to me that memory is being prematurely reclaimed by the garbage collector -- e.g. EBUSY from pthread_mutex_destroy.
But it could also be arbitrary memory corruption (sort of the same thing), same example, but rather than an actually busy mutex, it could be a corrupted mutex or random pointer. Some of that might be easy to track down, e.g. by tracing which addresses are initialized as mutexes, and maybe by putting pad bytes around mutexes and seeing if they get changed.
I'm reluctant to try draw any conclusions yet though, since I have very very little information/knowledge.
 
 
I also forgot to check if I was using any optimization. I'll be sure to not.
 
 
 - Jay

 
> Date: Tue, 1 Mar 2011 22:10:55 +0000
> From: dabenavidesd at yahoo.es
> To: jay.krell at cornell.edu; mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Hi all:
> but you could still run a *nix image with uniprocessor support kernel and try on the vbox, qemu, etc.
> Perhaps you would get enough simulation to detect that the problem is on the hardware layer (either physically or its abstraction) rather than the execution model (the pthreads scheduling policy), if it does no work may be there is a problem in ThreadPthread implementation of pthreads (don't need to switch its default is - smp 1).
> commands i.e in qemu:
> qemu -cdrom /path/to/system.iso -smp 2 
> and run threadtest from there
> 
> Thanks in advance
> 
> 
> 
> 
> 
> 
> --- El mar, 1/3/11, Mika Nystrom <mika at async.caltech.edu> escribi?:
> 
> > De: Mika Nystrom <mika at async.caltech.edu>
> > Asunto: Re: [M3devel] results of threadtest program on Windows7
> > Para: "Jay K" <jay.krell at cornell.edu>
> > CC: m3devel at elegosoft.com
> > Fecha: martes, 1 de marzo, 2011 13:17
> > 
> > Hi Jay,
> > 
> > 1. I think you should get forward progress no matter what,
> > although it
> > might be very slow on some systems.
> > 
> > 2. Not sure how you could get negative timings. That
> > would suggest that
> > Time.Now() is decreasing---which seems contrary to its
> > specification.
> > Although the code is doing some nasty stuff with the
> > timings, mainly
> > reading and writing them without locks. But it's
> > using INTEGER for
> > the results so I don't think there can be an atomicity
> > problem there.
> > Even if there were coherence problems between processors
> > (is this
> > technically possible?) the "now" value has to be coherent
> > since it's
> > from the thread that prints the results, and the "then"
> > values could
> > only be getting older, not newer...
> > 
> > 3. Note that there are systems (FreeBSD 4 is an example)
> > that have a
> > "pthreads" library but where the pthreads library is
> > implemented with
> > user threads. Could that be related to why OpenBSD is
> > working?
> > 
> > 4. Hm. I think I am only using multiprocessor
> > systems, yes. Hard to
> > find single-CPU systems nowadays! I think actually
> > the only one I have
> > is PPC_DARWIN, and I haven't tried the code on that. 
> > So yes this is a
> > possibility as far as explaining differences...
> > 
> > Mika
> > 
> > Jay K writes:
> > >--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_
> > >Content-Type: text/plain; charset="iso-8859-1"
> > >Content-Transfer-Encoding: quoted-printable
> > >
> > >
> > >I also haven't seen it fail on OpenBSD/x86/4.7. I'm
> > pretty sure using pthre=
> > >ads there.
> > >But on Solaris/5.10/sparc it hangs=2C for many hours.
> > >
> > >-bash-4.1$ ./threadtest=20
> > >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
> > >.
> > >
> > >Are we guranteed forward progress in suspending all
> > threads?
> > >
> > >I do see it fail usually on Darwin. e.g.:
> > >........pthread_mutex_destroy:EBUSY
> > >pthread_mutex_destroy:EBUSY
> > >..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:
> > >*** An array subscript was out of range.
> > >*** file
> > "../src/runtime/common/RTCollector.m3"=2C line 418
> > >***
> > >
> > >I haven't tried Linux yet.
> > >Do note that we have some variance in the pthreads
> > implementation.
> > >The "portable" implementation is used on Linux=2C
> > Solaris=2C NetBSD.
> > >And then OpenBSD=2C Darwin=2C FreeBSD each have slight
> > differences.
> > >
> > >Mika are your machines all multiprocessors?
> > >I do wonder if that helps increase the stress and if I
> > should be sure to us=
> > >e multiprocessors.
> > >
> > >I'm also considering taking the time to try various
> > historical versions=2C =
> > >either releases or dates in CVS.
> > >
> > > - Jay
> > >
> > >From: jay.krell at cornell.edu
> > >To: mika at async.caltech.edu=3B
> > rcolebur at scires.com
> > >Date: Tue=2C 1 Mar 2011 10:59:29 +0000
> > >CC: m3devel at elegosoft.com
> > >Subject: Re: [M3devel] results of threadtest program on
> > Windows7
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >I haven't seen it fail on NT=2C except for PutCard in
> > the test itself getti=
> > >ng negative numbers.
> > >I've run it just a few times now. One single and dual
> > processor virtual mac=
> > >hines.
> > >Randy=2C has it failed many times for you?
> > >
> > > - Jay
> > >
> > >> To: rcolebur at SCIRES.COM
> > >> Date: Sun=2C 27 Feb 2011 15:11:25 -0800
> > >> From: mika at async.caltech.edu
> > >> CC: m3devel at elegosoft.com
> > >> Subject: Re: [M3devel] results of threadtest
> > program on Windows7
> > >>=20
> > >> Ah=2C it just doesn't check command-line arguments
> > that carefully.
> > >>=20
> > >> I think what you did is equivalent to "-tests
> > STD".
> > >=20
> > >> Mika
> > >>=20
> > >> "Coleburn=2C Randy" writes:
> > >> >Mika:
> > >> >
> > >> >No change with "-tests POSIX".
> > >> >
> > >> >Interesting twist: On Windows 7=2C I
> > thought I'd see what the command l=
> > >ine o=3D
> > >> >ptions are=2C and I typed "threadtest -help"
> > rather than reading the cod=
> > >e.
> > >> >
> > >> >First time=2C it produced what appears to be a
> > NIL deref crash. Then=2C=
> > > I trie=3D
> > >> >d it again and it ran to completion. 
> > Something seems non-deterministic =
> > >her=3D
> > >> >e. See below.
> > >> >
> > >>
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > -help
> > >> >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
> > >> >.
> > >> >
> > >> >***
> > >> >*** runtime error:
> > >> >*** Attempt to reference an
> > illegal memory location.
> > >> >*** pc =3D3D 0x77762262
> > >> >***
> > >> >
> > >> >Stack trace:
> > >> > FP 
> > PC Procedure
> > >> >--------- --------- 
> > -------------------------------
> > >> > 0xcdf998 0x130351b SystemError +
> > 0x64 in ..\src\runtime\NT386\RTSigna=
> > >l.m=3D
> > >> >3
> > >> > 0xcdf9c0 0x77762262 <???>
> > >> > 0xcdf9d8 0x12e83b7 LockMutex +
> > 0x4f in ..\src\thread\WIN32\ThreadWin3=
> > >2.m=3D
> > >> >3
> > >> > 0xcdfa00 0x12c7b08 GetChar + 0x28
> > in ..\src\rw\Rd.m3
> > >> > 0xcdfb38 0x12c12e3 RApply + 0xd3
> > in ..\src\Main.m3
> > >> > 0xcdfb74 0x12e971f ThreadBase +
> > 0x254 in ..\src\thread\WIN32\ThreadWi=
> > >n32=3D
> > >> >.m3
> > >> > 0xcdfb80 0x76543677 <???>
> > >> > 0xcdfbc0 0x77779f02 <???>
> > >> >......... ......... ... more
> > frames ...
> > >> >
> > >>
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > -help
> > >> >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
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >All tests complete. Congratulations.
> > >> >
> > >> >Regards=2C
> > >> >Randy Coleburn
> > >> >
> > >> >-----Original Message-----
> > >> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> > >> >Sent: Sunday=2C February 27=2C 2011 3:30 PM
> > >> >To: Coleburn=2C Randy
> > >> >Cc: m3devel at elegosoft.com
> > >> >Subject: Re: [M3devel] results of threadtest
> > program on Windows7=3D20
> > >> >
> > >> >Hi Randy=2C
> > >> >
> > >> >You can try it with -tests POSIX as well.
> > >> >
> > >> >I find on user threads it runs very slowly
> > (but it does run) because of =
> > >how=3D
> > >> > unfair
> > >> >the thread scheduler is.
> > >> >
> > >> >Next step might be to whittle down the tests
> > and see if you can get a fa=
> > >ilu=3D
> > >> >re with
> > >> >a single test running and -n 2. That
> > would likely be the simplest scena=
> > >rio=3D
> > >> > to
> > >> >start further debugging from.
> > >> >
> > >> > Mika
> > >> >
> > >> >"Coleburn=2C Randy" writes:
> > >> >>Mika et al:
> > >> >>
> > >> >>Thought I would try something else.
> > >> >>
> > >> >>I took the sources of your thread test
> > program to an older XP machine t=
> > >hat=3D
> > >> > =3D3D
> > >> >>has CM3 circa August 2008. This is
> > the machine and implementation I us=
> > >ed =3D
> > >> >w=3D3D
> > >> >>hen building a major project I did a
> > couple years back.
> > >> >>
> > >> >>The thread test program does indeed build
> > on this old system=2C but whe=
> > >n I r=3D
> > >> >u=3D3D
> > >> >>n it=2C I get different results than with
> > the latest HEAD branch code. =
> > >=3D3D20
> > >> >>
> > >> >>After it prints "running...printing
> > oldest/median age/newest"=2C on the=
> > > next=3D
> > >> > =3D3D
> > >> >>line I get two periods ".." and now the
> > program seems hung. I'll let i=
> > >t "=3D
> > >> >r=3D3D
> > >> >>un" for a few more minutes to see if
> > anything else happens before killi=
> > >ng =3D
> > >> >i=3D3D
> > >> >>t.
> > >> >>
> > >> >>At least we don't get the subscript and
> > assertion failures on this olde=
> > >r C=3D
> > >> >M=3D3D
> > >> >>3 platform.
> > >> >>
> > >> >>Regards=2C
> > >> >>Randy Coleburn
> > >> >>
> > >> >>
> > >> >>-----Original Message-----
> > >> >>From: Coleburn=2C Randy=3D3D20
> > >> >>Sent: Sunday=2C February 27=2C 2011 2:09
> > PM
> > >> >>To: m3devel at elegosoft.com
> > >> >>Subject: Re: [M3devel] results of
> > threadtest program on Windows7
> > >> >>
> > >> >>Mika:
> > >> >>
> > >> >>Ok=2C I've updated to latest HEAD and I've
> > also built Jay's m3sleep pro=
> > >gram.
> > >> >>
> > >> >>Here is what happens now when I run your
> > threadtest program on Windows =
> > >7.
> > >> >>
> > >>
> > >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest
> > -tests ALL=
> > >=2C-fo=3D
> > >> >r=3D3D
> > >> >>k
> > >> >>Writing file...done
> > >> >>Creating read threads...done
> > >> >>Creating nxread threads...done
> > >> >>Creating tryexcept threads...done
> > >> >>Creating forktoomuch threads...done
> > >> >>Creating alloc threads...done
> > >> >>Creating creat threads...done
> > >> >>Creating lock threads...done
> > >> >>running...printing oldest/median
> > age/newest
> > >> >>
> > >> >>
> > >> >>***
> > >> >>*** runtime error:
> > >> >>*** An array subscript was
> > out of range.
> > >> >>*** file
> > "..\src\runtime\common\RTCollector.m3"=2C line 418
> > >> >>***
> > >> >>
> > >> >>
> > >> >>
> > >> >>***
> > >> >>*** runtime error:
> > >> >>*** <*ASSERT*> failed.
> > >> >>*** file
> > "..\src\thread\WIN32\ThreadWin32.m3"=2C line 841
> > >> >>***
> > >> >>
> > >> >>The last error repeats ad infinitum until
> > I press CNTRL-C to abort.
> > >> >>
> > >> >>I'll send more info on the Windows install
> > of Modula3 in a subsequent p=
> > >ost=3D
> > >> >.
> > >> >>
> > >> >>Regards=2C
> > >> >>Randy Coleburn
> > >> >>
> > >> >>-----Original Message-----
> > >> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D3D20
> > >> >>Sent: Saturday=2C February 26=2C 2011
> > 12:55 PM
> > >> >>To: Coleburn=2C Randy
> > >> >>Cc: m3devel at elegosoft.com
> > >> >>Subject: Re: [M3devel] results of
> > threadtest program on Windows7=3D3D20
> > >> >>
> > >> >>Hi Randy=2C
> > >> >>
> > >> >>Hm yes it looks like my Windows
> > programming skills leave something
> > >> >>to be desired.
> > >> >>
> > >> >>You can run the thread tester while
> > skipping a test as follows
> > >> >>
> > >> >> threadtest -tests
> > ALL=2C-fork
> > >> >>
> > >> >>(for instance)
> > >> >>
> > >> >>if you just run=3D3D20
> > >> >>
> > >> >> threadtest -sadfassdaf
> > >> >>
> > >> >>it'll print the tests that are available.
> > >> >>
> > >> >>As it happens=2C I just had to upgrade my
> > windows 2000 system to window=
> > >s 7.
> > >> >>Can you give me a very brief description
> > of what you did to install Mod=
> > >ula=3D
> > >> >-=3D3D
> > >> >>3
> > >> >>on this system?
> > >> >>
> > >> >> Mika
> > >> >>
> > >> >>"Coleburn=2C Randy" writes:
> > >>
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >> >>>Content-Type: text/plain=3B
> > charset=3D3D3D"us-ascii"
> > >> >>>Content-Transfer-Encoding:
> > quoted-printable
> > >> >>>
> > >> >>>Mika:
> > >> >>>
> > >> >>>I've finally managed to get cm3
> > rebuilt on Windows 7 again.
> > >> >>>
> > >> >>>So=2C I ran your threadtest program.
> > >> >>>
> > >> >>>Here are the results. Note the
> > "..." is where I cut out a bunch of th=
> > >e r=3D
> > >> >e=3D3D
> > >> >>p=3D3D3D
> > >> >>>eating "ERROR FApply" messages.
> > >> >>>
> > >>
> > >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > >> >>>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
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>.
> > >> >>>.
> > >> >>>.
> > >> >>>***
> > >> >>>*** runtime error:
> > >> >>>*** An enumeration or
> > subrange value was out of range.
> > >> >>>*** file
> > "..\src\Main.m3"=2C line 340
> > >> >>>***
> > >> >>>
> > >> >>>laziest thread is 0/0/ERROR FApply:
> > OSError.E: ErrorCode=3D3D3D3D2: T=
> > >he sy=3D
> > >> >ste=3D3D
> > >> >>m c=3D3D3D
> > >> >>>annot find the file specified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>.
> > >> >>>.
> > >> >>>.
> > >> >>>laziest thread is 0/0/ERROR FApply:
> > OSError.E: ErrorCode=3D3D3D3D2: T=
> > >he sy=3D
> > >> >ste=3D3D
> > >> >>m c=3D3D3D
> > >> >>>annot find the file specified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>.
> > >> >>>.
> > >> >>>.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>Stack trace:
> > >> >>> FP 
> > PC Procedure
> > >> >>>--------- --------- 
> > -------------------------------
> > >> >>>0x30fbd0 0x127218a 
> > PutStats + 0x1a3 in ..\src\Main.m3
> > >> >>>0x30fcc0 0x1273825 Main_M3
> > + 0x11db(!) in ..\src\Main.m3
> > >> >>>
> > >> >>>Regards=2C
> > >> >>>Randy Coleburn
> > >> >>>
> > >>
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >> >>>Content-Type: text/html=3B
> > charset=3D3D3D"us-ascii"
> > >> >>>Content-Transfer-Encoding:
> > quoted-printable
> > >> >>>
> > > 
> > 
> > 
> > =
> > >
> > >--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_
> > >Content-Type: text/html; charset="iso-8859-1"
> > >Content-Transfer-Encoding: quoted-printable
> > >
> > ><html>
> > ><head>
> > ><style><!--
> > >.hmmessage P
> > >{
> > >margin:0px=3B
> > >padding:0px
> > >}
> > >body.hmmessage
> > >{
> > >font-size: 10pt=3B
> > >font-family:Tahoma
> > >}
> > >--></style>
> > ></head>
> > ><body class=3D'hmmessage'>
> > >I also haven't seen it fail on OpenBSD/x86/4.7. I'm
> > pretty sure using pthre=
> > >ads there.<br>But on Solaris/5.10/sparc it
> > hangs=2C for many hours.<br><br>=
> > >-bash-4.1$ ./threadtest <br>Writing
> > file...done<br>Creating read threads...=
> > >done<br>Creating fork
> > threads...done<br>Creating alloc
> > threads...done<br>Cr=
> > >eating lock threads...done<br>running...printing
> > oldest/median age/newest<b=
> > >r>.<br><br>Are we guranteed forward
> > progress in suspending all threads?<br>=
> > ><br>I do see it fail usually on Darwin.
> > e.g.:<br>........pthread_mutex_dest=
> > >roy:EBUSY<br>pthread_mutex_destroy:EBUSY<br>..laziest
> > thread is 0/0/0 (test=
> > >s: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock
> > 0/0/0)<br>...<br><br>***<br>*** r=
> > >untime
> > error:<br>***&nbsp=3B&nbsp=3B&nbsp=3B An
> > array subscript was out of =
> > >range.<br>***&nbsp=3B&nbsp=3B&nbsp=3B
> > file "../src/runtime/common/RTCollect=
> > >or.m3"=2C line 418<br>***<br><br>I
> > haven't tried Linux yet.<br>Do note that=
> > > we have some variance in the pthreads
> > implementation.<br>The "portable" im=
> > >plementation is used on Linux=2C Solaris=2C
> > NetBSD.<br>And then OpenBSD=2C =
> > >Darwin=2C FreeBSD each have slight
> > differences.<br><br>Mika are your machin=
> > >es all multiprocessors?<br>I do wonder if that
> > helps increase the stress an=
> > >d if I should be sure to use
> > multiprocessors.<br><br>I'm also considering t=
> > >aking the time to try various historical versions=2C
> > either releases or dat=
> > >es in CVS.<br><br>&nbsp=3B-
> > Jay<br><br><hr id=3D"stopSpelling">From:
> > jay.kr=
> > >ell at cornell.edu<br>To:
> > mika at async.caltech.edu=3B
> > rcolebur at scires.com<br>Dat=
> > >e: Tue=2C 1 Mar 2011 10:59:29 +0000<br>CC: m3devel at elegosoft.com<br>Subject=
> > >: Re: [M3devel] results of threadtest program on
> > Windows7<br><br>
> > >
> > ><meta http-equiv=3D"Content-Type"
> > content=3D"text/html=3B charset=3Dunicode=
> > >">
> > ><meta name=3D"Generator" content=3D"Microsoft
> > SafeHTML">
> > ><style>
> > >.ExternalClass .ecxhmmessage P
> > >{padding:0px=3B}
> > >.ExternalClass body.ecxhmmessage
> > >{font-size:10pt=3Bfont-family:Tahoma=3B}
> > >
> > ></style>
> > >
> > >
> > >I haven't seen it fail on NT=2C except for PutCard in
> > the test itself getti=
> > >ng negative numbers.<br>I've run it just a few
> > times now. One single and du=
> > >al processor virtual machines.<br>Randy=2C has it
> > failed many times for you=
> > >?<br><br>&nbsp=3B-
> > Jay<br><br>&gt=3B To: rcolebur at SCIRES.COM<br>&gt=3B
> > Date=
> > >: Sun=2C 27 Feb 2011 15:11:25 -0800<br>&gt=3B
> > From: mika at async.caltech.edu<=
> > >br>&gt=3B CC: m3devel at elegosoft.com<br>&gt=3B
> > Subject: Re: [M3devel] result=
> > >s of threadtest program on Windows7<br>&gt=3B
> > <br>&gt=3B Ah=2C it just does=
> > >n't check command-line arguments that
> > carefully.<br>&gt=3B <br>&gt=3B I thi=
> > >nk what you did is equivalent to "-tests
> > STD".<br>&gt=3B <br>&gt=3B 
> > Mi=
> > >ka<br>&gt=3B <br>&gt=3B
> > "Coleburn=2C Randy" writes:<br>&gt=3B
> > &gt=3BMika:<b=
> > >r>&gt=3B &gt=3B<br>&gt=3B
> > &gt=3BNo change with "-tests POSIX".<br>&gt=3B
> > &g=
> > >t=3B<br>&gt=3B &gt=3BInteresting
> > twist: On Windows 7=2C I thought I'd see =
> > >what the command line o=3D<br>&gt=3B
> > &gt=3Bptions are=2C and I typed "threa=
> > >dtest -help" rather than reading the
> > code.<br>&gt=3B &gt=3B<br>&gt=3B
> > &gt=
> > >=3BFirst time=2C it produced what appears to be a NIL
> > deref crash. Then=2C=
> > > I trie=3D<br>&gt=3B &gt=3Bd it again and
> > it ran to completion. Something =
> > >seems non-deterministic her=3D<br>&gt=3B
> > &gt=3Be. See below.<br>&gt=3B &gt=
> > >=3B<br>&gt=3B
> > &gt=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bt=
> > >hreadtest.exe -help<br>&gt=3B
> > &gt=3BWriting file...done<br>&gt=3B
> > &gt=3BCre=
> > >ating read threads...done<br>&gt=3B
> > &gt=3BCreating fork threads...done<br>&=
> > >gt=3B &gt=3BCreating alloc
> > threads...done<br>&gt=3B &gt=3BCreating lock
> > thr=
> > >eads...done<br>&gt=3B
> > &gt=3Brunning...printing oldest/median
> > age/newest<br>=
> > >&gt=3B &gt=3B.<br>&gt=3B
> > &gt=3B<br>&gt=3B
> > &gt=3B***<br>&gt=3B &gt=3B*** run=
> > >time error:<br>&gt=3B &gt=3B*** 
> > Attempt to reference an illegal memory l=
> > >ocation.<br>&gt=3B &gt=3B*** 
> > pc =3D3D 0x77762262<br>&gt=3B
> > &gt=3B***<br>=
> > >&gt=3B &gt=3B<br>&gt=3B
> > &gt=3BStack trace:<br>&gt=3B
> > &gt=3B FP 
> > PC=
> > > Procedure<br>&gt=3B
> > &gt=3B--------- --------- 
> > ---------------------=
> > >----------<br>&gt=3B &gt=3B
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\s=
> > >rc\runtime\NT386\RTSignal.m=3D<br>&gt=3B
> > &gt=3B3<br>&gt=3B &gt=3B 0xcdf9c0 =
> > > 0x77762262 
> > &lt=3B???&gt=3B<br>&gt=3B &gt=3B
> > 0xcdf9d8 0x12e83b7 LockMute=
> > >x + 0x4f in
> > ..\src\thread\WIN32\ThreadWin32.m=3D<br>&gt=3B
> > &gt=3B3<br>&gt=
> > >=3B &gt=3B 0xcdfa00 0x12c7b08 GetChar +
> > 0x28 in ..\src\rw\Rd.m3<br>&gt=3B=
> > > &gt=3B 0xcdfb38 0x12c12e3 RApply +
> > 0xd3 in ..\src\Main.m3<br>&gt=3B &gt=
> > >=3B 0xcdfb74 0x12e971f ThreadBase + 0x254
> > in ..\src\thread\WIN32\ThreadWi=
> > >n32=3D<br>&gt=3B
> > &gt=3B.m3<br>&gt=3B &gt=3B 0xcdfb80 
> > 0x76543677 &lt=3B???=
> > >&gt=3B<br>&gt=3B &gt=3B
> > 0xcdfbc0 0x77779f02 
> > &lt=3B???&gt=3B<br>&gt=3B &gt=
> > >=3B......... ......... ... more frames
> > ...<br>&gt=3B &gt=3B<br>&gt=3B
> > &gt=
> > >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest.exe
> > -he=
> > >lp<br>&gt=3B &gt=3BWriting
> > file...done<br>&gt=3B &gt=3BCreating read
> > thread=
> > >s...done<br>&gt=3B &gt=3BCreating fork
> > threads...done<br>&gt=3B &gt=3BCreat=
> > >ing alloc threads...done<br>&gt=3B
> > &gt=3BCreating lock threads...done<br>&g=
> > >t=3B &gt=3Brunning...printing oldest/median
> > age/newest<br>&gt=3B &gt=3B....=
> > >......laziest thread is 0/0/0 (tests: read 0/0/0 fork
> > 0/0/0 alloc 0/0/0=3D<=
> > >br>&gt=3B &gt=3B lock
> > 0/0/0)<br>&gt=3B &gt=3B..........laziest
> > thread is 0/=
> > >0/0 (tests: read 0/0/0 fork 0/0/0 alloc
> > 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/=
> > >0)<br>&gt=3B &gt=3B..........laziest
> > thread is 0/0/0 (tests: read 0/0/0 for=
> > >k 0/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B
> > lock 0/0/0)<br>&gt=3B &gt=3B.......=
> > >...laziest thread is 0/0/0 (tests: read 0/0/0 fork
> > 0/0/0 alloc 0/0/0=3D<br>=
> > >&gt=3B &gt=3B lock 0/0/0)<br>&gt=3B
> > &gt=3B..........laziest thread is 0/0/0=
> > > (tests: read 0/0/0 fork 0/0/0 alloc
> > 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/0)<=
> > >br>&gt=3B &gt=3B..........laziest thread is
> > 0/0/0 (tests: read 0/0/0 fork 0=
> > >/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock
> > 0/0/0)<br>&gt=3B &gt=3B..........=
> > >laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0
> > alloc 0/0/0=3D<br>&gt=
> > >=3B &gt=3B lock 0/0/0)<br>&gt=3B
> > &gt=3B..........laziest thread is 0/0/0 (t=
> > ests: read 0/0/0 fork 0/0/0 alloc
> > 0/0/0=3D<br>&gt=3B &gt=3B lock
> > 0/0/0)<br>=
> > >&gt=3B &gt=3B..........laziest thread is 0/0/0
> > (tests: read 0/0/0 fork 0/0/=
> > >0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock
> > 0/0/0)<br>&gt=3B &gt=3B..........laz=
> > >iest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0
> > alloc 0/0/0=3D<br>&gt=3B=
> > > &gt=3B lock 0/0/0)<br>&gt=3B
> > &gt=3BAll tests complete. Congratulations.<b=
> > >r>&gt=3B &gt=3B<br>&gt=3B
> > &gt=3BRegards=2C<br>&gt=3B &gt=3BRandy
> > Coleburn<b=
> > >r>&gt=3B &gt=3B<br>&gt=3B
> > &gt=3B-----Original Message-----<br>&gt=3B
> > &gt=3B=
> > >From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20<br>&gt=3B
> > &gt=3BSen=
> > >t: Sunday=2C February 27=2C 2011 3:30
> > PM<br>&gt=3B &gt=3BTo: Coleburn=2C Ra=
> > >ndy<br>&gt=3B &gt=3BCc: m3devel at elegosoft.com<br>&gt=3B
> > &gt=3BSubject: Re: =
> > >[M3devel] results of threadtest program on
> > Windows7=3D20<br>&gt=3B &gt=3B<b=
> > >r>&gt=3B &gt=3BHi
> > Randy=2C<br>&gt=3B &gt=3B<br>&gt=3B
> > &gt=3BYou can try it =
> > >with -tests POSIX as well.<br>&gt=3B
> > &gt=3B<br>&gt=3B &gt=3BI find on user =
> > >threads it runs very slowly (but it does run) because
> > of how=3D<br>&gt=3B &=
> > >gt=3B unfair<br>&gt=3B &gt=3Bthe thread
> > scheduler is.<br>&gt=3B
> > &gt=3B<br>&=
> > >gt=3B &gt=3BNext step might be to whittle down the
> > tests and see if you can=
> > > get a failu=3D<br>&gt=3B &gt=3Bre
> > with<br>&gt=3B &gt=3Ba single test runni=
> > >ng and -n 2. That would likely be the simplest
> > scenario=3D<br>&gt=3B &gt=
> > >=3B to<br>&gt=3B &gt=3Bstart further
> > debugging from.<br>&gt=3B
> > &gt=3B<br>&g=
> > >t=3B &gt=3B 
> > Mika<br>&gt=3B
> > &gt=3B<br>&gt=3B &gt=3B"Coleburn=2C Randy"
> > w=
> > >rites:<br>&gt=3B &gt=3B&gt=3BMika et
> > al:<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &=
> > >gt=3B&gt=3BThought I would try something
> > else.<br>&gt=3B
> > &gt=3B&gt=3B<br>&g=
> > >t=3B &gt=3B&gt=3BI took the sources of your
> > thread test program to an older=
> > > XP machine that=3D<br>&gt=3B &gt=3B
> > =3D3D<br>&gt=3B &gt=3B&gt=3Bhas CM3 ci=
> > >rca August 2008. This is the machine and
> > implementation I used =3D<br>&gt=
> > >=3B &gt=3Bw=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bhen building a major project I did a=
> > > couple years back.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BThe thread=
> > > test program does indeed build on this old system=2C
> > but when I r=3D<br>&g=
> > >t=3B &gt=3Bu=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bn it=2C I get different results tha=
> > >n with the latest HEAD branch code.
> > =3D3D20<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=
> > >=3B &gt=3B&gt=3BAfter it prints
> > "running...printing oldest/median age/newes=
> > >t"=2C on the next=3D<br>&gt=3B &gt=3B
> > =3D3D<br>&gt=3B &gt=3B&gt=3Bline I ge=
> > >t two periods ".." and now the program seems
> > hung. I'll let it "=3D<br>&gt=
> > >=3B &gt=3Br=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bun" for a few more minutes to see if=
> > > anything else happens before killing
> > =3D<br>&gt=3B &gt=3Bi=3D3D<br>&gt=3B
> > =
> > >&gt=3B&gt=3Bt.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BAt least we don=
> > >'t get the subscript and assertion failures on this
> > older C=3D<br>&gt=3B &g=
> > >t=3BM=3D3D<br>&gt=3B &gt=3B&gt=3B3
> > platform.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=
> > >=3B &gt=3B&gt=3BRegards=2C<br>&gt=3B
> > &gt=3B&gt=3BRandy Coleburn<br>&gt=3B
> > &=
> > >gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B-----Original Mess=
> > >age-----<br>&gt=3B &gt=3B&gt=3BFrom:
> > Coleburn=2C Randy=3D3D20<br>&gt=3B &gt=
> > >=3B&gt=3BSent: Sunday=2C February 27=2C 2011 2:09
> > PM<br>&gt=3B &gt=3B&gt=3B=
> > >To: m3devel at elegosoft.com<br>&gt=3B
> > &gt=3B&gt=3BSubject: Re: [M3devel] resu=
> > >lts of threadtest program on
> > Windows7<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=
> > >=3B&gt=3BMika:<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BOk=2C I've upda=
> > >ted to latest HEAD and I've also built Jay's m3sleep
> > program.<br>&gt=3B &gt=
> > >=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BHere is what happens now when I run your
> > th=
> > >readtest program on Windows 7.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
> > >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest
> > -tests =
> > >ALL=2C-fo=3D<br>&gt=3B
> > &gt=3Br=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bk<br>&gt=3B &gt=
> > >=3B&gt=3BWriting file...done<br>&gt=3B
> > &gt=3B&gt=3BCreating read threads...=
> > >done<br>&gt=3B &gt=3B&gt=3BCreating
> > nxread threads...done<br>&gt=3B &gt=3B&=
> > >gt=3BCreating tryexcept
> > threads...done<br>&gt=3B
> > &gt=3B&gt=3BCreating forkt=
> > >oomuch threads...done<br>&gt=3B
> > &gt=3B&gt=3BCreating alloc threads...done<b=
> > >r>&gt=3B &gt=3B&gt=3BCreating creat
> > threads...done<br>&gt=3B &gt=3B&gt=3BCr=
> > >eating lock threads...done<br>&gt=3B
> > &gt=3B&gt=3Brunning...printing oldest/=
> > >median age/newest<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &=
> > >gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B*** runtime error:<br>&gt=3B
> > &gt=3B&gt=
> > >=3B*** An array subscript was out of
> > range.<br>&gt=3B
> > &gt=3B&gt=3B*** =
> > > file "..\src\runtime\common\RTCollector.m3"=2C line
> > 418<br>&gt=3B &gt=3B&g=
> > >t=3B***<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
> > >=3B<br>&gt=3B
> > &gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B*** runtime error:<br>&=
> > >gt=3B &gt=3B&gt=3B*** 
> > &lt=3B*ASSERT*&gt=3B failed.<br>&gt=3B
> > &gt=3B&gt=
> > >=3B*** file
> > "..\src\thread\WIN32\ThreadWin32.m3"=2C line
> > 841<br>&gt=3B &=
> > >gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BThe last error =
> > >repeats ad infinitum until I press CNTRL-C to
> > abort.<br>&gt=3B &gt=3B&gt=3B=
> > ><br>&gt=3B &gt=3B&gt=3BI'll send more
> > info on the Windows install of Modula=
> > >3 in a subsequent post=3D<br>&gt=3B
> > &gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=
> > >=3B &gt=3B&gt=3BRegards=2C<br>&gt=3B
> > &gt=3B&gt=3BRandy Coleburn<br>&gt=3B
> > &=
> > >gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B-----Original
> > Message-----<br>&gt=3B &gt=
> > >=3B&gt=3BFrom: Mika Nystrom [mailto:mika at async.caltech.edu]=3D3D20<br>&gt=
> > >=3B &gt=3B&gt=3BSent: Saturday=2C February
> > 26=2C 2011 12:55 PM<br>&gt=3B &g=
> > >t=3B&gt=3BTo: Coleburn=2C Randy<br>&gt=3B
> > &gt=3B&gt=3BCc: m3devel at elegosoft=
> > >.com<br>&gt=3B &gt=3B&gt=3BSubject:
> > Re: [M3devel] results of threadtest pro=
> > >gram on Windows7=3D3D20<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BHi Ran=
> > >dy=2C<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BHm yes it looks like my =
> > >Windows programming skills leave
> > something<br>&gt=3B &gt=3B&gt=3Bto be
> > desi=
> > >red.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BYou can run the thread te=
> > >ster while skipping a test as
> > follows<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=
> > >=3B&gt=3B threadtest -tests
> > ALL=2C-fork<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B =
> > >&gt=3B&gt=3B(for instance)<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3Bif =
> > >you just run=3D3D20<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B threadt=
> > >est -sadfassdaf<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3Bit'll print th=
> > >e tests that are available.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BAs=
> > > it happens=2C I just had to upgrade my windows 2000
> > system to windows 7.<b=
> > >r>&gt=3B &gt=3B&gt=3BCan you give me a
> > very brief description of what you d=
> > >id to install Modula=3D<br>&gt=3B
> > &gt=3B-=3D3D<br>&gt=3B
> > &gt=3B&gt=3B3<br>&=
> > >gt=3B &gt=3B&gt=3Bon this
> > system?<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=3B&g=
> > >t=3B Mika<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B"Coleburn=2C Ran=
> > >dy" writes:<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B--_000_D67F02DDC62F7545A6B84C285F88=
> > >F3E6EE25C849atlex02srv_<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BContent-Type: text/plai=
> > >n=3B charset=3D3D3D"us-ascii"<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BContent-Transfer-=
> > >Encoding: quoted-printable<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=
> > >=3B&gt=3BMika:<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BI'v=
> > >e finally managed to get cm3 rebuilt on Windows 7
> > again.<br>&gt=3B &gt=3B&g=
> > >t=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BSo=2C I ran your threadtest
> > program.=
> > ><br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BHere are the resu=
> > >lts. Note the "..." is where I cut out a bunch of
> > the r=3D<br>&gt=3B &gt=
> > >=3Be=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Beating=
> > > "ERROR FApply" messages.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=
> > >=3B&gt=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest.e=
> > >xe<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BWriting
> > file...done<br>&gt=3B &gt=3B&gt=3B&g=
> > >t=3BCreating read threads...done<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BCreating fork =
> > >threads...done<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BCreating alloc
> > threads...done<br=
> > >>&gt=3B &gt=3B&gt=3B&gt=3BCreating
> > lock threads...done<br>&gt=3B &gt=3B&gt=
> > >=3B&gt=3Brunning...printing oldest/median
> > age/newest<br>&gt=3B &gt=3B&gt=3B=
> > >&gt=3BERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find=
> > > the f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=
> > >=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OS=
> > >Error.E: ErrorCode=3D3D3D3D2: The system cannot
> > find the f=3D<br>&gt=3B &g=
> > >t=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Be=
> > >cified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E: 
> > ErrorCode=3D3=
> > >D3D3D2: The system cannot find the
> > f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B =
> > >&gt=3B&gt=3B sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=
> > >=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B=
> > >.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B*** runtime e=
> > >rror:<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B*** An
> > enumeration or subrange value w=
> > >as out of range.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B*** file
> > "..\src\Main.m3"=
> > >=2C line 340<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<b=
> > >r>&gt=3B &gt=3B&gt=3B&gt=3Blaziest
> > thread is 0/0/ERROR FApply: OSError.E: =
> > >ErrorCode=3D3D3D3D2: The sy=3D<br>&gt=3B
> > &gt=3Bste=3D3D<br>&gt=3B &gt=3B&gt=
> > >=3Bm c=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Bannot find the file
> > specified.<br=
> > >>&gt=3B &gt=3B&gt=3B&gt=3BERROR
> > FApply: OSError.E: ErrorCode=3D3D3D3D2: Th=
> > >e system cannot find the f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=
> > >=3B sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&g=
> > >t=3BERROR FApply: OSError.E: ErrorCode=3D3D3D3D2:
> > The system cannot find t=
> > >he f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B=
> > >
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSErr=
> > >or.E: ErrorCode=3D3D3D3D2: The system cannot find
> > the f=3D<br>&gt=3B &gt=
> > >=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Bec=
> > >ified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=
> > >=3B &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Blaziest thread is 0/0/E=
> > >RROR FApply: OSError.E: ErrorCode=3D3D3D3D2: The
> > sy=3D<br>&gt=3B &gt=3Bste=
> > >=3D3D<br>&gt=3B &gt=3B&gt=3Bm
> > c=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Bannot fi=
> > >nd the file specified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E:=
> > > ErrorCode=3D3D3D3D2: The system cannot find the
> > f=3D<br>&gt=3B &gt=3Bile=
> > >=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.=
> > ><br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2:=
> > > The system cannot find the f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&=
> > >gt=3B sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B=
> > >&gt=3BERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find=
> > > the f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=
> > >=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=
> > >=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B=
> > >ERROR FApply: OSError.E: ErrorCode=3D3D3D3D2: The
> > system cannot find the f=
> > >=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B &gt=
> > >=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E=
> > >: ErrorCode=3D3D3D3D2: The system cannot find the
> > f=3D<br>&gt=3B &gt=3Bile=
> > >=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.=
> > ><br>&gt=3B
> > &gt=3B&gt=3B&gt=3BStack
> > trace:<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B FP=
> > > PC 
> > Procedure<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B--------- ---------=
> > > 
> > -------------------------------<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B0x30fbd0 0x1=
> > >27218a PutStats + 0x1a3 in
> > ..\src\Main.m3<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B0x30=
> > >fcc0 0x1273825 Main_M3 + 0x11db(!) in
> > ..\src\Main.m3<br>&gt=3B &gt=3B&gt=
> > >=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BRegards=2C<br>&gt=3B
> > &gt=3B&gt=3B&gt=
> > >=3BRandy Coleburn<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B=
> > >--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_<br>&gt=3B
> > &gt=3B=
> > >&gt=3B&gt=3BContent-Type: text/html=3B
> > charset=3D3D3D"us-ascii"<br>&gt=3B &=
> > >gt=3B&gt=3B&gt=3BContent-Transfer-Encoding:
> > quoted-printable<br>&gt=3B &gt=
> > >=3B&gt=3B&gt=3B<br> 
> > 
> > 
> > </body>
> > ></html>=
> > >
> > >--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_--
> > 
> 
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110302/cc086c5c/attachment.html>

From hendrik at topoi.pooq.com  Wed Mar  2 04:39:45 2011
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Tue, 1 Mar 2011 22:39:45 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <20110301181718.12EFC1A2078@async.async.caltech.edu>
References: <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>
	<COL101-W6172E969583BD60401B836E6C10@phx.gbl>
	<20110301181718.12EFC1A2078@async.async.caltech.edu>
Message-ID: <20110302033945.GC32641@topoi.pooq.com>

On Tue, Mar 01, 2011 at 10:17:18AM -0800, Mika Nystrom wrote:
> 
> Hi Jay,
> 
> 2. Not sure how you could get negative timings.  That would suggest that
> Time.Now() is decreasing---which seems contrary to its specification.
> Although the code is doing some nasty stuff with the timings, mainly
> reading and writing them without locks.  But it's using INTEGER for
> the results so I don't think there can be an atomicity problem there.
> Even if there were coherence problems between processors (is this
> technically possible?) the "now" value has to be coherent since it's
> from the thread that prints the results, and the "then" values could
> only be getting older, not newer...

I've been on a machine before on which the clock occasinally ran 
backwards -- notably a CDC Cyber machine.  I don't doubt that OS and 
hardware designers have found ways to replicate this behaviour on moderm 
machines.  :-(

-- hendrik


From jay.krell at cornell.edu  Wed Mar  2 05:49:16 2011
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Mar 2011 04:49:16 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <20110302033945.GC32641@topoi.pooq.com>
References: <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	<COL101-W6172E969583BD60401B836E6C10@phx.gbl>,
	<20110301181718.12EFC1A2078@async.async.caltech.edu>,
	<20110302033945.GC32641@topoi.pooq.com>
Message-ID: <COL101-W4908705893B5758DC5446EE6C00@phx.gbl>


> I've been on a machine before on which the clock occasinally ran 
> backwards -- notably a CDC Cyber machine. I don't doubt that OS and 
> hardware designers have found ways to replicate this behaviour on moderm 
> machines. :-(
> I've been on a machine before on which the clock occasinally ran 
> backwards -- notably a CDC Cyber machine. I don't doubt that OS and 

Come on! Widely used modern systems must be and are very high quality,
not like older and little used systems. The clock is not going backwards.
 
 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110302/3f0e8a9c/attachment.html>

From hosking at cs.purdue.edu  Wed Mar  2 15:11:55 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 2 Mar 2011 09:11:55 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W3670B74A99994199607C6BE6C00@phx.gbl>
References: <20110301181718.12EFC1A2078@async.async.caltech.edu>,
	<452042.5906.qm@web29706.mail.ird.yahoo.com>
	<COL101-W3670B74A99994199607C6BE6C00@phx.gbl>
Message-ID: <D8168970-37FE-43C9-8127-BE5024AD43E0@cs.purdue.edu>

'Twould be useful to see a stack dump.

On Mar 1, 2011, at 10:11 PM, Jay K wrote:

> Most of the runs error or succeed within 10 minutes. The one Solaris/sparc run I made ran for well over 4 hours and didn't get very far. I'd say it was hung forever.
>  
>  
> I didn't debug it.
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110302/3228a606/attachment.html>

From dabenavidesd at yahoo.es  Wed Mar  2 22:31:41 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 2 Mar 2011 21:31:41 +0000 (GMT)
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W3670B74A99994199607C6BE6C00@phx.gbl>
Message-ID: <571065.83147.qm@web29715.mail.ird.yahoo.com>

Hi all:
yes, but technically you could insert some empty chips slots on the same wafer but in cases of blade systems I'm sure you can, just don't know how much about something like plug-and-play with that.
Thanks in advance

--- El mar, 1/3/11, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: RE: [M3devel] results of threadtest program on Windows7
Para: dabenavidesd at yahoo.es, "Mika Nystrom" <mika at async.caltech.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: martes, 1 de marzo, 2011 22:11




I have still have mostly uniprocessors (though busy selling stuff off...)

? I do have a MacBook Pro and Dell laptop with 2 processors each though.

? It is that MacBook Pro where I can consistently get Darwin to fail, and a?1 and 2 proc Windows virtual machine on the MacBook Pro?that consistently works.

? While Modula-3 user threads never run anything truly concurrently, i.e. on multiple prcoessors, there should still be almost arbitrary preemption.

?

?

I'm skeptical of?any emulation's or virtualization's ability to simulate more processors than underlying physical processors.

?

?

Most of the runs error or succeed within 10 minutes. The one Solaris/sparc run I made ran for well over 4 hours and didn't get very far. I'd say it was hung forever.

?

?

I didn't debug it.

?

?

Yes, OpenBSD pthreads are user threads and therefore probably only ever use one processor.

But that machine only has one. :)


?

I think this will quite difficult to track down.

It might be useful to find an old starting point that succeeds and upgrade forward looking for when things fail.

That is tedious and has its own set of difficulties, granted.

?There are many points in time that don't compile, many are my fault, and there are also many combinations of starting/ending points that don't compile due to some mismatches between start/end.

?

?

I have to try Linux and/or FreeBSD still.

?

?

The errors on Darwin imply to me that memory is being prematurely reclaimed by the garbage collector -- e.g. EBUSY from pthread_mutex_destroy.

But it could also be arbitrary memory corruption (sort of the same thing), same example, but rather than an actually busy mutex, it could be a corrupted mutex or random pointer. Some of that might be easy to track down, e.g. by tracing which addresses are initialized as mutexes, and maybe by putting pad bytes around mutexes and seeing if they get changed.

I'm reluctant to try draw any conclusions yet though, since I have very very little information/knowledge.

?

?

I also forgot to check if I was using any optimization. I'll be sure to not.

?

?

?- Jay


?

> Date: Tue, 1 Mar 2011 22:10:55 +0000
> From: dabenavidesd at yahoo.es
> To: jay.krell at cornell.edu; mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Hi all:
> but you could still run a *nix image with uniprocessor support kernel and try on the vbox, qemu, etc.
> Perhaps you would get enough simulation to detect that the problem is on the hardware layer (either physically or its abstraction) rather than the execution model (the pthreads scheduling policy), if it does no work may be there is a problem in ThreadPthread implementation of pthreads (don't need to switch its default is - smp 1).
> commands i.e in qemu:
> qemu -cdrom /path/to/system.iso -smp 2 
> and run threadtest from there
> 
> Thanks in advance
> 
> 
> 
> 
> 
> 
> --- El mar, 1/3/11, Mika Nystrom <mika at async.caltech.edu> escribi?:
> 
> > De: Mika Nystrom <mika at async.caltech.edu>
> > Asunto: Re: [M3devel] results of threadtest program on Windows7
> > Para: "Jay K" <jay.krell at cornell.edu>
> > CC: m3devel at elegosoft.com
> > Fecha: martes, 1 de marzo, 2011 13:17
> > 
> > Hi Jay,
> > 
> > 1. I think you should get forward progress no matter what,
> > although it
> > might be very slow on some systems.
> > 
> > 2. Not sure how you could get negative timings. That
> > would suggest that
> > Time.Now() is decreasing---which seems contrary to its
> > specification.
> > Although the code is doing some nasty stuff with the
> > timings, mainly
> > reading and writing them without locks. But it's
> > using INTEGER for
> > the results so I don't think there can be an atomicity
> > problem there.
> > Even if there were coherence problems between processors
> > (is this
> > technically possible?) the "now" value has to be coherent
> > since it's
> > from the thread that prints the results, and the "then"
> > values could
> > only be getting older, not newer...
> > 
> > 3. Note that there are systems (FreeBSD 4 is an example)
> > that have a
> > "pthreads" library but where the pthreads library is
> > implemented with
> > user threads. Could that be related to why OpenBSD is
> > working?
> > 
> > 4. Hm. I think I am only using multiprocessor
> > systems, yes. Hard to
> > find single-CPU systems nowadays! I think actually
> > the only one I have
> > is PPC_DARWIN, and I haven't tried the code on that. 
> > So yes this is a
> > possibility as far as explaining differences...
> > 
> > Mika
> > 
> > Jay K writes:
> > >--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_
> > >Content-Type: text/plain; charset="iso-8859-1"
> > >Content-Transfer-Encoding: quoted-printable
> > >
> > >
> > >I also haven't seen it fail on OpenBSD/x86/4.7. I'm
> > pretty sure using pthre=
> > >ads there.
> > >But on Solaris/5.10/sparc it hangs=2C for many hours.
> > >
> > >-bash-4.1$ ./threadtest=20
> > >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
> > >.
> > >
> > >Are we guranteed forward progress in suspending all
> > threads?
> > >
> > >I do see it fail usually on Darwin. e.g.:
> > >........pthread_mutex_destroy:EBUSY
> > >pthread_mutex_destroy:EBUSY
> > >..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:
> > >*** An array subscript was out of range.
> > >*** file
> > "../src/runtime/common/RTCollector.m3"=2C line 418
> > >***
> > >
> > >I haven't tried Linux yet.
> > >Do note that we have some variance in the pthreads
> > implementation.
> > >The "portable" implementation is used on Linux=2C
> > Solaris=2C NetBSD.
> > >And then OpenBSD=2C Darwin=2C FreeBSD each have slight
> > differences.
> > >
> > >Mika are your machines all multiprocessors?
> > >I do wonder if that helps increase the stress and if I
> > should be sure to us=
> > >e multiprocessors.
> > >
> > >I'm also considering taking the time to try various
> > historical versions=2C =
> > >either releases or dates in CVS.
> > >
> > > - Jay
> > >
> > >From: jay.krell at cornell.edu
> > >To: mika at async.caltech.edu=3B
> > rcolebur at scires.com
> > >Date: Tue=2C 1 Mar 2011 10:59:29 +0000
> > >CC: m3devel at elegosoft.com
> > >Subject: Re: [M3devel] results of threadtest program on
> > Windows7
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >I haven't seen it fail on NT=2C except for PutCard in
> > the test itself getti=
> > >ng negative numbers.
> > >I've run it just a few times now. One single and dual
> > processor virtual mac=
> > >hines.
> > >Randy=2C has it failed many times for you?
> > >
> > > - Jay
> > >
> > >> To: rcolebur at SCIRES.COM
> > >> Date: Sun=2C 27 Feb 2011 15:11:25 -0800
> > >> From: mika at async.caltech.edu
> > >> CC: m3devel at elegosoft.com
> > >> Subject: Re: [M3devel] results of threadtest
> > program on Windows7
> > >>=20
> > >> Ah=2C it just doesn't check command-line arguments
> > that carefully.
> > >>=20
> > >> I think what you did is equivalent to "-tests
> > STD".
> > >=20
> > >> Mika
> > >>=20
> > >> "Coleburn=2C Randy" writes:
> > >> >Mika:
> > >> >
> > >> >No change with "-tests POSIX".
> > >> >
> > >> >Interesting twist: On Windows 7=2C I
> > thought I'd see what the command l=
> > >ine o=3D
> > >> >ptions are=2C and I typed "threadtest -help"
> > rather than reading the cod=
> > >e.
> > >> >
> > >> >First time=2C it produced what appears to be a
> > NIL deref crash. Then=2C=
> > > I trie=3D
> > >> >d it again and it ran to completion. 
> > Something seems non-deterministic =
> > >her=3D
> > >> >e. See below.
> > >> >
> > >>
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > -help
> > >> >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
> > >> >.
> > >> >
> > >> >***
> > >> >*** runtime error:
> > >> >*** Attempt to reference an
> > illegal memory location.
> > >> >*** pc =3D3D 0x77762262
> > >> >***
> > >> >
> > >> >Stack trace:
> > >> > FP 
> > PC Procedure
> > >> >--------- --------- 
> > -------------------------------
> > >> > 0xcdf998 0x130351b SystemError +
> > 0x64 in ..\src\runtime\NT386\RTSigna=
> > >l.m=3D
> > >> >3
> > >> > 0xcdf9c0 0x77762262 <???>
> > >> > 0xcdf9d8 0x12e83b7 LockMutex +
> > 0x4f in ..\src\thread\WIN32\ThreadWin3=
> > >2.m=3D
> > >> >3
> > >> > 0xcdfa00 0x12c7b08 GetChar + 0x28
> > in ..\src\rw\Rd.m3
> > >> > 0xcdfb38 0x12c12e3 RApply + 0xd3
> > in ..\src\Main.m3
> > >> > 0xcdfb74 0x12e971f ThreadBase +
> > 0x254 in ..\src\thread\WIN32\ThreadWi=
> > >n32=3D
> > >> >.m3
> > >> > 0xcdfb80 0x76543677 <???>
> > >> > 0xcdfbc0 0x77779f02 <???>
> > >> >......... ......... ... more
> > frames ...
> > >> >
> > >>
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > -help
> > >> >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
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >All tests complete. Congratulations.
> > >> >
> > >> >Regards=2C
> > >> >Randy Coleburn
> > >> >
> > >> >-----Original Message-----
> > >> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> > >> >Sent: Sunday=2C February 27=2C 2011 3:30 PM
> > >> >To: Coleburn=2C Randy
> > >> >Cc: m3devel at elegosoft.com
> > >> >Subject: Re: [M3devel] results of threadtest
> > program on Windows7=3D20
> > >> >
> > >> >Hi Randy=2C
> > >> >
> > >> >You can try it with -tests POSIX as well.
> > >> >
> > >> >I find on user threads it runs very slowly
> > (but it does run) because of =
> > >how=3D
> > >> > unfair
> > >> >the thread scheduler is.
> > >> >
> > >> >Next step might be to whittle down the tests
> > and see if you can get a fa=
> > >ilu=3D
> > >> >re with
> > >> >a single test running and -n 2. That
> > would likely be the simplest scena=
> > >rio=3D
> > >> > to
> > >> >start further debugging from.
> > >> >
> > >> > Mika
> > >> >
> > >> >"Coleburn=2C Randy" writes:
> > >> >>Mika et al:
> > >> >>
> > >> >>Thought I would try something else.
> > >> >>
> > >> >>I took the sources of your thread test
> > program to an older XP machine t=
> > >hat=3D
> > >> > =3D3D
> > >> >>has CM3 circa August 2008. This is
> > the machine and implementation I us=
> > >ed =3D
> > >> >w=3D3D
> > >> >>hen building a major project I did a
> > couple years back.
> > >> >>
> > >> >>The thread test program does indeed build
> > on this old system=2C but whe=
> > >n I r=3D
> > >> >u=3D3D
> > >> >>n it=2C I get different results than with
> > the latest HEAD branch code. =
> > >=3D3D20
> > >> >>
> > >> >>After it prints "running...printing
> > oldest/median age/newest"=2C on the=
> > > next=3D
> > >> > =3D3D
> > >> >>line I get two periods ".." and now the
> > program seems hung. I'll let i=
> > >t "=3D
> > >> >r=3D3D
> > >> >>un" for a few more minutes to see if
> > anything else happens before killi=
> > >ng =3D
> > >> >i=3D3D
> > >> >>t.
> > >> >>
> > >> >>At least we don't get the subscript and
> > assertion failures on this olde=
> > >r C=3D
> > >> >M=3D3D
> > >> >>3 platform.
> > >> >>
> > >> >>Regards=2C
> > >> >>Randy Coleburn
> > >> >>
> > >> >>
> > >> >>-----Original Message-----
> > >> >>From: Coleburn=2C Randy=3D3D20
> > >> >>Sent: Sunday=2C February 27=2C 2011 2:09
> > PM
> > >> >>To: m3devel at elegosoft.com
> > >> >>Subject: Re: [M3devel] results of
> > threadtest program on Windows7
> > >> >>
> > >> >>Mika:
> > >> >>
> > >> >>Ok=2C I've updated to latest HEAD and I've
> > also built Jay's m3sleep pro=
> > >gram.
> > >> >>
> > >> >>Here is what happens now when I run your
> > threadtest program on Windows =
> > >7.
> > >> >>
> > >>
> > >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest
> > -tests ALL=
> > >=2C-fo=3D
> > >> >r=3D3D
> > >> >>k
> > >> >>Writing file...done
> > >> >>Creating read threads...done
> > >> >>Creating nxread threads...done
> > >> >>Creating tryexcept threads...done
> > >> >>Creating forktoomuch threads...done
> > >> >>Creating alloc threads...done
> > >> >>Creating creat threads...done
> > >> >>Creating lock threads...done
> > >> >>running...printing oldest/median
> > age/newest
> > >> >>
> > >> >>
> > >> >>***
> > >> >>*** runtime error:
> > >> >>*** An array subscript was
> > out of range.
> > >> >>*** file
> > "..\src\runtime\common\RTCollector.m3"=2C line 418
> > >> >>***
> > >> >>
> > >> >>
> > >> >>
> > >> >>***
> > >> >>*** runtime error:
> > >> >>*** <*ASSERT*> failed.
> > >> >>*** file
> > "..\src\thread\WIN32\ThreadWin32.m3"=2C line 841
> > >> >>***
> > >> >>
> > >> >>The last error repeats ad infinitum until
> > I press CNTRL-C to abort.
> > >> >>
> > >> >>I'll send more info on the Windows install
> > of Modula3 in a subsequent p=
> > >ost=3D
> > >> >.
> > >> >>
> > >> >>Regards=2C
> > >> >>Randy Coleburn
> > >> >>
> > >> >>-----Original Message-----
> > >> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D3D20
> > >> >>Sent: Saturday=2C February 26=2C 2011
> > 12:55 PM
> > >> >>To: Coleburn=2C Randy
> > >> >>Cc: m3devel at elegosoft.com
> > >> >>Subject: Re: [M3devel] results of
> > threadtest program on Windows7=3D3D20
> > >> >>
> > >> >>Hi Randy=2C
> > >> >>
> > >> >>Hm yes it looks like my Windows
> > programming skills leave something
> > >> >>to be desired.
> > >> >>
> > >> >>You can run the thread tester while
> > skipping a test as follows
> > >> >>
> > >> >> threadtest -tests
> > ALL=2C-fork
> > >> >>
> > >> >>(for instance)
> > >> >>
> > >> >>if you just run=3D3D20
> > >> >>
> > >> >> threadtest -sadfassdaf
> > >> >>
> > >> >>it'll print the tests that are available.
> > >> >>
> > >> >>As it happens=2C I just had to upgrade my
> > windows 2000 system to window=
> > >s 7.
> > >> >>Can you give me a very brief description
> > of what you did to install Mod=
> > >ula=3D
> > >> >-=3D3D
> > >> >>3
> > >> >>on this system?
> > >> >>
> > >> >> Mika
> > >> >>
> > >> >>"Coleburn=2C Randy" writes:
> > >>
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >> >>>Content-Type: text/plain=3B
> > charset=3D3D3D"us-ascii"
> > >> >>>Content-Transfer-Encoding:
> > quoted-printable
> > >> >>>
> > >> >>>Mika:
> > >> >>>
> > >> >>>I've finally managed to get cm3
> > rebuilt on Windows 7 again.
> > >> >>>
> > >> >>>So=2C I ran your threadtest program.
> > >> >>>
> > >> >>>Here are the results. Note the
> > "..." is where I cut out a bunch of th=
> > >e r=3D
> > >> >e=3D3D
> > >> >>p=3D3D3D
> > >> >>>eating "ERROR FApply" messages.
> > >> >>>
> > >>
> > >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > >> >>>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
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>.
> > >> >>>.
> > >> >>>.
> > >> >>>***
> > >> >>>*** runtime error:
> > >> >>>*** An enumeration or
> > subrange value was out of range.
> > >> >>>*** file
> > "..\src\Main.m3"=2C line 340
> > >> >>>***
> > >> >>>
> > >> >>>laziest thread is 0/0/ERROR FApply:
> > OSError.E: ErrorCode=3D3D3D3D2: T=
> > >he sy=3D
> > >> >ste=3D3D
> > >> >>m c=3D3D3D
> > >> >>>annot find the file specified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>.
> > >> >>>.
> > >> >>>.
> > >> >>>laziest thread is 0/0/ERROR FApply:
> > OSError.E: ErrorCode=3D3D3D3D2: T=
> > >he sy=3D
> > >> >ste=3D3D
> > >> >>m c=3D3D3D
> > >> >>>annot find the file specified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>.
> > >> >>>.
> > >> >>>.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>Stack trace:
> > >> >>> FP 
> > PC Procedure
> > >> >>>--------- --------- 
> > -------------------------------
> > >> >>>0x30fbd0 0x127218a 
> > PutStats + 0x1a3 in ..\src\Main.m3
> > >> >>>0x30fcc0 0x1273825 Main_M3
> > + 0x11db(!) in ..\src\Main.m3
> > >> >>>
> > >> >>>Regards=2C
> > >> >>>Randy Coleburn
> > >> >>>
> > >>
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >> >>>Content-Type: text/html=3B
> > charset=3D3D3D"us-ascii"
> > >> >>>Content-Transfer-Encoding:
> > quoted-printable
> > >> >>>
> > > 
> > 
> > 
> > =
> > >
> > >--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_
> > >Content-Type: text/html; charset="iso-8859-1"
> > >Content-Transfer-Encoding: quoted-printable
> > >
> > ><html>
> > ><head>
> > ><style><!--
> > >.hmmessage P
> > >{
> > >margin:0px=3B
> > >padding:0px
> > >}
> > >body.hmmessage
> > >{
> > >font-size: 10pt=3B
> > >font-family:Tahoma
> > >}
> > >--></style>
> > ></head>
> > ><body class=3D'hmmessage'>
> > >I also haven't seen it fail on OpenBSD/x86/4.7. I'm
> > pretty sure using pthre=
> > >ads there.<br>But on Solaris/5.10/sparc it
> > hangs=2C for many hours.<br><br>=
> > >-bash-4.1$ ./threadtest <br>Writing
> > file...done<br>Creating read threads...=
> > >done<br>Creating fork
> > threads...done<br>Creating alloc
> > threads...done<br>Cr=
> > >eating lock threads...done<br>running...printing
> > oldest/median age/newest<b=
> > >r>.<br><br>Are we guranteed forward
> > progress in suspending all threads?<br>=
> > ><br>I do see it fail usually on Darwin.
> > e.g.:<br>........pthread_mutex_dest=
> > >roy:EBUSY<br>pthread_mutex_destroy:EBUSY<br>..laziest
> > thread is 0/0/0 (test=
> > >s: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock
> > 0/0/0)<br>...<br><br>***<br>*** r=
> > >untime
> > error:<br>***&nbsp=3B&nbsp=3B&nbsp=3B An
> > array subscript was out of =
> > >range.<br>***&nbsp=3B&nbsp=3B&nbsp=3B
> > file "../src/runtime/common/RTCollect=
> > >or.m3"=2C line 418<br>***<br><br>I
> > haven't tried Linux yet.<br>Do note that=
> > > we have some variance in the pthreads
> > implementation.<br>The "portable" im=
> > >plementation is used on Linux=2C Solaris=2C
> > NetBSD.<br>And then OpenBSD=2C =
> > >Darwin=2C FreeBSD each have slight
> > differences.<br><br>Mika are your machin=
> > >es all multiprocessors?<br>I do wonder if that
> > helps increase the stress an=
> > >d if I should be sure to use
> > multiprocessors.<br><br>I'm also considering t=
> > >aking the time to try various historical versions=2C
> > either releases or dat=
> > >es in CVS.<br><br>&nbsp=3B-
> > Jay<br><br><hr id=3D"stopSpelling">From:
> > jay.kr=
> > >ell at cornell.edu<br>To:
> > mika at async.caltech.edu=3B
> > rcolebur at scires.com<br>Dat=
> > >e: Tue=2C 1 Mar 2011 10:59:29 +0000<br>CC: m3devel at elegosoft.com<br>Subject=
> > >: Re: [M3devel] results of threadtest program on
> > Windows7<br><br>
> > >
> > ><meta http-equiv=3D"Content-Type"
> > content=3D"text/html=3B charset=3Dunicode=
> > >">
> > ><meta name=3D"Generator" content=3D"Microsoft
> > SafeHTML">
> > ><style>
> > >.ExternalClass .ecxhmmessage P
> > >{padding:0px=3B}
> > >.ExternalClass body.ecxhmmessage
> > >{font-size:10pt=3Bfont-family:Tahoma=3B}
> > >
> > ></style>
> > >
> > >
> > >I haven't seen it fail on NT=2C except for PutCard in
> > the test itself getti=
> > >ng negative numbers.<br>I've run it just a few
> > times now. One single and du=
> > >al processor virtual machines.<br>Randy=2C has it
> > failed many times for you=
> > >?<br><br>&nbsp=3B-
> > Jay<br><br>&gt=3B To: rcolebur at SCIRES.COM<br>&gt=3B
> > Date=
> > >: Sun=2C 27 Feb 2011 15:11:25 -0800<br>&gt=3B
> > From: mika at async.caltech.edu<=
> > >br>&gt=3B CC: m3devel at elegosoft.com<br>&gt=3B
> > Subject: Re: [M3devel] result=
> > >s of threadtest program on Windows7<br>&gt=3B
> > <br>&gt=3B Ah=2C it just does=
> > >n't check command-line arguments that
> > carefully.<br>&gt=3B <br>&gt=3B I thi=
> > >nk what you did is equivalent to "-tests
> > STD".<br>&gt=3B <br>&gt=3B 
> > Mi=
> > >ka<br>&gt=3B <br>&gt=3B
> > "Coleburn=2C Randy" writes:<br>&gt=3B
> > &gt=3BMika:<b=
> > >r>&gt=3B &gt=3B<br>&gt=3B
> > &gt=3BNo change with "-tests POSIX".<br>&gt=3B
> > &g=
> > >t=3B<br>&gt=3B &gt=3BInteresting
> > twist: On Windows 7=2C I thought I'd see =
> > >what the command line o=3D<br>&gt=3B
> > &gt=3Bptions are=2C and I typed "threa=
> > >dtest -help" rather than reading the
> > code.<br>&gt=3B &gt=3B<br>&gt=3B
> > &gt=
> > >=3BFirst time=2C it produced what appears to be a NIL
> > deref crash. Then=2C=
> > > I trie=3D<br>&gt=3B &gt=3Bd it again and
> > it ran to completion. Something =
> > >seems non-deterministic her=3D<br>&gt=3B
> > &gt=3Be. See below.<br>&gt=3B &gt=
> > >=3B<br>&gt=3B
> > &gt=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bt=
> > >hreadtest.exe -help<br>&gt=3B
> > &gt=3BWriting file...done<br>&gt=3B
> > &gt=3BCre=
> > >ating read threads...done<br>&gt=3B
> > &gt=3BCreating fork threads...done<br>&=
> > >gt=3B &gt=3BCreating alloc
> > threads...done<br>&gt=3B &gt=3BCreating lock
> > thr=
> > >eads...done<br>&gt=3B
> > &gt=3Brunning...printing oldest/median
> > age/newest<br>=
> > >&gt=3B &gt=3B.<br>&gt=3B
> > &gt=3B<br>&gt=3B
> > &gt=3B***<br>&gt=3B &gt=3B*** run=
> > >time error:<br>&gt=3B &gt=3B*** 
> > Attempt to reference an illegal memory l=
> > >ocation.<br>&gt=3B &gt=3B*** 
> > pc =3D3D 0x77762262<br>&gt=3B
> > &gt=3B***<br>=
> > >&gt=3B &gt=3B<br>&gt=3B
> > &gt=3BStack trace:<br>&gt=3B
> > &gt=3B FP 
> > PC=
> > > Procedure<br>&gt=3B
> > &gt=3B--------- --------- 
> > ---------------------=
> > >----------<br>&gt=3B &gt=3B
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\s=
> > >rc\runtime\NT386\RTSignal.m=3D<br>&gt=3B
> > &gt=3B3<br>&gt=3B &gt=3B 0xcdf9c0 =
> > > 0x77762262 
> > &lt=3B???&gt=3B<br>&gt=3B &gt=3B
> > 0xcdf9d8 0x12e83b7 LockMute=
> > >x + 0x4f in
> > ..\src\thread\WIN32\ThreadWin32.m=3D<br>&gt=3B
> > &gt=3B3<br>&gt=
> > >=3B &gt=3B 0xcdfa00 0x12c7b08 GetChar +
> > 0x28 in ..\src\rw\Rd.m3<br>&gt=3B=
> > > &gt=3B 0xcdfb38 0x12c12e3 RApply +
> > 0xd3 in ..\src\Main.m3<br>&gt=3B &gt=
> > >=3B 0xcdfb74 0x12e971f ThreadBase + 0x254
> > in ..\src\thread\WIN32\ThreadWi=
> > >n32=3D<br>&gt=3B
> > &gt=3B.m3<br>&gt=3B &gt=3B 0xcdfb80 
> > 0x76543677 &lt=3B???=
> > >&gt=3B<br>&gt=3B &gt=3B
> > 0xcdfbc0 0x77779f02 
> > &lt=3B???&gt=3B<br>&gt=3B &gt=
> > >=3B......... ......... ... more frames
> > ...<br>&gt=3B &gt=3B<br>&gt=3B
> > &gt=
> > >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest.exe
> > -he=
> > >lp<br>&gt=3B &gt=3BWriting
> > file...done<br>&gt=3B &gt=3BCreating read
> > thread=
> > >s...done<br>&gt=3B &gt=3BCreating fork
> > threads...done<br>&gt=3B &gt=3BCreat=
> > >ing alloc threads...done<br>&gt=3B
> > &gt=3BCreating lock threads...done<br>&g=
> > >t=3B &gt=3Brunning...printing oldest/median
> > age/newest<br>&gt=3B &gt=3B....=
> > >......laziest thread is 0/0/0 (tests: read 0/0/0 fork
> > 0/0/0 alloc 0/0/0=3D<=
> > >br>&gt=3B &gt=3B lock
> > 0/0/0)<br>&gt=3B &gt=3B..........laziest
> > thread is 0/=
> > >0/0 (tests: read 0/0/0 fork 0/0/0 alloc
> > 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/=
> > >0)<br>&gt=3B &gt=3B..........laziest
> > thread is 0/0/0 (tests: read 0/0/0 for=
> > >k 0/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B
> > lock 0/0/0)<br>&gt=3B &gt=3B.......=
> > >...laziest thread is 0/0/0 (tests: read 0/0/0 fork
> > 0/0/0 alloc 0/0/0=3D<br>=
> > >&gt=3B &gt=3B lock 0/0/0)<br>&gt=3B
> > &gt=3B..........laziest thread is 0/0/0=
> > > (tests: read 0/0/0 fork 0/0/0 alloc
> > 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/0)<=
> > >br>&gt=3B &gt=3B..........laziest thread is
> > 0/0/0 (tests: read 0/0/0 fork 0=
> > >/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock
> > 0/0/0)<br>&gt=3B &gt=3B..........=
> > >laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0
> > alloc 0/0/0=3D<br>&gt=
> > >=3B &gt=3B lock 0/0/0)<br>&gt=3B
> > &gt=3B..........laziest thread is 0/0/0 (t=
> > ests: read 0/0/0 fork 0/0/0 alloc
> > 0/0/0=3D<br>&gt=3B &gt=3B lock
> > 0/0/0)<br>=
> > >&gt=3B &gt=3B..........laziest thread is 0/0/0
> > (tests: read 0/0/0 fork 0/0/=
> > >0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock
> > 0/0/0)<br>&gt=3B &gt=3B..........laz=
> > >iest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0
> > alloc 0/0/0=3D<br>&gt=3B=
> > > &gt=3B lock 0/0/0)<br>&gt=3B
> > &gt=3BAll tests complete. Congratulations.<b=
> > >r>&gt=3B &gt=3B<br>&gt=3B
> > &gt=3BRegards=2C<br>&gt=3B &gt=3BRandy
> > Coleburn<b=
> > >r>&gt=3B &gt=3B<br>&gt=3B
> > &gt=3B-----Original Message-----<br>&gt=3B
> > &gt=3B=
> > >From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20<br>&gt=3B
> > &gt=3BSen=
> > >t: Sunday=2C February 27=2C 2011 3:30
> > PM<br>&gt=3B &gt=3BTo: Coleburn=2C Ra=
> > >ndy<br>&gt=3B &gt=3BCc: m3devel at elegosoft.com<br>&gt=3B
> > &gt=3BSubject: Re: =
> > >[M3devel] results of threadtest program on
> > Windows7=3D20<br>&gt=3B &gt=3B<b=
> > >r>&gt=3B &gt=3BHi
> > Randy=2C<br>&gt=3B &gt=3B<br>&gt=3B
> > &gt=3BYou can try it =
> > >with -tests POSIX as well.<br>&gt=3B
> > &gt=3B<br>&gt=3B &gt=3BI find on user =
> > >threads it runs very slowly (but it does run) because
> > of how=3D<br>&gt=3B &=
> > >gt=3B unfair<br>&gt=3B &gt=3Bthe thread
> > scheduler is.<br>&gt=3B
> > &gt=3B<br>&=
> > >gt=3B &gt=3BNext step might be to whittle down the
> > tests and see if you can=
> > > get a failu=3D<br>&gt=3B &gt=3Bre
> > with<br>&gt=3B &gt=3Ba single test runni=
> > >ng and -n 2. That would likely be the simplest
> > scenario=3D<br>&gt=3B &gt=
> > >=3B to<br>&gt=3B &gt=3Bstart further
> > debugging from.<br>&gt=3B
> > &gt=3B<br>&g=
> > >t=3B &gt=3B 
> > Mika<br>&gt=3B
> > &gt=3B<br>&gt=3B &gt=3B"Coleburn=2C Randy"
> > w=
> > >rites:<br>&gt=3B &gt=3B&gt=3BMika et
> > al:<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &=
> > >gt=3B&gt=3BThought I would try something
> > else.<br>&gt=3B
> > &gt=3B&gt=3B<br>&g=
> > >t=3B &gt=3B&gt=3BI took the sources of your
> > thread test program to an older=
> > > XP machine that=3D<br>&gt=3B &gt=3B
> > =3D3D<br>&gt=3B &gt=3B&gt=3Bhas CM3 ci=
> > >rca August 2008. This is the machine and
> > implementation I used =3D<br>&gt=
> > >=3B &gt=3Bw=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bhen building a major project I did a=
> > > couple years back.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BThe thread=
> > > test program does indeed build on this old system=2C
> > but when I r=3D<br>&g=
> > >t=3B &gt=3Bu=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bn it=2C I get different results tha=
> > >n with the latest HEAD branch code.
> > =3D3D20<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=
> > >=3B &gt=3B&gt=3BAfter it prints
> > "running...printing oldest/median age/newes=
> > >t"=2C on the next=3D<br>&gt=3B &gt=3B
> > =3D3D<br>&gt=3B &gt=3B&gt=3Bline I ge=
> > >t two periods ".." and now the program seems
> > hung. I'll let it "=3D<br>&gt=
> > >=3B &gt=3Br=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bun" for a few more minutes to see if=
> > > anything else happens before killing
> > =3D<br>&gt=3B &gt=3Bi=3D3D<br>&gt=3B
> > =
> > >&gt=3B&gt=3Bt.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BAt least we don=
> > >'t get the subscript and assertion failures on this
> > older C=3D<br>&gt=3B &g=
> > >t=3BM=3D3D<br>&gt=3B &gt=3B&gt=3B3
> > platform.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=
> > >=3B &gt=3B&gt=3BRegards=2C<br>&gt=3B
> > &gt=3B&gt=3BRandy Coleburn<br>&gt=3B
> > &=
> > >gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B-----Original Mess=
> > >age-----<br>&gt=3B &gt=3B&gt=3BFrom:
> > Coleburn=2C Randy=3D3D20<br>&gt=3B &gt=
> > >=3B&gt=3BSent: Sunday=2C February 27=2C 2011 2:09
> > PM<br>&gt=3B &gt=3B&gt=3B=
> > >To: m3devel at elegosoft.com<br>&gt=3B
> > &gt=3B&gt=3BSubject: Re: [M3devel] resu=
> > >lts of threadtest program on
> > Windows7<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=
> > >=3B&gt=3BMika:<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BOk=2C I've upda=
> > >ted to latest HEAD and I've also built Jay's m3sleep
> > program.<br>&gt=3B &gt=
> > >=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BHere is what happens now when I run your
> > th=
> > >readtest program on Windows 7.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
> > >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest
> > -tests =
> > >ALL=2C-fo=3D<br>&gt=3B
> > &gt=3Br=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bk<br>&gt=3B &gt=
> > >=3B&gt=3BWriting file...done<br>&gt=3B
> > &gt=3B&gt=3BCreating read threads...=
> > >done<br>&gt=3B &gt=3B&gt=3BCreating
> > nxread threads...done<br>&gt=3B &gt=3B&=
> > >gt=3BCreating tryexcept
> > threads...done<br>&gt=3B
> > &gt=3B&gt=3BCreating forkt=
> > >oomuch threads...done<br>&gt=3B
> > &gt=3B&gt=3BCreating alloc threads...done<b=
> > >r>&gt=3B &gt=3B&gt=3BCreating creat
> > threads...done<br>&gt=3B &gt=3B&gt=3BCr=
> > >eating lock threads...done<br>&gt=3B
> > &gt=3B&gt=3Brunning...printing oldest/=
> > >median age/newest<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &=
> > >gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B*** runtime error:<br>&gt=3B
> > &gt=3B&gt=
> > >=3B*** An array subscript was out of
> > range.<br>&gt=3B
> > &gt=3B&gt=3B*** =
> > > file "..\src\runtime\common\RTCollector.m3"=2C line
> > 418<br>&gt=3B &gt=3B&g=
> > >t=3B***<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
> > >=3B<br>&gt=3B
> > &gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B*** runtime error:<br>&=
> > >gt=3B &gt=3B&gt=3B*** 
> > &lt=3B*ASSERT*&gt=3B failed.<br>&gt=3B
> > &gt=3B&gt=
> > >=3B*** file
> > "..\src\thread\WIN32\ThreadWin32.m3"=2C line
> > 841<br>&gt=3B &=
> > >gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BThe last error =
> > >repeats ad infinitum until I press CNTRL-C to
> > abort.<br>&gt=3B &gt=3B&gt=3B=
> > ><br>&gt=3B &gt=3B&gt=3BI'll send more
> > info on the Windows install of Modula=
> > >3 in a subsequent post=3D<br>&gt=3B
> > &gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=
> > >=3B &gt=3B&gt=3BRegards=2C<br>&gt=3B
> > &gt=3B&gt=3BRandy Coleburn<br>&gt=3B
> > &=
> > >gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B-----Original
> > Message-----<br>&gt=3B &gt=
> > >=3B&gt=3BFrom: Mika Nystrom [mailto:mika at async.caltech.edu]=3D3D20<br>&gt=
> > >=3B &gt=3B&gt=3BSent: Saturday=2C February
> > 26=2C 2011 12:55 PM<br>&gt=3B &g=
> > >t=3B&gt=3BTo: Coleburn=2C Randy<br>&gt=3B
> > &gt=3B&gt=3BCc: m3devel at elegosoft=
> > >.com<br>&gt=3B &gt=3B&gt=3BSubject:
> > Re: [M3devel] results of threadtest pro=
> > >gram on Windows7=3D3D20<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BHi Ran=
> > >dy=2C<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BHm yes it looks like my =
> > >Windows programming skills leave
> > something<br>&gt=3B &gt=3B&gt=3Bto be
> > desi=
> > >red.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BYou can run the thread te=
> > >ster while skipping a test as
> > follows<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=
> > >=3B&gt=3B threadtest -tests
> > ALL=2C-fork<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B =
> > >&gt=3B&gt=3B(for instance)<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3Bif =
> > >you just run=3D3D20<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B threadt=
> > >est -sadfassdaf<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3Bit'll print th=
> > >e tests that are available.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BAs=
> > > it happens=2C I just had to upgrade my windows 2000
> > system to windows 7.<b=
> > >r>&gt=3B &gt=3B&gt=3BCan you give me a
> > very brief description of what you d=
> > >id to install Modula=3D<br>&gt=3B
> > &gt=3B-=3D3D<br>&gt=3B
> > &gt=3B&gt=3B3<br>&=
> > >gt=3B &gt=3B&gt=3Bon this
> > system?<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=3B&g=
> > >t=3B Mika<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B"Coleburn=2C Ran=
> > >dy" writes:<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B--_000_D67F02DDC62F7545A6B84C285F88=
> > >F3E6EE25C849atlex02srv_<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BContent-Type: text/plai=
> > >n=3B charset=3D3D3D"us-ascii"<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BContent-Transfer-=
> > >Encoding: quoted-printable<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=
> > >=3B&gt=3BMika:<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BI'v=
> > >e finally managed to get cm3 rebuilt on Windows 7
> > again.<br>&gt=3B &gt=3B&g=
> > >t=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BSo=2C I ran your threadtest
> > program.=
> > ><br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BHere are the resu=
> > >lts. Note the "..." is where I cut out a bunch of
> > the r=3D<br>&gt=3B &gt=
> > >=3Be=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Beating=
> > > "ERROR FApply" messages.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=
> > >=3B&gt=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest.e=
> > >xe<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BWriting
> > file...done<br>&gt=3B &gt=3B&gt=3B&g=
> > >t=3BCreating read threads...done<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BCreating fork =
> > >threads...done<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BCreating alloc
> > threads...done<br=
> > >>&gt=3B &gt=3B&gt=3B&gt=3BCreating
> > lock threads...done<br>&gt=3B &gt=3B&gt=
> > >=3B&gt=3Brunning...printing oldest/median
> > age/newest<br>&gt=3B &gt=3B&gt=3B=
> > >&gt=3BERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find=
> > > the f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=
> > >=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OS=
> > >Error.E: ErrorCode=3D3D3D3D2: The system cannot
> > find the f=3D<br>&gt=3B &g=
> > >t=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Be=
> > >cified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E: 
> > ErrorCode=3D3=
> > >D3D3D2: The system cannot find the
> > f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B =
> > >&gt=3B&gt=3B sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=
> > >=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B=
> > >.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B*** runtime e=
> > >rror:<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B*** An
> > enumeration or subrange value w=
> > >as out of range.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B*** file
> > "..\src\Main.m3"=
> > >=2C line 340<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<b=
> > >r>&gt=3B &gt=3B&gt=3B&gt=3Blaziest
> > thread is 0/0/ERROR FApply: OSError.E: =
> > >ErrorCode=3D3D3D3D2: The sy=3D<br>&gt=3B
> > &gt=3Bste=3D3D<br>&gt=3B &gt=3B&gt=
> > >=3Bm c=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Bannot find the file
> > specified.<br=
> > >>&gt=3B &gt=3B&gt=3B&gt=3BERROR
> > FApply: OSError.E: ErrorCode=3D3D3D3D2: Th=
> > >e system cannot find the f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=
> > >=3B sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&g=
> > >t=3BERROR FApply: OSError.E: ErrorCode=3D3D3D3D2:
> > The system cannot find t=
> > >he f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B=
> > >
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSErr=
> > >or.E: ErrorCode=3D3D3D3D2: The system cannot find
> > the f=3D<br>&gt=3B &gt=
> > >=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Bec=
> > >ified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=
> > >=3B &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Blaziest thread is 0/0/E=
> > >RROR FApply: OSError.E: ErrorCode=3D3D3D3D2: The
> > sy=3D<br>&gt=3B &gt=3Bste=
> > >=3D3D<br>&gt=3B &gt=3B&gt=3Bm
> > c=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Bannot fi=
> > >nd the file specified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E:=
> > > ErrorCode=3D3D3D3D2: The system cannot find the
> > f=3D<br>&gt=3B &gt=3Bile=
> > >=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.=
> > ><br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2:=
> > > The system cannot find the f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&=
> > >gt=3B sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B=
> > >&gt=3BERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find=
> > > the f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=
> > >=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=
> > >=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B=
> > >ERROR FApply: OSError.E: ErrorCode=3D3D3D3D2: The
> > system cannot find the f=
> > >=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B &gt=
> > >=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E=
> > >: ErrorCode=3D3D3D3D2: The system cannot find the
> > f=3D<br>&gt=3B &gt=3Bile=
> > >=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.=
> > ><br>&gt=3B
> > &gt=3B&gt=3B&gt=3BStack
> > trace:<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B FP=
> > > PC 
> > Procedure<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B--------- ---------=
> > > 
> > -------------------------------<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B0x30fbd0 0x1=
> > >27218a PutStats + 0x1a3 in
> > ..\src\Main.m3<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B0x30=
> > >fcc0 0x1273825 Main_M3 + 0x11db(!) in
> > ..\src\Main.m3<br>&gt=3B &gt=3B&gt=
> > >=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BRegards=2C<br>&gt=3B
> > &gt=3B&gt=3B&gt=
> > >=3BRandy Coleburn<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B=
> > >--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_<br>&gt=3B
> > &gt=3B=
> > >&gt=3B&gt=3BContent-Type: text/html=3B
> > charset=3D3D3D"us-ascii"<br>&gt=3B &=
> > >gt=3B&gt=3B&gt=3BContent-Transfer-Encoding:
> > quoted-printable<br>&gt=3B &gt=
> > >=3B&gt=3B&gt=3B<br> 
> > 
> > 
> > </body>
> > ></html>=
> > >
> > >--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_--
> > 
> 
> 
> 
 		 	   		  



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110302/95baa618/attachment.html>

From rcolebur at SCIRES.COM  Thu Mar  3 01:42:47 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>,
	<20110227231125.3DC611A2078@async.async.caltech.edu>
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>

Yes, it fails more often than it runs for me.
Regards,
Randy

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7

I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
>
> Ah, it just doesn't check command-line arguments that carefully.
>
> I think what you did is equivalent to "-tests STD".
>
> Mika
>
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- --------- -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
> >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110302/c3494867/attachment.html>

From jay.krell at cornell.edu  Thu Mar  3 02:17:44 2011
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 3 Mar 2011 01:17:44 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>
Message-ID: <COL101-W4726257303F22627175774E6C30@phx.gbl>


Even with the change I made PutCard to PutInt?
That's the only failure I've seen.
I'll try on a non-virtual dual-proc machine later.
 
Thanks,
 - Jay
 


From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7






Yes, it fails more often than it runs for me.
Regards,
Randy
 


From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7
 
I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Ah, it just doesn't check command-line arguments that carefully.
> 
> I think what you did is equivalent to "-tests STD".
> 
> Mika
> 
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- --------- -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
> >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>> 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110303/cf2fb41d/attachment.html>

From rcolebur at SCIRES.COM  Thu Mar  3 02:36:19 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Wed, 2 Mar 2011 20:36:19 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W4726257303F22627175774E6C30@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>
	<COL101-W4726257303F22627175774E6C30@phx.gbl>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>

Jay:

Ok, I just updated from HEAD and got your latest change to thread test program.

Here are two invocations, back to back, each failing in different ways.

The second one repeats the last error message ad infinitum until you press CNTRL-C to abort.  But note, several different errors reported earlier.

Regards,
Randy

C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cm3
--- building in NT386 ---

ignoring ..\src\m3overrides

new source -> compiling Main.m3
new "Main.mo" -> linking threadtest.exe

C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cd NT386

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
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


***
*** runtime error:
***    <*ASSERT*> failed..
***    file "..\src\runtime\common\RTCollector.m3", line 1086
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0xddfaf0  0x123dffb  CleanBetween + 0x47 in ..\src\runtime\common\RTCollector.m3
0xddfb34  0x1241870  CheckLoadTracedRef + 0xc5 in ..\src\runtime\common\RTCollector.m3
0xddfb74  0x121683c  Init + 0x95 in ..\src\rw\FileRd.m3
0xddfba0  0x121679d  Open + 0x4d in ..\src\rw\FileRd.m3
0xddfcd8  0x1211288  RApply + 0x78 in ..\src\Main.m3
0xddfd14  0x123976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
0xddfd20  0x76d53677  <???>
0xddfd60  0x773c9f02  <???>
.........  .........  ... more frames ...

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
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
.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0x12ec5ad = Move + 0x50 in ..\src\runtime\common\RTCollector.m3
***



***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***



***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Wednesday, March 02, 2011 8:18 PM
To: Coleburn, Randy; m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7

Even with the change I made PutCard to PutInt?
That's the only failure I've seen.
I'll try on a non-virtual dual-proc machine later.

Thanks,
 - Jay

________________________________
From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7
Yes, it fails more often than it runs for me.
Regards,
Randy

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7

I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
>
> Ah, it just doesn't check command-line arguments that carefully.
>
> I think what you did is equivalent to "-tests STD".
>
> Mika
>
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- --------- -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
> >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110302/38ebde7e/attachment.html>

From dabenavidesd at yahoo.es  Thu Mar  3 03:27:58 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 3 Mar 2011 02:27:58 +0000 (GMT)
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W4726257303F22627175774E6C30@phx.gbl>
Message-ID: <974355.12644.qm@web29717.mail.ird.yahoo.com>

Hi all:
I would doubt but there could be some source of problem in smp on the Win32 platform, since there was a SPINE implementation on an intelligent NIC with 2 embedded MIPS CPUs, perhaps this was just a driver RT but it was for real time and in such a case there should be no problem besides that of the scheduling policy, but thinking how about linking MS Win2k R is a kind of crazy not to believe there was some synchronization with CPU board threads and that component threading at some point I believe.

Even more in embedded systems, there was a MPU implementation of it in 80186 a decade ago,? perhaps would be good to have a look of their Thread interface implementation it might be seem interesting if so.

But in any case there should be plenty of ways of implementing the threading tests incrementally of number of threads, besides you may want to check some uniprocessors with hyperThreading technology (sort of thread physical divisions inside the cpu), they are presented to OS as 2 smp processors, it could be interesting, I remember to test? time ago in this machines and anything weird happened, but quite time ago with ThreadPthread LINUXLIBC6 systems with normally distributed programs.
?
What about results in Win2k ?
Thanks in advance

--- El mi?, 2/3/11, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] results of threadtest program on Windows7
Para: rcolebur at scires.com, "m3devel" <m3devel at elegosoft.com>
Fecha: mi?rcoles, 2 de marzo, 2011 20:17




Even with the change?I made?PutCard to PutInt?

That's the only failure I've seen.

I'll try on a non-virtual dual-proc machine later.

?

Thanks,

?- Jay
?



From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7


 

#yiv891226996 .yiv891226996ExternalClass p.yiv891226996ecxMsoNormal, #yiv891226996 .yiv891226996ExternalClass li.yiv891226996ecxMsoNormal, #yiv891226996 .yiv891226996ExternalClass div.yiv891226996ecxMsoNormal
{margin-bottom:.0001pt;font-size:12.0pt;font-family:'serif';}
#yiv891226996 .yiv891226996ExternalClass a:link, #yiv891226996 .yiv891226996ExternalClass span.yiv891226996ecxMsoHyperlink
{color:blue;text-decoration:underline;}
#yiv891226996 .yiv891226996ExternalClass a:visited, #yiv891226996 .yiv891226996ExternalClass span.yiv891226996ecxMsoHyperlinkFollowed
{color:purple;text-decoration:underline;}
#yiv891226996 .yiv891226996ExternalClass p
{margin-right:0in;margin-left:0in;font-size:12.0pt;font-family:'serif';}
#yiv891226996 .yiv891226996ExternalClass span.yiv891226996ecxEmailStyle18
{font-family:'sans-serif';color:#1F497D;}
#yiv891226996 .yiv891226996ExternalClass .yiv891226996ecxMsoChpDefault
{font-size:10.0pt;}
 _filtered #yiv891226996 {}
#yiv891226996 .yiv891226996ExternalClass div.yiv891226996ecxWordSection1
{}




Yes, it fails more often than it runs for me.
Regards,
Randy
?


From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7
?
I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

?- Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Ah, it just doesn't check command-line arguments that carefully.
> 
> I think what you did is equivalent to "-tests STD".
> 
> Mika
> 
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- --------- -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
> >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>> 		 	   		  



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110303/a531d0d6/attachment.html>

From jay.krell at cornell.edu  Thu Mar  3 03:46:39 2011
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 3 Mar 2011 02:46:39 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <974355.12644.qm@web29717.mail.ird.yahoo.com>
References: <COL101-W4726257303F22627175774E6C30@phx.gbl>,
	<974355.12644.qm@web29717.mail.ird.yahoo.com>
Message-ID: <COL101-W2637AB63DA6D9866A00D07E6C30@phx.gbl>


There is probably a bug in RTCollector.m3 or RTAllocator.m3.

 - Jay

Date: Thu, 3 Mar 2011 02:27:58 +0000
From: dabenavidesd at yahoo.es
Subject: Re: [M3devel] results of threadtest program on Windows7
To: rcolebur at scires.com; m3devel at elegosoft.com; jay.krell at cornell.edu

Hi all:
I would doubt but there could be some source of problem in smp on the Win32 platform, since there was a SPINE implementation on an intelligent NIC with 2 embedded MIPS CPUs, perhaps this was just a driver RT but it was for real time and in such a case there should be no problem besides that of the scheduling policy, but thinking how about linking MS Win2k R is a kind of crazy not to believe there was some synchronization with CPU board threads and that component threading at some point I believe.

Even more in embedded systems, there was a MPU implementation of it in 80186 a decade ago,  perhaps would be good to have a look of their Thread interface implementation it might be seem interesting if so.

But in any case there should be plenty of ways of implementing the threading tests incrementally of number of threads, besides you may
 want to check some uniprocessors with hyperThreading technology (sort of thread physical divisions inside the cpu), they are presented to OS as 2 smp processors, it could be interesting, I remember to test  time ago in this machines and anything weird happened, but quite time ago with ThreadPthread LINUXLIBC6 systems with normally distributed programs.
 
What about results in Win2k ?
Thanks in advance

--- El mi?, 2/3/11, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] results of threadtest program on Windows7
Para: rcolebur at scires.com, "m3devel" <m3devel at elegosoft.com>
Fecha: mi?rcoles, 2 de marzo, 2011 20:17




Even with the change I made PutCard to PutInt?

That's the only failure I've seen.

I'll try on a non-virtual dual-proc machine later.

 

Thanks,

 - Jay
 



From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7


 



Yes, it fails more often than it runs for me.
Regards,
Randy
 


From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7
 
I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Ah, it just doesn't check command-line arguments that carefully.
> 
> I think what you did is equivalent to "-tests STD".
> 
> Mika
> 
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the
 command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- ---------
 -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
>
 >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle
 down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints
 "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built
 Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
>
 >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm
 yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type:
 text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR
 FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file
 specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply:
 OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 +
 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>> 		 	   		  

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110303/32472aed/attachment.html>

From jay.krell at cornell.edu  Thu Mar  3 07:32:50 2011
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 3 Mar 2011 06:32:50 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W2637AB63DA6D9866A00D07E6C30@phx.gbl>
References: <COL101-W4726257303F22627175774E6C30@phx.gbl>,
	<974355.12644.qm@web29717.mail.ird.yahoo.com>,
	<COL101-W2637AB63DA6D9866A00D07E6C30@phx.gbl>
Message-ID: <COL101-W1943F7B289FE5FD33E5D1EE6C30@phx.gbl>


Solaris doesn't hang now. I didn't change anything. And it succeeds.
Here are some stacks for a failure on I386_DARWIN.
Notice that it *should* abort right after the EBUSY print, but it still run a while.
Possibly too much information is lost.


(gdb) run
Starting program: /Users/jay/dev2/cm3/m3-libs/m3core/tests/thread/I386_DARWIN/threadtest 
Reading symbols for shared libraries ++. done
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
..........laziest thread is 1/0/0 (tests: read 0/0/0 fork 1/1/1 alloc 0/0/0 lock 0/0/0)
.........pthread_mutex_destroy:EBUSY (0)
.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:
***    An array subscript was out of range.
***    file "../src/runtime/common/RTCollector.m3", line 418
***


Program received signal SIGABRT, Aborted.
0x9385f44e in __semwait_signal ()
(gdb) bt
#0  0x9385f44e in __semwait_signal ()
#1  0x9388a3e6 in _pthread_cond_wait ()
#2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
#3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299133562.375689) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
#4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
#5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
#6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
#7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
#8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
#9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
#10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16


(gdb) thread apply all bt

Thread 13 (process 86311 thread 0x2a03):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#4  0x00003ed8 in Main__LApply (cl=0x9557d8) at ../src/Main.m3:290
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01130) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01130) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 12 (process 86311 thread 0x1f03):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#4  0x00003ed8 in Main__LApply (cl=0x9557a0) at ../src/Main.m3:290
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01080) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01080) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 11 (process 86311 thread 0x1e03):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#4  0x00003ed8 in Main__LApply (cl=0x955768) at ../src/Main.m3:290
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 10 (process 86311 thread 0x1d03):
#0  0x93934136 in __semwait_signal_nocancel ()
#1  0x93933d1b in nanosleep$NOCANCEL$UNIX2003 ()
#2  0x9392d013 in usleep$NOCANCEL$UNIX2003 ()
#3  0x93944685 in abort ()
#4  0x0004b5e6 in Cstdlib__abort () at ../src/C/Common/CstdlibC.c:21
#5  0x000434dd in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20
#6  0x0003d51f in RTProcess__Crash (msg=0x0) at ../src/runtime/common/RTProcess.m3:65
#7  0x0003b9d3 in RTError__EndError (crash=1 '\001') at ../src/runtime/common/RTError.m3:118
#8  0x0003b6e6 in RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:40
#9  0x0003bdc7 in RTException__Crash (a=0xb0490a64, raises=0 '\0', rte=0x7d100) at ../src/runtime/common/RTException.m3:79
#10 0x0003bb21 in RTException__DefaultBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:39
#11 0x0003ba7c in RTException__InvokeBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
#12 0x00043ca5 in RTException__Raise (act=0xb0490a64) at ../src/runtime/ex_frame/RTExFrame.m3:85
#13 0x0003bbb4 in RTException__DefaultBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:47
#14 0x0003ba7c in RTException__InvokeBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
#15 0x00043ca5 in RTException__Raise (act=0xb0490a64) at ../src/runtime/ex_frame/RTExFrame.m3:85
#16 0x0002b102 in RTHooks__ReportFault (module=0x70f80, info=13378) at ../src/runtime/common/RTHooks.m3:111
#17 0x000394c5 in _m3_fault (arg=13378) at ../src/runtime/common/RTCollector.m3:393
#18 0x0002fdd2 in RTCollector__Move (self=0xb3000c, cp=0x9a0014) at ../src/runtime/common/RTCollector.m3:418
#19 0x0002e503 in RTHeapMap__Walk (x=0x9a0014, pc=0x79928, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:202
#20 0x0002dc9c in RTHeapMap__DoWalkRef (t=0x6de54, a=0x9a0014, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:62
#21 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e3f4, a=0x9a000c, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:57
#22 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e508, a=0x9a000c, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:57
#23 0x0002dc2e in RTHeapMap__WalkRef (h=0x9a0008, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:47
#24 0x00032279 in RTCollector__CleanBetween (h=0x9a0008, he=0x9b0000, clean=0 '\0') at ../src/runtime/common/RTCollector.m3:1091
#25 0x00032098 in RTCollector__CleanPage (page=0x9a0000) at ../src/runtime/common/RTCollector.m3:1064
#26 0x00031798 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885
#27 0x00030e75 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720
#28 0x00030a97 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654
#29 0x0002cb85 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00f64) at ../src/runtime/common/RTAllocator.m3:367
#30 0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:296
#31 0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:143
#32 0x00003b5f in Main__AApply (cl=0x9556f8) at ../src/Main.m3:260
#33 0x00046ee2 in ThreadPThread__RunThread (me=0xa00f20) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#34 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00f20) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#35 0x93889155 in _pthread_start ()
#36 0x93889012 in thread_start ()

Thread 9 (process 86311 thread 0x1c03):
#0  0x938582a2 in semaphore_wait_trap ()
#1  0x9385fd92 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00eb4) at ../src/runtime/common/RTAllocator.m3:365
#5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:296
#6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:143
#7  0x00003b5f in Main__AApply (cl=0x9556c0) at ../src/Main.m3:260
#8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00e70) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00e70) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#10 0x93889155 in _pthread_start ()
#11 0x93889012 in thread_start ()

Thread 8 (process 86311 thread 0x1b03):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00e04) at ../src/runtime/common/RTAllocator.m3:365
#5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:296
#6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:143
#7  0x00003b5f in Main__AApply (cl=0x955688) at ../src/Main.m3:260
#8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00dc0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00dc0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#10 0x93889155 in _pthread_start ()
#11 0x93889012 in thread_start ()

Thread 7 (process 86311 thread 0x1a03):
#0  0x9389c856 in __wait4 ()
#1  0x9389c847 in waitpid$UNIX2003 ()
#2  0x0004b222 in Uexec__waitpid (i=86384, j=0xb030ad9c, k=0) at ../src/unix/Common/Uexec.c:67
#3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86384, status=0xb030ad9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
#4  0x0000d66a in Process__Wait (p=0xb00018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
#5  0x00003719 in Main__FApply (cl=0x955618) at ../src/Main.m3:230
#6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00d60) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00d60) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#8  0x93889155 in _pthread_start ()
#9  0x93889012 in thread_start ()

Thread 6 (process 86311 thread 0x1903):
#0  0x9389c856 in __wait4 ()
#1  0x9389c847 in waitpid$UNIX2003 ()
#2  0x0004b222 in Uexec__waitpid (i=86385, j=0xb0288d9c, k=0) at ../src/unix/Common/Uexec.c:67
#3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86385, status=0xb0288d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
#4  0x0000d66a in Process__Wait (p=0xbd000c) at ../src/os/POSIX/ProcessPosixCommon.m3:275
#5  0x00003719 in Main__FApply (cl=0x9555e0) at ../src/Main.m3:230
#6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00b70) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00b70) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#8  0x93889155 in _pthread_start ()
#9  0x93889012 in thread_start ()

Thread 5 (process 86311 thread 0x1803):
#0  0x9389c856 in __wait4 ()
#1  0x9389c847 in waitpid$UNIX2003 ()
#2  0x0004b222 in Uexec__waitpid (i=86386, j=0xb0206d9c, k=0) at ../src/unix/Common/Uexec.c:67
#3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86386, status=0xb0206d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
#4  0x0000d66a in Process__Wait (p=0x9d0018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
#5  0x00003719 in Main__FApply (cl=0x9555a8) at ../src/Main.m3:230
#6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00ac0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00ac0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#8  0x93889155 in _pthread_start ()
#9  0x93889012 in thread_start ()

Thread 4 (process 86311 thread 0x1103):
#0  0x9385fb99 in pthread_mutex_lock ()
#1  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00c20) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#2  0x0004503c in ThreadPThread__LockMutex (m=0xb6000c) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#3  0x0000e060 in Rd__GetChar (rd=0xb6000c) at ../src/rw/Rd.m3:33
#4  0x000030b5 in Main__RApply (cl=0x955538) at ../src/Main.m3:177
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 3 (process 86311 thread 0x117):
#0  0x93859304 in pthread_getspecific ()
#1  0x0004a529 in ThreadPThread__GetActivation () at ../src/thread/PTHREAD/ThreadPThreadC.c:309
#2  0x00049f52 in RTHooks__PushEFrame (frame=0xb0102d20) at ../src/thread/PTHREAD/ThreadPThread.m3:1385
#3  0x0000e07b in Rd__GetChar (rd=0x99000c) at ../src/rw/Rd.m3:33
#4  0x000030b5 in Main__RApply (cl=0x955500) at ../src/Main.m3:177
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 2 (process 86311 thread 0x313):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=12, dataAlignment=4, thread=0xa00834) at ../src/runtime/common/RTAllocator.m3:365
#5  0x0002bf13 in RTAllocator__GetTracedObj (def=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:224
#6  0x0002b98a in RTHooks__AllocateTracedObj (defn=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:122
#7  0x00008eeb in FilePosix__New (fd=5, ds=1) at ../src/os/POSIX/FilePosix.m3:63
#8  0x0000a4eb in FS__OpenFileReadonly (pn=0x775b8) at ../src/os/POSIX/FSPosix.m3:182
#9  0x00014dfa in FileRd__Open (p=0x775b8) at ../src/rw/FileRd.m3:16
#10 0x00003046 in Main__RApply (cl=0x9554c8) at ../src/Main.m3:174
#11 0x00046ee2 in ThreadPThread__RunThread (me=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#12 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#13 0x93889155 in _pthread_start ()
#14 0x93889012 in thread_start ()

Thread 1 (process 86311 local thread 0x2e03):
#0  0x9385f44e in __semwait_signal ()
#1  0x9388a3e6 in _pthread_cond_wait ()
#2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
#3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299133562.375689) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
#4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
#5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
#6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
#7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
#8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
#9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
#10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16







From: jay.krell at cornell.edu
To: dabenavidesd at yahoo.es; rcolebur at scires.com; m3devel at elegosoft.com
Subject: RE: [M3devel] results of threadtest program on Windows7
Date: Thu, 3 Mar 2011 02:46:39 +0000








There is probably a bug in RTCollector.m3 or RTAllocator.m3.

 - Jay

Date: Thu, 3 Mar 2011 02:27:58 +0000
From: dabenavidesd at yahoo.es
Subject: Re: [M3devel] results of threadtest program on Windows7
To: rcolebur at scires.com; m3devel at elegosoft.com; jay.krell at cornell.edu

Hi all:
I would doubt but there could be some source of problem in smp on the Win32 platform, since there was a SPINE implementation on an intelligent NIC with 2 embedded MIPS CPUs, perhaps this was just a driver RT but it was for real time and in such a case there should be no problem besides that of the scheduling policy, but thinking how about linking MS Win2k R is a kind of crazy not to believe there was some synchronization with CPU board threads and that component threading at some point I believe.

Even more in embedded systems, there was a MPU implementation of it in 80186 a decade ago,  perhaps would be good to have a look of their Thread interface implementation it might be seem interesting if so.

But in any case there should be plenty of ways of implementing the threading tests incrementally of number of threads, besides you may
 want to check some uniprocessors with hyperThreading technology (sort of thread physical divisions inside the cpu), they are presented to OS as 2 smp processors, it could be interesting, I remember to test  time ago in this machines and anything weird happened, but quite time ago with ThreadPthread LINUXLIBC6 systems with normally distributed programs.
 
What about results in Win2k ?
Thanks in advance

--- El mi?, 2/3/11, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] results of threadtest program on Windows7
Para: rcolebur at scires.com, "m3devel" <m3devel at elegosoft.com>
Fecha: mi?rcoles, 2 de marzo, 2011 20:17




Even with the change I made PutCard to PutInt?

That's the only failure I've seen.

I'll try on a non-virtual dual-proc machine later.

 

Thanks,

 - Jay
 



From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7


 



Yes, it fails more often than it runs for me.
Regards,
Randy
 


From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7
 
I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Ah, it just doesn't check command-line arguments that carefully.
> 
> I think what you did is equivalent to "-tests STD".
> 
> Mika
> 
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the
 command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- ---------
 -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
>
 >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle
 down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints
 "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built
 Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
>
 >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm
 yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type:
 text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR
 FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file
 specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply:
 OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 +
 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>> 		 	   		  

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110303/60fab6ef/attachment.html>

From jay.krell at cornell.edu  Thu Mar  3 07:37:49 2011
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 3 Mar 2011 06:37:49 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W1943F7B289FE5FD33E5D1EE6C30@phx.gbl>
References: <COL101-W4726257303F22627175774E6C30@phx.gbl>,
	<974355.12644.qm@web29717.mail.ird.yahoo.com>,
	<COL101-W2637AB63DA6D9866A00D07E6C30@phx.gbl>,
	<COL101-W1943F7B289FE5FD33E5D1EE6C30@phx.gbl>
Message-ID: <COL101-W52252742B56CBFEAD0A0DFE6C30@phx.gbl>


Here is another failure also I386_DARWIN.


(gdb) break RTError__MsgS
Breakpoint 2 at 0x3b65f: file ../src/runtime/common/RTError.m3, line 30.
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /Users/jay/dev2/cm3/m3-libs/m3core/tests/thread/I386_DARWIN/threadtest 
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
..[Switching to process 86430 thread 0x1503]

Breakpoint 2, RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:30
30        StartError (msgA, msgB, msgC);
(gdb) bt
#0  RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:30
#1  0x0003bdc7 in RTException__Crash (a=0xb040ea64, raises=0 '\0', rte=0x7d100) at ../src/runtime/common/RTException.m3:79
#2  0x0003bb21 in RTException__DefaultBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:39
#3  0x0003ba7c in RTException__InvokeBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
#4  0x00043ca5 in RTException__Raise (act=0xb040ea64) at ../src/runtime/ex_frame/RTExFrame.m3:85
#5  0x0003bbb4 in RTException__DefaultBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:47
#6  0x0003ba7c in RTException__InvokeBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
#7  0x00043ca5 in RTException__Raise (act=0xb040ea64) at ../src/runtime/ex_frame/RTExFrame.m3:85
#8  0x0002b102 in RTHooks__ReportFault (module=0x70f80, info=13378) at ../src/runtime/common/RTHooks.m3:111
#9  0x000394c5 in _m3_fault (arg=13378) at ../src/runtime/common/RTCollector.m3:393
#10 0x0002fdd2 in RTCollector__Move (self=0xb4000c, cp=0xba0014) at ../src/runtime/common/RTCollector.m3:418
#11 0x0002e503 in RTHeapMap__Walk (x=0xba0014, pc=0x79928, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:202
#12 0x0002dc9c in RTHeapMap__DoWalkRef (t=0x6de54, a=0xba0014, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:62
#13 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e3f4, a=0xba000c, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:57
#14 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e508, a=0xba000c, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:57
#15 0x0002dc2e in RTHeapMap__WalkRef (h=0xba0008, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:47
#16 0x00032279 in RTCollector__CleanBetween (h=0xba0008, he=0xbb0000, clean=0 '\0') at ../src/runtime/common/RTCollector.m3:1091
#17 0x00032098 in RTCollector__CleanPage (page=0xba0000) at ../src/runtime/common/RTCollector.m3:1064
#18 0x00031798 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885
#19 0x00030e75 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720
#20 0x00030a97 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654
#21 0x0002cb85 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00e74) at ../src/runtime/common/RTAllocator.m3:367
#22 0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:296
#23 0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:143
#24 0x00003b5f in Main__AApply (cl=0x9556c0) at ../src/Main.m3:260
#25 0x00046ee2 in ThreadPThread__RunThread (me=0xa00e30) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#26 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00e30) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#27 0x93889155 in _pthread_start ()
#28 0x93889012 in thread_start ()
(gdb) threads apply all bt
Undefined command: "threads".  Try "help".
(gdb) thread apply all bt

Thread 13 (process 86430 thread 0x1903):
#0  0x9388a6f1 in semaphore_wait_signal ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00880) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#4  0x00003ed8 in Main__LApply (cl=0x9557d8) at ../src/Main.m3:290
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa010f0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa010f0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 12 (process 86430 thread 0x1803):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00880) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#4  0x00003ed8 in Main__LApply (cl=0x9557a0) at ../src/Main.m3:290
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01040) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01040) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 11 (process 86430 thread 0x1703):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00880) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#4  0x00003ed8 in Main__LApply (cl=0x955768) at ../src/Main.m3:290
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00f90) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00f90) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 10 (process 86430 thread 0x1603):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00f24) at ../src/runtime/common/RTAllocator.m3:365
#5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:296
#6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:143
#7  0x00003b5f in Main__AApply (cl=0x9556f8) at ../src/Main.m3:260
#8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00ee0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00ee0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#10 0x93889155 in _pthread_start ()
#11 0x93889012 in thread_start ()

Thread 9 (process 86430 thread 0x1503):
#0  RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:30
#1  0x0003bdc7 in RTException__Crash (a=0xb040ea64, raises=0 '\0', rte=0x7d100) at ../src/runtime/common/RTException.m3:79
#2  0x0003bb21 in RTException__DefaultBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:39
#3  0x0003ba7c in RTException__InvokeBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
#4  0x00043ca5 in RTException__Raise (act=0xb040ea64) at ../src/runtime/ex_frame/RTExFrame.m3:85
#5  0x0003bbb4 in RTException__DefaultBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:47
#6  0x0003ba7c in RTException__InvokeBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
#7  0x00043ca5 in RTException__Raise (act=0xb040ea64) at ../src/runtime/ex_frame/RTExFrame.m3:85
#8  0x0002b102 in RTHooks__ReportFault (module=0x70f80, info=13378) at ../src/runtime/common/RTHooks.m3:111
#9  0x000394c5 in _m3_fault (arg=13378) at ../src/runtime/common/RTCollector.m3:393
#10 0x0002fdd2 in RTCollector__Move (self=0xb4000c, cp=0xba0014) at ../src/runtime/common/RTCollector.m3:418
#11 0x0002e503 in RTHeapMap__Walk (x=0xba0014, pc=0x79928, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:202
#12 0x0002dc9c in RTHeapMap__DoWalkRef (t=0x6de54, a=0xba0014, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:62
#13 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e3f4, a=0xba000c, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:57
#14 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e508, a=0xba000c, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:57
#15 0x0002dc2e in RTHeapMap__WalkRef (h=0xba0008, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:47
#16 0x00032279 in RTCollector__CleanBetween (h=0xba0008, he=0xbb0000, clean=0 '\0') at ../src/runtime/common/RTCollector.m3:1091
#17 0x00032098 in RTCollector__CleanPage (page=0xba0000) at ../src/runtime/common/RTCollector.m3:1064
#18 0x00031798 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885
#19 0x00030e75 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720
#20 0x00030a97 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654
#21 0x0002cb85 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00e74) at ../src/runtime/common/RTAllocator.m3:367
#22 0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:296
#23 0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:143
#24 0x00003b5f in Main__AApply (cl=0x9556c0) at ../src/Main.m3:260
#25 0x00046ee2 in ThreadPThread__RunThread (me=0xa00e30) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#26 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00e30) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#27 0x93889155 in _pthread_start ()
#28 0x93889012 in thread_start ()

Thread 8 (process 86430 thread 0x1403):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00dc4) at ../src/runtime/common/RTAllocator.m3:365
#5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:296
#6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:143
#7  0x00003b5f in Main__AApply (cl=0x955688) at ../src/Main.m3:260
#8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00d80) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00d80) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#10 0x93889155 in _pthread_start ()
#11 0x93889012 in thread_start ()

Thread 7 (process 86430 thread 0x1303):
#0  0x9389c856 in __wait4 ()
#1  0x9389c847 in waitpid$UNIX2003 ()
#2  0x0004b222 in Uexec__waitpid (i=86436, j=0xb030ad9c, k=0) at ../src/unix/Common/Uexec.c:67
#3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86436, status=0xb030ad9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
#4  0x0000d66a in Process__Wait (p=0xb00018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
#5  0x00003719 in Main__FApply (cl=0x955618) at ../src/Main.m3:230
#6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00d20) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00d20) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#8  0x93889155 in _pthread_start ()
#9  0x93889012 in thread_start ()

Thread 6 (process 86430 thread 0x1203):
#0  0x9389c856 in __wait4 ()
#1  0x9389c847 in waitpid$UNIX2003 ()
#2  0x0004b222 in Uexec__waitpid (i=86437, j=0xb0288d9c, k=0) at ../src/unix/Common/Uexec.c:67
#3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86437, status=0xb0288d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
#4  0x0000d66a in Process__Wait (p=0xbd0018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
#5  0x00003719 in Main__FApply (cl=0x9555e0) at ../src/Main.m3:230
#6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00b30) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00b30) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#8  0x93889155 in _pthread_start ()
#9  0x93889012 in thread_start ()

Thread 5 (process 86430 thread 0x1103):
#0  0x9389c856 in __wait4 ()
#1  0x9389c847 in waitpid$UNIX2003 ()
#2  0x0004b222 in Uexec__waitpid (i=86435, j=0xb0206d9c, k=0) at ../src/unix/Common/Uexec.c:67
#3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86435, status=0xb0206d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
#4  0x0000d66a in Process__Wait (p=0xc2000c) at ../src/os/POSIX/ProcessPosixCommon.m3:275
#5  0x00003719 in Main__FApply (cl=0x9555a8) at ../src/Main.m3:230
#6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00a80) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00a80) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#8  0x93889155 in _pthread_start ()
#9  0x93889012 in thread_start ()

Thread 4 (process 86430 thread 0x1003):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=12, dataAlignment=4, thread=0xa00a14) at ../src/runtime/common/RTAllocator.m3:365
#5  0x0002bf13 in RTAllocator__GetTracedObj (def=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:224
#6  0x0002b98a in RTHooks__AllocateTracedObj (defn=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:122
#7  0x00008eeb in FilePosix__New (fd=5, ds=1) at ../src/os/POSIX/FilePosix.m3:63
#8  0x0000a4eb in FS__OpenFileReadonly (pn=0x775b8) at ../src/os/POSIX/FSPosix.m3:182
#9  0x00014dfa in FileRd__Open (p=0x775b8) at ../src/rw/FileRd.m3:16
#10 0x00003046 in Main__RApply (cl=0x955538) at ../src/Main.m3:174
#11 0x00046ee2 in ThreadPThread__RunThread (me=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#12 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#13 0x93889155 in _pthread_start ()
#14 0x93889012 in thread_start ()

Thread 3 (process 86430 thread 0x117):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x74220) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00044f3a in ThreadPThread__InitMutex (m=0x960010, root=0x96000c, Clean=0x44dac) at ../src/thread/PTHREAD/ThreadPThread.m3:101
#4  0x0004500b in ThreadPThread__LockMutex (m=0x96000c) at ../src/thread/PTHREAD/ThreadPThread.m3:117
#5  0x0000e060 in Rd__GetChar (rd=0x96000c) at ../src/rw/Rd.m3:33
#6  0x000030b5 in Main__RApply (cl=0x955500) at ../src/Main.m3:177
#7  0x00046ee2 in ThreadPThread__RunThread (me=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#8  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#9  0x93889155 in _pthread_start ()
#10 0x93889012 in thread_start ()

Thread 2 (process 86430 thread 0x313):
#0  0x938582a2 in semaphore_wait_trap ()
#1  0x9385fd92 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x00036509 in RTHeapRep__RegisterFinalCleanup (r=0x9b1050, p=0x44dac) at ../src/runtime/common/RTCollector.m3:2148
#5  0x00044fa2 in ThreadPThread__InitMutex (m=0x9b1054, root=0x9b1050, Clean=0x44dac) at ../src/thread/PTHREAD/ThreadPThread.m3:106
#6  0x0004500b in ThreadPThread__LockMutex (m=0x9b1050) at ../src/thread/PTHREAD/ThreadPThread.m3:117
#7  0x0000e060 in Rd__GetChar (rd=0x9b1050) at ../src/rw/Rd.m3:33
#8  0x000030b5 in Main__RApply (cl=0x9554c8) at ../src/Main.m3:177
#9  0x00046ee2 in ThreadPThread__RunThread (me=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#10 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#11 0x93889155 in _pthread_start ()
#12 0x93889012 in thread_start ()

Thread 1 (process 86430 local thread 0x4507):
#0  0x9385f44e in __semwait_signal ()
#1  0x9388a3e6 in _pthread_cond_wait ()
#2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
#3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299134070.4957981) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
#4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
#5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
#6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
#7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
#8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
#9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
#10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16

 - Jay


From: jay.krell at cornell.edu
To: dabenavidesd at yahoo.es; rcolebur at scires.com; m3devel at elegosoft.com
Subject: RE: [M3devel] results of threadtest program on Windows7
Date: Thu, 3 Mar 2011 06:32:50 +0000








Solaris doesn't hang now. I didn't change anything. And it succeeds.
Here are some stacks for a failure on I386_DARWIN.
Notice that it *should* abort right after the EBUSY print, but it still run a while.
Possibly too much information is lost.


(gdb) run
Starting program: /Users/jay/dev2/cm3/m3-libs/m3core/tests/thread/I386_DARWIN/threadtest 
Reading symbols for shared libraries ++. done
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
..........laziest thread is 1/0/0 (tests: read 0/0/0 fork 1/1/1 alloc 0/0/0 lock 0/0/0)
.........pthread_mutex_destroy:EBUSY (0)
.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:
***    An array subscript was out of range.
***    file "../src/runtime/common/RTCollector.m3", line 418
***


Program received signal SIGABRT, Aborted.
0x9385f44e in __semwait_signal ()
(gdb) bt
#0  0x9385f44e in __semwait_signal ()
#1  0x9388a3e6 in _pthread_cond_wait ()
#2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
#3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299133562.375689) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
#4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
#5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
#6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
#7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
#8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
#9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
#10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16


(gdb) thread apply all bt

Thread 13 (process 86311 thread 0x2a03):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#4  0x00003ed8 in Main__LApply (cl=0x9557d8) at ../src/Main.m3:290
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01130) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01130) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 12 (process 86311 thread 0x1f03):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#4  0x00003ed8 in Main__LApply (cl=0x9557a0) at ../src/Main.m3:290
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01080) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01080) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 11 (process 86311 thread 0x1e03):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#4  0x00003ed8 in Main__LApply (cl=0x955768) at ../src/Main.m3:290
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 10 (process 86311 thread 0x1d03):
#0  0x93934136 in __semwait_signal_nocancel ()
#1  0x93933d1b in nanosleep$NOCANCEL$UNIX2003 ()
#2  0x9392d013 in usleep$NOCANCEL$UNIX2003 ()
#3  0x93944685 in abort ()
#4  0x0004b5e6 in Cstdlib__abort () at ../src/C/Common/CstdlibC.c:21
#5  0x000434dd in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20
#6  0x0003d51f in RTProcess__Crash (msg=0x0) at ../src/runtime/common/RTProcess.m3:65
#7  0x0003b9d3 in RTError__EndError (crash=1 '\001') at ../src/runtime/common/RTError.m3:118
#8  0x0003b6e6 in RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:40
#9  0x0003bdc7 in RTException__Crash (a=0xb0490a64, raises=0 '\0', rte=0x7d100) at ../src/runtime/common/RTException.m3:79
#10 0x0003bb21 in RTException__DefaultBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:39
#11 0x0003ba7c in RTException__InvokeBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
#12 0x00043ca5 in RTException__Raise (act=0xb0490a64) at ../src/runtime/ex_frame/RTExFrame.m3:85
#13 0x0003bbb4 in RTException__DefaultBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:47
#14 0x0003ba7c in RTException__InvokeBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
#15 0x00043ca5 in RTException__Raise (act=0xb0490a64) at ../src/runtime/ex_frame/RTExFrame.m3:85
#16 0x0002b102 in RTHooks__ReportFault (module=0x70f80, info=13378) at ../src/runtime/common/RTHooks.m3:111
#17 0x000394c5 in _m3_fault (arg=13378) at ../src/runtime/common/RTCollector.m3:393
#18 0x0002fdd2 in RTCollector__Move (self=0xb3000c, cp=0x9a0014) at ../src/runtime/common/RTCollector.m3:418
#19 0x0002e503 in RTHeapMap__Walk (x=0x9a0014, pc=0x79928, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:202
#20 0x0002dc9c in RTHeapMap__DoWalkRef (t=0x6de54, a=0x9a0014, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:62
#21 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e3f4, a=0x9a000c, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:57
#22 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e508, a=0x9a000c, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:57
#23 0x0002dc2e in RTHeapMap__WalkRef (h=0x9a0008, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:47
#24 0x00032279 in RTCollector__CleanBetween (h=0x9a0008, he=0x9b0000, clean=0 '\0') at ../src/runtime/common/RTCollector.m3:1091
#25 0x00032098 in RTCollector__CleanPage (page=0x9a0000) at ../src/runtime/common/RTCollector.m3:1064
#26 0x00031798 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885
#27 0x00030e75 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720
#28 0x00030a97 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654
#29 0x0002cb85 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00f64) at ../src/runtime/common/RTAllocator.m3:367
#30 0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:296
#31 0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:143
#32 0x00003b5f in Main__AApply (cl=0x9556f8) at ../src/Main.m3:260
#33 0x00046ee2 in ThreadPThread__RunThread (me=0xa00f20) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#34 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00f20) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#35 0x93889155 in _pthread_start ()
#36 0x93889012 in thread_start ()

Thread 9 (process 86311 thread 0x1c03):
#0  0x938582a2 in semaphore_wait_trap ()
#1  0x9385fd92 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00eb4) at ../src/runtime/common/RTAllocator.m3:365
#5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:296
#6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:143
#7  0x00003b5f in Main__AApply (cl=0x9556c0) at ../src/Main.m3:260
#8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00e70) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00e70) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#10 0x93889155 in _pthread_start ()
#11 0x93889012 in thread_start ()

Thread 8 (process 86311 thread 0x1b03):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00e04) at ../src/runtime/common/RTAllocator.m3:365
#5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:296
#6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:143
#7  0x00003b5f in Main__AApply (cl=0x955688) at ../src/Main.m3:260
#8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00dc0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00dc0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#10 0x93889155 in _pthread_start ()
#11 0x93889012 in thread_start ()

Thread 7 (process 86311 thread 0x1a03):
#0  0x9389c856 in __wait4 ()
#1  0x9389c847 in waitpid$UNIX2003 ()
#2  0x0004b222 in Uexec__waitpid (i=86384, j=0xb030ad9c, k=0) at ../src/unix/Common/Uexec.c:67
#3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86384, status=0xb030ad9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
#4  0x0000d66a in Process__Wait (p=0xb00018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
#5  0x00003719 in Main__FApply (cl=0x955618) at ../src/Main.m3:230
#6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00d60) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00d60) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#8  0x93889155 in _pthread_start ()
#9  0x93889012 in thread_start ()

Thread 6 (process 86311 thread 0x1903):
#0  0x9389c856 in __wait4 ()
#1  0x9389c847 in waitpid$UNIX2003 ()
#2  0x0004b222 in Uexec__waitpid (i=86385, j=0xb0288d9c, k=0) at ../src/unix/Common/Uexec.c:67
#3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86385, status=0xb0288d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
#4  0x0000d66a in Process__Wait (p=0xbd000c) at ../src/os/POSIX/ProcessPosixCommon.m3:275
#5  0x00003719 in Main__FApply (cl=0x9555e0) at ../src/Main.m3:230
#6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00b70) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00b70) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#8  0x93889155 in _pthread_start ()
#9  0x93889012 in thread_start ()

Thread 5 (process 86311 thread 0x1803):
#0  0x9389c856 in __wait4 ()
#1  0x9389c847 in waitpid$UNIX2003 ()
#2  0x0004b222 in Uexec__waitpid (i=86386, j=0xb0206d9c, k=0) at ../src/unix/Common/Uexec.c:67
#3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86386, status=0xb0206d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
#4  0x0000d66a in Process__Wait (p=0x9d0018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
#5  0x00003719 in Main__FApply (cl=0x9555a8) at ../src/Main.m3:230
#6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00ac0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00ac0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#8  0x93889155 in _pthread_start ()
#9  0x93889012 in thread_start ()

Thread 4 (process 86311 thread 0x1103):
#0  0x9385fb99 in pthread_mutex_lock ()
#1  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00c20) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#2  0x0004503c in ThreadPThread__LockMutex (m=0xb6000c) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#3  0x0000e060 in Rd__GetChar (rd=0xb6000c) at ../src/rw/Rd.m3:33
#4  0x000030b5 in Main__RApply (cl=0x955538) at ../src/Main.m3:177
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 3 (process 86311 thread 0x117):
#0  0x93859304 in pthread_getspecific ()
#1  0x0004a529 in ThreadPThread__GetActivation () at ../src/thread/PTHREAD/ThreadPThreadC.c:309
#2  0x00049f52 in RTHooks__PushEFrame (frame=0xb0102d20) at ../src/thread/PTHREAD/ThreadPThread.m3:1385
#3  0x0000e07b in Rd__GetChar (rd=0x99000c) at ../src/rw/Rd.m3:33
#4  0x000030b5 in Main__RApply (cl=0x955500) at ../src/Main.m3:177
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 2 (process 86311 thread 0x313):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=12, dataAlignment=4, thread=0xa00834) at ../src/runtime/common/RTAllocator.m3:365
#5  0x0002bf13 in RTAllocator__GetTracedObj (def=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:224
#6  0x0002b98a in RTHooks__AllocateTracedObj (defn=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:122
#7  0x00008eeb in FilePosix__New (fd=5, ds=1) at ../src/os/POSIX/FilePosix.m3:63
#8  0x0000a4eb in FS__OpenFileReadonly (pn=0x775b8) at ../src/os/POSIX/FSPosix.m3:182
#9  0x00014dfa in FileRd__Open (p=0x775b8) at ../src/rw/FileRd.m3:16
#10 0x00003046 in Main__RApply (cl=0x9554c8) at ../src/Main.m3:174
#11 0x00046ee2 in ThreadPThread__RunThread (me=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#12 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#13 0x93889155 in _pthread_start ()
#14 0x93889012 in thread_start ()

Thread 1 (process 86311 local thread 0x2e03):
#0  0x9385f44e in __semwait_signal ()
#1  0x9388a3e6 in _pthread_cond_wait ()
#2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
#3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299133562.375689) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
#4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
#5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
#6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
#7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
#8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
#9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
#10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16







From: jay.krell at cornell.edu
To: dabenavidesd at yahoo.es; rcolebur at scires.com; m3devel at elegosoft.com
Subject: RE: [M3devel] results of threadtest program on Windows7
Date: Thu, 3 Mar 2011 02:46:39 +0000








There is probably a bug in RTCollector.m3 or RTAllocator.m3.

 - Jay

Date: Thu, 3 Mar 2011 02:27:58 +0000
From: dabenavidesd at yahoo.es
Subject: Re: [M3devel] results of threadtest program on Windows7
To: rcolebur at scires.com; m3devel at elegosoft.com; jay.krell at cornell.edu

Hi all:
I would doubt but there could be some source of problem in smp on the Win32 platform, since there was a SPINE implementation on an intelligent NIC with 2 embedded MIPS CPUs, perhaps this was just a driver RT but it was for real time and in such a case there should be no problem besides that of the scheduling policy, but thinking how about linking MS Win2k R is a kind of crazy not to believe there was some synchronization with CPU board threads and that component threading at some point I believe.

Even more in embedded systems, there was a MPU implementation of it in 80186 a decade ago,  perhaps would be good to have a look of their Thread interface implementation it might be seem interesting if so.

But in any case there should be plenty of ways of implementing the threading tests incrementally of number of threads, besides you may
 want to check some uniprocessors with hyperThreading technology (sort of thread physical divisions inside the cpu), they are presented to OS as 2 smp processors, it could be interesting, I remember to test  time ago in this machines and anything weird happened, but quite time ago with ThreadPthread LINUXLIBC6 systems with normally distributed programs.
 
What about results in Win2k ?
Thanks in advance

--- El mi?, 2/3/11, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] results of threadtest program on Windows7
Para: rcolebur at scires.com, "m3devel" <m3devel at elegosoft.com>
Fecha: mi?rcoles, 2 de marzo, 2011 20:17




Even with the change I made PutCard to PutInt?

That's the only failure I've seen.

I'll try on a non-virtual dual-proc machine later.

 

Thanks,

 - Jay
 



From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7


 



Yes, it fails more often than it runs for me.
Regards,
Randy
 


From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7
 
I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Ah, it just doesn't check command-line arguments that carefully.
> 
> I think what you did is equivalent to "-tests STD".
> 
> Mika
> 
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the
 command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- ---------
 -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
>
 >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle
 down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints
 "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built
 Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
>
 >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm
 yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type:
 text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR
 FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file
 specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply:
 OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 +
 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>> 		 	   		  

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110303/e4e568c3/attachment.html>

From hosking at cs.purdue.edu  Thu Mar  3 16:39:07 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 3 Mar 2011 10:39:07 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>
	<COL101-W4726257303F22627175774E6C30@phx.gbl>
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>
Message-ID: <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>

Both of these errors indicate major breakdown in the garbage collector.
It could be that the damage was done much earlier than the crash.
To check for earlier damage please run with @M3paranoidgc.
Also, you could try running with @M3nogc, or @M3noincremental, or @M3nogenerational, to see if any of them trigger the errors.


On Mar 2, 2011, at 8:36 PM, Coleburn, Randy wrote:

> Jay:
>  
> Ok, I just updated from HEAD and got your latest change to thread test program.
>  
> Here are two invocations, back to back, each failing in different ways. 
>  
> The second one repeats the last error message ad infinitum until you press CNTRL-C to abort.  But note, several different errors reported earlier.
>  
> Regards,
> Randy
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cm3
> --- building in NT386 ---
>  
> ignoring ..\src\m3overrides
>  
> new source -> compiling Main.m3
> new "Main.mo" -> linking threadtest.exe
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cd NT386
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> 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
>  
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed..
> ***    file "..\src\runtime\common\RTCollector.m3", line 1086
> ***
>  
> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0xddfaf0  0x123dffb  CleanBetween + 0x47 in ..\src\runtime\common\RTCollector.m3
> 0xddfb34  0x1241870  CheckLoadTracedRef + 0xc5 in ..\src\runtime\common\RTCollector.m3
> 0xddfb74  0x121683c  Init + 0x95 in ..\src\rw\FileRd.m3
> 0xddfba0  0x121679d  Open + 0x4d in ..\src\rw\FileRd.m3
> 0xddfcd8  0x1211288  RApply + 0x78 in ..\src\Main.m3
> 0xddfd14  0x123976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
> 0xddfd20  0x76d53677  <???>
> 0xddfd60  0x773c9f02  <???>
> .........  .........  ... more frames ...
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> 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
> .
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
> ***    pc = 0x12ec5ad = Move + 0x50 in ..\src\runtime\common\RTCollector.m3
> ***
>  
>  
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
>  
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Wednesday, March 02, 2011 8:18 PM
> To: Coleburn, Randy; m3devel
> Subject: RE: [M3devel] results of threadtest program on Windows7
>  
> Even with the change I made PutCard to PutInt?
> That's the only failure I've seen.
> I'll try on a non-virtual dual-proc machine later.
>  
> Thanks,
>  - Jay
>  
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Wed, 2 Mar 2011 19:42:47 -0500
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Yes, it fails more often than it runs for me.
> Regards,
> Randy
>  
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Tuesday, March 01, 2011 5:59 AM
> To: Mika Nystrom; Coleburn, Randy
> Cc: m3devel
> Subject: RE: [M3devel] results of threadtest program on Windows7
>  
> I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
> I've run it just a few times now. One single and dual processor virtual machines.
> Randy, has it failed many times for you?
> 
>  - Jay
> 
> > To: rcolebur at SCIRES.COM
> > Date: Sun, 27 Feb 2011 15:11:25 -0800
> > From: mika at async.caltech.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] results of threadtest program on Windows7
> > 
> > Ah, it just doesn't check command-line arguments that carefully.
> > 
> > I think what you did is equivalent to "-tests STD".
> > 
> > Mika
> > 
> > "Coleburn, Randy" writes:
> > >Mika:
> > >
> > >No change with "-tests POSIX".
> > >
> > >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> > >ptions are, and I typed "threadtest -help" rather than reading the code.
> > >
> > >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> > >d it again and it ran to completion. Something seems non-deterministic her=
> > >e. See below.
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >.
> > >
> > >***
> > >*** runtime error:
> > >*** Attempt to reference an illegal memory location.
> > >*** pc =3D 0x77762262
> > >***
> > >
> > >Stack trace:
> > > FP PC Procedure
> > >--------- --------- -------------------------------
> > > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> > >3
> > > 0xcdf9c0 0x77762262 <???>
> > > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> > >3
> > > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> > >.m3
> > > 0xcdfb80 0x76543677 <???>
> > > 0xcdfbc0 0x77779f02 <???>
> > >......... ......... ... more frames ...
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >All tests complete. Congratulations.
> > >
> > >Regards,
> > >Randy Coleburn
> > >
> > >-----Original Message-----
> > >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> > >Sent: Sunday, February 27, 2011 3:30 PM
> > >To: Coleburn, Randy
> > >Cc: m3devel at elegosoft.com
> > >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> > >
> > >Hi Randy,
> > >
> > >You can try it with -tests POSIX as well.
> > >
> > >I find on user threads it runs very slowly (but it does run) because of how=
> > > unfair
> > >the thread scheduler is.
> > >
> > >Next step might be to whittle down the tests and see if you can get a failu=
> > >re with
> > >a single test running and -n 2. That would likely be the simplest scenario=
> > > to
> > >start further debugging from.
> > >
> > > Mika
> > >
> > >"Coleburn, Randy" writes:
> > >>Mika et al:
> > >>
> > >>Thought I would try something else.
> > >>
> > >>I took the sources of your thread test program to an older XP machine that=
> > > =3D
> > >>has CM3 circa August 2008. This is the machine and implementation I used =
> > >w=3D
> > >>hen building a major project I did a couple years back.
> > >>
> > >>The thread test program does indeed build on this old system, but when I r=
> > >u=3D
> > >>n it, I get different results than with the latest HEAD branch code. =3D20
> > >>
> > >>After it prints "running...printing oldest/median age/newest", on the next=
> > > =3D
> > >>line I get two periods ".." and now the program seems hung. I'll let it "=
> > >r=3D
> > >>un" for a few more minutes to see if anything else happens before killing =
> > >i=3D
> > >>t.
> > >>
> > >>At least we don't get the subscript and assertion failures on this older C=
> > >M=3D
> > >>3 platform.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>
> > >>-----Original Message-----
> > >>From: Coleburn, Randy=3D20
> > >>Sent: Sunday, February 27, 2011 2:09 PM
> > >>To: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7
> > >>
> > >>Mika:
> > >>
> > >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> > >>
> > >>Here is what happens now when I run your threadtest program on Windows 7.
> > >>
> > >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> > >r=3D
> > >>k
> > >>Writing file...done
> > >>Creating read threads...done
> > >>Creating nxread threads...done
> > >>Creating tryexcept threads...done
> > >>Creating forktoomuch threads...done
> > >>Creating alloc threads...done
> > >>Creating creat threads...done
> > >>Creating lock threads...done
> > >>running...printing oldest/median age/newest
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** An array subscript was out of range.
> > >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> > >>***
> > >>
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** <*ASSERT*> failed.
> > >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> > >>***
> > >>
> > >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> > >>
> > >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> > >.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>-----Original Message-----
> > >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> > >>Sent: Saturday, February 26, 2011 12:55 PM
> > >>To: Coleburn, Randy
> > >>Cc: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> > >>
> > >>Hi Randy,
> > >>
> > >>Hm yes it looks like my Windows programming skills leave something
> > >>to be desired.
> > >>
> > >>You can run the thread tester while skipping a test as follows
> > >>
> > >> threadtest -tests ALL,-fork
> > >>
> > >>(for instance)
> > >>
> > >>if you just run=3D20
> > >>
> > >> threadtest -sadfassdaf
> > >>
> > >>it'll print the tests that are available.
> > >>
> > >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> > >>Can you give me a very brief description of what you did to install Modula=
> > >-=3D
> > >>3
> > >>on this system?
> > >>
> > >> Mika
> > >>
> > >>"Coleburn, Randy" writes:
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>
> > >>>Mika:
> > >>>
> > >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> > >>>
> > >>>So, I ran your threadtest program.
> > >>>
> > >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> > >e=3D
> > >>p=3D3D
> > >>>eating "ERROR FApply" messages.
> > >>>
> > >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > >>>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
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>***
> > >>>*** runtime error:
> > >>>*** An enumeration or subrange value was out of range.
> > >>>*** file "..\src\Main.m3", line 340
> > >>>***
> > >>>
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>Stack trace:
> > >>> FP PC Procedure
> > >>>--------- --------- -------------------------------
> > >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> > >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> > >>>
> > >>>Regards,
> > >>>Randy Coleburn
> > >>>
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/html; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110303/63ad1ce4/attachment.html>

From hosking at cs.purdue.edu  Thu Mar  3 16:40:35 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 3 Mar 2011 10:40:35 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W2637AB63DA6D9866A00D07E6C30@phx.gbl>
References: <COL101-W4726257303F22627175774E6C30@phx.gbl>,
	<974355.12644.qm@web29717.mail.ird.yahoo.com>
	<COL101-W2637AB63DA6D9866A00D07E6C30@phx.gbl>
Message-ID: <12DDA3F3-61D8-47B6-AF76-9362068A061A@cs.purdue.edu>

The bug is not necessarily there.  If the collector is not kept properly informed of the mutator's actions or the pointers it holds in its stacks then the world will break.  What has changed recently that might affect the collector and allocator?

On Mar 2, 2011, at 9:46 PM, Jay K wrote:

> There is probably a bug in RTCollector.m3 or RTAllocator.m3.
> 
>  - Jay
> 
> Date: Thu, 3 Mar 2011 02:27:58 +0000
> From: dabenavidesd at yahoo.es
> Subject: Re: [M3devel] results of threadtest program on Windows7
> To: rcolebur at scires.com; m3devel at elegosoft.com; jay.krell at cornell.edu
> 
> Hi all:
> I would doubt but there could be some source of problem in smp on the Win32 platform, since there was a SPINE implementation on an intelligent NIC with 2 embedded MIPS CPUs, perhaps this was just a driver RT but it was for real time and in such a case there should be no problem besides that of the scheduling policy, but thinking how about linking MS Win2k R is a kind of crazy not to believe there was some synchronization with CPU board threads and that component threading at some point I believe.
> 
> Even more in embedded systems, there was a MPU implementation of it in 80186 a decade ago,  perhaps would be good to have a look of their Thread interface implementation it might be seem interesting if so.
> 
> But in any case there should be plenty of ways of implementing the threading tests incrementally of number of threads, besides you may want to check some uniprocessors with hyperThreading technology (sort of thread physical divisions inside the cpu), they are presented to OS as 2 smp processors, it could be interesting, I remember to test  time ago in this machines and anything weird happened, but quite time ago with ThreadPthread LINUXLIBC6 systems with normally distributed programs.
>  
> What about results in Win2k ?
> Thanks in advance
> 
> --- El mi?, 2/3/11, Jay K <jay.krell at cornell.edu> escribi?:
> 
> De: Jay K <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] results of threadtest program on Windows7
> Para: rcolebur at scires.com, "m3devel" <m3devel at elegosoft.com>
> Fecha: mi?rcoles, 2 de marzo, 2011 20:17
> 
> Even with the change I made PutCard to PutInt?
> That's the only failure I've seen.
> I'll try on a non-virtual dual-proc machine later.
>  
> Thanks,
>  - Jay
>  
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Wed, 2 Mar 2011 19:42:47 -0500
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Yes, it fails more often than it runs for me.
> Regards,
> Randy
>  
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Tuesday, March 01, 2011 5:59 AM
> To: Mika Nystrom; Coleburn, Randy
> Cc: m3devel
> Subject: RE: [M3devel] results of threadtest program on Windows7
>  
> I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
> I've run it just a few times now. One single and dual processor virtual machines.
> Randy, has it failed many times for you?
> 
>  - Jay
> 
> > To: rcolebur at SCIRES.COM
> > Date: Sun, 27 Feb 2011 15:11:25 -0800
> > From: mika at async.caltech.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] results of threadtest program on Windows7
> > 
> > Ah, it just doesn't check command-line arguments that carefully.
> > 
> > I think what you did is equivalent to "-tests STD".
> > 
> > Mika
> > 
> > "Coleburn, Randy" writes:
> > >Mika:
> > >
> > >No change with "-tests POSIX".
> > >
> > >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> > >ptions are, and I typed "threadtest -help" rather than reading the code.
> > >
> > >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> > >d it again and it ran to completion. Something seems non-deterministic her=
> > >e. See below.
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >.
> > >
> > >***
> > >*** runtime error:
> > >*** Attempt to reference an illegal memory location.
> > >*** pc =3D 0x77762262
> > >***
> > >
> > >Stack trace:
> > > FP PC Procedure
> > >--------- --------- -------------------------------
> > > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> > >3
> > > 0xcdf9c0 0x77762262 <???>
> > > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> > >3
> > > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> > >.m3
> > > 0xcdfb80 0x76543677 <???>
> > > 0xcdfbc0 0x77779f02 <???>
> > >......... ......... ... more frames ...
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >All tests complete. Congratulations.
> > >
> > >Regards,
> > >Randy Coleburn
> > >
> > >-----Original Message-----
> > >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> > >Sent: Sunday, February 27, 2011 3:30 PM
> > >To: Coleburn, Randy
> > >Cc: m3devel at elegosoft.com
> > >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> > >
> > >Hi Randy,
> > >
> > >You can try it with -tests POSIX as well.
> > >
> > >I find on user threads it runs very slowly (but it does run) because of how=
> > > unfair
> > >the thread scheduler is.
> > >
> > >Next step might be to whittle down the tests and see if you can get a failu=
> > >re with
> > >a single test running and -n 2. That would likely be the simplest scenario=
> > > to
> > >start further debugging from.
> > >
> > > Mika
> > >
> > >"Coleburn, Randy" writes:
> > >>Mika et al:
> > >>
> > >>Thought I would try something else.
> > >>
> > >>I took the sources of your thread test program to an older XP machine that=
> > > =3D
> > >>has CM3 circa August 2008. This is the machine and implementation I used =
> > >w=3D
> > >>hen building a major project I did a couple years back.
> > >>
> > >>The thread test program does indeed build on this old system, but when I r=
> > >u=3D
> > >>n it, I get different results than with the latest HEAD branch code. =3D20
> > >>
> > >>After it prints "running...printing oldest/median age/newest", on the next=
> > > =3D
> > >>line I get two periods ".." and now the program seems hung. I'll let it "=
> > >r=3D
> > >>un" for a few more minutes to see if anything else happens before killing =
> > >i=3D
> > >>t.
> > >>
> > >>At least we don't get the subscript and assertion failures on this older C=
> > >M=3D
> > >>3 platform.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>
> > >>-----Original Message-----
> > >>From: Coleburn, Randy=3D20
> > >>Sent: Sunday, February 27, 2011 2:09 PM
> > >>To: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7
> > >>
> > >>Mika:
> > >>
> > >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> > >>
> > >>Here is what happens now when I run your threadtest program on Windows 7.
> > >>
> > >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> > >r=3D
> > >>k
> > >>Writing file...done
> > >>Creating read threads...done
> > >>Creating nxread threads...done
> > >>Creating tryexcept threads...done
> > >>Creating forktoomuch threads...done
> > >>Creating alloc threads...done
> > >>Creating creat threads...done
> > >>Creating lock threads...done
> > >>running...printing oldest/median age/newest
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** An array subscript was out of range.
> > >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> > >>***
> > >>
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** <*ASSERT*> failed.
> > >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> > >>***
> > >>
> > >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> > >>
> > >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> > >.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>-----Original Message-----
> > >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> > >>Sent: Saturday, February 26, 2011 12:55 PM
> > >>To: Coleburn, Randy
> > >>Cc: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> > >>
> > >>Hi Randy,
> > >>
> > >>Hm yes it looks like my Windows programming skills leave something
> > >>to be desired.
> > >>
> > >>You can run the thread tester while skipping a test as follows
> > >>
> > >> threadtest -tests ALL,-fork
> > >>
> > >>(for instance)
> > >>
> > >>if you just run=3D20
> > >>
> > >> threadtest -sadfassdaf
> > >>
> > >>it'll print the tests that are available.
> > >>
> > >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> > >>Can you give me a very brief description of what you did to install Modula=
> > >-=3D
> > >>3
> > >>on this system?
> > >>
> > >> Mika
> > >>
> > >>"Coleburn, Randy" writes:
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>
> > >>>Mika:
> > >>>
> > >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> > >>>
> > >>>So, I ran your threadtest program.
> > >>>
> > >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> > >e=3D
> > >>p=3D3D
> > >>>eating "ERROR FApply" messages.
> > >>>
> > >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > >>>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
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>***
> > >>>*** runtime error:
> > >>>*** An enumeration or subrange value was out of range.
> > >>>*** file "..\src\Main.m3", line 340
> > >>>***
> > >>>
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>Stack trace:
> > >>> FP PC Procedure
> > >>>--------- --------- -------------------------------
> > >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> > >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> > >>>
> > >>>Regards,
> > >>>Randy Coleburn
> > >>>
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/html; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110303/fbecdef7/attachment.html>

From hosking at cs.purdue.edu  Thu Mar  3 16:41:48 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 3 Mar 2011 10:41:48 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W52252742B56CBFEAD0A0DFE6C30@phx.gbl>
References: <COL101-W4726257303F22627175774E6C30@phx.gbl>,
	<974355.12644.qm@web29717.mail.ird.yahoo.com>,
	<COL101-W2637AB63DA6D9866A00D07E6C30@phx.gbl>,
	<COL101-W1943F7B289FE5FD33E5D1EE6C30@phx.gbl>
	<COL101-W52252742B56CBFEAD0A0DFE6C30@phx.gbl>
Message-ID: <5572AFA1-4813-4556-B900-B53C1B3F4A00@cs.purdue.edu>

Again, the problem is not necessarily in the collector/allocator.  There has been a lot of churn lately in the threads implementations which could result in confusing the memory manager.


On Mar 3, 2011, at 1:37 AM, Jay K wrote:

> Here is another failure also I386_DARWIN.
> 
> 
> (gdb) break RTError__MsgS
> Breakpoint 2 at 0x3b65f: file ../src/runtime/common/RTError.m3, line 30.
> (gdb) run
> The program being debugged has been started already.
> Start it from the beginning? (y or n) y
> Starting program: /Users/jay/dev2/cm3/m3-libs/m3core/tests/thread/I386_DARWIN/threadtest 
> 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
> ..[Switching to process 86430 thread 0x1503]
> 
> Breakpoint 2, RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:30
> 30        StartError (msgA, msgB, msgC);
> (gdb) bt
> #0  RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:30
> #1  0x0003bdc7 in RTException__Crash (a=0xb040ea64, raises=0 '\0', rte=0x7d100) at ../src/runtime/common/RTException.m3:79
> #2  0x0003bb21 in RTException__DefaultBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:39
> #3  0x0003ba7c in RTException__InvokeBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
> #4  0x00043ca5 in RTException__Raise (act=0xb040ea64) at ../src/runtime/ex_frame/RTExFrame.m3:85
> #5  0x0003bbb4 in RTException__DefaultBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:47
> #6  0x0003ba7c in RTException__InvokeBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
> #7  0x00043ca5 in RTException__Raise (act=0xb040ea64) at ../src/runtime/ex_frame/RTExFrame.m3:85
> #8  0x0002b102 in RTHooks__ReportFault (module=0x70f80, info=13378) at ../src/runtime/common/RTHooks.m3:111
> #9  0x000394c5 in _m3_fault (arg=13378) at ../src/runtime/common/RTCollector.m3:393
> #10 0x0002fdd2 in RTCollector__Move (self=0xb4000c, cp=0xba0014) at ../src/runtime/common/RTCollector.m3:418
> #11 0x0002e503 in RTHeapMap__Walk (x=0xba0014, pc=0x79928, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:202
> #12 0x0002dc9c in RTHeapMap__DoWalkRef (t=0x6de54, a=0xba0014, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:62
> #13 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e3f4, a=0xba000c, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:57
> #14 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e508, a=0xba000c, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:57
> #15 0x0002dc2e in RTHeapMap__WalkRef (h=0xba0008, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:47
> #16 0x00032279 in RTCollector__CleanBetween (h=0xba0008, he=0xbb0000, clean=0 '\0') at ../src/runtime/common/RTCollector.m3:1091
> #17 0x00032098 in RTCollector__CleanPage (page=0xba0000) at ../src/runtime/common/RTCollector.m3:1064
> #18 0x00031798 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885
> #19 0x00030e75 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720
> #20 0x00030a97 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654
> #21 0x0002cb85 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00e74) at ../src/runtime/common/RTAllocator.m3:367
> #22 0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:296
> #23 0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:143
> #24 0x00003b5f in Main__AApply (cl=0x9556c0) at ../src/Main.m3:260
> #25 0x00046ee2 in ThreadPThread__RunThread (me=0xa00e30) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #26 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00e30) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #27 0x93889155 in _pthread_start ()
> #28 0x93889012 in thread_start ()
> (gdb) threads apply all bt
> Undefined command: "threads".  Try "help".
> (gdb) thread apply all bt
> 
> Thread 13 (process 86430 thread 0x1903):
> #0  0x9388a6f1 in semaphore_wait_signal ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00880) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #4  0x00003ed8 in Main__LApply (cl=0x9557d8) at ../src/Main.m3:290
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa010f0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa010f0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 12 (process 86430 thread 0x1803):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00880) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #4  0x00003ed8 in Main__LApply (cl=0x9557a0) at ../src/Main.m3:290
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01040) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01040) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 11 (process 86430 thread 0x1703):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00880) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #4  0x00003ed8 in Main__LApply (cl=0x955768) at ../src/Main.m3:290
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00f90) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00f90) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 10 (process 86430 thread 0x1603):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00f24) at ../src/runtime/common/RTAllocator.m3:365
> #5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:296
> #6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:143
> #7  0x00003b5f in Main__AApply (cl=0x9556f8) at ../src/Main.m3:260
> #8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00ee0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00ee0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #10 0x93889155 in _pthread_start ()
> #11 0x93889012 in thread_start ()
> 
> Thread 9 (process 86430 thread 0x1503):
> #0  RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:30
> #1  0x0003bdc7 in RTException__Crash (a=0xb040ea64, raises=0 '\0', rte=0x7d100) at ../src/runtime/common/RTException.m3:79
> #2  0x0003bb21 in RTException__DefaultBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:39
> #3  0x0003ba7c in RTException__InvokeBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
> #4  0x00043ca5 in RTException__Raise (act=0xb040ea64) at ../src/runtime/ex_frame/RTExFrame.m3:85
> #5  0x0003bbb4 in RTException__DefaultBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:47
> #6  0x0003ba7c in RTException__InvokeBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
> #7  0x00043ca5 in RTException__Raise (act=0xb040ea64) at ../src/runtime/ex_frame/RTExFrame.m3:85
> #8  0x0002b102 in RTHooks__ReportFault (module=0x70f80, info=13378) at ../src/runtime/common/RTHooks.m3:111
> #9  0x000394c5 in _m3_fault (arg=13378) at ../src/runtime/common/RTCollector.m3:393
> #10 0x0002fdd2 in RTCollector__Move (self=0xb4000c, cp=0xba0014) at ../src/runtime/common/RTCollector.m3:418
> #11 0x0002e503 in RTHeapMap__Walk (x=0xba0014, pc=0x79928, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:202
> #12 0x0002dc9c in RTHeapMap__DoWalkRef (t=0x6de54, a=0xba0014, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:62
> #13 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e3f4, a=0xba000c, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:57
> #14 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e508, a=0xba000c, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:57
> #15 0x0002dc2e in RTHeapMap__WalkRef (h=0xba0008, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:47
> #16 0x00032279 in RTCollector__CleanBetween (h=0xba0008, he=0xbb0000, clean=0 '\0') at ../src/runtime/common/RTCollector.m3:1091
> #17 0x00032098 in RTCollector__CleanPage (page=0xba0000) at ../src/runtime/common/RTCollector.m3:1064
> #18 0x00031798 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885
> #19 0x00030e75 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720
> #20 0x00030a97 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654
> #21 0x0002cb85 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00e74) at ../src/runtime/common/RTAllocator.m3:367
> #22 0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:296
> #23 0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:143
> #24 0x00003b5f in Main__AApply (cl=0x9556c0) at ../src/Main.m3:260
> #25 0x00046ee2 in ThreadPThread__RunThread (me=0xa00e30) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #26 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00e30) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #27 0x93889155 in _pthread_start ()
> #28 0x93889012 in thread_start ()
> 
> Thread 8 (process 86430 thread 0x1403):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00dc4) at ../src/runtime/common/RTAllocator.m3:365
> #5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:296
> #6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:143
> #7  0x00003b5f in Main__AApply (cl=0x955688) at ../src/Main.m3:260
> #8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00d80) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00d80) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #10 0x93889155 in _pthread_start ()
> #11 0x93889012 in thread_start ()
> 
> Thread 7 (process 86430 thread 0x1303):
> #0  0x9389c856 in __wait4 ()
> #1  0x9389c847 in waitpid$UNIX2003 ()
> #2  0x0004b222 in Uexec__waitpid (i=86436, j=0xb030ad9c, k=0) at ../src/unix/Common/Uexec.c:67
> #3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86436, status=0xb030ad9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
> #4  0x0000d66a in Process__Wait (p=0xb00018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
> #5  0x00003719 in Main__FApply (cl=0x955618) at ../src/Main.m3:230
> #6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00d20) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00d20) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #8  0x93889155 in _pthread_start ()
> #9  0x93889012 in thread_start ()
> 
> Thread 6 (process 86430 thread 0x1203):
> #0  0x9389c856 in __wait4 ()
> #1  0x9389c847 in waitpid$UNIX2003 ()
> #2  0x0004b222 in Uexec__waitpid (i=86437, j=0xb0288d9c, k=0) at ../src/unix/Common/Uexec.c:67
> #3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86437, status=0xb0288d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
> #4  0x0000d66a in Process__Wait (p=0xbd0018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
> #5  0x00003719 in Main__FApply (cl=0x9555e0) at ../src/Main.m3:230
> #6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00b30) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00b30) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #8  0x93889155 in _pthread_start ()
> #9  0x93889012 in thread_start ()
> 
> Thread 5 (process 86430 thread 0x1103):
> #0  0x9389c856 in __wait4 ()
> #1  0x9389c847 in waitpid$UNIX2003 ()
> #2  0x0004b222 in Uexec__waitpid (i=86435, j=0xb0206d9c, k=0) at ../src/unix/Common/Uexec.c:67
> #3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86435, status=0xb0206d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
> #4  0x0000d66a in Process__Wait (p=0xc2000c) at ../src/os/POSIX/ProcessPosixCommon.m3:275
> #5  0x00003719 in Main__FApply (cl=0x9555a8) at ../src/Main.m3:230
> #6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00a80) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00a80) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #8  0x93889155 in _pthread_start ()
> #9  0x93889012 in thread_start ()
> 
> Thread 4 (process 86430 thread 0x1003):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=12, dataAlignment=4, thread=0xa00a14) at ../src/runtime/common/RTAllocator.m3:365
> #5  0x0002bf13 in RTAllocator__GetTracedObj (def=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:224
> #6  0x0002b98a in RTHooks__AllocateTracedObj (defn=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:122
> #7  0x00008eeb in FilePosix__New (fd=5, ds=1) at ../src/os/POSIX/FilePosix.m3:63
> #8  0x0000a4eb in FS__OpenFileReadonly (pn=0x775b8) at ../src/os/POSIX/FSPosix.m3:182
> #9  0x00014dfa in FileRd__Open (p=0x775b8) at ../src/rw/FileRd.m3:16
> #10 0x00003046 in Main__RApply (cl=0x955538) at ../src/Main.m3:174
> #11 0x00046ee2 in ThreadPThread__RunThread (me=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #12 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #13 0x93889155 in _pthread_start ()
> #14 0x93889012 in thread_start ()
> 
> Thread 3 (process 86430 thread 0x117):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x74220) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00044f3a in ThreadPThread__InitMutex (m=0x960010, root=0x96000c, Clean=0x44dac) at ../src/thread/PTHREAD/ThreadPThread.m3:101
> #4  0x0004500b in ThreadPThread__LockMutex (m=0x96000c) at ../src/thread/PTHREAD/ThreadPThread.m3:117
> #5  0x0000e060 in Rd__GetChar (rd=0x96000c) at ../src/rw/Rd.m3:33
> #6  0x000030b5 in Main__RApply (cl=0x955500) at ../src/Main.m3:177
> #7  0x00046ee2 in ThreadPThread__RunThread (me=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #8  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #9  0x93889155 in _pthread_start ()
> #10 0x93889012 in thread_start ()
> 
> Thread 2 (process 86430 thread 0x313):
> #0  0x938582a2 in semaphore_wait_trap ()
> #1  0x9385fd92 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x00036509 in RTHeapRep__RegisterFinalCleanup (r=0x9b1050, p=0x44dac) at ../src/runtime/common/RTCollector.m3:2148
> #5  0x00044fa2 in ThreadPThread__InitMutex (m=0x9b1054, root=0x9b1050, Clean=0x44dac) at ../src/thread/PTHREAD/ThreadPThread.m3:106
> #6  0x0004500b in ThreadPThread__LockMutex (m=0x9b1050) at ../src/thread/PTHREAD/ThreadPThread.m3:117
> #7  0x0000e060 in Rd__GetChar (rd=0x9b1050) at ../src/rw/Rd.m3:33
> #8  0x000030b5 in Main__RApply (cl=0x9554c8) at ../src/Main.m3:177
> #9  0x00046ee2 in ThreadPThread__RunThread (me=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #10 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #11 0x93889155 in _pthread_start ()
> #12 0x93889012 in thread_start ()
> 
> Thread 1 (process 86430 local thread 0x4507):
> #0  0x9385f44e in __semwait_signal ()
> #1  0x9388a3e6 in _pthread_cond_wait ()
> #2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
> #3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299134070.4957981) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
> #4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
> #5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
> #6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
> #7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
> #8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
> #9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
> #10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16
> 
>  - Jay
> 
> 
> From: jay.krell at cornell.edu
> To: dabenavidesd at yahoo.es; rcolebur at scires.com; m3devel at elegosoft.com
> Subject: RE: [M3devel] results of threadtest program on Windows7
> Date: Thu, 3 Mar 2011 06:32:50 +0000
> 
> Solaris doesn't hang now. I didn't change anything. And it succeeds.
> Here are some stacks for a failure on I386_DARWIN.
> Notice that it *should* abort right after the EBUSY print, but it still run a while.
> Possibly too much information is lost.
> 
> 
> (gdb) run
> Starting program: /Users/jay/dev2/cm3/m3-libs/m3core/tests/thread/I386_DARWIN/threadtest 
> Reading symbols for shared libraries ++. done
> 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
> ..........laziest thread is 1/0/0 (tests: read 0/0/0 fork 1/1/1 alloc 0/0/0 lock 0/0/0)
> .........pthread_mutex_destroy:EBUSY (0)
> .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:
> ***    An array subscript was out of range.
> ***    file "../src/runtime/common/RTCollector.m3", line 418
> ***
> 
> 
> Program received signal SIGABRT, Aborted.
> 0x9385f44e in __semwait_signal ()
> (gdb) bt
> #0  0x9385f44e in __semwait_signal ()
> #1  0x9388a3e6 in _pthread_cond_wait ()
> #2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
> #3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299133562.375689) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
> #4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
> #5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
> #6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
> #7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
> #8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
> #9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
> #10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16
> 
> 
> (gdb) thread apply all bt
> 
> Thread 13 (process 86311 thread 0x2a03):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #4  0x00003ed8 in Main__LApply (cl=0x9557d8) at ../src/Main.m3:290
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01130) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01130) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 12 (process 86311 thread 0x1f03):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #4  0x00003ed8 in Main__LApply (cl=0x9557a0) at ../src/Main.m3:290
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01080) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01080) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 11 (process 86311 thread 0x1e03):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #4  0x00003ed8 in Main__LApply (cl=0x955768) at ../src/Main.m3:290
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 10 (process 86311 thread 0x1d03):
> #0  0x93934136 in __semwait_signal_nocancel ()
> #1  0x93933d1b in nanosleep$NOCANCEL$UNIX2003 ()
> #2  0x9392d013 in usleep$NOCANCEL$UNIX2003 ()
> #3  0x93944685 in abort ()
> #4  0x0004b5e6 in Cstdlib__abort () at ../src/C/Common/CstdlibC.c:21
> #5  0x000434dd in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20
> #6  0x0003d51f in RTProcess__Crash (msg=0x0) at ../src/runtime/common/RTProcess.m3:65
> #7  0x0003b9d3 in RTError__EndError (crash=1 '\001') at ../src/runtime/common/RTError.m3:118
> #8  0x0003b6e6 in RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:40
> #9  0x0003bdc7 in RTException__Crash (a=0xb0490a64, raises=0 '\0', rte=0x7d100) at ../src/runtime/common/RTException.m3:79
> #10 0x0003bb21 in RTException__DefaultBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:39
> #11 0x0003ba7c in RTException__InvokeBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
> #12 0x00043ca5 in RTException__Raise (act=0xb0490a64) at ../src/runtime/ex_frame/RTExFrame.m3:85
> #13 0x0003bbb4 in RTException__DefaultBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:47
> #14 0x0003ba7c in RTException__InvokeBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
> #15 0x00043ca5 in RTException__Raise (act=0xb0490a64) at ../src/runtime/ex_frame/RTExFrame.m3:85
> #16 0x0002b102 in RTHooks__ReportFault (module=0x70f80, info=13378) at ../src/runtime/common/RTHooks.m3:111
> #17 0x000394c5 in _m3_fault (arg=13378) at ../src/runtime/common/RTCollector.m3:393
> #18 0x0002fdd2 in RTCollector__Move (self=0xb3000c, cp=0x9a0014) at ../src/runtime/common/RTCollector.m3:418
> #19 0x0002e503 in RTHeapMap__Walk (x=0x9a0014, pc=0x79928, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:202
> #20 0x0002dc9c in RTHeapMap__DoWalkRef (t=0x6de54, a=0x9a0014, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:62
> #21 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e3f4, a=0x9a000c, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:57
> #22 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e508, a=0x9a000c, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:57
> #23 0x0002dc2e in RTHeapMap__WalkRef (h=0x9a0008, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:47
> #24 0x00032279 in RTCollector__CleanBetween (h=0x9a0008, he=0x9b0000, clean=0 '\0') at ../src/runtime/common/RTCollector.m3:1091
> #25 0x00032098 in RTCollector__CleanPage (page=0x9a0000) at ../src/runtime/common/RTCollector.m3:1064
> #26 0x00031798 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885
> #27 0x00030e75 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720
> #28 0x00030a97 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654
> #29 0x0002cb85 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00f64) at ../src/runtime/common/RTAllocator.m3:367
> #30 0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:296
> #31 0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:143
> #32 0x00003b5f in Main__AApply (cl=0x9556f8) at ../src/Main.m3:260
> #33 0x00046ee2 in ThreadPThread__RunThread (me=0xa00f20) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #34 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00f20) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #35 0x93889155 in _pthread_start ()
> #36 0x93889012 in thread_start ()
> 
> Thread 9 (process 86311 thread 0x1c03):
> #0  0x938582a2 in semaphore_wait_trap ()
> #1  0x9385fd92 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00eb4) at ../src/runtime/common/RTAllocator.m3:365
> #5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:296
> #6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:143
> #7  0x00003b5f in Main__AApply (cl=0x9556c0) at ../src/Main.m3:260
> #8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00e70) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00e70) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #10 0x93889155 in _pthread_start ()
> #11 0x93889012 in thread_start ()
> 
> Thread 8 (process 86311 thread 0x1b03):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00e04) at ../src/runtime/common/RTAllocator.m3:365
> #5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:296
> #6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:143
> #7  0x00003b5f in Main__AApply (cl=0x955688) at ../src/Main.m3:260
> #8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00dc0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00dc0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #10 0x93889155 in _pthread_start ()
> #11 0x93889012 in thread_start ()
> 
> Thread 7 (process 86311 thread 0x1a03):
> #0  0x9389c856 in __wait4 ()
> #1  0x9389c847 in waitpid$UNIX2003 ()
> #2  0x0004b222 in Uexec__waitpid (i=86384, j=0xb030ad9c, k=0) at ../src/unix/Common/Uexec.c:67
> #3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86384, status=0xb030ad9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
> #4  0x0000d66a in Process__Wait (p=0xb00018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
> #5  0x00003719 in Main__FApply (cl=0x955618) at ../src/Main.m3:230
> #6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00d60) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00d60) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #8  0x93889155 in _pthread_start ()
> #9  0x93889012 in thread_start ()
> 
> Thread 6 (process 86311 thread 0x1903):
> #0  0x9389c856 in __wait4 ()
> #1  0x9389c847 in waitpid$UNIX2003 ()
> #2  0x0004b222 in Uexec__waitpid (i=86385, j=0xb0288d9c, k=0) at ../src/unix/Common/Uexec.c:67
> #3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86385, status=0xb0288d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
> #4  0x0000d66a in Process__Wait (p=0xbd000c) at ../src/os/POSIX/ProcessPosixCommon.m3:275
> #5  0x00003719 in Main__FApply (cl=0x9555e0) at ../src/Main.m3:230
> #6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00b70) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00b70) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #8  0x93889155 in _pthread_start ()
> #9  0x93889012 in thread_start ()
> 
> Thread 5 (process 86311 thread 0x1803):
> #0  0x9389c856 in __wait4 ()
> #1  0x9389c847 in waitpid$UNIX2003 ()
> #2  0x0004b222 in Uexec__waitpid (i=86386, j=0xb0206d9c, k=0) at ../src/unix/Common/Uexec.c:67
> #3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86386, status=0xb0206d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
> #4  0x0000d66a in Process__Wait (p=0x9d0018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
> #5  0x00003719 in Main__FApply (cl=0x9555a8) at ../src/Main.m3:230
> #6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00ac0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00ac0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #8  0x93889155 in _pthread_start ()
> #9  0x93889012 in thread_start ()
> 
> Thread 4 (process 86311 thread 0x1103):
> #0  0x9385fb99 in pthread_mutex_lock ()
> #1  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00c20) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #2  0x0004503c in ThreadPThread__LockMutex (m=0xb6000c) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #3  0x0000e060 in Rd__GetChar (rd=0xb6000c) at ../src/rw/Rd.m3:33
> #4  0x000030b5 in Main__RApply (cl=0x955538) at ../src/Main.m3:177
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 3 (process 86311 thread 0x117):
> #0  0x93859304 in pthread_getspecific ()
> #1  0x0004a529 in ThreadPThread__GetActivation () at ../src/thread/PTHREAD/ThreadPThreadC.c:309
> #2  0x00049f52 in RTHooks__PushEFrame (frame=0xb0102d20) at ../src/thread/PTHREAD/ThreadPThread.m3:1385
> #3  0x0000e07b in Rd__GetChar (rd=0x99000c) at ../src/rw/Rd.m3:33
> #4  0x000030b5 in Main__RApply (cl=0x955500) at ../src/Main.m3:177
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 2 (process 86311 thread 0x313):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=12, dataAlignment=4, thread=0xa00834) at ../src/runtime/common/RTAllocator.m3:365
> #5  0x0002bf13 in RTAllocator__GetTracedObj (def=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:224
> #6  0x0002b98a in RTHooks__AllocateTracedObj (defn=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:122
> #7  0x00008eeb in FilePosix__New (fd=5, ds=1) at ../src/os/POSIX/FilePosix.m3:63
> #8  0x0000a4eb in FS__OpenFileReadonly (pn=0x775b8) at ../src/os/POSIX/FSPosix.m3:182
> #9  0x00014dfa in FileRd__Open (p=0x775b8) at ../src/rw/FileRd.m3:16
> #10 0x00003046 in Main__RApply (cl=0x9554c8) at ../src/Main.m3:174
> #11 0x00046ee2 in ThreadPThread__RunThread (me=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #12 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #13 0x93889155 in _pthread_start ()
> #14 0x93889012 in thread_start ()
> 
> Thread 1 (process 86311 local thread 0x2e03):
> #0  0x9385f44e in __semwait_signal ()
> #1  0x9388a3e6 in _pthread_cond_wait ()
> #2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
> #3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299133562.375689) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
> #4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
> #5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
> #6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
> #7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
> #8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
> #9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
> #10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16
> 
> 
> 
> 
> 
> 
> 
> From: jay.krell at cornell.edu
> To: dabenavidesd at yahoo.es; rcolebur at scires.com; m3devel at elegosoft.com
> Subject: RE: [M3devel] results of threadtest program on Windows7
> Date: Thu, 3 Mar 2011 02:46:39 +0000
> 
> There is probably a bug in RTCollector.m3 or RTAllocator.m3.
> 
>  - Jay
> 
> Date: Thu, 3 Mar 2011 02:27:58 +0000
> From: dabenavidesd at yahoo.es
> Subject: Re: [M3devel] results of threadtest program on Windows7
> To: rcolebur at scires.com; m3devel at elegosoft.com; jay.krell at cornell.edu
> 
> Hi all:
> I would doubt but there could be some source of problem in smp on the Win32 platform, since there was a SPINE implementation on an intelligent NIC with 2 embedded MIPS CPUs, perhaps this was just a driver RT but it was for real time and in such a case there should be no problem besides that of the scheduling policy, but thinking how about linking MS Win2k R is a kind of crazy not to believe there was some synchronization with CPU board threads and that component threading at some point I believe.
> 
> Even more in embedded systems, there was a MPU implementation of it in 80186 a decade ago,  perhaps would be good to have a look of their Thread interface implementation it might be seem interesting if so.
> 
> But in any case there should be plenty of ways of implementing the threading tests incrementally of number of threads, besides you may want to check some uniprocessors with hyperThreading technology (sort of thread physical divisions inside the cpu), they are presented to OS as 2 smp processors, it could be interesting, I remember to test  time ago in this machines and anything weird happened, but quite time ago with ThreadPthread LINUXLIBC6 systems with normally distributed programs.
>  
> What about results in Win2k ?
> Thanks in advance
> 
> --- El mi?, 2/3/11, Jay K <jay.krell at cornell.edu> escribi?:
> 
> De: Jay K <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] results of threadtest program on Windows7
> Para: rcolebur at scires.com, "m3devel" <m3devel at elegosoft.com>
> Fecha: mi?rcoles, 2 de marzo, 2011 20:17
> 
> Even with the change I made PutCard to PutInt?
> That's the only failure I've seen.
> I'll try on a non-virtual dual-proc machine later.
>  
> Thanks,
>  - Jay
>  
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Wed, 2 Mar 2011 19:42:47 -0500
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Yes, it fails more often than it runs for me.
> Regards,
> Randy
>  
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Tuesday, March 01, 2011 5:59 AM
> To: Mika Nystrom; Coleburn, Randy
> Cc: m3devel
> Subject: RE: [M3devel] results of threadtest program on Windows7
>  
> I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
> I've run it just a few times now. One single and dual processor virtual machines.
> Randy, has it failed many times for you?
> 
>  - Jay
> 
> > To: rcolebur at SCIRES.COM
> > Date: Sun, 27 Feb 2011 15:11:25 -0800
> > From: mika at async.caltech.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] results of threadtest program on Windows7
> > 
> > Ah, it just doesn't check command-line arguments that carefully.
> > 
> > I think what you did is equivalent to "-tests STD".
> > 
> > Mika
> > 
> > "Coleburn, Randy" writes:
> > >Mika:
> > >
> > >No change with "-tests POSIX".
> > >
> > >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> > >ptions are, and I typed "threadtest -help" rather than reading the code.
> > >
> > >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> > >d it again and it ran to completion. Something seems non-deterministic her=
> > >e. See below.
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >.
> > >
> > >***
> > >*** runtime error:
> > >*** Attempt to reference an illegal memory location.
> > >*** pc =3D 0x77762262
> > >***
> > >
> > >Stack trace:
> > > FP PC Procedure
> > >--------- --------- -------------------------------
> > > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> > >3
> > > 0xcdf9c0 0x77762262 <???>
> > > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> > >3
> > > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> > >.m3
> > > 0xcdfb80 0x76543677 <???>
> > > 0xcdfbc0 0x77779f02 <???>
> > >......... ......... ... more frames ...
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >All tests complete. Congratulations.
> > >
> > >Regards,
> > >Randy Coleburn
> > >
> > >-----Original Message-----
> > >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> > >Sent: Sunday, February 27, 2011 3:30 PM
> > >To: Coleburn, Randy
> > >Cc: m3devel at elegosoft.com
> > >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> > >
> > >Hi Randy,
> > >
> > >You can try it with -tests POSIX as well.
> > >
> > >I find on user threads it runs very slowly (but it does run) because of how=
> > > unfair
> > >the thread scheduler is.
> > >
> > >Next step might be to whittle down the tests and see if you can get a failu=
> > >re with
> > >a single test running and -n 2. That would likely be the simplest scenario=
> > > to
> > >start further debugging from.
> > >
> > > Mika
> > >
> > >"Coleburn, Randy" writes:
> > >>Mika et al:
> > >>
> > >>Thought I would try something else.
> > >>
> > >>I took the sources of your thread test program to an older XP machine that=
> > > =3D
> > >>has CM3 circa August 2008. This is the machine and implementation I used =
> > >w=3D
> > >>hen building a major project I did a couple years back.
> > >>
> > >>The thread test program does indeed build on this old system, but when I r=
> > >u=3D
> > >>n it, I get different results than with the latest HEAD branch code. =3D20
> > >>
> > >>After it prints "running...printing oldest/median age/newest", on the next=
> > > =3D
> > >>line I get two periods ".." and now the program seems hung. I'll let it "=
> > >r=3D
> > >>un" for a few more minutes to see if anything else happens before killing =
> > >i=3D
> > >>t.
> > >>
> > >>At least we don't get the subscript and assertion failures on this older C=
> > >M=3D
> > >>3 platform.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>
> > >>-----Original Message-----
> > >>From: Coleburn, Randy=3D20
> > >>Sent: Sunday, February 27, 2011 2:09 PM
> > >>To: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7
> > >>
> > >>Mika:
> > >>
> > >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> > >>
> > >>Here is what happens now when I run your threadtest program on Windows 7.
> > >>
> > >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> > >r=3D
> > >>k
> > >>Writing file...done
> > >>Creating read threads...done
> > >>Creating nxread threads...done
> > >>Creating tryexcept threads...done
> > >>Creating forktoomuch threads...done
> > >>Creating alloc threads...done
> > >>Creating creat threads...done
> > >>Creating lock threads...done
> > >>running...printing oldest/median age/newest
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** An array subscript was out of range.
> > >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> > >>***
> > >>
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** <*ASSERT*> failed.
> > >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> > >>***
> > >>
> > >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> > >>
> > >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> > >.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>-----Original Message-----
> > >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> > >>Sent: Saturday, February 26, 2011 12:55 PM
> > >>To: Coleburn, Randy
> > >>Cc: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> > >>
> > >>Hi Randy,
> > >>
> > >>Hm yes it looks like my Windows programming skills leave something
> > >>to be desired.
> > >>
> > >>You can run the thread tester while skipping a test as follows
> > >>
> > >> threadtest -tests ALL,-fork
> > >>
> > >>(for instance)
> > >>
> > >>if you just run=3D20
> > >>
> > >> threadtest -sadfassdaf
> > >>
> > >>it'll print the tests that are available.
> > >>
> > >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> > >>Can you give me a very brief description of what you did to install Modula=
> > >-=3D
> > >>3
> > >>on this system?
> > >>
> > >> Mika
> > >>
> > >>"Coleburn, Randy" writes:
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>
> > >>>Mika:
> > >>>
> > >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> > >>>
> > >>>So, I ran your threadtest program.
> > >>>
> > >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> > >e=3D
> > >>p=3D3D
> > >>>eating "ERROR FApply" messages.
> > >>>
> > >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > >>>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
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>***
> > >>>*** runtime error:
> > >>>*** An enumeration or subrange value was out of range.
> > >>>*** file "..\src\Main.m3", line 340
> > >>>***
> > >>>
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>Stack trace:
> > >>> FP PC Procedure
> > >>>--------- --------- -------------------------------
> > >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> > >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> > >>>
> > >>>Regards,
> > >>>Randy Coleburn
> > >>>
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/html; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110303/ad2560e7/attachment.html>

From hosking at cs.purdue.edu  Thu Mar  3 16:42:51 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 3 Mar 2011 10:42:51 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W1943F7B289FE5FD33E5D1EE6C30@phx.gbl>
References: <COL101-W4726257303F22627175774E6C30@phx.gbl>,
	<974355.12644.qm@web29717.mail.ird.yahoo.com>,
	<COL101-W2637AB63DA6D9866A00D07E6C30@phx.gbl>
	<COL101-W1943F7B289FE5FD33E5D1EE6C30@phx.gbl>
Message-ID: <DEFD098A-268B-41EB-B59E-03BF19CAF910@cs.purdue.edu>

Running with @M3paranoidgc should let us know how we end up with a pointer that does not refer to an object.

On Mar 3, 2011, at 1:32 AM, Jay K wrote:

> Solaris doesn't hang now. I didn't change anything. And it succeeds.
> Here are some stacks for a failure on I386_DARWIN.
> Notice that it *should* abort right after the EBUSY print, but it still run a while.
> Possibly too much information is lost.
> 
> 
> (gdb) run
> Starting program: /Users/jay/dev2/cm3/m3-libs/m3core/tests/thread/I386_DARWIN/threadtest 
> Reading symbols for shared libraries ++. done
> 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
> ..........laziest thread is 1/0/0 (tests: read 0/0/0 fork 1/1/1 alloc 0/0/0 lock 0/0/0)
> .........pthread_mutex_destroy:EBUSY (0)
> .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:
> ***    An array subscript was out of range.
> ***    file "../src/runtime/common/RTCollector.m3", line 418
> ***
> 
> 
> Program received signal SIGABRT, Aborted.
> 0x9385f44e in __semwait_signal ()
> (gdb) bt
> #0  0x9385f44e in __semwait_signal ()
> #1  0x9388a3e6 in _pthread_cond_wait ()
> #2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
> #3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299133562.375689) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
> #4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
> #5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
> #6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
> #7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
> #8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
> #9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
> #10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16
> 
> 
> (gdb) thread apply all bt
> 
> Thread 13 (process 86311 thread 0x2a03):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #4  0x00003ed8 in Main__LApply (cl=0x9557d8) at ../src/Main.m3:290
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01130) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01130) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 12 (process 86311 thread 0x1f03):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #4  0x00003ed8 in Main__LApply (cl=0x9557a0) at ../src/Main.m3:290
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01080) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01080) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 11 (process 86311 thread 0x1e03):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #4  0x00003ed8 in Main__LApply (cl=0x955768) at ../src/Main.m3:290
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 10 (process 86311 thread 0x1d03):
> #0  0x93934136 in __semwait_signal_nocancel ()
> #1  0x93933d1b in nanosleep$NOCANCEL$UNIX2003 ()
> #2  0x9392d013 in usleep$NOCANCEL$UNIX2003 ()
> #3  0x93944685 in abort ()
> #4  0x0004b5e6 in Cstdlib__abort () at ../src/C/Common/CstdlibC.c:21
> #5  0x000434dd in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20
> #6  0x0003d51f in RTProcess__Crash (msg=0x0) at ../src/runtime/common/RTProcess.m3:65
> #7  0x0003b9d3 in RTError__EndError (crash=1 '\001') at ../src/runtime/common/RTError.m3:118
> #8  0x0003b6e6 in RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:40
> #9  0x0003bdc7 in RTException__Crash (a=0xb0490a64, raises=0 '\0', rte=0x7d100) at ../src/runtime/common/RTException.m3:79
> #10 0x0003bb21 in RTException__DefaultBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:39
> #11 0x0003ba7c in RTException__InvokeBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
> #12 0x00043ca5 in RTException__Raise (act=0xb0490a64) at ../src/runtime/ex_frame/RTExFrame.m3:85
> #13 0x0003bbb4 in RTException__DefaultBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:47
> #14 0x0003ba7c in RTException__InvokeBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
> #15 0x00043ca5 in RTException__Raise (act=0xb0490a64) at ../src/runtime/ex_frame/RTExFrame.m3:85
> #16 0x0002b102 in RTHooks__ReportFault (module=0x70f80, info=13378) at ../src/runtime/common/RTHooks.m3:111
> #17 0x000394c5 in _m3_fault (arg=13378) at ../src/runtime/common/RTCollector.m3:393
> #18 0x0002fdd2 in RTCollector__Move (self=0xb3000c, cp=0x9a0014) at ../src/runtime/common/RTCollector.m3:418
> #19 0x0002e503 in RTHeapMap__Walk (x=0x9a0014, pc=0x79928, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:202
> #20 0x0002dc9c in RTHeapMap__DoWalkRef (t=0x6de54, a=0x9a0014, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:62
> #21 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e3f4, a=0x9a000c, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:57
> #22 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e508, a=0x9a000c, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:57
> #23 0x0002dc2e in RTHeapMap__WalkRef (h=0x9a0008, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:47
> #24 0x00032279 in RTCollector__CleanBetween (h=0x9a0008, he=0x9b0000, clean=0 '\0') at ../src/runtime/common/RTCollector.m3:1091
> #25 0x00032098 in RTCollector__CleanPage (page=0x9a0000) at ../src/runtime/common/RTCollector.m3:1064
> #26 0x00031798 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885
> #27 0x00030e75 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720
> #28 0x00030a97 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654
> #29 0x0002cb85 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00f64) at ../src/runtime/common/RTAllocator.m3:367
> #30 0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:296
> #31 0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:143
> #32 0x00003b5f in Main__AApply (cl=0x9556f8) at ../src/Main.m3:260
> #33 0x00046ee2 in ThreadPThread__RunThread (me=0xa00f20) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #34 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00f20) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #35 0x93889155 in _pthread_start ()
> #36 0x93889012 in thread_start ()
> 
> Thread 9 (process 86311 thread 0x1c03):
> #0  0x938582a2 in semaphore_wait_trap ()
> #1  0x9385fd92 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00eb4) at ../src/runtime/common/RTAllocator.m3:365
> #5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:296
> #6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:143
> #7  0x00003b5f in Main__AApply (cl=0x9556c0) at ../src/Main.m3:260
> #8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00e70) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00e70) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #10 0x93889155 in _pthread_start ()
> #11 0x93889012 in thread_start ()
> 
> Thread 8 (process 86311 thread 0x1b03):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00e04) at ../src/runtime/common/RTAllocator.m3:365
> #5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:296
> #6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:143
> #7  0x00003b5f in Main__AApply (cl=0x955688) at ../src/Main.m3:260
> #8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00dc0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00dc0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #10 0x93889155 in _pthread_start ()
> #11 0x93889012 in thread_start ()
> 
> Thread 7 (process 86311 thread 0x1a03):
> #0  0x9389c856 in __wait4 ()
> #1  0x9389c847 in waitpid$UNIX2003 ()
> #2  0x0004b222 in Uexec__waitpid (i=86384, j=0xb030ad9c, k=0) at ../src/unix/Common/Uexec.c:67
> #3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86384, status=0xb030ad9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
> #4  0x0000d66a in Process__Wait (p=0xb00018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
> #5  0x00003719 in Main__FApply (cl=0x955618) at ../src/Main.m3:230
> #6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00d60) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00d60) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #8  0x93889155 in _pthread_start ()
> #9  0x93889012 in thread_start ()
> 
> Thread 6 (process 86311 thread 0x1903):
> #0  0x9389c856 in __wait4 ()
> #1  0x9389c847 in waitpid$UNIX2003 ()
> #2  0x0004b222 in Uexec__waitpid (i=86385, j=0xb0288d9c, k=0) at ../src/unix/Common/Uexec.c:67
> #3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86385, status=0xb0288d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
> #4  0x0000d66a in Process__Wait (p=0xbd000c) at ../src/os/POSIX/ProcessPosixCommon.m3:275
> #5  0x00003719 in Main__FApply (cl=0x9555e0) at ../src/Main.m3:230
> #6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00b70) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00b70) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #8  0x93889155 in _pthread_start ()
> #9  0x93889012 in thread_start ()
> 
> Thread 5 (process 86311 thread 0x1803):
> #0  0x9389c856 in __wait4 ()
> #1  0x9389c847 in waitpid$UNIX2003 ()
> #2  0x0004b222 in Uexec__waitpid (i=86386, j=0xb0206d9c, k=0) at ../src/unix/Common/Uexec.c:67
> #3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86386, status=0xb0206d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
> #4  0x0000d66a in Process__Wait (p=0x9d0018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
> #5  0x00003719 in Main__FApply (cl=0x9555a8) at ../src/Main.m3:230
> #6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00ac0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00ac0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #8  0x93889155 in _pthread_start ()
> #9  0x93889012 in thread_start ()
> 
> Thread 4 (process 86311 thread 0x1103):
> #0  0x9385fb99 in pthread_mutex_lock ()
> #1  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00c20) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #2  0x0004503c in ThreadPThread__LockMutex (m=0xb6000c) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #3  0x0000e060 in Rd__GetChar (rd=0xb6000c) at ../src/rw/Rd.m3:33
> #4  0x000030b5 in Main__RApply (cl=0x955538) at ../src/Main.m3:177
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 3 (process 86311 thread 0x117):
> #0  0x93859304 in pthread_getspecific ()
> #1  0x0004a529 in ThreadPThread__GetActivation () at ../src/thread/PTHREAD/ThreadPThreadC.c:309
> #2  0x00049f52 in RTHooks__PushEFrame (frame=0xb0102d20) at ../src/thread/PTHREAD/ThreadPThread.m3:1385
> #3  0x0000e07b in Rd__GetChar (rd=0x99000c) at ../src/rw/Rd.m3:33
> #4  0x000030b5 in Main__RApply (cl=0x955500) at ../src/Main.m3:177
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 2 (process 86311 thread 0x313):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=12, dataAlignment=4, thread=0xa00834) at ../src/runtime/common/RTAllocator.m3:365
> #5  0x0002bf13 in RTAllocator__GetTracedObj (def=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:224
> #6  0x0002b98a in RTHooks__AllocateTracedObj (defn=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:122
> #7  0x00008eeb in FilePosix__New (fd=5, ds=1) at ../src/os/POSIX/FilePosix.m3:63
> #8  0x0000a4eb in FS__OpenFileReadonly (pn=0x775b8) at ../src/os/POSIX/FSPosix.m3:182
> #9  0x00014dfa in FileRd__Open (p=0x775b8) at ../src/rw/FileRd.m3:16
> #10 0x00003046 in Main__RApply (cl=0x9554c8) at ../src/Main.m3:174
> #11 0x00046ee2 in ThreadPThread__RunThread (me=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #12 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #13 0x93889155 in _pthread_start ()
> #14 0x93889012 in thread_start ()
> 
> Thread 1 (process 86311 local thread 0x2e03):
> #0  0x9385f44e in __semwait_signal ()
> #1  0x9388a3e6 in _pthread_cond_wait ()
> #2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
> #3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299133562.375689) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
> #4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
> #5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
> #6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
> #7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
> #8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
> #9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
> #10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16
> 
> 
> 
> 
> 
> 
> 
> From: jay.krell at cornell.edu
> To: dabenavidesd at yahoo.es; rcolebur at scires.com; m3devel at elegosoft.com
> Subject: RE: [M3devel] results of threadtest program on Windows7
> Date: Thu, 3 Mar 2011 02:46:39 +0000
> 
> There is probably a bug in RTCollector.m3 or RTAllocator.m3.
> 
>  - Jay
> 
> Date: Thu, 3 Mar 2011 02:27:58 +0000
> From: dabenavidesd at yahoo.es
> Subject: Re: [M3devel] results of threadtest program on Windows7
> To: rcolebur at scires.com; m3devel at elegosoft.com; jay.krell at cornell.edu
> 
> Hi all:
> I would doubt but there could be some source of problem in smp on the Win32 platform, since there was a SPINE implementation on an intelligent NIC with 2 embedded MIPS CPUs, perhaps this was just a driver RT but it was for real time and in such a case there should be no problem besides that of the scheduling policy, but thinking how about linking MS Win2k R is a kind of crazy not to believe there was some synchronization with CPU board threads and that component threading at some point I believe.
> 
> Even more in embedded systems, there was a MPU implementation of it in 80186 a decade ago,  perhaps would be good to have a look of their Thread interface implementation it might be seem interesting if so.
> 
> But in any case there should be plenty of ways of implementing the threading tests incrementally of number of threads, besides you may want to check some uniprocessors with hyperThreading technology (sort of thread physical divisions inside the cpu), they are presented to OS as 2 smp processors, it could be interesting, I remember to test  time ago in this machines and anything weird happened, but quite time ago with ThreadPthread LINUXLIBC6 systems with normally distributed programs.
>  
> What about results in Win2k ?
> Thanks in advance
> 
> --- El mi?, 2/3/11, Jay K <jay.krell at cornell.edu> escribi?:
> 
> De: Jay K <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] results of threadtest program on Windows7
> Para: rcolebur at scires.com, "m3devel" <m3devel at elegosoft.com>
> Fecha: mi?rcoles, 2 de marzo, 2011 20:17
> 
> Even with the change I made PutCard to PutInt?
> That's the only failure I've seen.
> I'll try on a non-virtual dual-proc machine later.
>  
> Thanks,
>  - Jay
>  
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Wed, 2 Mar 2011 19:42:47 -0500
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Yes, it fails more often than it runs for me.
> Regards,
> Randy
>  
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Tuesday, March 01, 2011 5:59 AM
> To: Mika Nystrom; Coleburn, Randy
> Cc: m3devel
> Subject: RE: [M3devel] results of threadtest program on Windows7
>  
> I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
> I've run it just a few times now. One single and dual processor virtual machines.
> Randy, has it failed many times for you?
> 
>  - Jay
> 
> > To: rcolebur at SCIRES.COM
> > Date: Sun, 27 Feb 2011 15:11:25 -0800
> > From: mika at async.caltech.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] results of threadtest program on Windows7
> > 
> > Ah, it just doesn't check command-line arguments that carefully.
> > 
> > I think what you did is equivalent to "-tests STD".
> > 
> > Mika
> > 
> > "Coleburn, Randy" writes:
> > >Mika:
> > >
> > >No change with "-tests POSIX".
> > >
> > >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> > >ptions are, and I typed "threadtest -help" rather than reading the code.
> > >
> > >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> > >d it again and it ran to completion. Something seems non-deterministic her=
> > >e. See below.
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >.
> > >
> > >***
> > >*** runtime error:
> > >*** Attempt to reference an illegal memory location.
> > >*** pc =3D 0x77762262
> > >***
> > >
> > >Stack trace:
> > > FP PC Procedure
> > >--------- --------- -------------------------------
> > > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> > >3
> > > 0xcdf9c0 0x77762262 <???>
> > > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> > >3
> > > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> > >.m3
> > > 0xcdfb80 0x76543677 <???>
> > > 0xcdfbc0 0x77779f02 <???>
> > >......... ......... ... more frames ...
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >All tests complete. Congratulations.
> > >
> > >Regards,
> > >Randy Coleburn
> > >
> > >-----Original Message-----
> > >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> > >Sent: Sunday, February 27, 2011 3:30 PM
> > >To: Coleburn, Randy
> > >Cc: m3devel at elegosoft.com
> > >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> > >
> > >Hi Randy,
> > >
> > >You can try it with -tests POSIX as well.
> > >
> > >I find on user threads it runs very slowly (but it does run) because of how=
> > > unfair
> > >the thread scheduler is.
> > >
> > >Next step might be to whittle down the tests and see if you can get a failu=
> > >re with
> > >a single test running and -n 2. That would likely be the simplest scenario=
> > > to
> > >start further debugging from.
> > >
> > > Mika
> > >
> > >"Coleburn, Randy" writes:
> > >>Mika et al:
> > >>
> > >>Thought I would try something else.
> > >>
> > >>I took the sources of your thread test program to an older XP machine that=
> > > =3D
> > >>has CM3 circa August 2008. This is the machine and implementation I used =
> > >w=3D
> > >>hen building a major project I did a couple years back.
> > >>
> > >>The thread test program does indeed build on this old system, but when I r=
> > >u=3D
> > >>n it, I get different results than with the latest HEAD branch code. =3D20
> > >>
> > >>After it prints "running...printing oldest/median age/newest", on the next=
> > > =3D
> > >>line I get two periods ".." and now the program seems hung. I'll let it "=
> > >r=3D
> > >>un" for a few more minutes to see if anything else happens before killing =
> > >i=3D
> > >>t.
> > >>
> > >>At least we don't get the subscript and assertion failures on this older C=
> > >M=3D
> > >>3 platform.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>
> > >>-----Original Message-----
> > >>From: Coleburn, Randy=3D20
> > >>Sent: Sunday, February 27, 2011 2:09 PM
> > >>To: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7
> > >>
> > >>Mika:
> > >>
> > >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> > >>
> > >>Here is what happens now when I run your threadtest program on Windows 7.
> > >>
> > >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> > >r=3D
> > >>k
> > >>Writing file...done
> > >>Creating read threads...done
> > >>Creating nxread threads...done
> > >>Creating tryexcept threads...done
> > >>Creating forktoomuch threads...done
> > >>Creating alloc threads...done
> > >>Creating creat threads...done
> > >>Creating lock threads...done
> > >>running...printing oldest/median age/newest
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** An array subscript was out of range.
> > >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> > >>***
> > >>
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** <*ASSERT*> failed.
> > >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> > >>***
> > >>
> > >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> > >>
> > >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> > >.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>-----Original Message-----
> > >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> > >>Sent: Saturday, February 26, 2011 12:55 PM
> > >>To: Coleburn, Randy
> > >>Cc: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> > >>
> > >>Hi Randy,
> > >>
> > >>Hm yes it looks like my Windows programming skills leave something
> > >>to be desired.
> > >>
> > >>You can run the thread tester while skipping a test as follows
> > >>
> > >> threadtest -tests ALL,-fork
> > >>
> > >>(for instance)
> > >>
> > >>if you just run=3D20
> > >>
> > >> threadtest -sadfassdaf
> > >>
> > >>it'll print the tests that are available.
> > >>
> > >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> > >>Can you give me a very brief description of what you did to install Modula=
> > >-=3D
> > >>3
> > >>on this system?
> > >>
> > >> Mika
> > >>
> > >>"Coleburn, Randy" writes:
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>
> > >>>Mika:
> > >>>
> > >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> > >>>
> > >>>So, I ran your threadtest program.
> > >>>
> > >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> > >e=3D
> > >>p=3D3D
> > >>>eating "ERROR FApply" messages.
> > >>>
> > >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > >>>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
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>***
> > >>>*** runtime error:
> > >>>*** An enumeration or subrange value was out of range.
> > >>>*** file "..\src\Main.m3", line 340
> > >>>***
> > >>>
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>Stack trace:
> > >>> FP PC Procedure
> > >>>--------- --------- -------------------------------
> > >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> > >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> > >>>
> > >>>Regards,
> > >>>Randy Coleburn
> > >>>
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/html; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110303/93b23a6e/attachment.html>

From rcolebur at SCIRES.COM  Thu Mar  3 19:47:11 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 3 Mar 2011 13:47:11 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>
	<COL101-W4726257303F22627175774E6C30@phx.gbl>
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>

Tony:

Here are results using the checks you suggested.  These are running on Windows 7.

*         @M3paranoidgc

*         @M3nogc

*         @M3noincremental

*         @M3nogenerational

As you can see below, the only one where the program ran to completion is when using M3nogenerational; However, this doesn't mean it solves the problem, because I ran a second time with this option (see below) and it crashed.

When using M3nogc, looks like we run out of memory.  The computer I am using for these tests is a Dell Latitude 6510 with 4GB RAM and a system-managed pagefile size.

Hope these test runs give some insight into the problem.

Let me know what else I can do to help.

Regards,
Randy

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc
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
.

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0xa8f9bc = RefSanityCheck + 0x2c in ..\src\runtime\common\RTCollector.m3
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogc
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
.....

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.
***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x1faf970   0xaaa7b2  Raise + 0x3f in ..\src\runtime\common\RuntimeError.m3
0x1faf990   0xa86902  AllocateOpenArray + 0x33 in ..\src\runtime\common\RTAllocator.m3
0x1faf9ec   0xa61ab3  AApply + 0x46 in ..\src\Main.m3
0x1fafa28   0xa8976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
0x1fafa34  0x75c43677  <???>
0x1fafa74  0x77b39f02  <???>
.........  .........  ... more frames ...

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3noincremental
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
.

***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\runtime\common\RTCollector.m3", line 418
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogenerational
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
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
All tests complete.  Congratulations.

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogenerational
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
.

***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\runtime\common\RTCollector.m3", line 418
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***


From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Thursday, March 03, 2011 10:39 AM
To: Coleburn, Randy
Cc: m3devel
Subject: Re: [M3devel] results of threadtest program on Windows7

Both of these errors indicate major breakdown in the garbage collector.
It could be that the damage was done much earlier than the crash.
To check for earlier damage please run with @M3paranoidgc.
Also, you could try running with @M3nogc, or @M3noincremental, or @M3nogenerational, to see if any of them trigger the errors.

On Mar 2, 2011, at 8:36 PM, Coleburn, Randy wrote:


Jay:

Ok, I just updated from HEAD and got your latest change to thread test program.

Here are two invocations, back to back, each failing in different ways.

The second one repeats the last error message ad infinitum until you press CNTRL-C to abort.  But note, several different errors reported earlier.

Regards,
Randy

C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cm3
--- building in NT386 ---

ignoring ..\src\m3overrides

new source -> compiling Main.m3
new "Main.mo" -> linking threadtest.exe

C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cd NT386

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
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


***
*** runtime error:
***    <*ASSERT*> failed..
***    file "..\src\runtime\common\RTCollector.m3", line 1086
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0xddfaf0  0x123dffb  CleanBetween + 0x47 in ..\src\runtime\common\RTCollector.m3
0xddfb34  0x1241870  CheckLoadTracedRef + 0xc5 in ..\src\runtime\common\RTCollector.m3
0xddfb74  0x121683c  Init + 0x95 in ..\src\rw\FileRd.m3
0xddfba0  0x121679d  Open + 0x4d in ..\src\rw\FileRd.m3
0xddfcd8  0x1211288  RApply + 0x78 in ..\src\Main.m3
0xddfd14  0x123976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
0xddfd20  0x76d53677  <???>
0xddfd60  0x773c9f02  <???>
.........  .........  ... more frames ...

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
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
.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0x12ec5ad = Move + 0x50 in ..\src\runtime\common\RTCollector.m3
***



***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***



***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

From: jayk123 at hotmail.com<mailto:jayk123 at hotmail.com> [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Wednesday, March 02, 2011 8:18 PM
To: Coleburn, Randy; m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7

Even with the change I made PutCard to PutInt?
That's the only failure I've seen.
I'll try on a non-virtual dual-proc machine later.

Thanks,
 - Jay

________________________________
From: rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>
To: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7
Yes, it fails more often than it runs for me.
Regards,
Randy

From: jayk123 at hotmail.com<mailto:jayk123 at hotmail.com> [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7

I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu<mailto:mika at async.caltech.edu>
> CC: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> Subject: Re: [M3devel] results of threadtest program on Windows7
>
> Ah, it just doesn't check command-line arguments that carefully.
>
> I think what you did is equivalent to "-tests STD".
>
> Mika
>
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- --------- -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
> >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110303/6613e6a9/attachment.html>

From mika at async.caltech.edu  Thu Mar  3 20:11:52 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Thu, 03 Mar 2011 11:11:52 -0800
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv> 
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>
	<COL101-W4726257303F22627175774E6C30@phx.gbl>
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>
Message-ID: <20110303191152.738111A2078@async.async.caltech.edu>

"Coleburn, Randy" writes:
>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE526EBEatlex02srv_
...
>When using M3nogc, looks like we run out of memory.  The computer I am usin=
>g for these tests is a Dell Latitude 6510 with 4GB RAM and a system-managed=
> pagefile size.

Well some (most) of the tests do allocate memory so perhaps that's not so surprising.

You might try it with -alloc , but creat and fork I'm sure also allocate memory on the
heap.

     Mika


From hosking at cs.purdue.edu  Thu Mar  3 20:19:17 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 3 Mar 2011 14:19:17 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>
	<COL101-W4726257303F22627175774E6C30@phx.gbl>
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>
Message-ID: <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>

Can you try with each of the following?

@M3paranoidgc @M3noincremental @M3nogenerational

@M3paranoidgc @M3noincremental

@M3paranoidgc @M3nogenerational

Also, if possible, can you print the stack dump immediately before the assertion error is printed out?  That means setting a breakpoint on the Raise function that reports assertion failures.  I think it is RTHooks__Raise.  Or perhaps RTHooks__ReportFault.  I don't recall exactly.


On Mar 3, 2011, at 1:47 PM, Coleburn, Randy wrote:

> Tony:
>  
> Here are results using the checks you suggested.  These are running on Windows 7.
> ?         @M3paranoidgc
> ?         @M3nogc
> ?         @M3noincremental
> ?         @M3nogenerational
>  
> As you can see below, the only one where the program ran to completion is when using M3nogenerational; However, this doesn?t mean it solves the problem, because I ran a second time with this option (see below) and it crashed.
>  
> When using M3nogc, looks like we run out of memory.  The computer I am using for these tests is a Dell Latitude 6510 with 4GB RAM and a system-managed pagefile size.
>  
> Hope these test runs give some insight into the problem. 
>  
> Let me know what else I can do to help.
>  
> Regards,
> Randy
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc
> 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
> .
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
> ***    pc = 0xa8f9bc = RefSanityCheck + 0x2c in ..\src\runtime\common\RTCollector.m3
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogc
> 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
> .....
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
> ***    file "..\src\runtime\common\RuntimeError.m3", line 63
> ***
>  
> ***    file "..\src\runtime\common\RuntimeError.m3", line 63
> ***
>  
> ***    file "..\src\runtime\common\RuntimeError.m3", line 63
> ***
>  
> ***    file "..\src\runtime\common\RuntimeError.m3", line 63
> ***
>  
> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0x1faf970   0xaaa7b2  Raise + 0x3f in ..\src\runtime\common\RuntimeError.m3
> 0x1faf990   0xa86902  AllocateOpenArray + 0x33 in ..\src\runtime\common\RTAllocator.m3
> 0x1faf9ec   0xa61ab3  AApply + 0x46 in ..\src\Main.m3
> 0x1fafa28   0xa8976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
> 0x1fafa34  0x75c43677  <???>
> 0x1fafa74  0x77b39f02  <???>
> .........  .........  ... more frames ...
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3noincremental
> 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
> .
>  
> ***
> *** runtime error:
> ***    An array subscript was out of range.
> ***    file "..\src\runtime\common\RTCollector.m3", line 418
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogenerational
> 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
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> All tests complete.  Congratulations.
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogenerational
> 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
> .
>  
> ***
> *** runtime error:
> ***    An array subscript was out of range.
> ***    file "..\src\runtime\common\RTCollector.m3", line 418
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Thursday, March 03, 2011 10:39 AM
> To: Coleburn, Randy
> Cc: m3devel
> Subject: Re: [M3devel] results of threadtest program on Windows7
>  
> Both of these errors indicate major breakdown in the garbage collector.
> It could be that the damage was done much earlier than the crash.
> To check for earlier damage please run with @M3paranoidgc.
> Also, you could try running with @M3nogc, or @M3noincremental, or @M3nogenerational, to see if any of them trigger the errors.
>  
> 
> On Mar 2, 2011, at 8:36 PM, Coleburn, Randy wrote:
> 
> 
> Jay:
>  
> Ok, I just updated from HEAD and got your latest change to thread test program.
>  
> Here are two invocations, back to back, each failing in different ways. 
>  
> The second one repeats the last error message ad infinitum until you press CNTRL-C to abort.  But note, several different errors reported earlier.
>  
> Regards,
> Randy
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cm3
> --- building in NT386 ---
>  
> ignoring ..\src\m3overrides
>  
> new source -> compiling Main.m3
> new "Main.mo" -> linking threadtest.exe
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cd NT386
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> 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
>  
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed..
> ***    file "..\src\runtime\common\RTCollector.m3", line 1086
> ***
>  
> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0xddfaf0  0x123dffb  CleanBetween + 0x47 in ..\src\runtime\common\RTCollector.m3
> 0xddfb34  0x1241870  CheckLoadTracedRef + 0xc5 in ..\src\runtime\common\RTCollector.m3
> 0xddfb74  0x121683c  Init + 0x95 in ..\src\rw\FileRd.m3
> 0xddfba0  0x121679d  Open + 0x4d in ..\src\rw\FileRd.m3
> 0xddfcd8  0x1211288  RApply + 0x78 in ..\src\Main.m3
> 0xddfd14  0x123976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
> 0xddfd20  0x76d53677  <???>
> 0xddfd60  0x773c9f02  <???>
> .........  .........  ... more frames ...
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> 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
> .
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
> ***    pc = 0x12ec5ad = Move + 0x50 in ..\src\runtime\common\RTCollector.m3
> ***
>  
>  
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
>  
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Wednesday, March 02, 2011 8:18 PM
> To: Coleburn, Randy; m3devel
> Subject: RE: [M3devel] results of threadtest program on Windows7
>  
> Even with the change I made PutCard to PutInt?
> That's the only failure I've seen.
> I'll try on a non-virtual dual-proc machine later.
>  
> Thanks,
>  - Jay
>  
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Wed, 2 Mar 2011 19:42:47 -0500
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Yes, it fails more often than it runs for me.
> Regards,
> Randy
>  
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Tuesday, March 01, 2011 5:59 AM
> To: Mika Nystrom; Coleburn, Randy
> Cc: m3devel
> Subject: RE: [M3devel] results of threadtest program on Windows7
>  
> I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
> I've run it just a few times now. One single and dual processor virtual machines.
> Randy, has it failed many times for you?
> 
>  - Jay
> 
> > To: rcolebur at SCIRES.COM
> > Date: Sun, 27 Feb 2011 15:11:25 -0800
> > From: mika at async.caltech.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] results of threadtest program on Windows7
> > 
> > Ah, it just doesn't check command-line arguments that carefully.
> > 
> > I think what you did is equivalent to "-tests STD".
> > 
> > Mika
> > 
> > "Coleburn, Randy" writes:
> > >Mika:
> > >
> > >No change with "-tests POSIX".
> > >
> > >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> > >ptions are, and I typed "threadtest -help" rather than reading the code.
> > >
> > >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> > >d it again and it ran to completion. Something seems non-deterministic her=
> > >e. See below.
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >.
> > >
> > >***
> > >*** runtime error:
> > >*** Attempt to reference an illegal memory location.
> > >*** pc =3D 0x77762262
> > >***
> > >
> > >Stack trace:
> > > FP PC Procedure
> > >--------- --------- -------------------------------
> > > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> > >3
> > > 0xcdf9c0 0x77762262 <???>
> > > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> > >3
> > > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> > >.m3
> > > 0xcdfb80 0x76543677 <???>
> > > 0xcdfbc0 0x77779f02 <???>
> > >......... ......... ... more frames ...
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >All tests complete. Congratulations.
> > >
> > >Regards,
> > >Randy Coleburn
> > >
> > >-----Original Message-----
> > >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> > >Sent: Sunday, February 27, 2011 3:30 PM
> > >To: Coleburn, Randy
> > >Cc: m3devel at elegosoft.com
> > >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> > >
> > >Hi Randy,
> > >
> > >You can try it with -tests POSIX as well.
> > >
> > >I find on user threads it runs very slowly (but it does run) because of how=
> > > unfair
> > >the thread scheduler is.
> > >
> > >Next step might be to whittle down the tests and see if you can get a failu=
> > >re with
> > >a single test running and -n 2. That would likely be the simplest scenario=
> > > to
> > >start further debugging from.
> > >
> > > Mika
> > >
> > >"Coleburn, Randy" writes:
> > >>Mika et al:
> > >>
> > >>Thought I would try something else.
> > >>
> > >>I took the sources of your thread test program to an older XP machine that=
> > > =3D
> > >>has CM3 circa August 2008. This is the machine and implementation I used =
> > >w=3D
> > >>hen building a major project I did a couple years back.
> > >>
> > >>The thread test program does indeed build on this old system, but when I r=
> > >u=3D
> > >>n it, I get different results than with the latest HEAD branch code. =3D20
> > >>
> > >>After it prints "running...printing oldest/median age/newest", on the next=
> > > =3D
> > >>line I get two periods ".." and now the program seems hung. I'll let it "=
> > >r=3D
> > >>un" for a few more minutes to see if anything else happens before killing =
> > >i=3D
> > >>t.
> > >>
> > >>At least we don't get the subscript and assertion failures on this older C=
> > >M=3D
> > >>3 platform.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>
> > >>-----Original Message-----
> > >>From: Coleburn, Randy=3D20
> > >>Sent: Sunday, February 27, 2011 2:09 PM
> > >>To: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7
> > >>
> > >>Mika:
> > >>
> > >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> > >>
> > >>Here is what happens now when I run your threadtest program on Windows 7.
> > >>
> > >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> > >r=3D
> > >>k
> > >>Writing file...done
> > >>Creating read threads...done
> > >>Creating nxread threads...done
> > >>Creating tryexcept threads...done
> > >>Creating forktoomuch threads...done
> > >>Creating alloc threads...done
> > >>Creating creat threads...done
> > >>Creating lock threads...done
> > >>running...printing oldest/median age/newest
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** An array subscript was out of range.
> > >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> > >>***
> > >>
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** <*ASSERT*> failed.
> > >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> > >>***
> > >>
> > >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> > >>
> > >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> > >.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>-----Original Message-----
> > >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> > >>Sent: Saturday, February 26, 2011 12:55 PM
> > >>To: Coleburn, Randy
> > >>Cc: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> > >>
> > >>Hi Randy,
> > >>
> > >>Hm yes it looks like my Windows programming skills leave something
> > >>to be desired.
> > >>
> > >>You can run the thread tester while skipping a test as follows
> > >>
> > >> threadtest -tests ALL,-fork
> > >>
> > >>(for instance)
> > >>
> > >>if you just run=3D20
> > >>
> > >> threadtest -sadfassdaf
> > >>
> > >>it'll print the tests that are available.
> > >>
> > >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> > >>Can you give me a very brief description of what you did to install Modula=
> > >-=3D
> > >>3
> > >>on this system?
> > >>
> > >> Mika
> > >>
> > >>"Coleburn, Randy" writes:
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>
> > >>>Mika:
> > >>>
> > >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> > >>>
> > >>>So, I ran your threadtest program.
> > >>>
> > >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> > >e=3D
> > >>p=3D3D
> > >>>eating "ERROR FApply" messages.
> > >>>
> > >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > >>>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
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>***
> > >>>*** runtime error:
> > >>>*** An enumeration or subrange value was out of range.
> > >>>*** file "..\src\Main.m3", line 340
> > >>>***
> > >>>
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>Stack trace:
> > >>> FP PC Procedure
> > >>>--------- --------- -------------------------------
> > >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> > >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> > >>>
> > >>>Regards,
> > >>>Randy Coleburn
> > >>>
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/html; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110303/5d0b2362/attachment.html>

From hendrik at topoi.pooq.com  Fri Mar  4 17:19:14 2011
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Fri, 4 Mar 2011 11:19:14 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <571065.83147.qm@web29715.mail.ird.yahoo.com>
References: <COL101-W3670B74A99994199607C6BE6C00@phx.gbl>
	<571065.83147.qm@web29715.mail.ird.yahoo.com>
Message-ID: <20110304161914.GC8263@topoi.pooq.com>

On Wed, Mar 02, 2011 at 09:31:41PM +0000, Daniel Alejandro Benavides D. wrote:
> Hi all:
> yes, but technically you could insert some empty chips slots on the same wafer but in cases of blade systems I'm sure you can, just don't know how much about something like plug-and-play with that.
> Thanks in advance
> 
> --- El mar, 1/3/11, Jay K <jay.krell at cornell.edu> escribi?:
> 
> De: Jay K <jay.krell at cornell.edu>
> Asunto: RE: [M3devel] results of threadtest program on Windows7
> Para: dabenavidesd at yahoo.es, "Mika Nystrom" <mika at async.caltech.edu>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: martes, 1 de marzo, 2011 22:11
> 
> 
> 
> 
> I have still have mostly uniprocessors (though busy selling stuff off...)
> 
> ? I do have a MacBook Pro and Dell laptop with 2 processors each though.
> 
> ? It is that MacBook Pro where I can consistently get Darwin to fail, and a?1 and 2 proc Windows virtual machine on the MacBook Pro?that consistently works.
> 
> ? While Modula-3 user threads never run anything truly 
>   concurrently, i.e. on multiple prcoessors, there should 
>   still be almost arbitrary preemption.

But you won't get parallel execution of instructions: 
user threads can at most switch threads between instructions.  
With two actual processors, it's possible to get races within 
the execution of a single instruction on each processor.

-- hendrik


From rcolebur at SCIRES.COM  Sat Mar  5 04:07:39 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 4 Mar 2011 22:07:39 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>
	<COL101-W4726257303F22627175774E6C30@phx.gbl>
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>
	<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>

Tony:

I do not have a debugger built for Windows, so I can't do the breakpoint yet.  I'll check into trying to build the debugger, but last time I tried this (a few years ago) it didn't work.  I used m3gdb on HPUX long time ago, but nothing for Windows.

Here are test results you requested (you will see I ran each of them twice, getting different results each time).

The very last test run resulted in another stack dump.

Regards,
Randy

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3noincremental @M3nogenerational
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
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
All tests complete.  Congratulations.

Although it ran to completion the first try, I ran again and it crashes, see below:

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3noincremental @M3nogenerational
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
.

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\runtime\common\RTCollector.m3", line 1709
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3noincremental
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
.

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0x12bf9bc = RefSanityCheck + 0x2c in ..\src\runtime\common\RTCollector.m3
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

Running this one a second time, I get these results:

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3noincremental
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
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
All tests complete.  Congratulations.

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3nogenerational
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
.

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0x12bf9bc = RefSanityCheck + 0x2c in ..\src\runtime\common\RTCollector.m3
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

Running a second time, I get these results:

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3nogenerational
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
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........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:
***    An array subscript was out of range.
***    file "..\src\rw\FileRd.m3", line 83
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0xadf764  0x1296ee8  Seek + 0x454 in ..\src\rw\FileRd.m3
0xadf78c  0x1297d84  DoSeek + 0x80 in ..\src\rw\Rd.m3
0xadf7b0  0x1297bf0  FastGetChar + 0x57 in ..\src\rw\Rd.m3
0xadf7d8  0x1297b58  GetChar + 0x48 in ..\src\rw\Rd.m3
0xadf910  0x12912e3  RApply + 0xd3 in ..\src\Main.m3
0xadf94c  0x12b976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
0xadf958  0x74f03677  <???>
0xadf998  0x77009f02  <???>
.........  .........  ... more frames ...

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Thursday, March 03, 2011 2:19 PM
To: Coleburn, Randy
Cc: m3devel
Subject: Re: [M3devel] results of threadtest program on Windows7

Can you try with each of the following?

@M3paranoidgc @M3noincremental @M3nogenerational

@M3paranoidgc @M3noincremental

@M3paranoidgc @M3nogenerational

Also, if possible, can you print the stack dump immediately before the assertion error is printed out?  That means setting a breakpoint on the Raise function that reports assertion failures.  I think it is RTHooks__Raise.  Or perhaps RTHooks__ReportFault.  I don't recall exactly.


On Mar 3, 2011, at 1:47 PM, Coleburn, Randy wrote:


Tony:

Here are results using the checks you suggested.  These are running on Windows 7.
*         @M3paranoidgc
*         @M3nogc
*         @M3noincremental
*         @M3nogenerational

As you can see below, the only one where the program ran to completion is when using M3nogenerational; However, this doesn't mean it solves the problem, because I ran a second time with this option (see below) and it crashed.

When using M3nogc, looks like we run out of memory.  The computer I am using for these tests is a Dell Latitude 6510 with 4GB RAM and a system-managed pagefile size.

Hope these test runs give some insight into the problem.

Let me know what else I can do to help.

Regards,
Randy

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc
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
.

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0xa8f9bc = RefSanityCheck + 0x2c in ..\src\runtime\common\RTCollector.m3
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogc
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
.....

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.
***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x1faf970   0xaaa7b2  Raise + 0x3f in ..\src\runtime\common\RuntimeError.m3
0x1faf990   0xa86902  AllocateOpenArray + 0x33 in ..\src\runtime\common\RTAllocator.m3
0x1faf9ec   0xa61ab3  AApply + 0x46 in ..\src\Main.m3
0x1fafa28   0xa8976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
0x1fafa34  0x75c43677  <???>
0x1fafa74  0x77b39f02  <???>
.........  .........  ... more frames ...

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3noincremental
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
.

***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\runtime\common\RTCollector.m3", line 418
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogenerational
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
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
All tests complete.  Congratulations.

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogenerational
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
.

***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\runtime\common\RTCollector.m3", line 418
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***


From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Thursday, March 03, 2011 10:39 AM
To: Coleburn, Randy
Cc: m3devel
Subject: Re: [M3devel] results of threadtest program on Windows7

Both of these errors indicate major breakdown in the garbage collector.
It could be that the damage was done much earlier than the crash.
To check for earlier damage please run with @M3paranoidgc.
Also, you could try running with @M3nogc, or @M3noincremental, or @M3nogenerational, to see if any of them trigger the errors.

On Mar 2, 2011, at 8:36 PM, Coleburn, Randy wrote:



Jay:

Ok, I just updated from HEAD and got your latest change to thread test program.

Here are two invocations, back to back, each failing in different ways.

The second one repeats the last error message ad infinitum until you press CNTRL-C to abort.  But note, several different errors reported earlier.

Regards,
Randy

C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cm3
--- building in NT386 ---

ignoring ..\src\m3overrides

new source -> compiling Main.m3
new "Main.mo" -> linking threadtest.exe

C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cd NT386

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
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


***
*** runtime error:
***    <*ASSERT*> failed..
***    file "..\src\runtime\common\RTCollector.m3", line 1086
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0xddfaf0  0x123dffb  CleanBetween + 0x47 in ..\src\runtime\common\RTCollector.m3
0xddfb34  0x1241870  CheckLoadTracedRef + 0xc5 in ..\src\runtime\common\RTCollector.m3
0xddfb74  0x121683c  Init + 0x95 in ..\src\rw\FileRd.m3
0xddfba0  0x121679d  Open + 0x4d in ..\src\rw\FileRd.m3
0xddfcd8  0x1211288  RApply + 0x78 in ..\src\Main.m3
0xddfd14  0x123976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
0xddfd20  0x76d53677  <???>
0xddfd60  0x773c9f02  <???>
.........  .........  ... more frames ...

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
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
.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0x12ec5ad = Move + 0x50 in ..\src\runtime\common\RTCollector.m3
***



***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***



***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

From: jayk123 at hotmail.com<mailto:jayk123 at hotmail.com> [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Wednesday, March 02, 2011 8:18 PM
To: Coleburn, Randy; m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7

Even with the change I made PutCard to PutInt?
That's the only failure I've seen.
I'll try on a non-virtual dual-proc machine later.

Thanks,
 - Jay

________________________________
From: rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>
To: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7
Yes, it fails more often than it runs for me.
Regards,
Randy

From: jayk123 at hotmail.com<mailto:jayk123 at hotmail.com> [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7

I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu<mailto:mika at async.caltech.edu>
> CC: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> Subject: Re: [M3devel] results of threadtest program on Windows7
>
> Ah, it just doesn't check command-line arguments that carefully.
>
> I think what you did is equivalent to "-tests STD".
>
> Mika
>
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- --------- -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
> >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110304/40ce9634/attachment.html>

From jay.krell at cornell.edu  Sat Mar  5 06:37:47 2011
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 5 Mar 2011 05:37:47 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>,
	,,<20110226175511.3F7D21A2078@async.async.caltech.edu>,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>,
	,,<20110227202950.46F3B1A2078@async.async.caltech.edu>,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>,
	, , <20110227231125.3DC611A2078@async.async.caltech.edu>, ,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>,
	<COL101-W4726257303F22627175774E6C30@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>,
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>,
	<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>
Message-ID: <COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>

Microsoft debuggers are freely downloadable. 

 Jay/phone

From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Fri, 4 Mar 2011 22:07:39 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7



Tony: I do not have a debugger built for Windows, so I can?t do the breakpoint yet.  I?ll check into trying to build the debugger, but last time I tried this (a few years ago) it didn?t work.  I used m3gdb on HPUX long time ago, but nothing for Windows. Here are test results you requested (you will see I ran each of them twice, getting different results each time).   The very last test run resulted in another stack dump. Regards,Randy C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3noincremental @M3nogenerationalWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)All tests complete.  Congratulations. Although it ran to completion the first try, I ran again and it crashes, see below: C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3noincremental @M3nogenerationalWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest. ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\runtime\common\RTCollector.m3", line 1709*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3noincrementalWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest. ****** runtime error:***    Attempt to reference an illegal memory location.***    pc = 0x12bf9bc = RefSanityCheck + 0x2c in ..\src\runtime\common\RTCollector.m3*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** Running this one a second time, I get these results: C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3noincrementalWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)All tests complete.  Congratulations. C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3nogenerationalWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest. ****** runtime error:***    Attempt to reference an illegal memory location.***    pc = 0x12bf9bc = RefSanityCheck + 0x2c in ..\src\runtime\common\RTCollector.m3*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** Running a second time, I get these results: C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3nogenerationalWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........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:***    An array subscript was out of range.***    file "..\src\rw\FileRd.m3", line 83*** Stack trace:   FP         PC      Procedure---------  ---------  ------------------------------- 0xadf764  0x1296ee8  Seek + 0x454 in ..\src\rw\FileRd.m3 0xadf78c  0x1297d84  DoSeek + 0x80 in ..\src\rw\Rd.m3 0xadf7b0  0x1297bf0  FastGetChar + 0x57 in ..\src\rw\Rd.m3 0xadf7d8  0x1297b58  GetChar + 0x48 in ..\src\rw\Rd.m3 0xadf910  0x12912e3  RApply + 0xd3 in ..\src\Main.m3 0xadf94c  0x12b976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3 0xadf958  0x74f03677  <???> 0xadf998  0x77009f02  <???>.........  .........  ... more frames ... From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
Sent: Thursday, March 03, 2011 2:19 PM
To: Coleburn, Randy
Cc: m3devel
Subject: Re: [M3devel] results of threadtest program on Windows7 Can you try with each of the following? @M3paranoidgc @M3noincremental @M3nogenerational @M3paranoidgc @M3noincremental @M3paranoidgc @M3nogenerational Also, if possible, can you print the stack dump immediately before the assertion error is printed out?  That means setting a breakpoint on the Raise function that reports assertion failures.  I think it is RTHooks__Raise.  Or perhaps RTHooks__ReportFault.  I don't recall exactly.  On Mar 3, 2011, at 1:47 PM, Coleburn, Randy wrote:

Tony: Here are results using the checks you suggested.  These are running on Windows 7.?         @M3paranoidgc?         @M3nogc?         @M3noincremental?         @M3nogenerational As you can see below, the only one where the program ran to completion is when using M3nogenerational; However, this doesn?t mean it solves the problem, because I ran a second time with this option (see below) and it crashed. When using M3nogc, looks like we run out of memory.  The computer I am using for these tests is a Dell Latitude 6510 with 4GB RAM and a system-managed pagefile size. Hope these test runs give some insight into the problem.  Let me know what else I can do to help. Regards,Randy C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgcWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest. ****** runtime error:***    Attempt to reference an illegal memory location.***    pc = 0xa8f9bc = RefSanityCheck + 0x2c in ..\src\runtime\common\RTCollector.m3*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogcWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest..... ****** runtime error:***    NEW() was unable to allocate more memory. ****** runtime error:***    NEW() was unable to allocate more memory. ****** runtime error:***    NEW() was unable to allocate more memory. ****** runtime error:***    NEW() was unable to allocate more memory. ****** runtime error:***    NEW() was unable to allocate more memory. ****** runtime error:***    NEW() was unable to allocate more memory. ****** runtime error:***    NEW() was unable to allocate more memory. ****** runtime error:***    NEW() was unable to allocate more memory. ****** runtime error:***    NEW() was unable to allocate more memory. ****** runtime error:***    NEW() was unable to allocate more memory.***    file "..\src\runtime\common\RuntimeError.m3", line 63*** ***    file "..\src\runtime\common\RuntimeError.m3", line 63*** ***    file "..\src\runtime\common\RuntimeError.m3", line 63*** ***    file "..\src\runtime\common\RuntimeError.m3", line 63*** Stack trace:   FP         PC      Procedure---------  ---------  -------------------------------0x1faf970   0xaaa7b2  Raise + 0x3f in ..\src\runtime\common\RuntimeError.m30x1faf990   0xa86902  AllocateOpenArray + 0x33 in ..\src\runtime\common\RTAllocator.m30x1faf9ec   0xa61ab3  AApply + 0x46 in ..\src\Main.m30x1fafa28   0xa8976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m30x1fafa34  0x75c43677  <???>0x1fafa74  0x77b39f02  <???>.........  .........  ... more frames ... C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3noincrementalWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest. ****** runtime error:***    An array subscript was out of range.***    file "..\src\runtime\common\RTCollector.m3", line 418*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogenerationalWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)All tests complete.  Congratulations. C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogenerationalWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest. ****** runtime error:***    An array subscript was out of range.***    file "..\src\runtime\common\RTCollector.m3", line 418*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841***  From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
Sent: Thursday, March 03, 2011 10:39 AM
To: Coleburn, Randy
Cc: m3devel
Subject: Re: [M3devel] results of threadtest program on Windows7 Both of these errors indicate major breakdown in the garbage collector.It could be that the damage was done much earlier than the crash.To check for earlier damage please run with @M3paranoidgc.Also, you could try running with @M3nogc, or @M3noincremental, or @M3nogenerational, to see if any of them trigger the errors. On Mar 2, 2011, at 8:36 PM, Coleburn, Randy wrote:


Jay: Ok, I just updated from HEAD and got your latest change to thread test program. Here are two invocations, back to back, each failing in different ways.  The second one repeats the last error message ad infinitum until you press CNTRL-C to abort.  But note, several different errors reported earlier. Regards,Randy C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cm3--- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling Main.m3new "Main.mo" -> linking threadtest.exe C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cd NT386 C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exeWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest  ****** runtime error:***    <*ASSERT*> failed..***    file "..\src\runtime\common\RTCollector.m3", line 1086*** Stack trace:   FP         PC      Procedure---------  ---------  -------------------------------0xddfaf0  0x123dffb  CleanBetween + 0x47 in ..\src\runtime\common\RTCollector.m30xddfb34  0x1241870  CheckLoadTracedRef + 0xc5 in ..\src\runtime\common\RTCollector.m30xddfb74  0x121683c  Init + 0x95 in ..\src\rw\FileRd.m30xddfba0  0x121679d  Open + 0x4d in ..\src\rw\FileRd.m30xddfcd8  0x1211288  RApply + 0x78 in ..\src\Main.m30xddfd14  0x123976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m30xddfd20  0x76d53677  <???>0xddfd60  0x773c9f02  <???>.........  .........  ... more frames ... C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exeWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest. ****** runtime error:***    Attempt to reference an illegal memory location. ****** runtime error:***    Attempt to reference an illegal memory location. ****** runtime error:***    Attempt to reference an illegal memory location.***    pc = 0x12ec5ad = Move + 0x50 in ..\src\runtime\common\RTCollector.m3***   ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841***   ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Wednesday, March 02, 2011 8:18 PM
To: Coleburn, Randy; m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7 Even with the change I made PutCard to PutInt?
That's the only failure I've seen.
I'll try on a non-virtual dual-proc machine later.
 
Thanks,
 - Jay
 From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7Yes, it fails more often than it runs for me.Regards,Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7 I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Ah, it just doesn't check command-line arguments that carefully.
> 
> I think what you did is equivalent to "-tests STD".
> 
> Mika
> 
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- --------- -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
> >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110305/259e7726/attachment.html>

From mika at async.caltech.edu  Sat Mar  5 19:05:58 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Sat, 05 Mar 2011 10:05:58 -0800
Subject: [M3devel] m3gdb broken
Message-ID: <20110305180558.451421A2078@async.async.caltech.edu>

Hi m3devel,

I don't know what's happened here.  m3gdb used to work, and work fairly
well (never perfectly, but...).  Now I'm trying to debug a program and
I get the following:

(m3gdb) break Main.m3:65
Debug info for file "Main.mc" not in stabs format
(m3gdb) 

The system/architecture is AMD64_FREEBSD but I've seen this problem on other
systems too.

Everything is from the CVS head.

Main was compiled as follows, says cm3 -commands:

gcc -gstabs+ -m64 -fPIC -z origin -Wl,--warn-common -Wl,-rpath,\$ORIGIN -Wl,-rpath,\$ORIGIN/../lib  -Wl,--fatal-warnings -z now -Bsymbolic -L/usr/local/lib -o sstubgen  _m3main.o Main.mo /home/mika/t/mscheme/sstubgen/AMD64_FREEBSD/libsstubgen.a /home/mika/t/mscheme/schemereadline/AMD64_FREEBSD/libschemereadline.a /home/mika/t/mscheme/schemesig/AMD64_FREEBSD/libschemesig.a /home/mika/t/calarm/m3readline/AMD64_FREEBSD/libm3readline.a /home/mika/t/calarm/sx/AMD64_FREEBSD/libsx.a /home/mika/t/mscheme/modula3scheme/AMD64_FREEBSD/libmodula3scheme.a /home/mika/t/rdwr/AMD64_FREEBSD/librdwr.a /home/mika/t/mscheme/AMD64_FREEBSD/libmscheme.a /home/mika/t/cit_util/AMD64_FREEBSD/libcit_util.a /usr/local/cm3/pkg/netobj/AMD64_FREEBSD/libm3netobj.a /usr/local/cm3/pkg/tcp/AMD64_FREEBSD/libm3tcp.a /usr/local/cm3/pkg/patternmatching/AMD64_FREEBSD/libpatternmatching.a /home/mika/t/mscheme/scheme-lib/AMD64_FREEBSD/libscheme-lib.a /usr/local/cm3/pkg/libbuf/AMD64_FREEBSD/liblibbuf.a /home/mika/t/ci
 t_common/AMD64_FREEBSD/libcit_common.a /usr/local/cm3/pkg/set/AMD64_FREEBSD/libset.a /home/mika/t/rdwrreset/AMD64_FREEBSD/librdwrreset.a /usr/local/cm3/pkg/m3tk/AMD64_FREEBSD/libm3tk.a /usr/local/cm3/pkg/m3tk-misc/AMD64_FREEBSD/libm3tk-misc.a /usr/local/cm3/pkg/libm3/AMD64_FREEBSD/libm3.a /usr/local/cm3/pkg/m3core/AMD64_FREEBSD/libm3core.a -lm -lcrypt -lssl -L/usr/local/lib -lintl -lreadline

I'm not even sure where to begin looking.  Is it a configuration issue,
something broken in the compiler, or what?

I fear m3gdb is essentially useless at the moment.

     Mika


From mika at async.caltech.edu  Sat Mar  5 21:06:30 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Sat, 05 Mar 2011 12:06:30 -0800
Subject: [M3devel] MODULEs in .M3IMPTAB
Message-ID: <20110305200630.F26711A2078@async.async.caltech.edu>

Hi again m3devel,

Can anyone think of a reason that cm3 should *not* emit information
about MODULEs that it compiles to .M3IMPTAB?  (It doesn't, today,
which means that m3tk-based tools can't find implementations, only
interfaces.)

    Mika


From hosking at cs.purdue.edu  Sat Mar  5 23:43:35 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 5 Mar 2011 17:43:35 -0500
Subject: [M3devel] MODULEs in .M3IMPTAB
In-Reply-To: <20110305200630.F26711A2078@async.async.caltech.edu>
References: <20110305200630.F26711A2078@async.async.caltech.edu>
Message-ID: <F14FF404-B88C-4C46-B433-744E45311209@cs.purdue.edu>

It used to work... :-(

On Mar 5, 2011, at 3:06 PM, Mika Nystrom wrote:

> Hi again m3devel,
> 
> Can anyone think of a reason that cm3 should *not* emit information
> about MODULEs that it compiles to .M3IMPTAB?  (It doesn't, today,
> which means that m3tk-based tools can't find implementations, only
> interfaces.)
> 
>    Mika



From mika at async.caltech.edu  Sat Mar  5 23:53:51 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Sat, 05 Mar 2011 14:53:51 -0800
Subject: [M3devel] MODULEs in .M3IMPTAB
In-Reply-To: <F14FF404-B88C-4C46-B433-744E45311209@cs.purdue.edu> 
References: <20110305200630.F26711A2078@async.async.caltech.edu>
	<F14FF404-B88C-4C46-B433-744E45311209@cs.purdue.edu>
Message-ID: <20110305225351.2A2AD1A2078@async.async.caltech.edu>


Tony, are you sure?  There don't seem to be any tools in CM3 that process
implementations with m3tk, or have I been looking in the wrong places?
stubgen doesn't, I don't think stablegen does, and m3pp and m3tohtml
don't even use m3tk.  Also it doesn't seem to work on PM3-1.13.2.  Hmmmmm....

     Mika

Tony Hosking writes:
>It used to work... :-(
>
>On Mar 5, 2011, at 3:06 PM, Mika Nystrom wrote:
>
>> Hi again m3devel,
>> 
>> Can anyone think of a reason that cm3 should *not* emit information
>> about MODULEs that it compiles to .M3IMPTAB?  (It doesn't, today,
>> which means that m3tk-based tools can't find implementations, only
>> interfaces.)
>> 
>>    Mika


From rcolebur at SCIRES.COM  Sun Mar  6 02:35:41 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Sat, 5 Mar 2011 20:35:41 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>,
	,,<20110226175511.3F7D21A2078@async.async.caltech.edu>,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>,
	,,<20110227202950.46F3B1A2078@async.async.caltech.edu>,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>,
	, , <20110227231125.3DC611A2078@async.async.caltech.edu>, ,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>,
	<COL101-W4726257303F22627175774E6C30@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>,
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>,
	<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>
	<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>

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/20110305/c882dbac/attachment.html>

From rodney_bates at lcwb.coop  Sun Mar  6 03:30:29 2011
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 05 Mar 2011 20:30:29 -0600
Subject: [M3devel] m3gdb broken
In-Reply-To: <20110305180558.451421A2078@async.async.caltech.edu>
References: <20110305180558.451421A2078@async.async.caltech.edu>
Message-ID: <4D72F1C5.2020504@lcwb.coop>



On 03/05/2011 12:05 PM, Mika Nystrom wrote:
> Hi m3devel,
>
> I don't know what's happened here.  m3gdb used to work, and work fairly
> well (never perfectly, but...).  Now I'm trying to debug a program and
> I get the following:
>
> (m3gdb) break Main.m3:65
> Debug info for file "Main.mc" not in stabs format

This message looks vaguely familiar to me, but I'm not recalling just yet.

> (m3gdb)
>
> The system/architecture is AMD64_FREEBSD but I've seen this problem on other
> systems too.
>
> Everything is from the CVS head.
>
> Main was compiled as follows, says cm3 -commands:
>
> gcc -gstabs+ -m64 -fPIC -z origin -Wl,--warn-common -Wl,-rpath,\$ORIGIN -Wl,-rpath,\$ORIGIN/../lib  -Wl,--fatal-warnings -z now -Bsymbolic -L/usr/local/lib -o sstubgen  _m3main.o Main.mo /home/mika/t/mscheme/sstubgen/AMD64_FREEBSD/libsstubgen.a /home/mika/t/mscheme/schemereadline/AMD64_FREEBSD/libschemereadline.a /home/mika/t/mscheme/schemesig/AMD64_FREEBSD/libschemesig.a /home/mika/t/calarm/m3readline/AMD64_FREEBSD/libm3readline.a /home/mika/t/calarm/sx/AMD64_FREEBSD/libsx.a /home/mika/t/mscheme/modula3scheme/AMD64_FREEBSD/libmodula3scheme.a /home/mika/t/rdwr/AMD64_FREEBSD/librdwr.a /home/mika/t/mscheme/AMD64_FREEBSD/libmscheme.a /home/mika/t/cit_util/AMD64_FREEBSD/libcit_util.a /usr/local/cm3/pkg/netobj/AMD64_FREEBSD/libm3netobj.a /usr/local/cm3/pkg/tcp/AMD64_FREEBSD/libm3tcp.a /usr/local/cm3/pkg/patternmatching/AMD64_FREEBSD/libpatternmatching.a /home/mika/t/mscheme/scheme-lib/AMD64_FREEBSD/libscheme-lib.a /usr/local/cm3/pkg/libbuf/AMD64_FREEBSD/liblibbuf.a /home/mika/t/
ci
>   t_common/AMD64_FREEBSD/libcit_common.a /usr/local/cm3/pkg/set/AMD64_FREEBSD/libset.a /home/mika/t/rdwrreset/AMD64_FREEBSD/librdwrreset.a /usr/local/cm3/pkg/m3tk/AMD64_FREEBSD/libm3tk.a /usr/local/cm3/pkg/m3tk-misc/AMD64_FREEBSD/libm3tk-misc.a /usr/local/cm3/pkg/libm3/AMD64_FREEBSD/libm3.a /usr/local/cm3/pkg/m3core/AMD64_FREEBSD/libm3core.a -lm -lcrypt -lssl -L/usr/local/lib -lintl -lreadline
>

This looks like the gcc command for the link step.  Everything it gets is either .o or .a.,
and it invokes gcc, not cm3cg.

I think the problem might lie in the compile step for Main, which would be giving
Main.mc as the input file name.  Its -g option could be the culprit. It should
look something like:

/usr/local/cm3//bin/cm3cg -gstabs+ -m64 -fPIC -mno-align-double -funwind-tables -quiet -fno-reorder-blocks Main.mc -o Main.ms



> I'm not even sure where to begin looking.  Is it a configuration issue,
> something broken in the compiler, or what?
>
> I fear m3gdb is essentially useless at the moment.
>
>       Mika
>

Rodney Bates


From mika at async.caltech.edu  Sun Mar  6 03:37:49 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Sat, 05 Mar 2011 18:37:49 -0800
Subject: [M3devel] m3gdb broken
In-Reply-To: <4D72F1C5.2020504@lcwb.coop> 
References: <20110305180558.451421A2078@async.async.caltech.edu>
	<4D72F1C5.2020504@lcwb.coop>
Message-ID: <20110306023749.88D321A2078@async.async.caltech.edu>

"Rodney M. Bates" writes:
...
>> Debug info for file "Main.mc" not in stabs format
>
>This message looks vaguely familiar to me, but I'm not recalling just yet.
>
>> (m3gdb)
>>
>> The system/architecture is AMD64_FREEBSD but I've seen this problem on other
...
>> Everything is from the CVS head.
>>
>> Main was compiled as follows, says cm3 -commands:
>>
>> gcc -gstabs+ -m64 -fPIC -z origin -Wl,--warn-common -Wl,-rpath,\$ORIGIN -Wl,-rpath,\$ORIGIN/../lib  -Wl,--fatal-warnings -z now -Bsymbolic -
>L/usr/local/lib -o sstubgen  _m3main.o Main.mo /home/mika/t/mscheme/sstubgen/AMD64_FREEBSD/libsstubgen.a /home/mika/t/mscheme/schemereadline/A
>MD64_FREEBSD/libschemereadline.a /home/mika/t/mscheme/schemesig/AMD64_FREEBSD/libschemesig.a /home/mika/t/calarm/m3readline/AMD64_FREEBSD/libm
>3readline.a /home/mika/t/calarm/sx/AMD64_FREEBSD/libsx.a /home/mika/t/mscheme/modula3scheme/AMD64_FREEBSD/libmodula3scheme.a /home/mika/t/rdwr
>/AMD64_FREEBSD/librdwr.a /home/mika/t/mscheme/AMD64_FREEBSD/libmscheme.a /home/mika/t/cit_util/AMD64_FREEBSD/libcit_util.a /usr/local/cm3/pkg/
>netobj/AMD64_FREEBSD/libm3netobj.a /usr/local/cm3/pkg/tcp/AMD64_FREEBSD/libm3tcp.a /usr/local/cm3/pkg/patternmatching/AMD64_FREEBSD/libpattern
>matching.a /home/mika/t/mscheme/scheme-lib/AMD64_FREEBSD/libscheme-lib.a /usr/local/cm3/pkg/libbuf/AMD64_FREEBSD/liblibbuf.a /home/mika/t/
>ci
>>   t_common/AMD64_FREEBSD/libcit_common.a /usr/local/cm3/pkg/set/AMD64_FREEBSD/libset.a /home/mika/t/rdwrreset/AMD64_FREEBSD/librdwrreset.a /
>usr/local/cm3/pkg/m3tk/AMD64_FREEBSD/libm3tk.a /usr/local/cm3/pkg/m3tk-misc/AMD64_FREEBSD/libm3tk-misc.a /usr/local/cm3/pkg/libm3/AMD64_FREEBS
>D/libm3.a /usr/local/cm3/pkg/m3core/AMD64_FREEBSD/libm3core.a -lm -lcrypt -lssl -L/usr/local/lib -lintl -lreadline
>>
>
>This looks like the gcc command for the link step.  Everything it gets is either .o or .a.,
>and it invokes gcc, not cm3cg.
>
>I think the problem might lie in the compile step for Main, which would be giving
>Main.mc as the input file name.  Its -g option could be the culprit. It should
>look something like:
>
>/usr/local/cm3//bin/cm3cg -gstabs+ -m64 -fPIC -mno-align-double -funwind-tables -quiet -fno-reorder-blocks Main.mc -o Main.ms
>

Sorry, I wasn't thinking.  But my cm3cg is also configured right, I think:

(236)ginger:~/t/mscheme/sstubgen/program/src>cm3 -x -commands | & grep Main
new source -> compiling Main.m3
m3front ../src/Main.m3 -w1
/usr/local/cm3//bin/cm3cg -mno-align-double -quiet -fno-reorder-blocks -funwind-tables -fPIC   -m64 -gstabs+ Main.mc -o Main.ms
as -64 Main.ms -o Main.mo
/usr/local/cm3//bin/cm3cg -mno-align-double -quiet -fno-reorder-blocks -funwind-tables -fPIC   -m64 -gstabs+ Main.mc -o Main.ms
as -64 Main.ms -o Main.mo
rm Main.mc
rm Main.ms
gcc -gstabs+ -m64 -fPIC -z origin -Wl,--warn-common -Wl,-rpath,\$ORIGIN -Wl,-rpath,\$ORIGIN/../lib  -Wl,--fatal-warnings -z now -Bsymbolic -L/usr/local/lib -o sstubgen  _m3main.o Main.mo /home/mika/t/mscheme/sstubgen/AMD64_FREEBSD/libsstubgen.a /home/mika/t/mscheme/schemereadline/AMD64_FREEBSD/libschemereadline.a /home/mika/t/mscheme/schemesig/AMD64_FREEBSD/libschemesig.a /home/mika/t/calarm/m3readline/AMD64_FREEBSD/libm3readline.a /home/mika/t/calarm/sx/AMD64_FREEBSD/libsx.a /home/mika/t/mscheme/modula3scheme/AMD64_FREEBSD/libmodula3scheme.a /home/mika/t/rdwr/AMD64_FREEBSD/librdwr.a /home/mika/t/mscheme/AMD64_FREEBSD/libmscheme.a /home/mika/t/cit_util/AMD64_FREEBSD/libcit_util.a /usr/local/cm3/pkg/netobj/AMD64_FREEBSD/libm3netobj.a /usr/local/cm3/pkg/tcp/AMD64_FREEBSD/libm3tcp.a /usr/local/cm3/pkg/patternmatching/AMD64_FREEBSD/libpatternmatching.a /home/mika/t/mscheme/scheme-lib/AMD64_FREEBSD/libscheme-lib.a /usr/local/cm3/pkg/libbuf/AMD64_FREEBSD/liblibbuf.a /home/mika/t/ci
 t_common/AMD64_FREEBSD/libcit_common.a /usr/local/cm3/pkg/set/AMD64_FREEBSD/libset.a /home/mika/t/rdwrreset/AMD64_FREEBSD/librdwrreset.a /usr/local/cm3/pkg/m3tk/AMD64_FREEBSD/libm3tk.a /usr/local/cm3/pkg/m3tk-misc/AMD64_FREEBSD/libm3tk-misc.a /usr/local/cm3/pkg/libm3/AMD64_FREEBSD/libm3.a /usr/local/cm3/pkg/m3core/AMD64_FREEBSD/libm3core.a -lm -lcrypt -lssl -L/usr/local/lib -lintl -lreadline




From mika at async.caltech.edu  Sun Mar  6 05:24:37 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Sat, 05 Mar 2011 20:24:37 -0800
Subject: [M3devel] MODULEs in .M3IMPTAB
In-Reply-To: <12847.73267.qm@web29719.mail.ird.yahoo.com> 
References: <12847.73267.qm@web29719.mail.ird.yahoo.com>
Message-ID: <20110306042437.D48591A2078@async.async.caltech.edu>

Let me be perfectly clear.

m3tk processes interfaces just fine.

m3tk at the moment doesn't know where to find implementations (MODULEs).

One can tell m3tk where to find them with a command-line switch specifying
a list of directories.  But that's not right, because only cm3 (the
compiler driver) knows which source files have been processed to build
which implementation.

I think my argument suggests the .m3s should be emitted to .M3IMPTAB together
with the .i3s (and .igs oh and also .mgs)

    Mika

"Daniel Alejandro Benavides D." writes:
>Hi all:
>yes, I think I did mention it in a past message because about the ESC, it n=
>eedes as it m3tk too, I didn't know it was a requirement of m3tk though. Bu=
>t because is just a module dependency analyzer I thought we could just crea=
>te one in m3tk, sort of a chicken and egg problem it seems now. OK, I with =
>an older cm3 we could use it to build it in a setting and then supply itsel=
>f in m3tk, if that's the way to go, therefore I think this is really needed=
> for ESC release.
>Another thing if you allow me is about again the ESC itself, I think that o=
>ne of the ways we could improve some of the ESC checks is to reuse some sor=
>t automatic program debugger I already mentioned about Juno which language =
>has a subset of Simplify language so we could try to postprocess further er=
>rors to guarantee they are so and the more important it could be possible t=
>o think in analyzing checks for soundness so we may try to put closer Simpl=
>if0y to its (in results terms) goal of finding more errors it can catch. Th=
>at said I would go for double checked proofs so me can arguably guarantee t=
>hey are sound proved theoretically and passing through it Simplify again, a=
>ll of this without modification to ESC per se. This is traditional approach=
> for debuggers, so its not a new idea again, just that we need to be smarte=
>r in certain way to catch with the less computation effort the most bugs we=
> can. Another thing I was thinking was to integrate this proofs in
> regular builds so for example a given all program proofs modified by the d=
>ebugger should be presented as warnings of error and something that must be=
> checked closely (supervised).
>Ok, let mw now your thoughts on this points, thanks in advance
>
>--- El s=E1b, 5/3/11, Mika Nystrom <mika at async.caltech.edu> escribi=F3:
>
>> De: Mika Nystrom <mika at async.caltech.edu>
>> Asunto: Re: [M3devel] MODULEs in .M3IMPTAB
>> Para: "Tony Hosking" <hosking at cs.purdue.edu>
>> CC: m3devel at elegosoft.com
>> Fecha: s=E1bado, 5 de marzo, 2011 17:53
>>=20
>> Tony, are you sure?  There don't seem to be any tools
>> in CM3 that process
>> implementations with m3tk, or have I been looking in the
>> wrong places?
>> stubgen doesn't, I don't think stablegen does, and m3pp and
>> m3tohtml
>> don't even use m3tk.  Also it doesn't seem to work on
>> PM3-1.13.2.  Hmmmmm....
>>=20
>>      Mika
>>=20
>> Tony Hosking writes:
>> >It used to work... :-(
>> >
>> >On Mar 5, 2011, at 3:06 PM, Mika Nystrom wrote:
>> >
>> >> Hi again m3devel,
>> >>=20
>> >> Can anyone think of a reason that cm3 should *not*
>> emit information
>> >> about MODULEs that it compiles to .M3IMPTAB?=20
>> (It doesn't, today,
>> >> which means that m3tk-based tools can't find
>> implementations, only
>> >> interfaces.)
>> >>=20
>> >>    Mika
>> =0A=0A=0A      


From dabenavidesd at yahoo.es  Sun Mar  6 05:20:10 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sun, 6 Mar 2011 04:20:10 +0000 (GMT)
Subject: [M3devel] MODULEs in .M3IMPTAB
In-Reply-To: <20110305225351.2A2AD1A2078@async.async.caltech.edu>
Message-ID: <12847.73267.qm@web29719.mail.ird.yahoo.com>

Hi all:
yes, I think I did mention it in a past message because about the ESC, it needes as it m3tk too, I didn't know it was a requirement of m3tk though. But because is just a module dependency analyzer I thought we could just create one in m3tk, sort of a chicken and egg problem it seems now. OK, I with an older cm3 we could use it to build it in a setting and then supply itself in m3tk, if that's the way to go, therefore I think this is really needed for ESC release.
Another thing if you allow me is about again the ESC itself, I think that one of the ways we could improve some of the ESC checks is to reuse some sort automatic program debugger I already mentioned about Juno which language has a subset of Simplify language so we could try to postprocess further errors to guarantee they are so and the more important it could be possible to think in analyzing checks for soundness so we may try to put closer Simplif0y to its (in results terms) goal of finding more errors it can catch. That said I would go for double checked proofs so me can arguably guarantee they are sound proved theoretically and passing through it Simplify again, all of this without modification to ESC per se. This is traditional approach for debuggers, so its not a new idea again, just that we need to be smarter in certain way to catch with the less computation effort the most bugs we can. Another thing I was thinking was to integrate this proofs in
 regular builds so for example a given all program proofs modified by the debugger should be presented as warnings of error and something that must be checked closely (supervised).
Ok, let mw now your thoughts on this points, thanks in advance

--- El s?b, 5/3/11, Mika Nystrom <mika at async.caltech.edu> escribi?:

> De: Mika Nystrom <mika at async.caltech.edu>
> Asunto: Re: [M3devel] MODULEs in .M3IMPTAB
> Para: "Tony Hosking" <hosking at cs.purdue.edu>
> CC: m3devel at elegosoft.com
> Fecha: s?bado, 5 de marzo, 2011 17:53
> 
> Tony, are you sure?  There don't seem to be any tools
> in CM3 that process
> implementations with m3tk, or have I been looking in the
> wrong places?
> stubgen doesn't, I don't think stablegen does, and m3pp and
> m3tohtml
> don't even use m3tk.  Also it doesn't seem to work on
> PM3-1.13.2.  Hmmmmm....
> 
>      Mika
> 
> Tony Hosking writes:
> >It used to work... :-(
> >
> >On Mar 5, 2011, at 3:06 PM, Mika Nystrom wrote:
> >
> >> Hi again m3devel,
> >> 
> >> Can anyone think of a reason that cm3 should *not*
> emit information
> >> about MODULEs that it compiles to .M3IMPTAB? 
> (It doesn't, today,
> >> which means that m3tk-based tools can't find
> implementations, only
> >> interfaces.)
> >> 
> >>    Mika
> 


      


From hosking at cs.purdue.edu  Sun Mar  6 15:54:14 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 6 Mar 2011 09:54:14 -0500
Subject: [M3devel] MODULEs in .M3IMPTAB
In-Reply-To: <20110305225351.2A2AD1A2078@async.async.caltech.edu>
References: <20110305200630.F26711A2078@async.async.caltech.edu>
	<F14FF404-B88C-4C46-B433-744E45311209@cs.purdue.edu>
	<20110305225351.2A2AD1A2078@async.async.caltech.edu>
Message-ID: <D09FFA7F-549C-41F6-AA59-05A6D4B1B48B@cs.purdue.edu>

m3browser?

Sent from my iPhone

On Mar 5, 2011, at 5:53 PM, Mika Nystrom <mika at async.caltech.edu> wrote:

> 
> Tony, are you sure?  There don't seem to be any tools in CM3 that process
> implementations with m3tk, or have I been looking in the wrong places?
> stubgen doesn't, I don't think stablegen does, and m3pp and m3tohtml
> don't even use m3tk.  Also it doesn't seem to work on PM3-1.13.2.  Hmmmmm....
> 
>     Mika
> 
> Tony Hosking writes:
>> It used to work... :-(
>> 
>> On Mar 5, 2011, at 3:06 PM, Mika Nystrom wrote:
>> 
>>> Hi again m3devel,
>>> 
>>> Can anyone think of a reason that cm3 should *not* emit information
>>> about MODULEs that it compiles to .M3IMPTAB?  (It doesn't, today,
>>> which means that m3tk-based tools can't find implementations, only
>>> interfaces.)
>>> 
>>>   Mika


From mika at async.caltech.edu  Sun Mar  6 17:46:35 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Sun, 06 Mar 2011 08:46:35 -0800
Subject: [M3devel] MODULEs in .M3IMPTAB
In-Reply-To: <D09FFA7F-549C-41F6-AA59-05A6D4B1B48B@cs.purdue.edu> 
References: <20110305200630.F26711A2078@async.async.caltech.edu>
	<F14FF404-B88C-4C46-B433-744E45311209@cs.purdue.edu>
	<20110305225351.2A2AD1A2078@async.async.caltech.edu>
	<D09FFA7F-549C-41F6-AA59-05A6D4B1B48B@cs.purdue.edu>
Message-ID: <20110306164635.A86E61A2078@async.async.caltech.edu>

Nope, m3browser uses something called "m3scan"...

Tony Hosking writes:
>m3browser?
>
>Sent from my iPhone
>
>On Mar 5, 2011, at 5:53 PM, Mika Nystrom <mika at async.caltech.edu> wrote:
>
>>=20
>> Tony, are you sure?  There don't seem to be any tools in CM3 that process
>> implementations with m3tk, or have I been looking in the wrong places?
>> stubgen doesn't, I don't think stablegen does, and m3pp and m3tohtml
>> don't even use m3tk.  Also it doesn't seem to work on PM3-1.13.2.  Hmmmmm.=
>...
>>=20
>>     Mika
>>=20
>> Tony Hosking writes:
>>> It used to work... :-(
>>>=20
>>> On Mar 5, 2011, at 3:06 PM, Mika Nystrom wrote:
>>>=20
>>>> Hi again m3devel,
>>>>=20
>>>> Can anyone think of a reason that cm3 should *not* emit information
>>>> about MODULEs that it compiles to .M3IMPTAB?  (It doesn't, today,
>>>> which means that m3tk-based tools can't find implementations, only
>>>> interfaces.)
>>>>=20
>>>>   Mika


From jay.krell at cornell.edu  Mon Mar  7 02:25:59 2011
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 7 Mar 2011 01:25:59 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , , ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , 
	, <20110227231125.3DC611A2078@async.async.caltech.edu>,
	,,<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, ,
	<COL101-W4726257303F22627175774E6C30@phx.gbl>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, ,
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, ,
	<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>,
	<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>
Message-ID: <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>


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/20110307/05931f46/attachment.html>

From jay.krell at cornell.edu  Mon Mar  7 06:39:53 2011
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 7 Mar 2011 05:39:53 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , ,
	,,<20110226175511.3F7D21A2078@async.async.caltech.edu>, , ,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , ,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , ,
	,,<20110227202950.46F3B1A2078@async.async.caltech.edu>, , ,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , ,,,
	<20110227231125.3DC611A2078@async.async.caltech.edu>, , , ,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , 
	, <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>,
	,,<COL101-W4726257303F22627175774E6C30@phx.gbl>,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>,
	,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>,
	,,<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, ,
	<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>,
	<COL101-W1162A9B603898CC921B557E6C70@phx.gbl>
Message-ID: <COL101-W26D3B03885998122254013E6C70@phx.gbl>


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/20110307/816bd520/attachment.html>

From jay.krell at cornell.edu  Mon Mar  7 06:51:32 2011
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 7 Mar 2011 05:51:32 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W26D3B03885998122254013E6C70@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	,,,,<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	,,,,<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	,,,,<20110227231125.3DC611A2078@async.async.caltech.edu>, , ,
	,,<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , ,,,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , ,
	<COL101-W4726257303F22627175774E6C30@phx.gbl>, , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , ,
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , , ,
	<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, , , 
	, <D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>,
	,,<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, ,
	<COL101-W1162A9B603898CC921B557E6C70@phx.gbl>,
	<COL101-W26D3B03885998122254013E6C70@phx.gbl>
Message-ID: <COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>


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/20110307/b5340413/attachment.html>

From jay.krell at cornell.edu  Mon Mar  7 07:53:06 2011
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 7 Mar 2011 06:53:06 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>,
	,,,,,,<20110226175511.3F7D21A2078@async.async.caltech.edu>,
	,,,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>,
	,,,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>,
	,,,,,,<20110227202950.46F3B1A2078@async.async.caltech.edu>,
	,,,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>,
	,,,,,,<20110227231125.3DC611A2078@async.async.caltech.edu>, ,
	,,,,<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, ,
	,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , ,
	,,<COL101-W4726257303F22627175774E6C30@phx.gbl>, , ,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , ,
	,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , ,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , ,
	,,<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, , ,,,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , ,
	<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , 
	, <D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>,
	, , <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, ,
	<COL101-W26D3B03885998122254013E6C70@phx.gbl>,
	<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>
Message-ID: <COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>


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/20110307/2ad39231/attachment.html>

From jay.krell at cornell.edu  Mon Mar  7 07:58:45 2011
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 7 Mar 2011 06:58:45 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , , , , ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , ,
	, <D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , ,
	, , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , ,
	, , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	, , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , ,
	, , <20110227231125.3DC611A2078@async.async.caltech.edu>, 
	,,,,,,<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	,,,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, ,
	,,,,<COL101-W4726257303F22627175774E6C30@phx.gbl>, ,
	,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, ,
	,,,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, ,
	,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, ,
	,,,,<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, ,
	,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , ,
	,,<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , ,,,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>,,, ,
	<COL101-W1162A9B603898CC921B557E6C70@phx.gbl>,
	, , <COL101-W26D3B03885998122254013E6C70@phx.gbl>, ,
	<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>,
	<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>
Message-ID: <COL101-W510B831AC595A3597FE281E6C70@phx.gbl>


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/20110307/4689d5a0/attachment.html>

From jay.krell at cornell.edu  Wed Mar  9 21:10:37 2011
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 9 Mar 2011 20:10:37 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W510B831AC595A3597FE281E6C70@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , , , , ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , ,
	, <D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , ,
	, , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , ,
	, , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	, , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , ,
	, , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , ,
	, , , <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , , ,
	, <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, 
	,,,,,,<COL101-W4726257303F22627175774E6C30@phx.gbl>,
	,,,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>,
	,,,,,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>,
	,,,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>,
	,,,,,,<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>,
	,,,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, ,
	,,,,<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, ,
	,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>,,,
	, , <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , , ,
	<COL101-W26D3B03885998122254013E6C70@phx.gbl>, ,
	<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>,
	<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>,
	<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>
Message-ID: <COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>


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/20110309/f55d5318/attachment.html>

From jay.krell at cornell.edu  Thu Mar 10 11:09:02 2011
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 10 Mar 2011 10:09:02 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , , , , ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , ,
	, <D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , ,
	, , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , ,
	, , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	, , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , ,
	, , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , ,
	, , , <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , , ,
	, <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , ,
	, , , <COL101-W4726257303F22627175774E6C30@phx.gbl>, , , , , , ,
	, <D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , ,
	, , , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, ,
	, , , , , , <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>,
	, , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, 
	,,,,,,<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>,
	, , , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , ,
	, , <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , , ,
	<COL101-W26D3B03885998122254013E6C70@phx.gbl>, ,
	<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>,
	<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>,
	<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>,
	<COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>
Message-ID: <COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>


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/105955e1/attachment.html>

From jay.krell at cornell.edu  Thu Mar 10 11:40:58 2011
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 10 Mar 2011 10:40:58 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , ,
	, , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , ,
	, , 
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , ,,, , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , ,,, , , , ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,,, , , , ,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , , , ,
	, 
	<20110227231125.3DC611A2078@async.async.caltech.edu>, , , , ,,, , ,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , , ,,,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , ,,, , ,
	<COL101-W4726257303F22627175774E6C30@phx.gbl>, , , , , , ,,,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , ,,, , ,
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , ,,, , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, ,,, , , , , ,
	<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>,,, , , , , ,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , , , ,
	<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , 
	, , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , , ,
	, , <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , ,
	,,<COL101-W26D3B03885998122254013E6C70@phx.gbl>,
	, , <COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>, ,
	<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>, ,
	<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>, ,
	<COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>,
	<COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>
Message-ID: <COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>


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/c8e8b320/attachment.html>

From jay.krell at cornell.edu  Thu Mar 10 12:05:40 2011
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 10 Mar 2011 11:05:40 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , ,
	, , , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , ,
	, 
	, , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , ,
	, , , 
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , ,,, , , ,
	, , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , , , ,
	, , 
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , , ,
	,,,,<20110227231125.3DC611A2078@async.async.caltech.edu>, , , , ,,, ,
	,,<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , , ,
	, , ,,<COL101-W4726257303F22627175774E6C30@phx.gbl>, , , , , ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , , ,
	, , 
	,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , ,,, , ,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, ,,, , , , ,
	, , <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, , , , , , , , ,
	, , 
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , , ,
	,,<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , ,,, , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , , ,,, ,
	<COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, ,
	,,,,<COL101-W26D3B03885998122254013E6C70@phx.gbl>,,, ,
	<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>,
	,,<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>,
	,,<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>,
	, , <COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>, ,
	<COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>,
	<COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>
Message-ID: <COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>


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/01a78fc7/attachment.html>

From jay.krell at cornell.edu  Thu Mar 10 12:11:35 2011
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 10 Mar 2011 11:11:35 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , ,,,
	, , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , ,
	, , , 
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , , ,
	, , 
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , , , , ,
	, , , , , 
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , , , , , ,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , ,
	,,,,,,<20110227231125.3DC611A2078@async.async.caltech.edu>, , , , ,,,
	,,,,<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , ,,, , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , , ,,, ,
	,,<COL101-W4726257303F22627175774E6C30@phx.gbl>, , , , , ,,, , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , , ,,,
	,,,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , ,,, ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , , , , ,
	, , , , , 
	<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, , , , , , , , , , ,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , ,
	,,,,<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , ,,, , , ,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , , ,,,
	,,<COL101-W1162A9B603898CC921B557E6C70@phx.gbl>,
	,,,,,,<COL101-W26D3B03885998122254013E6C70@phx.gbl>,,,
	, , <COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>, , , ,
	<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>, , , ,
	<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>, , , 
	, <COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>,
	, , <COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>, ,
	<COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>,
	<COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>
Message-ID: <COL101-W1593ED3DF56A0900656FCE6C80@phx.gbl>


I forgot to point out: I'll stick to 32bit Windows for now, while looking at Mika's threadtest.

 - Jay

From: jay.krell at cornell.edu
To: rcolebur at scires.com; m3devel at elegosoft.com
Date: Thu, 10 Mar 2011 11:05:40 +0000
Subject: Re: [M3devel] results of threadtest program on Windows7








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/e60c249b/attachment.html>

From rcolebur at SCIRES.COM  Thu Mar 10 17:18:31 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 10 Mar 2011 11:18:31 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , ,
	, , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , ,
	, , 
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , ,,, , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , ,,, , , , ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,,, , , , ,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , , , ,
	, 
	<20110227231125.3DC611A2078@async.async.caltech.edu>, , , , ,,, , ,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , , ,,,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , ,,, , ,
	<COL101-W4726257303F22627175774E6C30@phx.gbl>, , , , , , ,,,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , ,,, , ,
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , ,,, , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, ,,, , , , , ,
	<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>,,, , , , , ,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , , , ,
	<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , 
	, , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , , ,
	, , <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , ,
	,,<COL101-W26D3B03885998122254013E6C70@phx.gbl>,
	, , <COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>, ,
	<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>, ,
	<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>, ,
	<COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>,
	<COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>
	<COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6EE527A91@atlex02-srv>

Jay et al:

CM3's use of native windows threads has worked very well for me in the past, and the majority of all my programs have always been multithreaded.

Surely there must be some collection of changes in last couple of years that is responsible for the runtime errors we are seeing now with the thread test program.  Another possibility is that maybe there is something wrong with the thread test program itself that we haven't spotted yet.

I will try to take some time soon to go back to an earlier cm3 release and run the thread test program there to see how it fares.

Regards,
Randy

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Thursday, March 10, 2011 5:41 AM
To: Coleburn, Randy; m3devel
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/14057194/attachment.html>

From hosking at cs.purdue.edu  Thu Mar 10 17:50:40 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 10 Mar 2011 11:50:40 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , , , ,
	, , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , ,
	, , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , , ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	, , , , , , , ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	, , , , , , , , ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , , ,
	, , , <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , , ,
	, , , <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , ,
	, , , , , , , <COL101-W4726257303F22627175774E6C30@phx.gbl>, , ,
	, , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , , ,
	, , , , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , ,
	, , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , , , , ,
	, , , , <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, !
	, , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , ,
	, , , <COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , , , , ,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , ,
	, , , , <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , , , , ,
	<COL101-W26D3B03885998122254013E6C70@phx.gbl>, , , ,
	<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>, , ,
	<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>, , ,
	<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>, , ,
	<COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>, ,
	<COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>,
	<COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>
	<COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>
Message-ID: <FDAEB2B4-BC12-45DB-8F60-639A9B8E48EF@cs.purdue.edu>

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.html>

From dabenavidesd at yahoo.es  Thu Mar 10 20:19:00 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 10 Mar 2011 19:19:00 +0000 (GMT)
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <FDAEB2B4-BC12-45DB-8F60-639A9B8E48EF@cs.purdue.edu>
Message-ID: <291871.70222.qm@web29714.mail.ird.yahoo.com>

Hi all:
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.
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.
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.
Thanks in advance

--- El jue, 10/3/11, Tony Hosking <hosking at cs.purdue.edu> escribi?:

De: Tony Hosking <hosking at cs.purdue.edu>
Asunto: Re: [M3devel] results of threadtest program on Windows7
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 10 de marzo, 2011 11:50

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/3b78b82d/attachment.html>

From jay.krell at cornell.edu  Thu Mar 10 22:03:58 2011
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 10 Mar 2011 21:03:58 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <FDAEB2B4-BC12-45DB-8F60-639A9B8E48EF@cs.purdue.edu>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , ,
	, , , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , ,
	, , , 
	, , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , ,
	, , , 
	, , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , , , , , ,
	, , 
	, , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , , ,
	, , , 
	, <D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , , , , ,
	, , 
	, , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , , , , ,
	, , 
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , , ,,, , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , , , , , , ,
	, <COL101-W4726257303F22627175774E6C30@phx.gbl>, , ,,, , , , , ,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , , , , ,
	, , , 
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , ,,, , , , , ,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , , , , , , ,
	, , , 
	<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, !, , , , , , , , ,
	, 
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , , , ,
	, , <COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , , , , ,,, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , ,,, , , ,
	<COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , , , ,
	,,<COL101-W26D3B03885998122254013E6C70@phx.gbl>, , ,
	,,<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>, ,
	,,<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>, ,
	,,<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>, ,
	,,<COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>,
	, , <COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>, ,
	<COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>,
	<COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>,
	<FDAEB2B4-BC12-45DB-8F60-639A9B8E48EF@cs.purdue.edu>
Message-ID: <COL101-w573D2FF7546A4BCDD27275E6C80@phx.gbl>


I often forget this. Thank you.

 - Jay

From: hosking at cs.purdue.edu
Date: Thu, 10 Mar 2011 11:50:40 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] results of threadtest program on Windows7



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/35d57c4d/attachment.html>

From jay.krell at cornell.edu  Sat Mar 12 10:57:13 2011
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 12 Mar 2011 09:57:13 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-w573D2FF7546A4BCDD27275E6C80@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , ,
	, , , , , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , ,
	, , , , 
	, , , , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , ,
	, , 
	, , , , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , ,
	, , , , 
	, , , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , ,
	, , , , 
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , ,
	, , , 
	, , , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , ,
	, , , , 
	,,<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , , ,,, ,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , , , , ,
	, , ,,<COL101-W4726257303F22627175774E6C30@phx.gbl>, , ,,, , , , ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , , ,
	, , , , 
	,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , ,,, , , , ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , , , , ,
	, , , , 
	, , <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, !, , , , , , ,
	, , 
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , ,
	, , , 
	,,<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , , , , ,,,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , ,,, , ,
	,,<COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , , ,
	,,,,<COL101-W26D3B03885998122254013E6C70@phx.gbl>, ,
	,,,,<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>,
	,,,,<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>,
	,,,,<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>,
	, , , , <COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>, , , ,
	<COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>, ,
	<COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>,
	<COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>,
	<FDAEB2B4-BC12-45DB-8F60-639A9B8E48EF@cs.purdue.edu>,
	<COL101-w573D2FF7546A4BCDD27275E6C80@phx.gbl>
Message-ID: <COL101-w65CBD25BD3FC0BFF9115BBE6CA0@phx.gbl>


There is a lack of evidence that Java does things in a way at all resembling what Modula-3 does, on Win32.
 There is precious little in the way of calling the Win32 functions SuspendThread and GetThreadContext.
There is evidence that they use cooperative suspend.
It isn't conclusive, to me..just because there is so much there, it is not immediately clear.
That is, pretty clear there is code implementing cooperative suspend, but is that their entire story? I don't know.

 - Jay

From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] results of threadtest program on Windows7
Date: Thu, 10 Mar 2011 21:03:58 +0000








I often forget this. Thank you.

 - Jay

From: hosking at cs.purdue.edu
Date: Thu, 10 Mar 2011 11:50:40 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] results of threadtest program on Windows7



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/20110312/0a47c8d0/attachment.html>

From hosking at cs.purdue.edu  Sat Mar 12 17:23:04 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 12 Mar 2011 11:23:04 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-w65CBD25BD3FC0BFF9115BBE6CA0@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , , , ,
	, , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	, , , , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , , ,
	, , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , , , , ,
	, , , , , , ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , ,
	, , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , ,
	, , , , , , , ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , , ,
	, , , , , <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , ,
	, , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , , ,
	, , , , , , <COL101-W4726257303F22627175774E6C30@phx.gbl>, , , ,
	, , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , , ,
	, , , , , , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>,
	, , , , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , , , , ,
	, , , , , , <44BAC21C-4375-478B-9FDF-27181181D7!
	65@cs.purdue.edu>, !, , , , , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , ,
	, , , , , <COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , , ,
	, , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , , , ,
	, , , , <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , , , , ,
	, , <COL101-W26D3B03885998122254013E6C70@phx.gbl>, , , , , ,
	<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>, , , , ,
	<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>, , , , ,
	<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>, , , , ,
	<COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>, , , ,
	<COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>, ,
	<COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>,
	<COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>,
	<FDAEB2B4-BC12-45DB-8F60-639A9B8E48EF@cs.purdue.edu>,
	<COL101-w573D2FF7546A4BCDD27275E6C80@phx.gbl>
	<COL101-w65CBD25BD3FC0BFF9115BBE6CA0@phx.gbl>
Message-ID: <8972478C-50D2-41D1-8DEB-57323B1D3580@cs.purdue.edu>

I know they use cooperative suspend.
We do in Jikes RVM too.
That's another code base to look at.  Probably easier as it is all in Java.

On Mar 12, 2011, at 4:57 AM, Jay K wrote:

> There is a lack of evidence that Java does things in a way at all resembling what Modula-3 does, on Win32.
>  There is precious little in the way of calling the Win32 functions SuspendThread and GetThreadContext.
> There is evidence that they use cooperative suspend.
> It isn't conclusive, to me..just because there is so much there, it is not immediately clear.
> That is, pretty clear there is code implementing cooperative suspend, but is that their entire story? I don't know.
> 
>  - Jay
> 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] results of threadtest program on Windows7
> Date: Thu, 10 Mar 2011 21:03:58 +0000
> 
> I often forget this. Thank you.
> 
>  - Jay
> 
> From: hosking at cs.purdue.edu
> Date: Thu, 10 Mar 2011 11:50:40 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> 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/20110312/3f9c933e/attachment.html>

From jay.krell at cornell.edu  Sun Mar 13 01:40:36 2011
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 13 Mar 2011 00:40:36 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <8972478C-50D2-41D1-8DEB-57323B1D3580@cs.purdue.edu>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , ,
	, , , , , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , ,
	, , , , 
	, , , , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , ,
	, , 
	, , , , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , ,
	, , , , 
	, , , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , ,
	, , , , 
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , ,
	, , , 
	, , , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , ,
	, , , , 
	,,<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , , ,,, ,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , , , , ,
	, , ,,<COL101-W4726257303F22627175774E6C30@phx.gbl>, , ,,, , , , ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , , ,
	, , , , 
	,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , ,,, , , , ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , , , , ,
	, , , , 
	, , <44BAC21C-4375-478B-9FDF-27181181D7!, 65@cs.purdue.edu>, !, , , , , ,
	, , , 
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , ,
	, , , 
	,,<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , , , , ,,,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , ,,, , ,
	,,<COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , , ,
	,,,,<COL101-W26D3B03885998122254013E6C70@phx.gbl>, ,
	,,,,<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>,
	,,,,<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>,
	,,,,<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>,
	, , , , <COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>, , , ,
	<COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>, ,
	<COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>,
	<COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>,
	<FDAEB2B4-BC12-45DB-8F60-639A9B8E48EF@cs.purdue.edu>,
	<COL101-w573D2FF7546A4BCDD27275E6C80@phx.gbl>
	<COL101-w65CBD25BD3FC0BFF9115BBE6CA0@phx.gbl>,
	<8972478C-50D2-41D1-8DEB-57323B1D3580@cs.purdue.edu>
Message-ID: <COL101-W640F123E3C9A858317508E6CD0@phx.gbl>


I thought maybe they'd show a way for us to get away with "preemptive suspend",
a way to use SuspendThread/GetThreadContext with confidence.

So, you agree we want cooperative suspend then?
And we should maybe get going on implementing it?
Maybe do that before debugging Mika's problem?
  Well, to repeat myself, I'm ok with looking into 32bit-only Windows for Mika's problem.
  Though, clearly, as i've said, I have A LOT less time for Modula-3 now and probably ever.

 - Jay

Subject: Re: [M3devel] results of threadtest program on Windows7
From: hosking at cs.purdue.edu
Date: Sat, 12 Mar 2011 11:23:04 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu



I know they use cooperative suspend.We do in Jikes RVM too.That's another code base to look at.  Probably easier as it is all in Java.

On Mar 12, 2011, at 4:57 AM, Jay K wrote:There is a lack of evidence that Java does things in a way at all resembling what Modula-3 does, on Win32.
 There is precious little in the way of calling the Win32 functions SuspendThread and GetThreadContext.
There is evidence that they use cooperative suspend.
It isn't conclusive, to me..just because there is so much there, it is not immediately clear.
That is, pretty clear there is code implementing cooperative suspend, but is that their entire story? I don't know.

 - Jay

From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] results of threadtest program on Windows7
Date: Thu, 10 Mar 2011 21:03:58 +0000

I often forget this. Thank you.

 - Jay

From: hosking at cs.purdue.edu
Date: Thu, 10 Mar 2011 11:50:40 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] results of threadtest program on Windows7

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/20110313/8d270d25/attachment.html>

From hosking at cs.purdue.edu  Sun Mar 13 19:08:10 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 13 Mar 2011 14:08:10 -0400
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W640F123E3C9A858317508E6CD0@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , , , ,
	, , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	, , , , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , , ,
	, , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , , , , ,
	, , , , , , ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , ,
	, , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , ,
	, , , , , , , ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , , ,
	, , , , , <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , ,
	, , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , , ,
	, , , , , , <COL101-W4726257303F22627175774E6C30@phx.gbl>, , , ,
	, , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , , ,
	, , , , , , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>,
	, , , , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , , , , ,
	, , , , , , <44BAC21C-4375-478B-9FDF-27181181D7!
	!, 65@cs.purdue.edu>, !, , , , , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , ,
	, , , , , <COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , , ,
	, , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , , , ,
	, , , , <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , , , , ,
	, , <COL101-W26D3B03885998122254013E6C70@phx.gbl>, , , , , ,
	<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>, , , , ,
	<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>, , , , ,
	<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>, , , , ,
	<COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>, , , ,
	<COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>, ,
	<COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>,
	<COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>,
	<FDAEB2B4-BC12-45DB-8F60-639A9B8E48EF@cs.purdue.edu>,
	<COL101-w573D2FF7546A4BCDD27275E6C80@phx.gbl>
	<COL101-w65CBD25BD3FC0BFF9115BBE6CA0@phx.gbl>,
	<8972478C-50D2-41D1-8DEB-57323B1D3580@cs.purdue.edu>
	<COL101-W640F123E3C9A858317508E6CD0@phx.gbl>
Message-ID: <685C8B05-23D1-4BE8-93BB-3B11FFD28AFF@cs.purdue.edu>

I'd like to debug the current problem because it does not seem to imply any problem with suspend/resume.  More likely is losing a reference in the stacks somehow.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On Mar 12, 2011, at 7:40 PM, Jay K wrote:

> I thought maybe they'd show a way for us to get away with "preemptive suspend",
> a way to use SuspendThread/GetThreadContext with confidence.
> 
> So, you agree we want cooperative suspend then?
> And we should maybe get going on implementing it?
> Maybe do that before debugging Mika's problem?
>   Well, to repeat myself, I'm ok with looking into 32bit-only Windows for Mika's problem.
>   Though, clearly, as i've said, I have A LOT less time for Modula-3 now and probably ever.
> 
>  - Jay
> 
> Subject: Re: [M3devel] results of threadtest program on Windows7
> From: hosking at cs.purdue.edu
> Date: Sat, 12 Mar 2011 11:23:04 -0500
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> I know they use cooperative suspend.
> We do in Jikes RVM too.
> That's another code base to look at.  Probably easier as it is all in Java.
> 
> On Mar 12, 2011, at 4:57 AM, Jay K wrote:
> 
> There is a lack of evidence that Java does things in a way at all resembling what Modula-3 does, on Win32.
>  There is precious little in the way of calling the Win32 functions SuspendThread and GetThreadContext.
> There is evidence that they use cooperative suspend.
> It isn't conclusive, to me..just because there is so much there, it is not immediately clear.
> That is, pretty clear there is code implementing cooperative suspend, but is that their entire story? I don't know.
> 
>  - Jay
> 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] results of threadtest program on Windows7
> Date: Thu, 10 Mar 2011 21:03:58 +0000
> 
> I often forget this. Thank you.
> 
>  - Jay
> 
> From: hosking at cs.purdue.edu
> Date: Thu, 10 Mar 2011 11:50:40 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> 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/20110313/f58adf71/attachment.html>

From dabenavidesd at yahoo.es  Sun Mar 13 21:34:27 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sun, 13 Mar 2011 20:34:27 +0000 (GMT)
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <685C8B05-23D1-4BE8-93BB-3B11FFD28AFF@cs.purdue.edu>
Message-ID: <895304.26763.qm@web29717.mail.ird.yahoo.com>

Hi all:
I was wondering how it might to produce an environment such of gcc level compatibility, without breaking the runtime in two languages, that is sort of the idea I guess never fully released GNU Modula-3. Perhaps that was the idea of RMS, to make compatible interfaces so anything misbehaved in any platform could be replaced with something more usable for those purposes (and so he was just interested in code generator that accompanied m3tk) see:
http://opensource.apple.com/source/gcc/gcc-5479/boehm-gc/doc/README.macros

So in that case we could use some of the RT requirements more easily and give each platform free compatibility of our RT so more freedom for further developments, say GPL interface against implementations, etc and stabilize more the RT in terms of more up to date requirements, with openjdk, or any other RT, even OS deprecated ones (say we would want that applied in Android OS or any other lightweight system e.g Java I/O subsystem borrow):

http://www.semiramis.org.uk/rrw/software/misc/ksynch.html

Indeed a contracted developer by MIT developed such automating of information recovery from C interfaces (well an OO C dialect) to link with Modula-3 runtime without too much replication and much more smoothly? results? in terms of stability of? Modula-3 RT such e.g apply it too Atoms, etc with full compatiblity if so:
http://www.doc.ic.ac.uk/~pcc03/transfer.pdf
Perhaps this way can we reuse some more time of current developers and historical ones too, which I believe are very important too (especially ESC in Java for any kind of developer even from smartphones and innovative systems like? see:
http://whiley.org/about/overview/
).

Thanks in advance

--- El dom, 13/3/11, Tony Hosking <hosking at cs.purdue.edu> escribi?:

De: Tony Hosking <hosking at cs.purdue.edu>
Asunto: Re: [M3devel] results of threadtest program on Windows7
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: domingo, 13 de marzo, 2011 13:08

I'd like to debug the current problem because it does not seem to imply any problem with suspend/resume. ?More likely is losing a reference in the stacks somehow.

Antony Hosking?|?Associate Professor?| Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice?+1 765 494 6001 |?Mobile?+1 765 427 5484





On Mar 12, 2011, at 7:40 PM, Jay K wrote:
I thought maybe they'd show a way for us to get away with "preemptive suspend",
a way to use SuspendThread/GetThreadContext with confidence.

So, you agree we want cooperative suspend then?
And we should maybe get going on implementing it?
Maybe do that before debugging Mika's problem?
? Well, to repeat myself, I'm ok with looking into 32bit-only Windows for Mika's problem.
? Though, clearly, as i've said, I have A LOT less time for Modula-3 now and probably ever.

?- Jay

Subject: Re: [M3devel] results of threadtest program on Windows7
From:?hosking at cs.purdue.edu
Date: Sat, 12 Mar 2011 11:23:04 -0500
CC:?m3devel at elegosoft.com
To:?jay.krell at cornell.edu

I know they use cooperative suspend.We do in Jikes RVM too.That's another code base to look at. ?Probably easier as it is all in Java.
On Mar 12, 2011, at 4:57 AM, Jay K wrote:
There is a lack of evidence that Java does things in a way at all resembling what Modula-3 does, on Win32.
?There is precious little in the way of calling the Win32 functions SuspendThread and GetThreadContext.
There is evidence that they use cooperative suspend.
It isn't conclusive, to me..just because there is so much there, it is not immediately clear.
That is, pretty clear there is code implementing cooperative suspend, but is that their entire story? I don't know.

?- Jay

From:?jay.krell at cornell.edu
To:?hosking at cs.purdue.edu
CC:?m3devel at elegosoft.com
Subject: RE: [M3devel] results of threadtest program on Windows7
Date: Thu, 10 Mar 2011 21:03:58 +0000

I often forget this. Thank you.

?- Jay

From:?hosking at cs.purdue.edu
Date: Thu, 10 Mar 2011 11:50:40 -0500
To:?jay.krell at cornell.edu
CC:?m3devel at elegosoft.com
Subject: Re: [M3devel] results of threadtest program on Windows7

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/20110313/c6361136/attachment.html>

From dabenavidesd at yahoo.es  Sun Mar 13 21:44:39 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sun, 13 Mar 2011 20:44:39 +0000 (GMT)
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <895304.26763.qm@web29717.mail.ird.yahoo.com>
Message-ID: <234847.43171.qm@web29704.mail.ird.yahoo.com>

Hi all:
instead of before http://www.doc.ic.ac.uk/~pcc03/transfer.pdf
see:
ftp://asg3.andrew.cmu.edu/pub/AUIS/auis-6.3.1/doc/papers/atk/conference/Orgass.paper.ps
at cmu, the first at another too. 
Sorry, thanks in advance

--- El dom, 13/3/11, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] results of threadtest program on Windows7
Para: "Jay K" <jay.krell at cornell.edu>, "Tony Hosking" <hosking at cs.purdue.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: domingo, 13 de marzo, 2011 15:34

Hi all:
I was wondering how it might to produce an environment such of gcc level compatibility, without breaking the runtime in two languages, that is sort of the idea I guess never fully released GNU Modula-3. Perhaps that was the idea of RMS, to make compatible interfaces so anything misbehaved in any platform could be replaced with something more usable for those purposes (and so he was just interested in code generator that accompanied m3tk) see:
http://opensource.apple.com/source/gcc/gcc-5479/boehm-gc/doc/README.macros

So in that case we could use some of the RT requirements more easily and give each platform free compatibility of our RT so more freedom for further developments, say GPL interface against implementations, etc and stabilize more the RT in terms of more up to date requirements, with openjdk, or any other RT, even OS deprecated
 ones (say we would want that applied in Android OS or any other lightweight system e.g Java I/O subsystem borrow):

http://www.semiramis.org.uk/rrw/software/misc/ksynch.html

Indeed a contracted developer by MIT developed such automating of information recovery from C interfaces (well an OO C dialect) to link with Modula-3 runtime without too much replication and much more smoothly? results? in terms of stability of? Modula-3 RT such e.g apply it too Atoms, etc with full compatiblity if so:
http://www.doc.ic.ac.uk/~pcc03/transfer.pdf
Perhaps this way can we reuse some more time of current developers and historical ones too, which I believe are very important too (especially ESC in Java for any kind of developer even from smartphones and innovative systems like? see:
http://whiley.org/about/overview/
).

Thanks in advance

--- El dom, 13/3/11, Tony Hosking <hosking at cs.purdue.edu>
 escribi?:

De: Tony Hosking <hosking at cs.purdue.edu>
Asunto: Re: [M3devel] results of threadtest program on Windows7
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: domingo, 13 de marzo, 2011 13:08

I'd like to debug the current problem because it does not seem to imply any problem with suspend/resume. ?More likely is losing a reference in the stacks somehow.

Antony
 Hosking?|?Associate Professor?| Computer Science | Purdue University305 N. University
 Street | West Lafayette | IN 47907 | USAOffice?+1 765 494 6001 |?Mobile?+1 765 427 5484





On Mar 12, 2011, at 7:40 PM, Jay K wrote:
I thought maybe they'd show a way for us to get away with "preemptive suspend",
a way to use SuspendThread/GetThreadContext with confidence.

So, you agree we want cooperative suspend then?
And we should maybe get going on implementing it?
Maybe do that before debugging Mika's problem?
? Well, to repeat myself, I'm ok with looking into 32bit-only Windows for Mika's problem.
? Though,
 clearly, as i've said, I have A LOT less time for Modula-3 now and probably ever.

?- Jay

Subject: Re: [M3devel] results of threadtest program on Windows7
From:?hosking at cs.purdue.edu
Date: Sat, 12 Mar 2011 11:23:04 -0500
CC:?m3devel at elegosoft.com
To:?jay.krell at cornell.edu

I know they use cooperative suspend.We do in Jikes RVM
 too.That's another code base to look at. ?Probably easier as it is all in Java.
On Mar 12, 2011, at 4:57 AM, Jay K wrote:
There is a lack of evidence that Java does things in a way at all resembling what Modula-3 does, on Win32.
?There is precious little in the way of calling the Win32 functions SuspendThread and GetThreadContext.
There is evidence that they use cooperative suspend.
It isn't conclusive, to me..just because there is so much
 there, it is not immediately clear.
That is, pretty clear there is code implementing cooperative suspend, but is that their entire story? I don't know.

?- Jay

From:?jay.krell at cornell.edu
To:?hosking at cs.purdue.edu
CC:?m3devel at elegosoft.com
Subject: RE: [M3devel] results of threadtest program on Windows7
Date: Thu, 10 Mar 2011 21:03:58
 +0000

I often forget this. Thank you.

?- Jay

From:?hosking at cs.purdue.edu
Date: Thu, 10 Mar 2011 11:50:40 -0500
To:?jay.krell at cornell.edu
CC:?m3devel at elegosoft.com
Subject: Re: [M3devel] results of threadtest program on Windows7

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/20110313/5435f0b3/attachment.html>

From jay.krell at cornell.edu  Sun Mar 13 23:34:06 2011
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 13 Mar 2011 22:34:06 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <685C8B05-23D1-4BE8-93BB-3B11FFD28AFF@cs.purdue.edu>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , ,
	, , , , , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , ,
	, , , , , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , 
	, , , , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, 
	, , , , ,,, , , , , ,
	, , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , , , ,
	, , , 
	, , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , , ,
	, , , 
	, , , , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , ,
	, 
	, , , , , , , <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , , ,
	, , , , 
	, , , <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , , , ,
	, , , 
	, , , <COL101-W4726257303F22627175774E6C30@phx.gbl>, , , , , , , , , , ,
	, , 
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , , , , ,
	, , , 
	, , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , , , , , , ,
	, , 
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , , , , ,
	, , , 
	, , , , <44BAC21C-4375-478B-9FDF-27181181D7!, !, 65@cs.purdue.edu>, !, ,
	, , , , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , 
	, , , , , , , , , , <COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , ,
	, , , , 
	, , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , , ,
	, , , 
	, , , <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , , , , ,,, ,
	<COL101-W26D3B03885998122254013E6C70@phx.gbl>, , , , ,
	,,<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>, , , ,
	,,<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>, , , ,
	,,<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>, , , ,
	,,<COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>, , ,
	,,<COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>,
	, , <COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>, ,
	<COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>, ,
	<FDAEB2B4-BC12-45DB-8F60-639A9B8E48EF@cs.purdue.edu>, ,
	<COL101-w573D2FF7546A4BCDD27275E6C80@phx.gbl>,
	<COL101-w65CBD25BD3FC0BFF9115BBE6CA0@phx.gbl>, ,
	<8972478C-50D2-41D1-8DEB-57323B1D3580@cs.purdue.edu>,
	<COL101-W640F123E3C9A858317508E6CD0@phx.gbl>,
	<685C8B05-23D1-4BE8-93BB-3B11FFD28AFF@cs.purdue.edu>
Message-ID: <COL101-W27E336FE3D9BE3CC4F1320E6CD0@phx.gbl>


Huh? Imagine the stack/registers of a suspended thread cannot be reliably correctly retrieved.
That seems to be the case on wow64.
That would lead to these problems, right?
Anyone seen the tests fail on Win32 on a 32bit OS?
  Even so, I'd want to make sure that 32bit, we don't get the kernel thread context sometimes.
  But that shouldn't be hard to to detect and avoid, i.e. an out of range stack pointer.
I'll see how it goes on a 32bit Windows OS.

 - Jay

From: hosking at cs.purdue.edu
Date: Sun, 13 Mar 2011 14:08:10 -0400
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] results of threadtest program on Windows7



I'd like to debug the current problem because it does not seem to imply any problem with suspend/resume.  More likely is losing a reference in the stacks somehow.

Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484


On Mar 12, 2011, at 7:40 PM, Jay K wrote:I thought maybe they'd show a way for us to get away with "preemptive suspend",
a way to use SuspendThread/GetThreadContext with confidence.

So, you agree we want cooperative suspend then?
And we should maybe get going on implementing it?
Maybe do that before debugging Mika's problem?
  Well, to repeat myself, I'm ok with looking into 32bit-only Windows for Mika's problem.
  Though, clearly, as i've said, I have A LOT less time for Modula-3 now and probably ever.

 - Jay

Subject: Re: [M3devel] results of threadtest program on Windows7
From: hosking at cs.purdue.edu
Date: Sat, 12 Mar 2011 11:23:04 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

I know they use cooperative suspend.We do in Jikes RVM too.That's another code base to look at.  Probably easier as it is all in Java.
On Mar 12, 2011, at 4:57 AM, Jay K wrote:There is a lack of evidence that Java does things in a way at all resembling what Modula-3 does, on Win32.
 There is precious little in the way of calling the Win32 functions SuspendThread and GetThreadContext.
There is evidence that they use cooperative suspend.
It isn't conclusive, to me..just because there is so much there, it is not immediately clear.
That is, pretty clear there is code implementing cooperative suspend, but is that their entire story? I don't know.

 - Jay

From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] results of threadtest program on Windows7
Date: Thu, 10 Mar 2011 21:03:58 +0000

I often forget this. Thank you.

 - Jay

From: hosking at cs.purdue.edu
Date: Thu, 10 Mar 2011 11:50:40 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] results of threadtest program on Windows7

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/20110313/ee993653/attachment.html>

From dabenavidesd at yahoo.es  Mon Mar 14 17:26:54 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 14 Mar 2011 16:26:54 +0000 (GMT)
Subject: [M3devel] About current DCVS and Elego Compact version to don't
	fear the fork
Message-ID: <224092.3263.qm@web29710.mail.ird.yahoo.com>

Hi all:
I just was wondering was the current status of integration if so of both tools, as I have been reading this techguide, see:
http://www.zdnetasia.com/don-t-fear-the-fork-how-dvcs-aids-open-source-development-62207783.htm?scid=nl_z_tgos

about forks and distributed control version systems (maybe that should I call it diversion?).
Ok, I read that some of the Modules are ready for cvsup in Elego-compact but what about dcvs, does it makes sense for it to have it if it's not already integrated, or would you have considered this before current elego compact release, if there is anything specific towards that integration if so what else would be needed or are they loosely coupled?
I appreciate any comments and opinion about doing that, for instance a given php developer which already has cvsup as its control version system mirror of cvs may want to contract someone to make a fork and so to do that.
Thanks in advance



      


From jay.krell at cornell.edu  Mon Mar 14 20:52:22 2011
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 14 Mar 2011 19:52:22 +0000
Subject: [M3devel] About current DCVS and Elego Compact version to don't
 fear the fork
In-Reply-To: <224092.3263.qm@web29710.mail.ird.yahoo.com>
References: <224092.3263.qm@web29710.mail.ird.yahoo.com>
Message-ID: <COL101-W426E1F003C66371CECA627E6CC0@phx.gbl>


Surely the answer is to use GIT or Mercurial or Monotone.
And not anything based on CVS.
 
 - Jay
 
> Date: Mon, 14 Mar 2011 16:26:54 +0000
> From: dabenavidesd at yahoo.es
> To: m3devel at elegosoft.com
> Subject: [M3devel] About current DCVS and Elego Compact version to don't fear the fork
> 
> Hi all:
> I just was wondering was the current status of integration if so of both tools, as I have been reading this techguide, see:
> http://www.zdnetasia.com/don-t-fear-the-fork-how-dvcs-aids-open-source-development-62207783.htm?scid=nl_z_tgos
> 
> about forks and distributed control version systems (maybe that should I call it diversion?).
> Ok, I read that some of the Modules are ready for cvsup in Elego-compact but what about dcvs, does it makes sense for it to have it if it's not already integrated, or would you have considered this before current elego compact release, if there is anything specific towards that integration if so what else would be needed or are they loosely coupled?
> I appreciate any comments and opinion about doing that, for instance a given php developer which already has cvsup as its control version system mirror of cvs may want to contract someone to make a fork and so to do that.
> Thanks in advance 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/9eab90bd/attachment.html>

From wagner at elegosoft.com  Mon Mar 14 21:25:14 2011
From: wagner at elegosoft.com (Olaf Wagner)
Date: Mon, 14 Mar 2011 21:25:14 +0100
Subject: [M3devel] About current DCVS and Elego Compact version to	don't
	fear the fork
In-Reply-To: <COL101-W426E1F003C66371CECA627E6CC0@phx.gbl>
References: <224092.3263.qm@web29710.mail.ird.yahoo.com>
	<COL101-W426E1F003C66371CECA627E6CC0@phx.gbl>
Message-ID: <20110314212514.edcnep7i8wk8gwkc@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

>
> Surely the answer is to use GIT or Mercurial or Monotone.
> And not anything based on CVS.

Yes. There has never been enough interest in DCVS, though it was fully
functional and quite usable for its time. I would have recommended it
six years ago, but not today.

Olaf

>  - Jay
>
>> Date: Mon, 14 Mar 2011 16:26:54 +0000
>> From: dabenavidesd at yahoo.es
>> To: m3devel at elegosoft.com
>> Subject: [M3devel] About current DCVS and Elego Compact version to   
>> don't fear the fork
>>
>> Hi all:
>> I just was wondering was the current status of integration if so of  
>>  both tools, as I have been reading this techguide, see:
>> http://www.zdnetasia.com/don-t-fear-the-fork-how-dvcs-aids-open-source-development-62207783.htm?scid=nl_z_tgos
>>
>> about forks and distributed control version systems (maybe that   
>> should I call it diversion?).
>> Ok, I read that some of the Modules are ready for cvsup in   
>> Elego-compact but what about dcvs, does it makes sense for it to   
>> have it if it's not already integrated, or would you have   
>> considered this before current elego compact release, if there is   
>> anything specific towards that integration if so what else would be  
>>  needed or are they loosely coupled?
>> I appreciate any comments and opinion about doing that, for   
>> instance a given php developer which already has cvsup as its   
>> control version system mirror of cvs may want to contract someone   
>> to make a fork and so to do that.
>> Thanks in advance



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From dabenavidesd at yahoo.es  Mon Mar 14 22:04:04 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 14 Mar 2011 21:04:04 +0000 (GMT)
Subject: [M3devel] About current DCVS and Elego Compact version to don't
	fear the fork
In-Reply-To: <20110314212514.edcnep7i8wk8gwkc@mail.elegosoft.com>
Message-ID: <707155.91060.qm@web29716.mail.ird.yahoo.com>

Hi all:
Ok, in that sense, how easy would be to abstract it the control machinery of Elego ComPact from its version management (does it subversion classify as DVCS?).
Thanks in advance

--- El lun, 14/3/11, Olaf Wagner <wagner at elegosoft.com> escribi?:

> De: Olaf Wagner <wagner at elegosoft.com>
> Asunto: Re: [M3devel] About current DCVS and Elego Compact version to don't fear the fork
> Para: m3devel at elegosoft.com
> Fecha: lunes, 14 de marzo, 2011 15:25
> Quoting Jay K <jay.krell at cornell.edu>:
> 
> > 
> > Surely the answer is to use GIT or Mercurial or
> Monotone.
> > And not anything based on CVS.
> 
> Yes. There has never been enough interest in DCVS, though
> it was fully
> functional and quite usable for its time. I would have
> recommended it
> six years ago, but not today.
> 
> Olaf
> 
> >  - Jay
> > 
> >> Date: Mon, 14 Mar 2011 16:26:54 +0000
> >> From: dabenavidesd at yahoo.es
> >> To: m3devel at elegosoft.com
> >> Subject: [M3devel] About current DCVS and Elego
> Compact version to  don't fear the fork
> >> 
> >> Hi all:
> >> I just was wondering was the current status of
> integration if so of  both tools, as I have been
> reading this techguide, see:
> >> http://www.zdnetasia.com/don-t-fear-the-fork-how-dvcs-aids-open-source-development-62207783.htm?scid=nl_z_tgos
> >> 
> >> about forks and distributed control version
> systems (maybe that  should I call it diversion?).
> >> Ok, I read that some of the Modules are ready for
> cvsup in  Elego-compact but what about dcvs, does it
> makes sense for it to  have it if it's not already
> integrated, or would you have  considered this before
> current elego compact release, if there is  anything
> specific towards that integration if so what else would
> be  needed or are they loosely coupled?
> >> I appreciate any comments and opinion about doing
> that, for  instance a given php developer which already
> has cvsup as its  control version system mirror of cvs
> may want to contract someone  to make a fork and so to
> do that.
> >> Thanks in advance
> 
> 
> 
> --Olaf Wagner -- elego Software Solutions GmbH
>            
>    Gustav-Meyer-Allee 25 / Geb?ude 12, 13355
> Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345
> 869  fax: +49 30 23 45 86 95
>    http://www.elegosoft.com |
> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 |
> USt-IdNr: DE163214194
> 
> 


      


From rcolebur at SCIRES.COM  Mon Mar 14 22:14:20 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Mon, 14 Mar 2011 17:14:20 -0400
Subject: [M3devel] question re LONGINT
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E603418BD67F@atlex02-srv>

I was making some local mods to Mika's threadtest program to help me debug things a bit more on Windows.

I am trying to do:
   INC(counts[i]);
Where counts is REF ARRAY OF LONGINT

The compiler is complaining:
"..\src\Main.m3", line 189: ** INTERNAL CG ERROR *** unable to find integer type?  type=Int.64  s/o/a=64/0/32

I'm not sure what the status of LONGINT is on Windows.  If it is not fully implemented, let me know and I'll switch to REF ARRAY OF INTEGER, but I really need LONGINT.

Regards,
Randy Coleburn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/937a33f2/attachment.html>

From hosking at cs.purdue.edu  Mon Mar 14 22:21:01 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 14 Mar 2011 17:21:01 -0400
Subject: [M3devel] question re LONGINT
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BD67F@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BD67F@atlex02-srv>
Message-ID: <82BC458A-AEC4-4148-B65D-D6B4B0692CDD@cs.purdue.edu>

This is a known problem which I am still to fix.  I know what the issue is...
You can probably make do by reading counts[i] to a variable, incrementing, and assigning.

On Mar 14, 2011, at 5:14 PM, Coleburn, Randy wrote:

> I was making some local mods to Mika?s threadtest program to help me debug things a bit more on Windows.
>  
> I am trying to do:
>    INC(counts[i]);
> Where counts is REF ARRAY OF LONGINT
>  
> The compiler is complaining:
> "..\src\Main.m3", line 189: ** INTERNAL CG ERROR *** unable to find integer type?  type=Int.64  s/o/a=64/0/32
>  
> I?m not sure what the status of LONGINT is on Windows.  If it is not fully implemented, let me know and I?ll switch to REF ARRAY OF INTEGER, but I really need LONGINT.
>  
> Regards,
> Randy Coleburn
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/4b0192d1/attachment.html>

From jay.krell at cornell.edu  Mon Mar 14 23:33:43 2011
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 14 Mar 2011 22:33:43 +0000
Subject: [M3devel] question re LONGINT
In-Reply-To: <82BC458A-AEC4-4148-B65D-D6B4B0692CDD@cs.purdue.edu>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BD67F@atlex02-srv>,
	<82BC458A-AEC4-4148-B65D-D6B4B0692CDD@cs.purdue.edu>
Message-ID: <COL101-W1613B5382CDB4AA0998526E6CC0@phx.gbl>


 - That error is likely from the frontend and will likely occur for any target. Tony's reply implies this as well.
 
 - LONGINT is believed to fully work on NT386. But more testing is welcome.
 
 - (atomics ditto -- believed to work, testing welcome -- and we should probably use them some, e.g. in MUTEX initialization)
 
 - I would be curious to see if threadtest only fails on 64bit Windows. I haven't tried 32bit yet but I will soon.
   - I was thinking more about this WOW64 GetThreadContext problem and ways to mitigate it, other than cooperative suspend.
     I had already suggested and started to implement scanning the entire stack -- i.e. not depending on an ability to get ESP from a suspended thread.
     Like how FreeBSD and OpenBSD work, albeit it is a significant deoptimization.
     Regarding the rest of the context, perhaps it is a reasonable assumption for now to declare that it doesn't matter? e.g. to know/assume
     that m3back never leaves a value only in registers, that anything in a register will also be on the stack? And to disable optimization on the
     hypothetical MINGW platforms. ?
     But still to confirm if there are no problems on 32bit, and to mull over implementing cooperative suspend..in the little time available...
     (Oh, and also, I wonder if SuspendThread can suspend a thread while in the kernel, probably, and if GetThreadContext returns
     the kernel context in that case; should be easy to determine via some experimentation -- which would imply a problem on 32bit Windows also.)
 
 
 - Jay
 


From: hosking at cs.purdue.edu
Date: Mon, 14 Mar 2011 17:21:01 -0400
To: rcolebur at SCIRES.COM
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] question re LONGINT


This is a known problem which I am still to fix.  I know what the issue is...
You can probably make do by reading counts[i] to a variable, incrementing, and assigning.




On Mar 14, 2011, at 5:14 PM, Coleburn, Randy wrote:



I was making some local mods to Mika?s threadtest program to help me debug things a bit more on Windows.
 
I am trying to do:
   INC(counts[i]);
Where counts is REF ARRAY OF LONGINT
 
The compiler is complaining:
"..\src\Main.m3", line 189: ** INTERNAL CG ERROR *** unable to find integer type?  type=Int.64  s/o/a=64/0/32
 
I?m not sure what the status of LONGINT is on Windows.  If it is not fully implemented, let me know and I?ll switch to REF ARRAY OF INTEGER, but I really need LONGINT.
 
Regards,
Randy Coleburn
 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/38fe3b7e/attachment.html>

From rcolebur at SCIRES.COM  Mon Mar 14 23:45:44 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Mon, 14 Mar 2011 18:45:44 -0400
Subject: [M3devel] question on use of Time.Now in thread test program
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E603418BD6A3@atlex02-srv>

I have a question/concern regarding Mika's thread test program.

Each of the threads makes use of the Time.Now() call during each iteration of the thread's main loop.

I haven't fully investigated, but does anyone have concern that so many calls to the system clock from multiple competing threads might have some side effect on the running of multiple threads?

I've also done some limited experimentation with use of counters to see how many times each type of thread is able to go thru its loop between reporting intervals.

I continue to see various types of crashes on Windows 7 (64-bit), but sometimes tests are able to succeed.  I haven't found a repeatable pattern yet to the crashes, so I am still investigating, but just thought it worth asking the above question about use of Time.Now().

I will also try to experiment with Windows XP 32-bit and report back.

Regards,
Randy Coleburn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/4fc9452e/attachment.html>

From jay.krell at cornell.edu  Tue Mar 15 00:07:15 2011
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 14 Mar 2011 23:07:15 +0000
Subject: [M3devel] question on use of Time.Now in thread test program
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BD6A3@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BD6A3@atlex02-srv>
Message-ID: <COL101-W16E61CE9DCE94C7C824631E6CC0@phx.gbl>


Time.Now() is very cheap on Windows and should cause no concern.
It is just GetSystemTimeAsFileTime, which just reads some globals, followed by a simple unit and integer to double conversion.
I would avoid 64bit Windows for now, very unfortunate, but I don't trust GetThreadContext.
 
 
PROCEDURE Now(): T=
  VAR
    fileTime: WinBase.FILETIME;
  BEGIN
    WinBase.GetSystemTimeAsFileTime(fileTime);
    RETURN TimeWin32.FromFileTime(fileTime);
  END Now;


double
__cdecl
TimeWin32__FromFileTime(FILETIME ft)
{
    LARGE_INTEGER li;

    li.LowPart = ft.dwLowDateTime;
    li.HighPart = ft.dwHighDateTime;
    return ((double)li.QuadPart) / 1.0e7;
}


Hm -- I don't like passing structs by value, too hard to be sure how it works -- I'd like to change this to be "READONLY" -- passed by pointer.
Maybe code the entire thing in Modula-3 -- or more likely, the entire thing in C.
 
Time.Now() might be more expensive on other platform, I don't know.
 
I also see some failures, some success, no pattern.
I think the success is just luck and the code is by its nature very non-deterministic.
 
 - Jay
 


From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Mon, 14 Mar 2011 18:45:44 -0400
Subject: [M3devel] question on use of Time.Now in thread test program






I have a question/concern regarding Mika?s thread test program.
 
Each of the threads makes use of the Time.Now() call during each iteration of the thread?s main loop.  
 
I haven?t fully investigated, but does anyone have concern that so many calls to the system clock from multiple competing threads might have some side effect on the running of multiple threads?
 
I?ve also done some limited experimentation with use of counters to see how many times each type of thread is able to go thru its loop between reporting intervals.
 
I continue to see various types of crashes on Windows 7 (64-bit), but sometimes tests are able to succeed.  I haven?t found a repeatable pattern yet to the crashes, so I am still investigating, but just thought it worth asking the above question about use of Time.Now().
 
I will also try to experiment with Windows XP 32-bit and report back.
 
Regards,
Randy Coleburn 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/b0dca15e/attachment.html>

From dabenavidesd at yahoo.es  Tue Mar 15 00:21:49 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 14 Mar 2011 23:21:49 +0000 (GMT)
Subject: [M3devel] question on use of Time.Now in thread test program
In-Reply-To: <COL101-W16E61CE9DCE94C7C824631E6CC0@phx.gbl>
Message-ID: <569254.84801.qm@web29712.mail.ird.yahoo.com>

Hi all:
see at:
http://www.ic.unicamp.br/~stolfi/EXPORT/software/m3/Misc.html 

CPUTime module.
Thanks in advance

--- El lun, 14/3/11, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] question on use of Time.Now in thread test program
Para: rcolebur at scires.com, "m3devel" <m3devel at elegosoft.com>
Fecha: lunes, 14 de marzo, 2011 18:07




Time.Now() is very cheap on Windows and should cause no concern.

It is just GetSystemTimeAsFileTime, which just reads some globals, followed by a simple unit and integer to double conversion.

I would avoid 64bit Windows for now, very unfortunate, but I don't trust GetThreadContext.

?

?

PROCEDURE Now(): T=
? VAR
??? fileTime: WinBase.FILETIME;
? BEGIN
??? WinBase.GetSystemTimeAsFileTime(fileTime);
??? RETURN TimeWin32.FromFileTime(fileTime);
? END Now;



double
__cdecl
TimeWin32__FromFileTime(FILETIME ft)
{
??? LARGE_INTEGER li;

??? li.LowPart = ft.dwLowDateTime;
??? li.HighPart = ft.dwHighDateTime;
??? return ((double)li.QuadPart) / 1.0e7;
}



Hm -- I don't like passing structs by value, too hard to be sure how it works -- I'd like to change this to be "READONLY" -- passed by pointer.

Maybe code the entire thing in Modula-3 -- or more likely, the entire thing in C.

?

Time.Now() might be more expensive on other platform, I don't know.

?

I also see some failures, some success, no pattern.

I think the success is just luck and the code is by its nature very non-deterministic.

?

?- Jay
?



From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Mon, 14 Mar 2011 18:45:44 -0400
Subject: [M3devel] question on use of Time.Now in thread test program


 

#yiv1082952660 .yiv1082952660ExternalClass p.yiv1082952660ecxMsoNormal, #yiv1082952660 .yiv1082952660ExternalClass li.yiv1082952660ecxMsoNormal, #yiv1082952660 .yiv1082952660ExternalClass div.yiv1082952660ecxMsoNormal
{margin-bottom:.0001pt;font-size:11.0pt;font-family:'sans-serif';}
#yiv1082952660 .yiv1082952660ExternalClass a:link, #yiv1082952660 .yiv1082952660ExternalClass span.yiv1082952660ecxMsoHyperlink
{color:blue;text-decoration:underline;}
#yiv1082952660 .yiv1082952660ExternalClass a:visited, #yiv1082952660 .yiv1082952660ExternalClass span.yiv1082952660ecxMsoHyperlinkFollowed
{color:purple;text-decoration:underline;}
#yiv1082952660 .yiv1082952660ExternalClass span.yiv1082952660ecxEmailStyle17
{font-family:'sans-serif';color:windowtext;}
#yiv1082952660 .yiv1082952660ExternalClass .yiv1082952660ecxMsoChpDefault
{}
 _filtered #yiv1082952660 {}
#yiv1082952660 .yiv1082952660ExternalClass div.yiv1082952660ecxWordSection1
{}




I have a question/concern regarding Mika?s thread test program.
?
Each of the threads makes use of the Time.Now() call during each iteration of the thread?s main loop.? 
?
I haven?t fully investigated, but does anyone have concern that so many calls to the system clock from multiple competing threads might have some side effect on the running of multiple threads?
?
I?ve also done some limited experimentation with use of counters to see how many times each type of thread is able to go thru its loop between reporting intervals.
?
I continue to see various types of crashes on Windows 7 (64-bit), but sometimes tests are able to succeed.? I haven?t found a repeatable pattern yet to the crashes, so I am still investigating, but just thought it worth asking the above question about use of Time.Now().
?
I will also try to experiment with Windows XP 32-bit and report back.
?
Regards,
Randy Coleburn 		 	   		  



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/5b36d1fd/attachment.html>

From jay.krell at cornell.edu  Tue Mar 15 00:48:23 2011
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 14 Mar 2011 23:48:23 +0000
Subject: [M3devel] question on use of Time.Now in thread test program
In-Reply-To: <569254.84801.qm@web29712.mail.ird.yahoo.com>
References: <COL101-W16E61CE9DCE94C7C824631E6CC0@phx.gbl>,
	<569254.84801.qm@web29712.mail.ird.yahoo.com>
Message-ID: <COL101-W2A6D6D82DFF94AD42BA35E6CC0@phx.gbl>


Please don't use Uresource.struct_rusage in Modula-3.
I removed it. It is a portabilty/maintenance problem.
 
 - Jay

 


Date: Mon, 14 Mar 2011 23:21:49 +0000
From: dabenavidesd at yahoo.es
To: rcolebur at scires.com; m3devel at elegosoft.com; jay.krell at cornell.edu
Subject: Re: [M3devel] question on use of Time.Now in thread test program





Hi all:
see at:
http://www.ic.unicamp.br/~stolfi/EXPORT/software/m3/Misc.html 

CPUTime module.
Thanks in advance

--- El lun, 14/3/11, Jay K <jay.krell at cornell.edu> escribi?:


De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] question on use of Time.Now in thread test program
Para: rcolebur at scires.com, "m3devel" <m3devel at elegosoft.com>
Fecha: lunes, 14 de marzo, 2011 18:07




Time.Now() is very cheap on Windows and should cause no concern.
It is just GetSystemTimeAsFileTime, which just reads some globals, followed by a simple unit and integer to double conversion.
I would avoid 64bit Windows for now, very unfortunate, but I don't trust GetThreadContext.
 
 
PROCEDURE Now(): T=
  VAR
    fileTime: WinBase.FILETIME;
  BEGIN
    WinBase.GetSystemTimeAsFileTime(fileTime);
    RETURN TimeWin32.FromFileTime(fileTime);
  END Now;


double
__cdecl
TimeWin32__FromFileTime(FILETIME ft)
{
    LARGE_INTEGER li;

    li.LowPart = ft.dwLowDateTime;
    li.HighPart = ft.dwHighDateTime;
    return ((double)li.QuadPart) / 1.0e7;
}


Hm -- I don't like passing structs by value, too hard to be sure how it works -- I'd like to change this to be "READONLY" -- passed by pointer.
Maybe code the entire thing in Modula-3 -- or more likely, the entire thing in C.
 
Time.Now() might be more expensive on other platform, I don't know.
 
I also see some failures, some success, no pattern.
I think the success is just luck and the code is by its nature very non-deterministic.
 
 - Jay
 


From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Mon, 14 Mar 2011 18:45:44 -0400
Subject: [M3devel] question on use of Time.Now in thread test program





I have a question/concern regarding Mika?s thread test program.
 
Each of the threads makes use of the Time.Now() call during each iteration of the thread?s main loop.  
 
I haven?t fully investigated, but does anyone have concern that so many calls to the system clock from multiple competing threads might have some side effect on the running of multiple threads?
 
I?ve also done some limited experimentation with use of counters to see how many times each type of thread is able to go thru its loop between reporting intervals.
 
I continue to see various types of crashes on Windows 7 (64-bit), but sometimes tests are able to succeed.  I haven?t found a repeatable pattern yet to the crashes, so I am still investigating, but just thought it worth asking the above question about use of Time.Now().
 
I will also try to experiment with Windows XP 32-bit and report back.
 
Regards,
Randy Coleburn
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/7153deb4/attachment.html>

From hosking at cs.purdue.edu  Tue Mar 15 00:50:24 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 14 Mar 2011 19:50:24 -0400
Subject: [M3devel] question re LONGINT
In-Reply-To: <COL101-W1613B5382CDB4AA0998526E6CC0@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BD67F@atlex02-srv>,
	<82BC458A-AEC4-4148-B65D-D6B4B0692CDD@cs.purdue.edu>
	<COL101-W1613B5382CDB4AA0998526E6CC0@phx.gbl>
Message-ID: <C1309C40-1D9F-4C67-80A7-E04C9FDF3554@cs.purdue.edu>

On Mar 14, 2011, at 6:33 PM, Jay K wrote:

>  - That error is likely from the frontend and will likely occur for any target. Tony's reply implies this as well.
>  
>  - LONGINT is believed to fully work on NT386. But more testing is welcome.
>  
>  - (atomics ditto -- believed to work, testing welcome -- and we should probably use them some, e.g. in MUTEX initialization)

They are still slightly broken.  I have some fixes still to check in.  If only I could find some time to test everything...
But, they will be essential if we ever do cooperative thread suspension.

>   - I would be curious to see if threadtest only fails on 64bit Windows. I haven't tried 32bit yet but I will soon.
>    - I was thinking more about this WOW64 GetThreadContext problem and ways to mitigate it, other than cooperative suspend.
>      I had already suggested and started to implement scanning the entire stack -- i.e. not depending on an ability to get ESP from a suspended thread.
>      Like how FreeBSD and OpenBSD work, albeit it is a significant deoptimization.
>      Regarding the rest of the context, perhaps it is a reasonable assumption for now to declare that it doesn't matter? e.g. to know/assume
>      that m3back never leaves a value only in registers, that anything in a register will also be on the stack? And to disable optimization on the
>      hypothetical MINGW platforms. ?
>      But still to confirm if there are no problems on 32bit, and to mull over implementing cooperative suspend..in the little time available...
>      (Oh, and also, I wonder if SuspendThread can suspend a thread while in the kernel, probably, and if GetThreadContext returns
>      the kernel context in that case; should be easy to determine via some experimentation -- which would imply a problem on 32bit Windows also.)
>  
>  
>  - Jay
>  
> From: hosking at cs.purdue.edu
> Date: Mon, 14 Mar 2011 17:21:01 -0400
> To: rcolebur at SCIRES.COM
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] question re LONGINT
> 
> This is a known problem which I am still to fix.  I know what the issue is...
> You can probably make do by reading counts[i] to a variable, incrementing, and assigning.
> 
> On Mar 14, 2011, at 5:14 PM, Coleburn, Randy wrote:
> 
> I was making some local mods to Mika?s threadtest program to help me debug things a bit more on Windows.
>  
> I am trying to do:
>    INC(counts[i]);
> Where counts is REF ARRAY OF LONGINT
>  
> The compiler is complaining:
> "..\src\Main.m3", line 189: ** INTERNAL CG ERROR *** unable to find integer type?  type=Int.64  s/o/a=64/0/32
>  
> I?m not sure what the status of LONGINT is on Windows.  If it is not fully implemented, let me know and I?ll switch to REF ARRAY OF INTEGER, but I really need LONGINT.
>  
> Regards,
> Randy Coleburn
>  
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/552f4ee8/attachment.html>

From hosking at cs.purdue.edu  Tue Mar 15 02:06:53 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 14 Mar 2011 21:06:53 -0400
Subject: [M3devel] question re LONGINT
In-Reply-To: <COL101-W1613B5382CDB4AA0998526E6CC0@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BD67F@atlex02-srv>,
	<82BC458A-AEC4-4148-B65D-D6B4B0692CDD@cs.purdue.edu>
	<COL101-W1613B5382CDB4AA0998526E6CC0@phx.gbl>
Message-ID: <5B02FDDE-41EA-42FD-A57B-ECED6C626AC8@cs.purdue.edu>

On Mar 14, 2011, at 6:33 PM, Jay K wrote:

>  - That error is likely from the frontend and will likely occur for any target. Tony's reply implies this as well.
>  
>  - LONGINT is believed to fully work on NT386. But more testing is welcome.
>  
>  - (atomics ditto -- believed to work, testing welcome -- and we should probably use them some, e.g. in MUTEX initialization)

They are still slightly broken.  I have some fixes still to check in.  If only I could find some time to test everything...
But, they will be essential if we ever do cooperative thread suspension.

>   - I would be curious to see if threadtest only fails on 64bit Windows. I haven't tried 32bit yet but I will soon.
>    - I was thinking more about this WOW64 GetThreadContext problem and ways to mitigate it, other than cooperative suspend.
>      I had already suggested and started to implement scanning the entire stack -- i.e. not depending on an ability to get ESP from a suspended thread.
>      Like how FreeBSD and OpenBSD work, albeit it is a significant deoptimization.
>      Regarding the rest of the context, perhaps it is a reasonable assumption for now to declare that it doesn't matter? e.g. to know/assume
>      that m3back never leaves a value only in registers, that anything in a register will also be on the stack? And to disable optimization on the
>      hypothetical MINGW platforms. ?
>      But still to confirm if there are no problems on 32bit, and to mull over implementing cooperative suspend..in the little time available...
>      (Oh, and also, I wonder if SuspendThread can suspend a thread while in the kernel, probably, and if GetThreadContext returns
>      the kernel context in that case; should be easy to determine via some experimentation -- which would imply a problem on 32bit Windows also.)
>  
>  
>  - Jay
>  
> From: hosking at cs.purdue.edu
> Date: Mon, 14 Mar 2011 17:21:01 -0400
> To: rcolebur at SCIRES.COM
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] question re LONGINT
> 
> This is a known problem which I am still to fix.  I know what the issue is...
> You can probably make do by reading counts[i] to a variable, incrementing, and assigning.
> 
> On Mar 14, 2011, at 5:14 PM, Coleburn, Randy wrote:
> 
> I was making some local mods to Mika?s threadtest program to help me debug things a bit more on Windows.
>  
> I am trying to do:
>    INC(counts[i]);
> Where counts is REF ARRAY OF LONGINT
>  
> The compiler is complaining:
> "..\src\Main.m3", line 189: ** INTERNAL CG ERROR *** unable to find integer type?  type=Int.64  s/o/a=64/0/32
>  
> I?m not sure what the status of LONGINT is on Windows.  If it is not fully implemented, let me know and I?ll switch to REF ARRAY OF INTEGER, but I really need LONGINT.
>  
> Regards,
> Randy Coleburn
>  
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/7a5b1085/attachment.html>

From rcolebur at SCIRES.COM  Tue Mar 15 02:40:12 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Mon, 14 Mar 2011 21:40:12 -0400
Subject: [M3devel] draft new edition of thread test program
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E603418BD6AD@atlex02-srv>

Mika et al:

I didn't want to check in a modified version of your program without everyone agreeing my modifications are desired.

Attached is my modified source code.  See if you think the modifications are worthy of adding to the program, or feel free to adjust further, or just tell me you don't want to add them.  If you want me to check in the modified source, let me know.

Basically, I've done 2 things:


1.       Added pp.finish() in command line parsing so that if you put extra arguments on command line that aren't parsed, you will get an error message.  For example, I keep finding I sometimes separate the test names with space instead of comma, only to realize after program starts that the extra arguments were ignored.  (We could also change the specs to allow for comma to be used as a test name separator.)


2.       Added "-verbose" command line option.  If you choose this option, extra information is printed, namely:  as threads are created, their "id" is printed and then for each iteration, the number of times each thread executed its main loop is printed.  Also, if a thread doesn't make any progress on an iteration, a notice that the thread may be starved or deadlocked is printed.

Unless you use -verbose, the program output is the same as your version, except that if you give extra command line arguments, the program will abort and notify you.  For example,
C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -tests read lock
ParseParams: parameter 4 = "lock" extraneous or misplaced.

*** Couldnt parse cmd-line args.

Now, running on Windows 7 (64-bit), I still get non-deterministic behavior and some crashes.  For example:
C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,lock
Writing file...done
Creating read threads...
   read=0
   read=1
   read=2
done
Creating lock threads...
   lock=21
   lock=22
   lock=23
done
running...printing oldest/median age/newest
..........laziest thread is 0/0/0 (tests: read 0/0/0 lock 0/0/0)
   read Thread 0 completed 1670 loops.
   read Thread 1 completed 1692 loops.
   read Thread 2 completed 1849 loops.
   lock Thread 21 completed 11788253 loops.
   lock Thread 22 completed 9448889 loops.
   lock Thread 23 completed 9480853 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 lock 0/0/0)
   read Thread 0 completed 2148 loops.
   read Thread 1 completed 2113 loops.
   read Thread 2 completed 2343 loops.
   lock Thread 21 completed 13326765 loops.
   lock Thread 22 completed 11327588 loops.
   lock Thread 23 completed 12743882 loops.
.......

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0x126e37d = Move + 0x50 in ..\src\runtime\common\RTCollector.m3
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

I'll try on 32-bit XP soon and report.

Regards,
Randy Coleburn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/448a0612/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Main.m3
Type: application/octet-stream
Size: 18584 bytes
Desc: Main.m3
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/448a0612/attachment.obj>

From hosking at cs.purdue.edu  Tue Mar 15 03:44:10 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 14 Mar 2011 22:44:10 -0400
Subject: [M3devel] draft new edition of thread test program
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BD6AD@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BD6AD@atlex02-srv>
Message-ID: <A347E6AC-DAD7-4792-AD0D-C45712E46299@cs.purdue.edu>

In the face of these crashes it would be best to run all tests with the @M3paranoidgc flag at all times.

On Mar 14, 2011, at 9:40 PM, Coleburn, Randy wrote:

> Mika et al:
>  
> I didn?t want to check in a modified version of your program without everyone agreeing my modifications are desired.
>  
> Attached is my modified source code.  See if you think the modifications are worthy of adding to the program, or feel free to adjust further, or just tell me you don?t want to add them.  If you want me to check in the modified source, let me know.
>  
> Basically, I?ve done 2 things:
> 
> 1.       Added pp.finish() in command line parsing so that if you put extra arguments on command line that aren?t parsed, you will get an error message.  For example, I keep finding I sometimes separate the test names with space instead of comma, only to realize after program starts that the extra arguments were ignored.  (We could also change the specs to allow for comma to be used as a test name separator.)
> 
> 2.       Added ??verbose? command line option.  If you choose this option, extra information is printed, namely:  as threads are created, their ?id? is printed and then for each iteration, the number of times each thread executed its main loop is printed.  Also, if a thread doesn?t make any progress on an iteration, a notice that the thread may be starved or deadlocked is printed.
>  
> Unless you use ?verbose, the program output is the same as your version, except that if you give extra command line arguments, the program will abort and notify you.  For example,
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -tests read lock
> ParseParams: parameter 4 = "lock" extraneous or misplaced.
>  
> *** Couldnt parse cmd-line args.
>  
> Now, running on Windows 7 (64-bit), I still get non-deterministic behavior and some crashes.  For example:
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,lock
> Writing file...done
> Creating read threads...
>    read=0
>    read=1
>    read=2
> done
> Creating lock threads...
>    lock=21
>    lock=22
>    lock=23
> done
> running...printing oldest/median age/newest
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 lock 0/0/0)
>    read Thread 0 completed 1670 loops.
>    read Thread 1 completed 1692 loops.
>    read Thread 2 completed 1849 loops.
>    lock Thread 21 completed 11788253 loops.
>    lock Thread 22 completed 9448889 loops.
>    lock Thread 23 completed 9480853 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 lock 0/0/0)
>    read Thread 0 completed 2148 loops.
>    read Thread 1 completed 2113 loops.
>    read Thread 2 completed 2343 loops.
>    lock Thread 21 completed 13326765 loops.
>    lock Thread 22 completed 11327588 loops.
>    lock Thread 23 completed 12743882 loops.
> .......
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
> ***    pc = 0x126e37d = Move + 0x50 in ..\src\runtime\common\RTCollector.m3
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> I?ll try on 32-bit XP soon and report.
>  
> Regards,
> Randy Coleburn
>  
> <Main.m3>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/13a33906/attachment.html>

From mika at async.caltech.edu  Wed Mar 16 16:40:27 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Wed, 16 Mar 2011 08:40:27 -0700
Subject: [M3devel] draft new edition of thread test program
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BD6AD@atlex02-srv> 
References: <D67F02DDC62F7545A6B84C285F88F3E603418BD6AD@atlex02-srv>
Message-ID: <20110316154027.14DAF1A2078@async.async.caltech.edu>

Hi Randy,

No objections from me!

     Mika

"Coleburn, Randy" writes:
>--_004_D67F02DDC62F7545A6B84C285F88F3E603418BD6ADatlex02srv_
>Content-Type: multipart/alternative;
>	boundary="_000_D67F02DDC62F7545A6B84C285F88F3E603418BD6ADatlex02srv_"
>
>--_000_D67F02DDC62F7545A6B84C285F88F3E603418BD6ADatlex02srv_
>Content-Type: text/plain; charset="us-ascii"
>Content-Transfer-Encoding: quoted-printable
>
>Mika et al:
>
>I didn't want to check in a modified version of your program without everyo=
>ne agreeing my modifications are desired.
>
>Attached is my modified source code.  See if you think the modifications ar=
>e worthy of adding to the program, or feel free to adjust further, or just =
>tell me you don't want to add them.  If you want me to check in the modifie=
>d source, let me know.
>
>Basically, I've done 2 things:
>
>
>1.       Added pp.finish() in command line parsing so that if you put extra=
> arguments on command line that aren't parsed, you will get an error messag=
>e.  For example, I keep finding I sometimes separate the test names with sp=
>ace instead of comma, only to realize after program starts that the extra a=
>rguments were ignored.  (We could also change the specs to allow for comma =
>to be used as a test name separator.)
>
>
>2.       Added "-verbose" command line option.  If you choose this option, =
>extra information is printed, namely:  as threads are created, their "id" i=
>s printed and then for each iteration, the number of times each thread exec=
>uted its main loop is printed.  Also, if a thread doesn't make any progress=
> on an iteration, a notice that the thread may be starved or deadlocked is =
>printed.
>
>Unless you use -verbose, the program output is the same as your version, ex=
>cept that if you give extra command line arguments, the program will abort =
>and notify you.  For example,
>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -tests read=
> lock
>ParseParams: parameter 4 =3D "lock" extraneous or misplaced.
>
>*** Couldnt parse cmd-line args.
>
>Now, running on Windows 7 (64-bit), I still get non-deterministic behavior =
>and some crashes.  For example:
>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -t=
>ests read,lock
>Writing file...done
>Creating read threads...
>   read=3D0
>   read=3D1
>   read=3D2
>done
>Creating lock threads...
>   lock=3D21
>   lock=3D22
>   lock=3D23
>done
>running...printing oldest/median age/newest
>..........laziest thread is 0/0/0 (tests: read 0/0/0 lock 0/0/0)
>   read Thread 0 completed 1670 loops.
>   read Thread 1 completed 1692 loops.
>   read Thread 2 completed 1849 loops.
>   lock Thread 21 completed 11788253 loops.
>   lock Thread 22 completed 9448889 loops.
>   lock Thread 23 completed 9480853 loops.
>..........laziest thread is 0/0/0 (tests: read 0/0/0 lock 0/0/0)
>   read Thread 0 completed 2148 loops.
>   read Thread 1 completed 2113 loops.
>   read Thread 2 completed 2343 loops.
>   lock Thread 21 completed 13326765 loops.
>   lock Thread 22 completed 11327588 loops.
>   lock Thread 23 completed 12743882 loops.
>.......
>
>***
>*** runtime error:
>***    Attempt to reference an illegal memory location.
>
>***
>*** runtime error:
>***    Attempt to reference an illegal memory location.
>
>***
>*** runtime error:
>***    Attempt to reference an illegal memory location.
>***    pc =3D 0x126e37d =3D Move + 0x50 in ..\src\runtime\common\RTCollecto=
>r.m3
>***
>
>***
>*** runtime error:
>***    <*ASSERT*> failed.
>***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
>***
>
>***
>*** runtime error:
>***    <*ASSERT*> failed.
>***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
>***
>
>***
>*** runtime error:
>***    <*ASSERT*> failed.
>***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
>***
>
>I'll try on 32-bit XP soon and report.
>
>Regards,
>Randy Coleburn
>
>
>--_000_D67F02DDC62F7545A6B84C285F88F3E603418BD6ADatlex02srv_
>Content-Type: text/html; charset="us-ascii"
>Content-Transfer-Encoding: quoted-printable
>
><html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
>osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
>xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
>icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
>:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
>uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
>t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
>m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
>t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
>:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
>soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
>xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
>icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
>schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
>point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
>/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
>=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
>schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
>.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
>/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
>://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
>repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
> xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
>schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
>/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
>ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
>p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
>/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
>mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
>crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
>s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
>ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
>om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
>ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
>partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
>06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
>6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
>deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
>Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
>st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta http-equi=
>v=3DContent-Type content=3D"text/html; charset=3Dus-ascii"><meta name=3DGen=
>erator content=3D"Microsoft Word 12 (filtered medium)"><style><!--
>/* Font Definitions */
>@font-face
>	{font-family:"Cambria Math";
>	panose-1:2 4 5 3 5 4 6 3 2 4;}
>@font-face
>	{font-family:Calibri;
>	panose-1:2 15 5 2 2 2 4 3 2 4;}
>/* Style Definitions */
>p.MsoNormal, li.MsoNormal, div.MsoNormal
>	{margin:0in;
>	margin-bottom:.0001pt;
>	font-size:11.0pt;
>	font-family:"Calibri","sans-serif";}
>a:link, span.MsoHyperlink
>	{mso-style-priority:99;
>	color:blue;
>	text-decoration:underline;}
>a:visited, span.MsoHyperlinkFollowed
>	{mso-style-priority:99;
>	color:purple;
>	text-decoration:underline;}
>p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
>	{mso-style-priority:34;
>	margin-top:0in;
>	margin-right:0in;
>	margin-bottom:0in;
>	margin-left:.5in;
>	margin-bottom:.0001pt;
>	font-size:11.0pt;
>	font-family:"Calibri","sans-serif";}
>span.EmailStyle17
>	{mso-style-type:personal-compose;
>	font-family:"Calibri","sans-serif";
>	color:windowtext;}
>.MsoChpDefault
>	{mso-style-type:export-only;}
>@page WordSection1
>	{size:8.5in 11.0in;
>	margin:1.0in 1.0in 1.0in 1.0in;}
>div.WordSection1
>	{page:WordSection1;}
>/* List Definitions */
>@list l0
>	{mso-list-id:384720956;
>	mso-list-type:hybrid;
>	mso-list-template-ids:982285054 67698703 67698713 67698715 67698703 676987=
>13 67698715 67698703 67698713 67698715;}
>@list l0:level1
>	{mso-level-tab-stop:none;
>	mso-level-number-position:left;
>	text-indent:-.25in;}
>ol
>	{margin-bottom:0in;}
>ul
>	{margin-bottom:0in;}
>--></style><!--[if gte mso 9]><xml>
><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
></xml><![endif]--><!--[if gte mso 9]><xml>
><o:shapelayout v:ext=3D"edit">
><o:idmap v:ext=3D"edit" data=3D"1" />
></o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
>nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>Mika et al:<o:p>=
></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>I =
>didn&#8217;t want to check in a modified version of your program without ev=
>eryone agreeing my modifications are desired.<o:p></o:p></p><p class=3DMsoN=
>ormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>Attached is my modified sou=
>rce code.&nbsp; See if you think the modifications are worthy of adding to =
>the program, or feel free to adjust further, or just tell me you don&#8217;=
>t want to add them.&nbsp; If you want me to check in the modified source, l=
>et me know.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p clas=
>s=3DMsoNormal>Basically, I&#8217;ve done 2 things:<br><br><o:p></o:p></p><p=
> class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 lf=
>o1'><![if !supportLists]><span style=3D'mso-list:Ignore'>1.<span style=3D'f=
>ont:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></=
>span><![endif]>Added <b>pp.finish()</b> in command line parsing so that if =
>you put extra arguments on command line that aren&#8217;t parsed, you will =
>get an error message.&nbsp; For example, I keep finding I sometimes separat=
>e the test names with space instead of comma, only to realize after program=
> starts that the extra arguments were ignored.&nbsp; (We could also change =
>the specs to allow for comma to be used as a test name separator.)<br><br><=
>o:p></o:p></p><p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-l=
>ist:l0 level1 lfo1'><![if !supportLists]><span style=3D'mso-list:Ignore'>2.=
><span style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
>&nbsp; </span></span><![endif]>Added &#8220;<b>&#8211;verbose</b>&#8221; co=
>mmand line option.&nbsp; If you choose this option, extra information is pr=
>inted, namely: &nbsp;as threads are created, their &#8220;id&#8221; is prin=
>ted and then for each iteration, the number of times each thread executed i=
>ts main loop is printed.&nbsp; Also, if a thread doesn&#8217;t make any pro=
>gress on an iteration, a notice that the thread may be starved or deadlocke=
>d is printed.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p cl=
>ass=3DMsoNormal>Unless you use &#8211;verbose, the program output is the sa=
>me as your version, except that if you give extra command line arguments, t=
>he program will abort and notify you.&nbsp; For example,<o:p></o:p></p><p c=
>lass=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Cou=
>rier New"'>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt;threadtest.e=
>xe -tests read lock<o:p></o:p></span></p><p class=3DMsoNormal style=3D'marg=
>in-left:.5in'><span style=3D'font-family:"Courier New"'>ParseParams: parame=
>ter 4 =3D &quot;lock&quot; extraneous or misplaced.<o:p></o:p></span></p><p=
> class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"C=
>ourier New"'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal style=3D'marg=
>in-left:.5in'><span style=3D'font-family:"Courier New"'>*** Couldnt parse c=
>md-line args.<o:p></o:p></span></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></=
>p><p class=3DMsoNormal>Now, running on Windows 7 (64-bit), I still get non-=
>deterministic behavior and some crashes.&nbsp; For example:<o:p></o:p></p><=
>p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"=
>Courier New"'>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt;threadtes=
>t.exe -verbose -tests read,lock<o:p></o:p></span></p><p class=3DMsoNormal s=
>tyle=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'>Writing=
> file...done<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left=
>:.5in'><span style=3D'font-family:"Courier New"'>Creating read threads...<o=
>:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span s=
>tyle=3D'font-family:"Courier New"'>&nbsp;&nbsp; read=3D0<o:p></o:p></span><=
>/p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-fami=
>ly:"Courier New"'>&nbsp;&nbsp; read=3D1<o:p></o:p></span></p><p class=3DMso=
>Normal style=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'=
>>&nbsp;&nbsp; read=3D2<o:p></o:p></span></p><p class=3DMsoNormal style=3D'm=
>argin-left:.5in'><span style=3D'font-family:"Courier New"'>done<o:p></o:p><=
>/span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'fo=
>nt-family:"Courier New"'>Creating lock threads...<o:p></o:p></span></p><p c=
>lass=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Cou=
>rier New"'>&nbsp;&nbsp; lock=3D21<o:p></o:p></span></p><p class=3DMsoNormal=
> style=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'>&nbsp=
>;&nbsp; lock=3D22<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin=
>-left:.5in'><span style=3D'font-family:"Courier New"'>&nbsp;&nbsp; lock=3D2=
>3<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><spa=
>n style=3D'font-family:"Courier New"'>done<o:p></o:p></span></p><p class=3D=
>MsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Courier Ne=
>w"'>running...printing oldest/median age/newest<o:p></o:p></span></p><p cla=
>ss=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Couri=
>er New"'>..........laziest thread is 0/0/0 (tests: read 0/0/0 lock 0/0/0)<o=
>:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span s=
>tyle=3D'font-family:"Courier New"'>&nbsp;&nbsp; read Thread 0 completed 167=
>0 loops.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5i=
>n'><span style=3D'font-family:"Courier New"'>&nbsp;&nbsp; read Thread 1 com=
>pleted 1692 loops.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margi=
>n-left:.5in'><span style=3D'font-family:"Courier New"'>&nbsp;&nbsp; read Th=
>read 2 completed 1849 loops.<o:p></o:p></span></p><p class=3DMsoNormal styl=
>e=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'>&nbsp;&nbs=
>p; lock Thread 21 completed 11788253 loops.<o:p></o:p></span></p><p class=
>=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Courier=
> New"'>&nbsp;&nbsp; lock Thread 22 completed 9448889 loops.<o:p></o:p></spa=
>n></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-f=
>amily:"Courier New"'>&nbsp;&nbsp; lock Thread 23 completed 9480853 loops.<o=
>:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span s=
>tyle=3D'font-family:"Courier New"'>..........laziest thread is 0/0/0 (tests=
>: read 0/0/0 lock 0/0/0)<o:p></o:p></span></p><p class=3DMsoNormal style=3D=
>'margin-left:.5in'><span style=3D'font-family:"Courier New"'>&nbsp;&nbsp; r=
>ead Thread 0 completed 2148 loops.<o:p></o:p></span></p><p class=3DMsoNorma=
>l style=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'>&nbs=
>p;&nbsp; read Thread 1 completed 2113 loops.<o:p></o:p></span></p><p class=
>=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Courier=
> New"'>&nbsp;&nbsp; read Thread 2 completed 2343 loops.<o:p></o:p></span></=
>p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-famil=
>y:"Courier New"'>&nbsp;&nbsp; lock Thread 21 completed 13326765 loops.<o:p>=
></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span styl=
>e=3D'font-family:"Courier New"'>&nbsp;&nbsp; lock Thread 22 completed 11327=
>588 loops.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.=
>5in'><span style=3D'font-family:"Courier New"'>&nbsp;&nbsp; lock Thread 23 =
>completed 12743882 loops.<o:p></o:p></span></p><p class=3DMsoNormal style=
>=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'>.......<o:p=
>></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span sty=
>le=3D'font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=3DMso=
>Normal style=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'=
>>***<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><=
>span style=3D'font-family:"Courier New"'>*** runtime error:<o:p></o:p></spa=
>n></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-f=
>amily:"Courier New"'>***&nbsp;&nbsp;&nbsp; Attempt to reference an illegal =
>memory location.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-=
>left:.5in'><span style=3D'font-family:"Courier New"'><o:p>&nbsp;</o:p></spa=
>n></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-f=
>amily:"Courier New"'>***<o:p></o:p></span></p><p class=3DMsoNormal style=3D=
>'margin-left:.5in'><span style=3D'font-family:"Courier New"'>*** runtime er=
>ror:<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><=
>span style=3D'font-family:"Courier New"'>***&nbsp;&nbsp;&nbsp; Attempt to r=
>eference an illegal memory location.<o:p></o:p></span></p><p class=3DMsoNor=
>mal style=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'><o=
>:p>&nbsp;</o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><=
>span style=3D'font-family:"Courier New"'>***<o:p></o:p></span></p><p class=
>=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Courier=
> New"'>*** runtime error:<o:p></o:p></span></p><p class=3DMsoNormal style=
>=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'>***&nbsp;&n=
>bsp;&nbsp; Attempt to reference an illegal memory location.<o:p></o:p></spa=
>n></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-f=
>amily:"Courier New"'>***&nbsp;&nbsp;&nbsp; pc =3D 0x126e37d =3D Move + 0x50=
> in ..\src\runtime\common\RTCollector.m3<o:p></o:p></span></p><p class=3DMs=
>oNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"=
>'>***<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'>=
><span style=3D'font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p cl=
>ass=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Cour=
>ier New"'>***<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-lef=
>t:.5in'><span style=3D'font-family:"Courier New"'>*** runtime error:<o:p></=
>o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=
>=3D'font-family:"Courier New"'>***&nbsp;&nbsp;&nbsp; &lt;*ASSERT*&gt; faile=
>d.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><sp=
>an style=3D'font-family:"Courier New"'>***&nbsp;&nbsp;&nbsp; file &quot;..\=
>src\thread\WIN32\ThreadWin32.m3&quot;, line 841<o:p></o:p></span></p><p cla=
>ss=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Couri=
>er New"'>***<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left=
>:.5in'><span style=3D'font-family:"Courier New"'><o:p>&nbsp;</o:p></span></=
>p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-famil=
>y:"Courier New"'>***<o:p></o:p></span></p><p class=3DMsoNormal style=3D'mar=
>gin-left:.5in'><span style=3D'font-family:"Courier New"'>*** runtime error:=
><o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span=
> style=3D'font-family:"Courier New"'>***&nbsp;&nbsp;&nbsp; &lt;*ASSERT*&gt;=
> failed.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5i=
>n'><span style=3D'font-family:"Courier New"'>***&nbsp;&nbsp;&nbsp; file &qu=
>ot;..\src\thread\WIN32\ThreadWin32.m3&quot;, line 841<o:p></o:p></span></p>=
><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:=
>"Courier New"'>***<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margi=
>n-left:.5in'><span style=3D'font-family:"Courier New"'><o:p>&nbsp;</o:p></s=
>pan></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font=
>-family:"Courier New"'>***<o:p></o:p></span></p><p class=3DMsoNormal style=
>=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'>*** runtime=
> error:<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in=
>'><span style=3D'font-family:"Courier New"'>***&nbsp;&nbsp;&nbsp; &lt;*ASSE=
>RT*&gt; failed.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-l=
>eft:.5in'><span style=3D'font-family:"Courier New"'>***&nbsp;&nbsp;&nbsp; f=
>ile &quot;..\src\thread\WIN32\ThreadWin32.m3&quot;, line 841<o:p></o:p></sp=
>an></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-=
>family:"Courier New"'>***<o:p></o:p></span></p><p class=3DMsoNormal><o:p>&n=
>bsp;</o:p></p><p class=3DMsoNormal>I&#8217;ll try on 32-bit XP soon and rep=
>ort.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMso=
>Normal>Regards,<o:p></o:p></p><p class=3DMsoNormal>Randy Coleburn<o:p></o:p=
>></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></body></html>=
>
>--_000_D67F02DDC62F7545A6B84C285F88F3E603418BD6ADatlex02srv_--
>
>--_004_D67F02DDC62F7545A6B84C285F88F3E603418BD6ADatlex02srv_
>Content-Type: application/octet-stream; name="Main.m3"
>Content-Description: Main.m3
>Content-Disposition: attachment; filename="Main.m3"; size=18584;
>	creation-date="Thu, 03 Mar 2011 01:28:22 GMT";
>	modification-date="Tue, 15 Mar 2011 01:30:19 GMT"
>Content-Transfer-Encoding: base64
>
>TU9EVUxFIE1haW47DQoNCigqIFRocmVhZGluZyBzdHJlc3MtdGVzdC4NCg0KICAgQ3JlYXRlIGEg
>bnVtYmVyIG9mIHRocmVhZHMuICBuIGlzIHNwZWNpZmllZCB2aWEgblBlciwgSXQgaXMNCiAgIHJl
>YXNvbmFibGUgZm9yIG5QZXIgdG8gYmUgZnJvbSAxIHRvIGEgZmV3IGh1bmRyZWQuICBuUGVyIGRl
>ZmF1bHRzDQogICB0byAzIGJ1dCBjYW4gYmUgc2V0IGJ5IHRoZSAtbiBjb21tYW5kLWxpbmUgc3dp
>dGNoLg0KDQogICBPdGhlciBjb21tYW5kLWxpbmUgc3dpdGNoZXM6DQoNCiAgIC13YWl0IDxzdGVw
>cz4NCiAgICAgIGhvdyBtYW55IG9uZS1zZWNvbmQgd2FpdHMgdG8gZXhlY3V0ZSBiZXR3ZWVuIHBy
>aW50cyAoZGVmYXVsdCAxMCkNCg0KICAgLWl0ZXJzIDxpdGVycz4NCiAgICAgIGhvdyBtYW55IGl0
>ZXJhdGlvbnMgdG8gcnVuIGZvciAoZGVmYXVsdCAxMCkNCg0KICAgLXRlc3RzIDx0ZXN0MT4sPHRl
>c3QyPiwuLi4NCiAgICAgIGNvbW1hLXNlcGFyYXRlZCBsaXN0IG9mIHRlc3RzIChkZWZhdWx0IHN0
>ZCB0eXBlcykNCiAgICAgIGNhbiBzcGVjaWZ5IGFsbCB3aXRoICJBTEwiIG9yIHN0YW5kYXJkIHRl
>c3RzIHdpdGggIlNURCINCiAgICAgIGFuZCBjYW4gc3VidHJhY3QgdGVzdHMgd2l0aCAtPG5hbWUg
>b2YgdGVzdD4NCiAgICAgIGV4YW1wbGVzLg0KICAgICAgICAgLXRlc3RzIHJlYWQsYWxsb2MsY3Jl
>YXQNCg0KICAgICAgICAgLXRlc3RzIEFMTCwtcmVhZA0KDQogICBUaGUgdGhyZWFkcyBjcmVhdGVk
>IGFyZSBvZiBmaXZlIHR5cGVzLiAgRWFjaCB0eXBlIG9mIHRocmVhZCBzdGFydHMNCiAgIGJ5IHNs
>ZWVwaW5nIGZvciBhIHdoaWxlLCB0byBnaXZlIHRoZSBvdGhlciB0aHJlYWRzIGEgY2hhbmNlIHRv
>IGJlDQogICBjcmVhdGVkLg0KDQogICBUaGUgdGhyZWFkcyBhcmUgb2YgdGhlIGZvbGxvd2luZyB0
>eXBlczoNCg0KICAgMS4gUmVhZGVyIC0tIGNvbnRpbnVvdXNseSByZWFkIHRoZSBjb250ZW50cyBv
>ZiB0aGUgZmlsZSAiaG9odW0iLA0KICAgICAgY3JlYXRlZCBkdXJpbmcgc3RhcnR1cCBpbiBDV0Qg
>YnkgdGhlIG1haW4gdGhyZWFkLg0KDQogICAyLiBGb3JrZXIgLS0gcmVwZWF0ZWRseSBmb3JrIGEg
>c3VicHJvY2VzcyB0aGF0IHNsZWVwcyBmb3Igb25lIHNlY29uZA0KICAgICAgdXNpbmcgUHJvY2Vz
>cy5DcmVhdGUuDQoNCiAgIDJiLiBGb3JrVG9vTXVjaCAtLSBmb3JrICJzbGVlcCAxMCIgYW5kIGRv
>IE5PVCBjYWxsIFByb2Nlc3MuV2FpdC4NCiAgICAgIE1heSBnZW5lcmF0ZSBsb3RzIG9mIHpvbWJp
>ZXMuDQoNCiAgIDMuIEFsbG9jYXRvciAtLSByZXBlYXRlZGx5IGFsbG9jYXRlIGhlYXAgbWVtb3J5
>IGFuZCBwZXJmb3JtDQogICAgICBtZWFuaW5nbGVzcyBvcGVyYXRpb25zIG9uIGl0Lg0KDQogICA0
>LiBDcmVhdG9yIC0tIHJlcGVhdGVkbHkgZm9yayBhIHNpbXBsZSBUaHJlYWQuVCB0aGF0IGRvZXMg
>bm90aGluZw0KICAgICAgYW5kIGV4aXRzLiAgV2FpdCBmb3IgaXQgdG8gZXhpdCBiZWZvcmUgZm9y
>a2luZyBhbm90aGVyLg0KDQogICA1LiBMb2NrZXIgLS0gcmVwZWF0ZWRseSBpbmNyZW1lbnQgb3Ig
>ZGVjcmVtZW50IGEgc2luZ2xlIGludGVnZXINCiAgICAgIHZhcmlhYmxlIGZyb20gd2l0aGluIGEg
>TVVURVgtcHJvdGVjdGVkIGNyaXRpY2FsIHNlY3Rpb24uDQoNCiAgIDYuIFJlYWRlck5vRXhjZXB0
>IC0tIGxpa2UgUmVhZGVyIGJ1dCB3aXRob3V0IFRSWS1FWENFUFQNCg0KICAgNy4gVHJ5RXhjZXB0
>IC0tIGEgbG9vcCB0aGF0IGNhdGNoZXMgYW4gZXhjZXB0aW9uIHRoYXQgbmV2ZXIgaGFwcGVucw0K
>DQogICBFYWNoIHRocmVhZCB3cml0ZXMgdGhlIHRoZSBpdCBwZXJmb3JtcyBhbiBvcGVyYXRpb24g
>dG8gdGhlIHRpbWVzMQ0KICAgYXJyYXkuICBUaGUgdGltZXMxIGFycmF5IGlzIGNvcGllZCBieSB0
>aGUgbWFpbiB0aHJlYWQsIGV2ZXJ5IDEwKw0KICAgc2Vjb25kcywgaW50byB0aGUgdGltZXMyIGFy
>cmF5LiAgTm8gbG9ja3MgYXJlIHVzZWQgdG8gc3luY2hyb25pemUNCiAgIHRoaXMgY29weWluZyBh
>Y3Rpdml0eSBhcyB3ZSBkb24ndCB3YW50IHRvIGludHJvZHVjZSB0b28gbWFueSBwb3NzaWJsZQ0K
>ICAgcGxhY2VzIHRoaW5ncyBjb3VsZCBkZWFkbG9jay4NCg0KICAgVGhlIG1haW4gdGhyZWFkIHRo
>ZW4gcHJpbnRzIG91dCBob3cgbG9uZyBhZ28gdGhlIHRocmVhZCB0aGF0IGhhcyBub3QNCiAgIHdy
>aXR0ZW4gdGltZXMxIGxhc3Qgd3JvdGUgdGhhdCBhcnJheS4NCg0KICAgTm90ZSB0aGF0IGFjdGlv
>bnMgaW4gdGhlIG1haW4gdGhyZWFkIG1heSBhbGxvY2F0ZSBtZW1vcnkgYW5kIHRoZXJlZm9yZQ0K
>ICAgYWNxdWlyZXMgbG9ja3MgaW4gVGhyZWFkUFRocmVhZC5tMywgdGhlIGZpbGUgd2hpY2ggdGhl
>IHByb2dyYW0gaXMNCiAgIG1haW5seSBpbnRlbmRlZCB0byB0ZXN0LiAgVGhlIGRlc2lnbiBpcyBi
>YXNlZCBvbiBhIGtub3dsZWRnZSBvZiB0aGUNCiAgIGludGVybmFsIGJlaGF2aW9yIG9mIFRocmVh
>ZFBUaHJlYWQubTMgYW5kIGFsc28gb24gYSBrbm93bGVkZ2Ugb2YgdGhlDQogICBtaXNiZWhhdmlv
>ciBvZiBleGlzdGluZywgaGlnaGx5IG11bHRpdGhyZWFkZWQgYXBwbGljYXRpb25zLg0KDQoNCiAg
>IEZBSVJORVNTIElTU1VFUw0KDQogICBFc3BlY2lhbGx5IHdpdGggdXNlciB0aHJlYWRzLCB0aGVy
>ZSBtYXkgYmUgZmFpcm5lc3MgcHJvYmxlbXMuICBUaGUNCiAgIHBvaW50IG9mIHRoZSBwcm9ncmFt
>IGlzIHRvIHRlc3QgdGhyZWFkaW5nIHNvIHRoZXJlIGlzIG9idmlvdXNseSBubw0KICAgYXR0ZW1w
>dCBhdCBlbmZvcmNpbmcgZmFpcm5lc3MuICBXaXRoIHVzZXIgdGhyZWFkcywgdGhpcyBtYXkgY2F1
>c2UNCiAgIGNlcnRhaW4gdHlwZXMgb2YgdGhyZWFkcyB0byBtb25vcG9saXplIHRoZSBjcHUuICAi
>U1RELC1sb2NrIiBtaWdodA0KICAgYmUgYWR2aXNlZCBmb3IgdGhlIGxpc3Qgb2YgdGVzdHMgZm9y
>IHVzZXIgdGhyZWFkcy4NCg0KICAgQXV0aG9yOiBNaWthIE55c3Ryb20gPG1pa2FAYWx1bS5taXQu
>ZWR1Pg0KDQogICBDb3B5cmlnaHQgKGMpIDIwMTEgR2VuZXJhdGlvbiBDYXBpdGFsIEx0ZC4gIEFs
>bCByaWdodHMgcmVzZXJ2ZWQuDQoNCiAgIFBlcm1pc3Npb24gdG8gdXNlLCBjb3B5LCBtb2RpZnks
>IGFuZCBkaXN0cmlidXRlIHRoaXMgc29mdHdhcmUNCiAgIGFuZCBpdHMgZG9jdW1lbnRhdGlvbiBm
>b3IgYW55IHB1cnBvc2UgYW5kIHdpdGhvdXQgZmVlIGlzIGhlcmVieQ0KICAgZ3JhbnRlZCwgcHJv
>dmlkZWQgdGhhdCB0aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhcHBlYXIgaW4gYWxsDQogICBj
>b3BpZXMuIEdlbmVyYXRpb24gQ2FwaXRhbCBMdGQuIG1ha2VzIG5vIHJlcHJlc2VudGF0aW9ucw0K
>ICAgYWJvdXQgdGhlIHN1aXRhYmlsaXR5IG9mIHRoaXMgc29mdHdhcmUgZm9yIGFueSBwdXJwb3Nl
>LiBJdCBpcw0KICAgcHJvdmlkZWQgImFzIGlzIiB3aXRob3V0IGV4cHJlc3Mgb3IgaW1wbGllZCB3
>YXJyYW50eS4NCg0KICopDQogKCogTWFyY2ggMTQsIDIwMTEsIFIuQy5Db2xlYnVybjoNCiAgICAg
>ICBBZGRlZCAtdmVyYm9zZSBvcHRpb24gYW5kIHRocmVhZCBsb29wIGl0ZXJhdGlvbiBjb3VudGlu
>ZyB3aXRoIGV4cGxpY2l0IG5vdGlmaWNhdGlvbiBvZiBzdGFydmVkL2RlYWRsb2NrZWQgdGhyZWFk
>cy4NCiAgICAgICBBZGRlZCBwcC5maW5pc2goKSB0byB0ZWxsIGlmIGFsbCBjb21tYW5kIGxpbmUg
>cGFyYW1ldGVycyB3ZXJlIHByb2Nlc3NlZC4NCiAqKQ0KDQoNCklNUE9SVCBUaHJlYWQsIFJkLCBG
>aWxlUmQsIFdyLCBGaWxlV3IsIFByb2Nlc3M7DQpJTVBPUlQgVGltZTsNCklNUE9SVCBJbnRBcnJh
>eVNvcnQ7DQpJTVBPUlQgQXRvbSwgQXRvbUxpc3Q7DQpJTVBPUlQgT1NFcnJvcjsNCklNUE9SVCBQ
>YXJzZVBhcmFtcywgUGFyYW1zOw0KSU1QT1JUIFN0ZGlvOw0KSU1QT1JUIFRleHQ7DQpJTVBPUlQg
>Rm10Ow0KDQo8KiBGQVRBTCBUaHJlYWQuQWxlcnRlZCwgV3IuRmFpbHVyZSAqPg0KDQpDT05TVCBJ
>bml0UGF1c2UgPSAxLjBkMDsNCg0KVFlQRSBDbG9zdXJlID0gVGhyZWFkLkNsb3N1cmUgT0JKRUNU
>IGlkIDogQ0FSRElOQUwgRU5EOw0KDQpQUk9DRURVUkUgTWFrZVJlYWRlclRocmVhZChpIDogQ0FS
>RElOQUwpID0NCiAgQkVHSU4NCiAgICBFVkFMIFRocmVhZC5Gb3JrKE5FVyhDbG9zdXJlLCBpZCA6
>PSBpLCBhcHBseSA6PSBSQXBwbHkpKQ0KICBFTkQgTWFrZVJlYWRlclRocmVhZDsNCg0KUFJPQ0VE
>VVJFIE1ha2VSZWFkZXJOb0V4Y2VwdFRocmVhZChpIDogQ0FSRElOQUwpID0NCiAgQkVHSU4NCiAg
>ICBFVkFMIFRocmVhZC5Gb3JrKE5FVyhDbG9zdXJlLCBpZCA6PSBpLCBhcHBseSA6PSBOQXBwbHkp
>KQ0KICBFTkQgTWFrZVJlYWRlck5vRXhjZXB0VGhyZWFkOw0KDQpQUk9DRURVUkUgTWFrZVRyeUV4
>Y2VwdFRocmVhZChpIDogQ0FSRElOQUwpID0NCiAgQkVHSU4NCiAgICBFVkFMIFRocmVhZC5Gb3Jr
>KE5FVyhDbG9zdXJlLCBpZCA6PSBpLCBhcHBseSA6PSBUQXBwbHkpKQ0KICBFTkQgTWFrZVRyeUV4
>Y2VwdFRocmVhZDsNCg0KUFJPQ0VEVVJFIE1ha2VGb3JrZXJUaHJlYWQoaSA6IENBUkRJTkFMKSA9
>DQogIEJFR0lODQogICAgRVZBTCBUaHJlYWQuRm9yayhORVcoQ2xvc3VyZSwgaWQgOj0gaSwgYXBw
>bHkgOj0gRkFwcGx5KSkNCiAgRU5EIE1ha2VGb3JrZXJUaHJlYWQ7DQoNClBST0NFRFVSRSBNYWtl
>Rm9ya1Rvb011Y2hUaHJlYWQoaSA6IENBUkRJTkFMKSA9DQogIEJFR0lODQogICAgRVZBTCBUaHJl
>YWQuRm9yayhORVcoQ2xvc3VyZSwgaWQgOj0gaSwgYXBwbHkgOj0gTUFwcGx5KSkNCiAgRU5EIE1h
>a2VGb3JrVG9vTXVjaFRocmVhZDsNCg0KUFJPQ0VEVVJFIE1ha2VBbGxvY2F0b3JUaHJlYWQoaSA6
>IENBUkRJTkFMKSA9DQogIEJFR0lODQogICAgRVZBTCBUaHJlYWQuRm9yayhORVcoQ2xvc3VyZSwg
>aWQgOj0gaSwgYXBwbHkgOj0gQUFwcGx5KSkNCiAgRU5EIE1ha2VBbGxvY2F0b3JUaHJlYWQ7DQoN
>ClBST0NFRFVSRSBNYWtlQ3JlYXRvclRocmVhZChpIDogQ0FSRElOQUwpID0NCiAgQkVHSU4NCiAg
>ICBFVkFMIFRocmVhZC5Gb3JrKE5FVyhDbG9zdXJlLCBpZCA6PSBpLCBhcHBseSA6PSBDQXBwbHkp
>KQ0KICBFTkQgTWFrZUNyZWF0b3JUaHJlYWQ7DQoNClBST0NFRFVSRSBNYWtlTG9ja2VyVGhyZWFk
>KGkgOiBDQVJESU5BTCkgPQ0KICBCRUdJTg0KICAgIEVWQUwgVGhyZWFkLkZvcmsoTkVXKENsb3N1
>cmUsIGlkIDo9IGksIGFwcGx5IDo9IExBcHBseSkpDQogIEVORCBNYWtlTG9ja2VyVGhyZWFkOw0K
>DQpUWVBFDQogIFRocmVhZE1ha2VyID0gUFJPQ0VEVVJFKGkgOiBDQVJESU5BTCk7DQogIE5hbWVk
>ID0gUkVDT1JEIG1ha2VyIDogVGhyZWFkTWFrZXI7IG5hbWVkIDogVEVYVCBFTkQ7DQoNCkNPTlNU
>DQogIE1ha2VycyA9IEFSUkFZIE9GIE5hbWVkIHsNCiAgICBOYW1lZCB7IE1ha2VSZWFkZXJUaHJl
>YWQsICAgICAgICAgInJlYWQiICB9LA0KICAgIE5hbWVkIHsgTWFrZVJlYWRlck5vRXhjZXB0VGhy
>ZWFkLCAibnhyZWFkIiAgfSwNCiAgICBOYW1lZCB7IE1ha2VUcnlFeGNlcHRUaHJlYWQsICAgICAg
>InRyeWV4Y2VwdCIgIH0sDQogICAgTmFtZWQgeyBNYWtlRm9ya2VyVGhyZWFkLCAgICAgICAgICJm
>b3JrIiAgfSwNCiAgICBOYW1lZCB7IE1ha2VGb3JrVG9vTXVjaFRocmVhZCwgICAgImZvcmt0b29t
>dWNoIiAgfSwNCiAgICBOYW1lZCB7IE1ha2VBbGxvY2F0b3JUaHJlYWQsICAgICAgImFsbG9jIiB9
>LA0KICAgIE5hbWVkIHsgTWFrZUNyZWF0b3JUaHJlYWQsICAgICAgICAiY3JlYXQiIH0sDQogICAg
>TmFtZWQgeyBNYWtlTG9ja2VyVGhyZWFkLCAgICAgICAgICJsb2NrIiAgfQ0KICB9Ow0KDQpDT05T
>VCBTdGRUZXN0QXJyID0gQVJSQVkgT0YgVEVYVCB7ICJyZWFkIiwgImZvcmsiLCAiYWxsb2MiLCAi
>Y3JlYXRlIiwgImxvY2siIH07DQooKiBkZXNpZ25hdGVkICJzdGFuZGFyZCIgdGVzdHMgKikNCg0K
>VFlQRSBNID0gWyBGSVJTVChNYWtlcnMpLi5MQVNUKE1ha2VycykgXTsNCg0KKCoqKioqKioqKioq
>KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
>KiopDQoNClBST0NFRFVSRSBSQXBwbHkoY2wgOiBDbG9zdXJlKSA6IFJFRkFOWSA9DQogIEJFR0lO
>DQogICAgY291bnRzMVtjbC5pZF0gOj0gMEw7DQogICAgY291bnRzM1tjbC5pZF0gOj0gMEw7DQog
>ICAgVGhyZWFkLlBhdXNlKEluaXRQYXVzZSk7DQogICAgTE9PUA0KICAgICAgVFJZDQogICAgICAg
>IFdJVEggcmQgPSBGaWxlUmQuT3BlbihGaWxlbmFtZSkgRE8NCiAgICAgICAgICBUUlkNCiAgICAg
>ICAgICAgIExPT1ANCiAgICAgICAgICAgICAgPCpVTlVTRUQqPlZBUiBjIDo9IFJkLkdldENoYXIo
>cmQpOyBCRUdJTiAgRU5EDQogICAgICAgICAgICBFTkQNCiAgICAgICAgICBFWENFUFQNCiAgICAg
>ICAgICAgIFJkLkVuZE9mRmlsZSA9PiBSZC5DbG9zZShyZCkNCiAgICAgICAgICBFTkQ7DQogICAg
>ICAgICAgdGltZXMxW2NsLmlkXTo9IEZMT09SKFRpbWUuTm93KCkpDQogICAgICAgIEVORA0KICAg
>ICAgRVhDRVBUDQogICAgICAgIE9TRXJyb3IuRSh4KSA9PiBFcnJvcigiUkFwcGx5OiBPU0Vycm9y
>LkU6ICIgJiBGbXRBdG9tTGlzdCh4KSkNCiAgICAgIHwNCiAgICAgICAgUmQuRmFpbHVyZSh4KSA9
>PiBFcnJvcigiUkFwcGx5OiBSZC5GYWlsdXJlOiAiICYgRm10QXRvbUxpc3QoeCkpDQogICAgICBF
>TkQ7DQogICAgICBjb3VudHMxW2NsLmlkXSA6PSBjb3VudHMxW2NsLmlkXSArIDFMOyAoKiB3b3Vs
>ZCBiZSBuaWNlIHRvIHVzZSBJTkMgaGVyZSwgYnV0IHRoZXJlIGlzIGEgQ0cgYnVnIG9uIE5UMzg2
>IHdpdGggSU5DIG9mIExPTkdJTlQgKikNCiAgICBFTkQNCiAgRU5EIFJBcHBseTsNCg0KUFJPQ0VE
>VVJFIE5BcHBseShjbCA6IENsb3N1cmUpIDogUkVGQU5ZID0NCiAgPCpGQVRBTCBPU0Vycm9yLkUs
>IFJkLkZhaWx1cmUsIFJkLkVuZE9mRmlsZSo+DQogIEJFR0lODQogICAgY291bnRzMVtjbC5pZF0g
>Oj0gMEw7DQogICAgY291bnRzM1tjbC5pZF0gOj0gMEw7DQogICAgVGhyZWFkLlBhdXNlKEluaXRQ
>YXVzZSk7DQogICAgTE9PUA0KICAgICAgV0lUSCByZCA9IEZpbGVSZC5PcGVuKEZpbGVuYW1lKSBE
>Tw0KICAgICAgICBXSElMRSBOT1QgUmQuRU9GKHJkKSBETw0KICAgICAgICAgIDwqVU5VU0VEKj5W
>QVIgYyA6PSBSZC5HZXRDaGFyKHJkKTsgQkVHSU4gIEVORA0KICAgICAgICBFTkQ7DQogICAgICAg
>IFJkLkNsb3NlKHJkKTsNCiAgICAgICAgdGltZXMxW2NsLmlkXTo9IEZMT09SKFRpbWUuTm93KCkp
>DQogICAgICBFTkQ7DQogICAgICBjb3VudHMxW2NsLmlkXSA6PSBjb3VudHMxW2NsLmlkXSArIDFM
>OyAoKiB3b3VsZCBiZSBuaWNlIHRvIHVzZSBJTkMgaGVyZSwgYnV0IHRoZXJlIGlzIGEgQ0cgYnVn
>IG9uIE5UMzg2IHdpdGggSU5DIG9mIExPTkdJTlQgKikNCiAgICBFTkQNCiAgRU5EIE5BcHBseTsN
>Cg0KRVhDRVBUSU9OIFg7DQoNClBST0NFRFVSRSBUQXBwbHkoY2wgOiBDbG9zdXJlKSA6IFJFRkFO
>WSA9DQogIEJFR0lODQogICAgY291bnRzMVtjbC5pZF0gOj0gMEw7DQogICAgY291bnRzM1tjbC5p
>ZF0gOj0gMEw7DQogICAgVGhyZWFkLlBhdXNlKEluaXRQYXVzZSk7DQogICAgTE9PUA0KICAgICAg
>VFJZDQogICAgICAgIFdJVEggbm93ID0gVGltZS5Ob3coKSBETw0KICAgICAgICAgIHRpbWVzMVtj
>bC5pZF06PSBGTE9PUihub3cpOw0KICAgICAgICAgIElGIG5vdyA8IDAuMGQwIFRIRU4gUkFJU0Ug
>WCBFTkQNCiAgICAgICAgRU5EDQogICAgICBFWENFUFQgWCA9PiA8KkFTU0VSVCBGQUxTRSo+DQog
>ICAgICBFTkQ7DQogICAgICBjb3VudHMxW2NsLmlkXSA6PSBjb3VudHMxW2NsLmlkXSArIDFMOyAo
>KiB3b3VsZCBiZSBuaWNlIHRvIHVzZSBJTkMgaGVyZSwgYnV0IHRoZXJlIGlzIGEgQ0cgYnVnIG9u
>IE5UMzg2IHdpdGggSU5DIG9mIExPTkdJTlQgKikNCiAgICBFTkQNCiAgRU5EIFRBcHBseTsNCg0K
>UFJPQ0VEVVJFIEZBcHBseShjbCA6IENsb3N1cmUpIDogUkVGQU5ZID0NCiAgQkVHSU4NCiAgICBj
>b3VudHMxW2NsLmlkXSA6PSAwTDsNCiAgICBjb3VudHMzW2NsLmlkXSA6PSAwTDsNCiAgICBUaHJl
>YWQuUGF1c2UoSW5pdFBhdXNlKTsNCiAgICBMT09QDQogICAgICBUUlkNCiAgICAgICAgV0lUSCBw
>cm9jID0gUHJvY2Vzcy5DcmVhdGUoUGFyYW1zLkdldCgwKSwNCiAgICAgICAgICAgICAgICAgICAg
>ICAgICAgICAgICAgICAgQVJSQVkgT0YgVEVYVCB7ICItc2xlZXAiIH0pIERPDQogICAgICAgICAg
>RVZBTCBQcm9jZXNzLldhaXQocHJvYyk7IHRpbWVzMVtjbC5pZF0gOj0gRkxPT1IoVGltZS5Ob3co
>KSkNCiAgICAgICAgRU5EDQogICAgICBFWENFUFQNCiAgICAgICAgT1NFcnJvci5FKHgpID0+IEVy
>cm9yKCJGQXBwbHk6IE9TRXJyb3IuRTogIiAmIEZtdEF0b21MaXN0KHgpKQ0KICAgICAgRU5EOw0K
>ICAgICAgY291bnRzMVtjbC5pZF0gOj0gY291bnRzMVtjbC5pZF0gKyAxTDsgKCogd291bGQgYmUg
>bmljZSB0byB1c2UgSU5DIGhlcmUsIGJ1dCB0aGVyZSBpcyBhIENHIGJ1ZyBvbiBOVDM4NiB3aXRo
>IElOQyBvZiBMT05HSU5UICopDQogICAgRU5EDQogIEVORCBGQXBwbHk7DQoNClBST0NFRFVSRSBN
>QXBwbHkoY2wgOiBDbG9zdXJlKSA6IFJFRkFOWSA9DQogIEJFR0lODQogICAgY291bnRzMVtjbC5p
>ZF0gOj0gMEw7DQogICAgY291bnRzM1tjbC5pZF0gOj0gMEw7DQogICAgVGhyZWFkLlBhdXNlKElu
>aXRQYXVzZSk7DQogICAgTE9PUA0KICAgICAgVFJZDQogICAgICAgIDwqTk9XQVJOKj5XSVRIIHBy
>b2MgPSBQcm9jZXNzLkNyZWF0ZShQYXJhbXMuR2V0KDApLA0KICAgICAgICAgICAgICAgICAgICAg
>ICAgICAgICAgICAgICBBUlJBWSBPRiBURVhUIHsgIi1zbGVlcDEwIiB9KSBETw0KICAgICAgICAg
>ICgqIG5vIFByb2Nlc3MuV2FpdCAqKQ0KICAgICAgICAgIHRpbWVzMVtjbC5pZF0gOj0gRkxPT1Io
>VGltZS5Ob3coKSk7DQogICAgICAgICAgVGhyZWFkLlBhdXNlKDEuMGQwKQ0KICAgICAgICBFTkQN
>CiAgICAgIEVYQ0VQVA0KICAgICAgICBPU0Vycm9yLkUoeCkgPT4gRXJyb3IoIkZBcHBseTogT1NF
>cnJvci5FOiAiICYgRm10QXRvbUxpc3QoeCkpDQogICAgICBFTkQ7DQogICAgICBjb3VudHMxW2Ns
>LmlkXSA6PSBjb3VudHMxW2NsLmlkXSArIDFMOyAoKiB3b3VsZCBiZSBuaWNlIHRvIHVzZSBJTkMg
>aGVyZSwgYnV0IHRoZXJlIGlzIGEgQ0cgYnVnIG9uIE5UMzg2IHdpdGggSU5DIG9mIExPTkdJTlQg
>KikNCiAgICBFTkQNCiAgRU5EIE1BcHBseTsNCg0KUFJPQ0VEVVJFIEFBcHBseShjbCA6IENsb3N1
>cmUpIDogUkVGQU5ZID0NCiAgQkVHSU4NCiAgICBjb3VudHMxW2NsLmlkXSA6PSAwTDsNCiAgICBj
>b3VudHMzW2NsLmlkXSA6PSAwTDsNCiAgICBUaHJlYWQuUGF1c2UoSW5pdFBhdXNlKTsNCiAgICBM
>T09QDQogICAgICBWQVINCiAgICAgICAgYXJyIDo9IE5FVyhSRUYgQVJSQVkgT0YgSU5URUdFUiwg
>MTAyNSk7DQogICAgICBCRUdJTg0KICAgICAgICBGT1IgaSA6PSBGSVJTVChhcnJeKSsxIFRPIExB
>U1QoYXJyXikgRE8NCiAgICAgICAgICBhcnJbaV0gOj0gYXJyW2ldIC0gYXJyW2ktMV0NCiAgICAg
>ICAgRU5EOyB0aW1lczFbY2wuaWRdIDo9IEZMT09SKFRpbWUuTm93KCkpDQogICAgICBFTkQ7DQog
>ICAgICBjb3VudHMxW2NsLmlkXSA6PSBjb3VudHMxW2NsLmlkXSArIDFMOyAoKiB3b3VsZCBiZSBu
>aWNlIHRvIHVzZSBJTkMgaGVyZSwgYnV0IHRoZXJlIGlzIGEgQ0cgYnVnIG9uIE5UMzg2IHdpdGgg
>SU5DIG9mIExPTkdJTlQgKikNCiAgICBFTkQNCiAgRU5EIEFBcHBseTsNCg0KUFJPQ0VEVVJFIENB
>cHBseShjbCA6IENsb3N1cmUpIDogUkVGQU5ZID0NCiAgQkVHSU4NCiAgICBjb3VudHMxW2NsLmlk
>XSA6PSAwTDsNCiAgICBjb3VudHMzW2NsLmlkXSA6PSAwTDsNCiAgICBUaHJlYWQuUGF1c2UoSW5p
>dFBhdXNlKTsNCiAgICBMT09QDQogICAgICBWQVINCiAgICAgICAgdCA6PSBUaHJlYWQuRm9yayhO
>RVcoVGhyZWFkLkNsb3N1cmUsIGFwcGx5IDo9IFRocmVhZE5PUCkpOw0KICAgICAgQkVHSU4NCiAg
>ICAgICAgRVZBTCBUaHJlYWQuSm9pbih0KTsgdGltZXMxW2NsLmlkXSA6PSBGTE9PUihUaW1lLk5v
>dygpKQ0KICAgICAgRU5EOw0KICAgICAgY291bnRzMVtjbC5pZF0gOj0gY291bnRzMVtjbC5pZF0g
>KyAxTDsgKCogd291bGQgYmUgbmljZSB0byB1c2UgSU5DIGhlcmUsIGJ1dCB0aGVyZSBpcyBhIENH
>IGJ1ZyBvbiBOVDM4NiB3aXRoIElOQyBvZiBMT05HSU5UICopDQogICAgRU5EDQogIEVORCBDQXBw
>bHk7DQoNClBST0NFRFVSRSBUaHJlYWROT1AoPCpVTlVTRUQqPmNsIDogVGhyZWFkLkNsb3N1cmUp
>IDogUkVGQU5ZID0gQkVHSU4gUkVUVVJOIE5JTCBFTkQgVGhyZWFkTk9QOw0KDQpWQVIgbXUgICAg
>IDo9IE5FVyhNVVRFWCk7DQpWQVIgc2hhcmVkIDo9IDA7DQoNClBST0NFRFVSRSBMQXBwbHkoY2wg
>OiBDbG9zdXJlKSA6IFJFRkFOWSA9DQogIEJFR0lODQogICAgY291bnRzMVtjbC5pZF0gOj0gMEw7
>DQogICAgY291bnRzM1tjbC5pZF0gOj0gMEw7DQogICAgVGhyZWFkLlBhdXNlKEluaXRQYXVzZSk7
>DQogICAgTE9PUA0KICAgICAgTE9DSyBtdSBETw0KICAgICAgICBDQVNFIGNsLmlkIE1PRCAyIE9G
>DQogICAgICAgICAgMSA9PiBJTkMoc2hhcmVkKQ0KICAgICAgICB8DQogICAgICAgICAgMCA9PiBE
>RUMoc2hhcmVkKQ0KICAgICAgICBFTFNFDQogICAgICAgICAgPCpBU1NFUlQgRkFMU0UqPg0KICAg
>ICAgICBFTkQNCiAgICAgIEVORDsgdGltZXMxW2NsLmlkXSA6PSBGTE9PUihUaW1lLk5vdygpKTsN
>CiAgICAgIGNvdW50czFbY2wuaWRdIDo9IGNvdW50czFbY2wuaWRdICsgMUw7ICgqIHdvdWxkIGJl
>IG5pY2UgdG8gdXNlIElOQyBoZXJlLCBidXQgdGhlcmUgaXMgYSBDRyBidWcgb24gTlQzODYgd2l0
>aCBJTkMgb2YgTE9OR0lOVCAqKQ0KICAgIEVORA0KICBFTkQgTEFwcGx5Ow0KDQoNCkNPTlNUIEZp
>bGVuYW1lID0gImhvaHVtIjsNCg0KUFJPQ0VEVVJFIFdyaXRlQUZpbGUoKSA9DQogIDwqRkFUQUwg
>V3IuRmFpbHVyZSwgT1NFcnJvci5FKj4gICgqIGVycm9ycyBkdXJpbmcgc2V0dXAgYXJlIGp1c3Qg
>ZmF0YWwgKikNCiAgQkVHSU4NCiAgICBXSVRIIHdyID0gRmlsZVdyLk9wZW4oRmlsZW5hbWUpIERP
>DQogICAgICBGT1IgaSA6PSAxIFRPIDI1NiBETw0KICAgICAgICBGT1IgaiA6PSAxIFRPIGkgRE8N
>CiAgICAgICAgICBXci5QdXRDaGFyKHdyLCBWQUwoT1JEKCdBJykgKyBpIE1PRCAyNSwgQ0hBUikp
>DQogICAgICAgIEVORDsNCiAgICAgICAgV3IuUHV0VGV4dCh3ciwgV3IuRU9MKQ0KICAgICAgRU5E
>Ow0KICAgICAgV3IuQ2xvc2Uod3IpDQogICAgRU5EDQogIEVORCBXcml0ZUFGaWxlOw0KDQpQUk9D
>RURVUkUgUHV0SW50KGMgOiBJTlRFR0VSKSA9DQogIEJFR0lODQogICAgSUYgYyA8IDAgVEhFTg0K
>ICAgICAgV3IuUHV0Q2hhcihTdGRpby5zdGRvdXQsJy0nKTsNCiAgICAgIGMgOj0gLWM7DQogICAg
>RU5EOw0KICAgIElGIGMgPiAxMCBUSEVODQogICAgICBQdXRJbnQoYyBESVYgMTApDQogICAgRU5E
>Ow0KICAgIFdyLlB1dENoYXIoU3RkaW8uc3Rkb3V0LFZBTChjIE1PRCAxMCArIE9SRCgnMCcpLENI
>QVIpKQ0KICBFTkQgUHV0SW50Ow0KDQpQUk9DRURVUkUgUHV0U3RhdHMoVkFSIGEgOiBBUlJBWSBP
>RiBJTlRFR0VSKSA9DQogICgqIG5vdyBpcyBnbG9iYWwgaW4gTWFpbi5tMyAqKQ0KICBCRUdJTg0K
>ICAgIEludEFycmF5U29ydC5Tb3J0KGEpOw0KDQogICAgKCogdGhlIHJlc3VsdCBpc24ndCBxdWl0
>ZSByaWdodCBpZiBOVU1CRVIoYSkgaXMgZXZlbiAqKQ0KICAgIFdJVEggbWluID0gYVtGSVJTVChh
>KV0sDQogICAgICAgICBtYXggPSBhW0xBU1QoYSldLA0KICAgICAgICAgbWVkID0gYVtMQVNUKGEp
>IERJViAyXSBETw0KICAgICAgUHV0SW50KG5vdy1taW4pOw0KICAgICAgV3IuUHV0Q2hhcihTdGRp
>by5zdGRvdXQsJy8nKTsNCiAgICAgIFB1dEludChub3ctbWVkKTsNCiAgICAgIFdyLlB1dENoYXIo
>U3RkaW8uc3Rkb3V0LCcvJyk7DQogICAgICBQdXRJbnQobm93LW1heCkNCiAgICBFTkQNCiAgRU5E
>IFB1dFN0YXRzOw0KDQpQUk9DRURVUkUgRm10QXRvbUxpc3QoZXJyIDogQXRvbUxpc3QuVCkgOiBU
>RVhUID0NCiAgVkFSDQogICAgbXNnIDo9ICIiOw0KICAgIHAgOj0gZXJyOw0KICBCRUdJTg0KICAg
>IFdISUxFIHAgIyBOSUwgRE8NCiAgICAgIG1zZyA6PSBtc2cgJiAiICIgJiBBdG9tLlRvVGV4dChw
>LmhlYWQpOyBwIDo9IHAudGFpbA0KICAgIEVORDsNCiAgICBSRVRVUk4gbXNnDQogIEVORCBGbXRB
>dG9tTGlzdDsNCg0KUFJPQ0VEVVJFIEVycm9yKG1zZyA6IFRFWFQpID0NCiAgQkVHSU4NCiAgICBX
>ci5QdXRUZXh0KFN0ZGlvLnN0ZG91dCwiRVJST1IgIiAmIG1zZyAmIFdyLkVPTCkNCiAgRU5EIEVy
>cm9yOw0KDQpQUk9DRURVUkUgQWRkVGVzdCh0ZXN0IDogVEVYVCkgPQ0KICBCRUdJTg0KICAgIElG
>ICAgIFRleHQuRXF1YWwoIkFMTCIsdGVzdCkgVEhFTg0KICAgICAgc2V0cyA6PSBTRVQgT0YgTSB7
>IEZJUlNUKE0pIC4uIExBU1QoTSkgfTsNCiAgICAgIFJFVFVSTg0KICAgIEVMU0lGIFRleHQuRXF1
>YWwoIlNURCIsdGVzdCkgVEhFTg0KICAgICAgc2V0cyA6PSBTdGRUZXN0czsNCiAgICAgIFJFVFVS
>Tg0KICAgIEVMU0lGIFRleHQuRXF1YWwoIlBPU0lYIix0ZXN0KSBUSEVODQogICAgICAoKiBlcXVh
>bCB0byBTVEQsLWxvY2sgKikNCiAgICAgIHNldHMgOj0gU3RkVGVzdHM7DQogICAgICB0ZXN0IDo9
>ICItbG9jayINCiAgICBFTkQ7DQoNCiAgICBGT1IgaSA6PSBGSVJTVChNYWtlcnMpIFRPIExBU1Qo
>TWFrZXJzKSBETw0KICAgICAgSUYgICAgVGV4dC5FcXVhbChNYWtlcnNbaV0ubmFtZWQsdGVzdCkg
>VEhFTg0KICAgICAgICBzZXRzIDo9IHNldHMgKyBTRVQgT0YgTSB7IGkgfTsgUkVUVVJODQogICAg
>ICBFTFNJRiBUZXh0LkVxdWFsKCItIiAmIE1ha2Vyc1tpXS5uYW1lZCx0ZXN0KSBUSEVODQogICAg
>ICAgIHNldHMgOj0gc2V0cyAtIFNFVCBPRiBNIHsgaSB9OyBSRVRVUk4NCiAgICAgIEVORA0KICAg
>IEVORDsNCg0KICAgICgqIG5vIG1hdGNoICopDQoNCiAgICBWQVINCiAgICAgIG1zZyA6PSAiTm8g
>dGVzdCBuYW1lZCBcIiIgJiB0ZXN0ICYgIlwiLCBrbm93biB0ZXN0czoiOw0KICAgIEJFR0lODQog
>ICAgICBGT1IgaSA6PSBGSVJTVChNYWtlcnMpIFRPIExBU1QoTWFrZXJzKSBETw0KICAgICAgICBt
>c2cgOj0gbXNnICYgIiAiICYgTWFrZXJzW2ldLm5hbWVkDQogICAgICBFTkQ7DQogICAgICBQcm9j
>ZXNzLkNyYXNoKG1zZykNCiAgICBFTkQNCiAgRU5EIEFkZFRlc3Q7DQoNCkNPTlNUDQogIERlZmF1
>bHROUGVyID0gMzsNClZBUg0KICBuUGVyIDo9IERlZmF1bHROUGVyOyAoKiBtdXN0IGJlIG9kZCAq
>KQ0KDQogIG4gOiBDQVJESU5BTDsNCg0KICB0aW1lczEsIHRpbWVzMiwgdGltZXMzIDogUkVGIEFS
>UkFZIE9GIElOVEVHRVI7DQogICgqIHRpbWVzMSA6IGlucHV0IGFycmF5DQogICAgIHRpbWVzMiA6
>IGEgc3RhYmxlIGNvcHkgb2YgdGltZXMxDQoNCiAgICAgdGltZXMzIDogYSBjb3B5IG9mIHRob3Nl
>IGJpdHMgb2YgdGltZXMxIHRoYXQgYXJlIGFjdGl2ZQ0KICAqKQ0KICBjb3VudHMxLCBjb3VudHMy
>LCBjb3VudHMzIDogUkVGIEFSUkFZIE9GIExPTkdJTlQ7DQogICgqIGNvdW50czEgOiBpbnB1dA0K
>ICAgICBjb3VudHMyIDogc3RhYmxlIGNvcHkgb2YgY291bnRzMQ0KICAgICBjb3VudHMzIDogY29w
>eSBvZiBwcmlvciBjb3VudHMyIHZhbHVlcyB1c2VkIGZvciBjb21wYXJpc29uDQogICopDQogIGFj
>dGl2ZTogUkVGIEFSUkFZIE9GIEJPT0xFQU47ICgqIHRlbGxzIGlmIGEgcGFydGljdWxhciB0aHJl
>YWQgaWQgaXMgYW4gYWN0aXZlIHRocmVhZCAqKQ0KICB0aHJlYWRNOiBSRUYgQVJSQVkgT0YgTTsg
>KCogZm9yIGFjdGl2ZSB0aHJlYWRzLCB0ZWxscyB0aGUgdHlwZSBvZiB0aHJlYWQsIGkuZS4sIGl0
>cyBNICopDQogIG5vdyA6IElOVEVHRVI7DQogIHNldHMgOiBTRVQgT0YgTTsNCg0KICBwcCA6PSBO
>RVcoUGFyc2VQYXJhbXMuVCkuaW5pdChTdGRpby5zdGRlcnIpOw0KDQogIGl0ZXJzIDo9IDEwOw0K
>ICB3YWl0ICA6PSAxMDsNCiAgU3RkVGVzdHMgOj0gU0VUIE9GIE0geyB9Ow0KICB2ZXJib3NlOiBC
>T09MRUFOIDo9IEZBTFNFOw0KDQpCRUdJTg0KICBGT1IgaSA6PSBGSVJTVChTdGRUZXN0QXJyKSBU
>TyBMQVNUKFN0ZFRlc3RBcnIpIERPDQogICAgRk9SIGogOj0gRklSU1QoTSkgVE8gTEFTVChNKSBE
>Tw0KICAgICAgSUYgVGV4dC5FcXVhbChTdGRUZXN0QXJyW2ldLE1ha2Vyc1tqXS5uYW1lZCkgVEhF
>Tg0KICAgICAgICBTdGRUZXN0cyA6PSBTdGRUZXN0cyArIFNFVCBPRiBNIHsgaiB9DQogICAgICBF
>TkQNCiAgICBFTkQNCiAgRU5EOw0KDQogIHNldHMgOj0gU3RkVGVzdHM7DQoNCiAgVFJZDQogICAg
>SUYgcHAua2V5d29yZFByZXNlbnQoIi1zbGVlcDEwIikgVEhFTg0KICAgICAgKCogc2xlZXAgYW5k
>IGV4aXQgKikNCiAgICAgIFRocmVhZC5QYXVzZSgxMC4wZDApOw0KICAgICAgUHJvY2Vzcy5FeGl0
>KDApDQogICAgRU5EOw0KICAgIElGIHBwLmtleXdvcmRQcmVzZW50KCItc2xlZXAiKSBUSEVODQog
>ICAgICAoKiBzbGVlcCBhbmQgZXhpdCAqKQ0KICAgICAgVGhyZWFkLlBhdXNlKDEuMGQwKTsNCiAg
>ICAgIFByb2Nlc3MuRXhpdCgwKQ0KICAgIEVORDsNCg0KICAgIElGIHBwLmtleXdvcmRQcmVzZW50
>KCItbiIpICAgICBUSEVOIG5QZXIgOj0gcHAuZ2V0TmV4dEludCgpIEVORDsNCiAgICBJRiBwcC5r
>ZXl3b3JkUHJlc2VudCgiLXdhaXQiKSAgVEhFTiB3YWl0IDo9IHBwLmdldE5leHRJbnQoKSBFTkQ7
>DQogICAgSUYgcHAua2V5d29yZFByZXNlbnQoIi1pdGVycyIpIFRIRU4gaXRlcnMgOj0gcHAuZ2V0
>TmV4dEludCgpIEVORDsNCiAgICBJRiBwcC5rZXl3b3JkUHJlc2VudCgiLXZlcmJvc2UiKSBUSEVO
>IHZlcmJvc2UgOj0gVFJVRTsgRU5EOw0KDQogICAgSUYgcHAua2V5d29yZFByZXNlbnQoIi10ZXN0
>cyIpIFRIRU4NCiAgICAgIFZBUg0KICAgICAgICBzIDo9IDA7DQogICAgICBCRUdJTg0KICAgICAg
>ICBzZXRzIDo9IFNFVCBPRiBNIHt9IDsNCg0KICAgICAgICBXSVRIIHRlc3RzID0gcHAuZ2V0TmV4
>dCgpLA0KICAgICAgICAgICAgIGwgICAgID0gVGV4dC5MZW5ndGgodGVzdHMpIERPDQogICAgICAg
>ICAgRk9SIGkgOj0gMCBUTyBsLTEgRE8NCiAgICAgICAgICAgIElGIGkgPSBsLTEgVEhFTg0KICAg
>ICAgICAgICAgICBBZGRUZXN0KFRleHQuU3ViKHRlc3RzLHMsbC1zKSkNCiAgICAgICAgICAgIEVM
>U0lGIFRleHQuR2V0Q2hhcih0ZXN0cyxpKSA9ICcsJyBUSEVODQogICAgICAgICAgICAgIEFkZFRl
>c3QoVGV4dC5TdWIodGVzdHMscyxpLXMpKTsNCiAgICAgICAgICAgICAgcyA6PSBpKzENCiAgICAg
>ICAgICAgIEVORA0KICAgICAgICAgIEVORA0KICAgICAgICBFTkQNCiAgICAgIEVORDsNCiAgICAg
>IHBwLmZpbmlzaCgpOw0KICAgIEVORA0KDQogIEVYQ0VQVA0KICAgIFBhcnNlUGFyYW1zLkVycm9y
>ID0+IFByb2Nlc3MuQ3Jhc2goIkNvdWxkbnQgcGFyc2UgY21kLWxpbmUgYXJncy4iKQ0KICBFTkQ7
>DQoNCiAgbiA6PSBOVU1CRVIoTWFrZXJzKSAqIG5QZXI7DQogIHRpbWVzMSA6PSBORVcoUkVGIEFS
>UkFZIE9GIElOVEVHRVIsIG4pOw0KICB0aW1lczIgOj0gTkVXKFJFRiBBUlJBWSBPRiBJTlRFR0VS
>LCBuKTsNCiAgdGltZXMzIDo9IE5FVyhSRUYgQVJSQVkgT0YgSU5URUdFUiwgbik7DQogIGNvdW50
>czEgOj0gTkVXKFJFRiBBUlJBWSBPRiBMT05HSU5ULCBuKTsNCiAgY291bnRzMiA6PSBORVcoUkVG
>IEFSUkFZIE9GIExPTkdJTlQsIG4pOw0KICBjb3VudHMzIDo9IE5FVyhSRUYgQVJSQVkgT0YgTE9O
>R0lOVCwgbik7DQogIGFjdGl2ZSA6PSBORVcoUkVGIEFSUkFZIE9GIEJPT0xFQU4sIG4pOw0KICB0
>aHJlYWRNIDo9IE5FVyhSRUYgQVJSQVkgT0YgTSwgbik7DQoNCiAgRk9SIGkgOj0gMCBUTyBuLTEN
>CiAgRE8NCiAgICAgYWN0aXZlW2ldIDo9IEZBTFNFOw0KICBFTkQ7ICgqIGZvciAqKQ0KDQogIFdy
>LlB1dFRleHQoU3RkaW8uc3Rkb3V0LCJXcml0aW5nIGZpbGUuLi4iKTsgV3IuRmx1c2goU3RkaW8u
>c3Rkb3V0KTsNCiAgV3JpdGVBRmlsZSgpOw0KICBXci5QdXRUZXh0KFN0ZGlvLnN0ZG91dCwiZG9u
>ZSIgJiBXci5FT0wpOyBXci5GbHVzaChTdGRpby5zdGRvdXQpOw0KDQogIEZPUiBpIDo9IEZJUlNU
>KE0pIFRPIExBU1QoTSkgRE8NCiAgICBJRiBpIElOIHNldHMgVEhFTg0KICAgICAgV3IuUHV0VGV4
>dChTdGRpby5zdGRvdXQsIkNyZWF0aW5nICIgJiBNYWtlcnNbaV0ubmFtZWQgJiAiIHRocmVhZHMu
>Li4iKTsNCiAgICAgIFdyLkZsdXNoKFN0ZGlvLnN0ZG91dCk7DQogICAgICBGT1IgaiA6PSAwIFRP
>IG5QZXIgLSAxIERPDQogICAgICAgIFdJVEggaWQgPSBpICogblBlciArIGoNCiAgICAgICAgRE8N
>CiAgICAgICAgICAgTWFrZXJzW2ldLm1ha2VyKGlkKTsNCiAgICAgICAgICAgYWN0aXZlW2lkXSA6
>PSBUUlVFOw0KICAgICAgICAgICB0aHJlYWRNW2lkXSA6PSBpOw0KICAgICAgICAgICBJRiB2ZXJi
>b3NlDQogICAgICAgICAgIFRIRU4NCiAgICAgICAgICAgICAgV3IuUHV0VGV4dChTdGRpby5zdGRv
>dXQsIFdyLkVPTCk7IFdyLlB1dFRleHQoU3RkaW8uc3Rkb3V0LCAiICAgIiAmIE1ha2Vyc1tpXS5u
>YW1lZCAmICI9Iik7IFB1dEludChpZCk7DQogICAgICAgICAgIEVORDsgKCogaWYgKikNCiAgICAg
>ICAgRU5EOyAoKiB3aXRoICopDQogICAgICBFTkQ7DQogICAgICBJRiB2ZXJib3NlDQogICAgICBU
>SEVODQogICAgICAgICBXci5QdXRUZXh0KFN0ZGlvLnN0ZG91dCwgV3IuRU9MKTsNCiAgICAgIEVO
>RDsgKCogaWYgKikNCiAgICAgIFdyLlB1dFRleHQoU3RkaW8uc3Rkb3V0LCAiZG9uZSIgJiBXci5F
>T0wpOyAgV3IuRmx1c2goU3RkaW8uc3Rkb3V0KQ0KICAgIEVORA0KICBFTkQ7DQoNCiAgV3IuUHV0
>VGV4dChTdGRpby5zdGRvdXQsInJ1bm5pbmcuLi5wcmludGluZyBvbGRlc3QvbWVkaWFuIGFnZS9u
>ZXdlc3QiICYgV3IuRU9MKTsNCiAgV3IuRmx1c2goU3RkaW8uc3Rkb3V0KTsNCiAgRk9SIGkgOj0g
>MSBUTyBpdGVycyBETw0KICAgIEZPUiBqIDo9IDEgVE8gd2FpdCBETw0KICAgICAgVGhyZWFkLlBh
>dXNlKDEuMGQwKTsNCiAgICAgIFdyLlB1dFRleHQoU3RkaW8uc3Rkb3V0LCIuIik7DQogICAgICBX
>ci5GbHVzaChTdGRpby5zdGRvdXQpDQogICAgRU5EOw0KICAgIHRpbWVzMl4gOj0gdGltZXMxXjsN
>CiAgICBub3cgIDo9IEZMT09SKFRpbWUuTm93KCkpOw0KICAgIGNvdW50czJeIDo9IGNvdW50czFe
>Ow0KICAgIFZBUg0KICAgICAgcCA6PSAwOw0KICAgIEJFR0lODQogICAgICBGT1IgaSA6PSBGSVJT
>VChNKSBUTyBMQVNUKE0pIERPDQogICAgICAgIElGIGkgSU4gc2V0cyBUSEVODQogICAgICAgICAg
>U1VCQVJSQVkodGltZXMzXixwLG5QZXIpIDo9IFNVQkFSUkFZKHRpbWVzMl4saSpuUGVyLG5QZXIp
>Ow0KICAgICAgICAgIElOQyhwLG5QZXIpDQogICAgICAgIEVORA0KICAgICAgRU5EOw0KICAgICAg
>V3IuUHV0VGV4dChTdGRpby5zdGRvdXQsImxhemllc3QgdGhyZWFkIGlzICIpOw0KICAgICAgUHV0
>U3RhdHMoU1VCQVJSQVkodGltZXMzXiwwLHApKTsNCiAgICAgIFdyLlB1dFRleHQoU3RkaW8uc3Rk
>b3V0LCIgKHRlc3RzOiIpOw0KDQogICAgICBGT1IgaSA6PSBGSVJTVChNKSBUTyBMQVNUKE0pIERP
>DQogICAgICAgIElGIGkgSU4gc2V0cyBUSEVODQogICAgICAgICAgV3IuUHV0VGV4dChTdGRpby5z
>dGRvdXQsIiAiKTsNCiAgICAgICAgICBXci5QdXRUZXh0KFN0ZGlvLnN0ZG91dCxNYWtlcnNbaV0u
>bmFtZWQpOw0KICAgICAgICAgIFdyLlB1dFRleHQoU3RkaW8uc3Rkb3V0LCIgIik7DQogICAgICAg
>ICAgUHV0U3RhdHMoU1VCQVJSQVkodGltZXMyXixpKm5QZXIsblBlcikpDQogICAgICAgIEVORA0K
>ICAgICAgRU5EOw0KICAgICAgV3IuUHV0VGV4dChTdGRpby5zdGRvdXQsIikiKTtXci5QdXRUZXh0
>KFN0ZGlvLnN0ZG91dCxXci5FT0wpOw0KICAgICAgV3IuRmx1c2goU3RkaW8uc3Rkb3V0KTsNCg0K
>ICAgICAgRk9SIGkgOj0gMCBUTyBuLTENCiAgICAgIERPDQogICAgICAgICBJRiBhY3RpdmVbaV0g
>QU5EIChjb3VudHMyW2ldID0gY291bnRzM1tpXSkNCiAgICAgICAgIFRIRU4NCiAgICAgICAgICAg
>IFdyLlB1dFRleHQoU3RkaW8uc3Rkb3V0LCBNYWtlcnNbdGhyZWFkTVtpXV0ubmFtZWQgJiAiIFRo
>cmVhZCAiICYgRm10LkludChpKSAmICIgYXBwZWFycyBzdGFydmVkIG9yIGRlYWRsb2NrZWQgISEh
>IiAmIFdyLkVPTCk7DQogICAgICAgICBFTFNJRiB2ZXJib3NlIEFORCBhY3RpdmVbaV0gQU5EIChj
>b3VudHMyW2ldID4gY291bnRzM1tpXSkNCiAgICAgICAgIFRIRU4NCiAgICAgICAgICAgIFdyLlB1
>dFRleHQoU3RkaW8uc3Rkb3V0LCAiICAgIiAmIE1ha2Vyc1t0aHJlYWRNW2ldXS5uYW1lZCAmICIg
>VGhyZWFkICIgJiBGbXQuSW50KGkpICYgIiBjb21wbGV0ZWQgIiAmIEZtdC5Mb25nSW50KGNvdW50
>czJbaV0gLSBjb3VudHMzW2ldKSAmICIgbG9vcHMuIiAmIFdyLkVPTCk7DQogICAgICAgICBFTkQ7
>ICgqIGlmICopDQogICAgICBFTkQ7ICgqIGZvciAqKQ0KICAgICAgY291bnRzM14gOj0gY291bnRz
>Ml47DQogICAgICBXci5GbHVzaChTdGRpby5zdGRvdXQpOw0KICAgIEVORA0KICBFTkQ7DQogIFdy
>LlB1dFRleHQoU3RkaW8uc3Rkb3V0LCAiQWxsIHRlc3RzIGNvbXBsZXRlLiAgQ29uZ3JhdHVsYXRp
>b25zLiIpOw0KICBXci5QdXRUZXh0KFN0ZGlvLnN0ZG91dCwgV3IuRU9MKTsNCkVORCBNYWluLg0K
>DQo=
>
>--_004_D67F02DDC62F7545A6B84C285F88F3E603418BD6ADatlex02srv_--


From rcolebur at SCIRES.COM  Wed Mar 16 19:42:10 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Wed, 16 Mar 2011 14:42:10 -0400
Subject: [M3devel] thread tests on NT386 32-bit circa 2008, not good so far
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E603418BDAF8@atlex02-srv>

I've gone back to a CM3 built on June 21, 2008.
Platform is IBM ThinkPad T60, Windows XP Professional, 32-bit.

If I try to put the "@M3paranoidgc" option on the command line, the thread test program always crashes, even before it reports anything about creating the threads.

"read", "nxread", "tryexcept", "fork", "forktoomuch", and "lock" tests seem to succeed.

"creat" and "alloc" seem to hang the program on the first iteration.  I see one "." printed and nothing else.  Have to CTRL-C abort.
BUT, if you run them with "@M3nogc" they will run until we run out of memory.  Tony, does this give any hint as to what may be wrong?

Output of the various runs is shown below:


C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read @M3paranoidgc

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0x42fb8c = AllocTraced + 0x3e in ..\src\runtime\common\RTCollector.m3
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 845
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 845
***


C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests alloc
Writing file...done
Creating alloc threads...
   alloc=15
   alloc=16
   alloc=17
done
running...printing oldest/median age/newest
.^C

C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests creat
Writing file...done
Creating creat threads...
   creat=18
   creat=19
   creat=20
done
running...printing oldest/median age/newest
.^C


C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests creat,alloc @M3nogc
Writing file...done
Creating alloc threads...
   alloc=15
   alloc=16
   alloc=17
done
Creating creat threads...
   creat=18
   creat=19
   creat=20
done
running...printing oldest/median age/newest
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 29204 loops.
   alloc Thread 16 completed 38868 loops.
   alloc Thread 17 completed 29118 loops.
   creat Thread 18 completed 111114 loops.
   creat Thread 19 completed 114913 loops.
   creat Thread 20 completed 108555 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 6968 loops.
   alloc Thread 16 completed 6747 loops.
   alloc Thread 17 completed 6331 loops.
   creat Thread 18 completed 40626 loops.
   creat Thread 19 completed 46526 loops.
   creat Thread 20 completed 43511 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 4857 loops.
   alloc Thread 16 completed 5409 loops.
   alloc Thread 17 completed 4601 loops.
   creat Thread 18 completed 50836 loops.
   creat Thread 19 completed 50108 loops.
   creat Thread 20 completed 53645 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 6249 loops.
   alloc Thread 16 completed 7252 loops.
   alloc Thread 17 completed 6770 loops.
   creat Thread 18 completed 62606 loops.
   creat Thread 19 completed 66036 loops.
   creat Thread 20 completed 62561 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 7000 loops.
   alloc Thread 16 completed 7559 loops.
   alloc Thread 17 completed 7389 loops.
   creat Thread 18 completed 66873 loops.
   creat Thread 19 completed 81612 loops.
   creat Thread 20 completed 62607 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 6666 loops.
   alloc Thread 16 completed 7579 loops.
   alloc Thread 17 completed 6964 loops.
   creat Thread 18 completed 89667 loops.
   creat Thread 19 completed 90794 loops.
   creat Thread 20 completed 90528 loops.
.....

***
*** runtime error:
***    NEW() was unable to allocate more memory.
***    file "..\src\runtime\common\RTCollector.m3", line 1545
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x4e7fe34   0x430197  LongAlloc + 0x89 in ..\src\runtime\common\RTCollector.m3
0x4e7fe90   0x42fd06  AllocTraced + 0x1b8 in ..\src\runtime\common\RTCollector.m3
0x4e7fed4   0x427ea9  GetOpenArray + 0x80 in ..\src\runtime\common\RTAllocator.m3
0x4e7fef8   0x427738  AllocateOpenArray + 0x19 in ..\src\runtime\common\RTAllocator.m3
0x4e7ff50   0x402293  AApply + 0x109 in ..\src\Main.m3
0x4e7ff88   0x42a34a  RunThread + 0x1f6 in ..\src\thread\WIN32\ThreadWin32.m3
0x4e7ffb4   0x42a0e3  ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3
.........  .........  ... more frames ...


C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lock
Writing file...done
Creating read threads...
   read=0
   read=1
   read=2
done
Creating nxread threads...
   nxread=3
   nxread=4
   nxread=5
done
Creating tryexcept threads...
   tryexcept=6
   tryexcept=7
   tryexcept=8
done
Creating fork threads...
   fork=9
   fork=0
   fork=11
done
Creating forktoomuch threads...
   forktoomuch=12
   forktoomuch=13
   forktoomuch=14
done
Creating lock threads...
   lock=21
   lock=22
   lock=23
done
running...printing oldest/median age/newest
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 2 loops.
   read Thread 1 completed 6 loops.
   read Thread 2 completed 4 loops.
   nxread Thread 3 completed 3 loops.
   nxread Thread 4 completed 1 loops.
   nxread Thread 5 completed 3 loops.
   tryexcept Thread 6 completed 14293296 loops.
   tryexcept Thread 7 completed 23332343 loops.
   tryexcept Thread 8 completed 14563267 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 5 loops.
   forktoomuch Thread 12 completed 6 loops.
   forktoomuch Thread 13 completed 7 loops.
   forktoomuch Thread 14 completed 6 loops.
   lock Thread 21 completed 1395 loops.
   lock Thread 22 completed 1613 loops.
   lock Thread 23 completed 2354 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 6 loops.
   read Thread 1 completed 13 loops.
   read Thread 2 completed 5 loops.
   nxread Thread 3 completed 8 loops.
   nxread Thread 4 completed 7 loops.
   nxread Thread 5 completed 10 loops.
   tryexcept Thread 6 completed 15350367 loops.
   tryexcept Thread 7 completed 22864059 loops.
   tryexcept Thread 8 completed 14516795 loops.
   fork Thread 9 completed 6 loops.
   fork Thread 10 completed 7 loops.
   fork Thread 11 completed 6 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 9 loops.
   forktoomuch Thread 14 completed 8 loops.
   lock Thread 21 completed 3742 loops.
   lock Thread 22 completed 2342 loops.
   lock Thread 23 completed 3827 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 5 loops.
   read Thread 1 completed 10 loops.
   read Thread 2 completed 4 loops.
   nxread Thread 3 completed 5 loops.
   nxread Thread 4 completed 3 loops.
   nxread Thread 5 completed 4 loops.
   tryexcept Thread 6 completed 14205335 loops.
   tryexcept Thread 7 completed 23955466 loops.
   tryexcept Thread 8 completed 14597334 loops.
   fork Thread 9 completed 7 loops.
   fork Thread 10 completed 6 loops.
   fork Thread 11 completed 7 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 9 loops.
   forktoomuch Thread 14 completed 8 loops.
   lock Thread 21 completed 1384 loops.
   lock Thread 22 completed 3801 loops.
   lock Thread 23 completed 4735 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 5 loops.
   read Thread 1 completed 9 loops.
   read Thread 2 completed 6 loops.
   nxread Thread 3 completed 5 loops.
   nxread Thread 4 completed 4 loops.
   nxread Thread 5 completed 9 loops.
   tryexcept Thread 6 completed 13962901 loops.
   tryexcept Thread 7 completed 22999610 loops.
   tryexcept Thread 8 completed 14123517 loops.
   fork Thread 9 completed 6 loops.
   fork Thread 10 completed 6 loops.
   fork Thread 11 completed 5 loops.
   forktoomuch Thread 12 completed 7 loops.
   forktoomuch Thread 13 completed 8 loops.
   forktoomuch Thread 14 completed 8 loops.
   lock Thread 21 completed 1744 loops.
   lock Thread 22 completed 2095 loops.
   lock Thread 23 completed 1503 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 2 loops.
   read Thread 1 completed 6 loops.
   read Thread 2 completed 2 loops.
   nxread Thread 3 completed 3 loops.
   nxread Thread 4 completed 3 loops.
   nxread Thread 5 completed 3 loops.
   tryexcept Thread 6 completed 15715885 loops.
   tryexcept Thread 7 completed 24769727 loops.
   tryexcept Thread 8 completed 15414675 loops.
   fork Thread 9 completed 7 loops.
   fork Thread 10 completed 6 loops.
   fork Thread 11 completed 7 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 8 loops.
   forktoomuch Thread 14 completed 9 loops.
   lock Thread 21 completed 1523 loops.
   lock Thread 22 completed 1922 loops.
   lock Thread 23 completed 1204 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 5 loops.
   read Thread 1 completed 9 loops.
   read Thread 2 completed 6 loops.
   nxread Thread 3 completed 4 loops.
   nxread Thread 4 completed 2 loops.
   nxread Thread 5 completed 8 loops.
   tryexcept Thread 6 completed 14688224 loops.
   tryexcept Thread 7 completed 23710577 loops.
   tryexcept Thread 8 completed 15355622 loops.
   fork Thread 9 completed 6 loops.
   fork Thread 10 completed 7 loops.
   fork Thread 11 completed 6 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 9 loops.
   forktoomuch Thread 14 completed 7 loops.
   lock Thread 21 completed 9427 loops.
   lock Thread 22 completed 3941 loops.
   lock Thread 23 completed 4421 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 9 loops.
   read Thread 1 completed 11 loops.
   read Thread 2 completed 6 loops.
   nxread Thread 3 completed 7 loops.
   nxread Thread 4 completed 5 loops.
   nxread Thread 5 completed 9 loops.
   tryexcept Thread 6 completed 16315690 loops.
   tryexcept Thread 7 completed 25110147 loops.
   tryexcept Thread 8 completed 17291322 loops.
   fork Thread 9 completed 5 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 5 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 9 loops.
   forktoomuch Thread 14 completed 8 loops.
   lock Thread 21 completed 1648 loops.
   lock Thread 22 completed 1274 loops.
   lock Thread 23 completed 975 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 2 loops.
   read Thread 1 completed 6 loops.
   read Thread 2 completed 3 loops.
   nxread Thread 3 completed 7 loops.
   nxread Thread 4 completed 4 loops.
   nxread Thread 5 completed 7 loops.
   tryexcept Thread 6 completed 16955552 loops.
   tryexcept Thread 7 completed 27781696 loops.
   tryexcept Thread 8 completed 16151561 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 3 loops.
   fork Thread 11 completed 2 loops.
   forktoomuch Thread 12 completed 7 loops.
   forktoomuch Thread 13 completed 7 loops.
   forktoomuch Thread 14 completed 7 loops.
   lock Thread 21 completed 2148 loops.
   lock Thread 22 completed 2179 loops.
   lock Thread 23 completed 1804 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 7 loops.
   read Thread 1 completed 5 loops.
   read Thread 2 completed 4 loops.
   nxread Thread 3 completed 9 loops.
   nxread Thread 4 completed 6 loops.
   nxread Thread 5 completed 5 loops.
   tryexcept Thread 6 completed 14537433 loops.
   tryexcept Thread 7 completed 24043303 loops.
   tryexcept Thread 8 completed 14258976 loops.
   fork Thread 9 completed 6 loops.
   fork Thread 10 completed 7 loops.
   fork Thread 11 completed 6 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 8 loops.
   forktoomuch Thread 14 completed 8 loops.
   lock Thread 21 completed 6504 loops.
   lock Thread 22 completed 2290 loops.
   lock Thread 23 completed 7696 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 5 loops.
   read Thread 1 completed 6 loops.
   read Thread 2 completed 2 loops.
   nxread Thread 3 completed 4 loops.
   nxread Thread 4 completed 1 loops.
   nxread Thread 5 completed 3 loops.
   tryexcept Thread 6 completed 17349384 loops.
   tryexcept Thread 7 completed 29845941 loops.
   tryexcept Thread 8 completed 17792587 loops.
   fork Thread 9 completed 5 loops.
   fork Thread 10 completed 5 loops.
   fork Thread 11 completed 6 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 9 loops.
   forktoomuch Thread 14 completed 9 loops.
   lock Thread 21 completed 2692 loops.
   lock Thread 22 completed 4498 loops.
   lock Thread 23 completed 3600 loops.
All tests complete.  Congratulations.

C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>

Regards,
Randy Coleburn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110316/5aece318/attachment.html>

From rcolebur at SCIRES.COM  Wed Mar 16 19:54:37 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Wed, 16 Mar 2011 14:54:37 -0400
Subject: [M3devel] another thread test run on NT386 32-bit using HEAD branch
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E603418BDB06@atlex02-srv>

Here are results from the following platform:
IBM G40, Windows XP Professional, 32-bit
Using current HEAD branch of CM3

Both of the runs below use @M3paranoidgc

Note on the second run using alloc and creat tests that I get an error about a thread trying to join twice.

C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lock @M3paranoidgc
Writing file...done
Creating read threads...
   read=0
   read=1
   read=2
done
Creating nxread threads...
   nxread=3
   nxread=4
   nxread=5
done
Creating tryexcept threads...
   tryexcept=6
   tryexcept=7
   tryexcept=8
done
Creating fork threads...
   fork=9
   fork=0
   fork=11
done
Creating forktoomuch threads...
   forktoomuch=12
   forktoomuch=13
   forktoomuch=14
done
Creating lock threads...
   lock=21
   lock=22
   lock=23
done
running...printing oldest/median age/newest
....

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0x4086a0 = Init + 0x79 in ..\src\rw\FileRd.m3
***

.Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x107feb8   0x44536b  SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m3
0x107ff00   0x4086a0  Init + 0x79 in ..\src\rw\FileRd.m3
0x107ff2c   0x40861d  Open + 0x4d in ..\src\rw\FileRd.m3
0x107ff78   0x40173e  NApply + 0x124 in ..\src\Main.m3
0x107ffb4   0x42b56f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
.........  .........  ... more frames ...



C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests alloc,creat @M3paranoidgc
Writing file...done
Creating alloc threads...
   alloc=15
   alloc=16
   alloc=17
done
Creating creat threads...
   creat=18
   creat=19
   creat=20
done
running...printing oldest/median age/newest
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 11125 loops.
   alloc Thread 16 completed 10472 loops.
   alloc Thread 17 completed 9722 loops.
   creat Thread 18 completed 84 loops.
   creat Thread 19 completed 98 loops.
   creat Thread 20 completed 96 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 14258 loops.
   alloc Thread 16 completed 10791 loops.
   alloc Thread 17 completed 11403 loops.
   creat Thread 18 completed 111 loops.
   creat Thread 19 completed 115 loops.
   creat Thread 20 completed 121 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 13954 loops.
   alloc Thread 16 completed 9547 loops.
   alloc Thread 17 completed 10561 loops.
   creat Thread 18 completed 115 loops.
   creat Thread 19 completed 121 loops.
   creat Thread 20 completed 125 loops.
.

***
*** runtime error:
***    Thread client error: attempt to join with thread twice
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 688
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x127fedc   0x42c3ee  Die + 0x2a in ..\src\thread\WIN32\ThreadWin32.m3
0x127ff10   0x42b882  XJoin + 0x3c in ..\src\thread\WIN32\ThreadWin32.m3
0x127ff38   0x42ba06  Join + 0x46 in ..\src\thread\WIN32\ThreadWin32.m3
0x127ff78   0x402777  CApply + 0x12d in ..\src\Main.m3
0x127ffb4   0x42b56f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
.........  .........  ... more frames ...


Regards,
Randy Coleburn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110316/9a242093/attachment.html>

From dabenavidesd at yahoo.es  Wed Mar 16 22:11:06 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 16 Mar 2011 21:11:06 +0000 (GMT)
Subject: [M3devel] thread tests on NT386 32-bit circa 2008,
	not good so far
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BDAF8@atlex02-srv>
Message-ID: <654158.70885.qm@web29702.mail.ird.yahoo.com>

Hi all:
I would be not surprised if its results were wrong crashes but because of the system threading.
Certainly we? would need to discard why the user threads are working so far and system threads are not working, i.e why CVsup is not working there are several idiomatic differences between system threads, each system indeed has its own behavior different from user threads, it certainly makes things portable in that sense to me.
But when ever we have access to one SPIN installation, I guess the program would be no trouble in running, as I think you could even debug it with a dynamic race condition detector, as I read somewhere, they did a catch somewhere in C client libraries linked against RT or better than that to use SPIN m3gdb specially modified for that purpose of remote debugging.
Even with the user threads implementation is not difficult but because of those libraries get into that debugging I believe.
Also we can annotate sources to debug later with ESC, at least its syntax, later more.
The other thing is that we then must need LL pragma which I still don't how to use, so any documentation on that is most welcome.
Yet another option would be catch the system threads in a stack trace able platform like there were before, perhaps this is the most feasible 
Thanks in advance

?

--- El mi?, 16/3/11, Coleburn, Randy <rcolebur at SCIRES.COM> escribi?:

De: Coleburn, Randy <rcolebur at SCIRES.COM>
Asunto: [M3devel] thread tests on NT386 32-bit circa 2008, not good so far
Para: "m3devel" <m3devel at elegosoft.com>
Fecha: mi?rcoles, 16 de marzo, 2011 13:42

I?ve gone back to a CM3 built on June 21, 2008.Platform is IBM ThinkPad T60, Windows XP Professional, 32-bit. ?If I try to put the ?@M3paranoidgc? option on the command line, the thread test program always crashes, even before it reports anything about creating the threads. ??read?, ?nxread?, ?tryexcept?, ?fork?, ?forktoomuch?, and ?lock? tests seem to succeed. ??creat? and ?alloc? seem to hang the program on the first iteration.? I see one ?.? printed and nothing else.? Have to CTRL-C abort.BUT, if you run them with ?@M3nogc? they will run until we run out of memory.? Tony, does this give any hint as to what may be wrong? ?Output of the various runs is shown below: ? ?C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read @M3paranoidgc ?****** runtime error:***??? Attempt to reference an illegal memory location.***??? pc = 0x42fb8c = AllocTraced + 0x3e in
 ..\src\runtime\common\RTCollector.m3*** ?****** runtime error:***??? <*ASSERT*> failed.***??? file "..\src\thread\WIN32\ThreadWin32.m3", line 845*** ?****** runtime error:***??? <*ASSERT*> failed.***??? file "..\src\thread\WIN32\ThreadWin32.m3", line 845*** ? ?C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests allocWriting file...doneCreating alloc threads...?? alloc=15?? alloc=16?? alloc=17donerunning...printing oldest/median age/newest.^C ?C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests creatWriting file...doneCreating creat threads...?? creat=18?? creat=19?? creat=20donerunning...printing oldest/median age/newest.^C ? ?C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests creat,alloc @M3nogcWriting file...doneCreating alloc threads...?? alloc=15?? alloc=16?? alloc=17doneCreating creat threads...?? creat=18??
 creat=19?? creat=20donerunning...printing oldest/median age/newest..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)?? alloc Thread 15 completed 29204 loops.?? alloc Thread 16 completed 38868 loops.?? alloc Thread 17 completed 29118 loops.?? creat Thread 18 completed 111114 loops.?? creat Thread 19 completed 114913 loops.?? creat Thread 20 completed 108555 loops...........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)?? alloc Thread 15 completed 6968 loops.?? alloc Thread 16 completed 6747 loops.?? alloc Thread 17 completed 6331 loops.?? creat Thread 18 completed 40626 loops.?? creat Thread 19 completed 46526 loops.?? creat Thread 20 completed 43511 loops...........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)?? alloc Thread 15 completed 4857 loops.?? alloc Thread 16 completed 5409 loops.?? alloc Thread 17 completed 4601 loops.?? creat Thread 18 completed 50836 loops.?? creat
 Thread 19 completed 50108 loops.?? creat Thread 20 completed 53645 loops...........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)?? alloc Thread 15 completed 6249 loops.?? alloc Thread 16 completed 7252 loops.?? alloc Thread 17 completed 6770 loops.?? creat Thread 18 completed 62606 loops.?? creat Thread 19 completed 66036 loops.?? creat Thread 20 completed 62561 loops...........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)?? alloc Thread 15 completed 7000 loops.?? alloc Thread 16 completed 7559 loops.?? alloc Thread 17 completed 7389 loops.?? creat Thread 18 completed 66873 loops.?? creat Thread 19 completed 81612 loops.?? creat Thread 20 completed 62607 loops...........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)?? alloc Thread 15 completed 6666 loops.?? alloc Thread 16 completed 7579 loops.?? alloc Thread 17 completed 6964 loops.?? creat Thread 18 completed 89667 loops.?? creat
 Thread 19 completed 90794 loops.?? creat Thread 20 completed 90528 loops...... ?****** runtime error:***??? NEW() was unable to allocate more memory.***??? file "..\src\runtime\common\RTCollector.m3", line 1545*** ?Stack trace:?? FP???????? PC????? Procedure---------? ---------? -------------------------------0x4e7fe34?? 0x430197? LongAlloc + 0x89 in ..\src\runtime\common\RTCollector.m30x4e7fe90?? 0x42fd06? AllocTraced + 0x1b8 in ..\src\runtime\common\RTCollector.m30x4e7fed4?? 0x427ea9? GetOpenArray + 0x80 in ..\src\runtime\common\RTAllocator.m30x4e7fef8?? 0x427738? AllocateOpenArray + 0x19 in ..\src\runtime\common\RTAllocator.m30x4e7ff50?? 0x402293? AApply + 0x109 in ..\src\Main.m30x4e7ff88?? 0x42a34a? RunThread + 0x1f6 in ..\src\thread\WIN32\ThreadWin32.m30x4e7ffb4?? 0x42a0e3? ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3.........? .........? ... more frames ... ?
 ?C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lockWriting file...doneCreating read threads...?? read=0?? read=1?? read=2doneCreating nxread threads...?? nxread=3?? nxread=4?? nxread=5doneCreating tryexcept threads...?? tryexcept=6?? tryexcept=7?? tryexcept=8doneCreating fork threads...?? fork=9?? fork=0?? fork=11doneCreating forktoomuch threads...?? forktoomuch=12?? forktoomuch=13?? forktoomuch=14doneCreating lock threads...?? lock=21?? lock=22?? lock=23donerunning...printing oldest/median age/newest..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 2 loops.?? read Thread 1 completed 6 loops.?? read Thread 2 completed 4 loops.?? nxread Thread 3 completed 3 loops.?? nxread Thread 4 completed 1 loops.?? nxread Thread 5 completed 3
 loops.?? tryexcept Thread 6 completed 14293296 loops.?? tryexcept Thread 7 completed 23332343 loops.?? tryexcept Thread 8 completed 14563267 loops.?? fork Thread 9 completed 4 loops.?? fork Thread 10 completed 4 loops.?? fork Thread 11 completed 5 loops.?? forktoomuch Thread 12 completed 6 loops.?? forktoomuch Thread 13 completed 7 loops.?? forktoomuch Thread 14 completed 6 loops.?? lock Thread 21 completed 1395 loops.?? lock Thread 22 completed 1613 loops.?? lock Thread 23 completed 2354 loops...........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 6 loops.?? read Thread 1 completed 13 loops.?? read Thread 2 completed 5 loops.?? nxread Thread 3 completed 8 loops.?? nxread Thread 4 completed 7 loops.?? nxread Thread 5 completed 10 loops.?? tryexcept Thread 6 completed 15350367 loops.?? tryexcept Thread 7 completed 22864059
 loops.?? tryexcept Thread 8 completed 14516795 loops.?? fork Thread 9 completed 6 loops.?? fork Thread 10 completed 7 loops.?? fork Thread 11 completed 6 loops.?? forktoomuch Thread 12 completed 8 loops.?? forktoomuch Thread 13 completed 9 loops.?? forktoomuch Thread 14 completed 8 loops.?? lock Thread 21 completed 3742 loops.?? lock Thread 22 completed 2342 loops.?? lock Thread 23 completed 3827 loops...........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 5 loops.?? read Thread 1 completed 10 loops.?? read Thread 2 completed 4 loops.?? nxread Thread 3 completed 5 loops.?? nxread Thread 4 completed 3 loops.?? nxread Thread 5 completed 4 loops.?? tryexcept Thread 6 completed 14205335 loops.?? tryexcept Thread 7 completed 23955466 loops.?? tryexcept Thread 8 completed 14597334 loops.?? fork Thread 9 completed 7 loops.??
 fork Thread 10 completed 6 loops.?? fork Thread 11 completed 7 loops.?? forktoomuch Thread 12 completed 8 loops.?? forktoomuch Thread 13 completed 9 loops.?? forktoomuch Thread 14 completed 8 loops.?? lock Thread 21 completed 1384 loops.?? lock Thread 22 completed 3801 loops.?? lock Thread 23 completed 4735 loops...........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 5 loops.?? read Thread 1 completed 9 loops.?? read Thread 2 completed 6 loops.?? nxread Thread 3 completed 5 loops.?? nxread Thread 4 completed 4 loops.?? nxread Thread 5 completed 9 loops.?? tryexcept Thread 6 completed 13962901 loops.?? tryexcept Thread 7 completed 22999610 loops.?? tryexcept Thread 8 completed 14123517 loops.?? fork Thread 9 completed 6 loops.?? fork Thread 10 completed 6 loops.?? fork Thread 11 completed 5 loops.?? forktoomuch Thread 12
 completed 7 loops.?? forktoomuch Thread 13 completed 8 loops.?? forktoomuch Thread 14 completed 8 loops.?? lock Thread 21 completed 1744 loops.?? lock Thread 22 completed 2095 loops.?? lock Thread 23 completed 1503 loops...........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 2 loops.?? read Thread 1 completed 6 loops.?? read Thread 2 completed 2 loops.?? nxread Thread 3 completed 3 loops.?? nxread Thread 4 completed 3 loops.? ?nxread Thread 5 completed 3 loops.?? tryexcept Thread 6 completed 15715885 loops.?? tryexcept Thread 7 completed 24769727 loops.?? tryexcept Thread 8 completed 15414675 loops.?? fork Thread 9 completed 7 loops.?? fork Thread 10 completed 6 loops.?? fork Thread 11 completed 7 loops.?? forktoomuch Thread 12 completed 8 loops.?? forktoomuch Thread 13 completed 8 loops.?? forktoomuch Thread 14 completed
 9 loops.?? lock Thread 21 completed 1523 loops.?? lock Thread 22 completed 1922 loops.?? lock Thread 23 completed 1204 loops...........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 5 loops.?? read Thread 1 completed 9 loops.?? read Thread 2 completed 6 loops.?? nxread Thread 3 completed 4 loops.?? nxread Thread 4 completed 2 loops.?? nxread Thread 5 completed 8 loops.?? tryexcept Thread 6 completed 14688224 loops.?? tryexcept Thread 7 completed 23710577 loops.?? tryexcept Thread 8 completed 15355622 loops.?? fork Thread 9 completed 6 loops.?? fork Thread 10 completed 7 loops.?? fork Thread 11 completed 6 loops.?? forktoomuch Thread 12 completed 8 loops.?? forktoomuch Thread 13 completed 9 loops.?? forktoomuch Thread 14 completed 7 loops.?? lock Thread 21 completed 9427 loops.?? lock Thread 22 completed 3941 loops.?? lock
 Thread 23 completed 4421 loops...........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 9 loops.?? read Thread 1 completed 11 loops.?? read Thread 2 completed 6 loops.?? nxread Thread 3 completed 7 loops.?? nxread Thread 4 completed 5 loops.?? nxread Thread 5 completed 9 loops.?? tryexcept Thread 6 completed 16315690 loops.?? tryexcept Thread 7 completed 25110147 loops.?? tryexcept Thread 8 completed 17291322 loops.?? fork Thread 9 completed 5 loops.?? fork Thread 10 completed 4 loops.?? fork Thread 11 completed 5 loops.? ?forktoomuch Thread 12 completed 8 loops.?? forktoomuch Thread 13 completed 9 loops.?? forktoomuch Thread 14 completed 8 loops.?? lock Thread 21 completed 1648 loops.?? lock Thread 22 completed 1274 loops.?? lock Thread 23 completed 975 loops...........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0
 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 2 loops.?? read Thread 1 completed 6 loops.?? read Thread 2 completed 3 loops.?? nxread Thread 3 completed 7 loops.?? nxread Thread 4 completed 4 loops.?? nxread Thread 5 completed 7 loops.?? tryexcept Thread 6 completed 16955552 loops.?? tryexcept Thread 7 completed 27781696 loops.?? tryexcept Thread 8 completed 16151561 loops.?? fork Thread 9 completed 4 loops.?? fork Thread 10 completed 3 loops.?? fork Thread 11 completed 2 loops.?? forktoomuch Thread 12 completed 7 loops.?? forktoomuch Thread 13 completed 7 loops.?? forktoomuch Thread 14 completed 7 loops.?? lock Thread 21 completed 2148 loops.?? lock Thread 22 completed 2179 loops.?? lock Thread 23 completed 1804 loops...........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 7 loops.??
 read Thread 1 completed 5 loops.?? read Thread 2 completed 4 loops.?? nxread Thread 3 completed 9 loops.?? nxread Thread 4 completed 6 loops.?? nxread Thread 5 completed 5 loops.?? tryexcept Thread 6 completed 14537433 loops.?? tryexcept Thread 7 completed 24043303 loops.?? tryexcept Thread 8 completed 14258976 loops.?? fork Thread 9 completed 6 loops.?? fork Thread 10 completed 7 loops.?? fork Thread 11 completed 6 loops.?? forktoomuch Thread 12 completed 8 loops.?? forktoomuch Thread 13 completed 8 loops.?? forktoomuch Thread 14 completed 8 loops.?? lock Thread 21 completed 6504 loops.?? lock Thread 22 completed 2290 loops.?? lock Thread 23 completed 7696 loops...........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 5 loops.?? read Thread 1 completed 6 loops.?? read Thread 2 completed 2 loops.?? nxread Thread 3 completed
 4 loops.?? nxread Thread 4 completed 1 loops.?? nxread Thread 5 completed 3 loops.?? tryexcept Thread 6 completed 17349384 loops.?? tryexcept Thread 7 completed 29845941 loops.?? tryexcept Thread 8 completed 17792587 loops.?? fork Thread 9 completed 5 loops.?? fork Thread 10 completed 5 loops.?? fork Thread 11 completed 6 loops.? ?forktoomuch Thread 12 completed 8 loops.?? forktoomuch Thread 13 completed 9 loops.?? forktoomuch Thread 14 completed 9 loops.?? lock Thread 21 completed 2692 loops.?? lock Thread 22 completed 4498 loops.?? lock Thread 23 completed 3600 loops.All tests complete.? Congratulations. ?C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386> ?Regards,Randy Coleburn ?


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110316/e17b3645/attachment.html>

From hosking at cs.purdue.edu  Wed Mar 16 22:22:38 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 16 Mar 2011 17:22:38 -0400
Subject: [M3devel] another thread test run on NT386 32-bit using HEAD
	branch
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BDB06@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BDB06@atlex02-srv>
Message-ID: <0BEFC896-66CC-4441-8271-360FD0E3F59B@cs.purdue.edu>

Badness both places.  Not sure I see anything obvious from these dumps.

On Mar 16, 2011, at 2:54 PM, Coleburn, Randy wrote:

> Here are results from the following platform:
> IBM G40, Windows XP Professional, 32-bit
> Using current HEAD branch of CM3
>  
> Both of the runs below use @M3paranoidgc
>  
> Note on the second run using alloc and creat tests that I get an error about a thread trying to join twice.
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lock @M3paranoidgc
> Writing file...done
> Creating read threads...
>    read=0
>    read=1
>    read=2
> done
> Creating nxread threads...
>    nxread=3
>    nxread=4
>    nxread=5
> done
> Creating tryexcept threads...
>    tryexcept=6
>    tryexcept=7
>    tryexcept=8
> done
> Creating fork threads...
>    fork=9
>    fork=0
>    fork=11
> done
> Creating forktoomuch threads...
>    forktoomuch=12
>    forktoomuch=13
>    forktoomuch=14
> done
> Creating lock threads...
>    lock=21
>    lock=22
>    lock=23
> done
> running...printing oldest/median age/newest
> ....
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
> ***    pc = 0x4086a0 = Init + 0x79 in ..\src\rw\FileRd.m3
> ***
>  
> .Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0x107feb8   0x44536b  SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m3
> 0x107ff00   0x4086a0  Init + 0x79 in ..\src\rw\FileRd.m3
> 0x107ff2c   0x40861d  Open + 0x4d in ..\src\rw\FileRd.m3
> 0x107ff78   0x40173e  NApply + 0x124 in ..\src\Main.m3
> 0x107ffb4   0x42b56f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
> .........  .........  ... more frames ...
>  
>  
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests alloc,creat @M3paranoidgc
> Writing file...done
> Creating alloc threads...
>    alloc=15
>    alloc=16
>    alloc=17
> done
> Creating creat threads...
>    creat=18
>    creat=19
>    creat=20
> done
> running...printing oldest/median age/newest
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 11125 loops.
>    alloc Thread 16 completed 10472 loops.
>    alloc Thread 17 completed 9722 loops.
>    creat Thread 18 completed 84 loops.
>    creat Thread 19 completed 98 loops.
>    creat Thread 20 completed 96 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 14258 loops.
>    alloc Thread 16 completed 10791 loops.
>    alloc Thread 17 completed 11403 loops.
>    creat Thread 18 completed 111 loops.
>    creat Thread 19 completed 115 loops.
>    creat Thread 20 completed 121 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 13954 loops.
>    alloc Thread 16 completed 9547 loops.
>    alloc Thread 17 completed 10561 loops.
>    creat Thread 18 completed 115 loops.
>    creat Thread 19 completed 121 loops.
>    creat Thread 20 completed 125 loops.
> .
>  
> ***
> *** runtime error:
> ***    Thread client error: attempt to join with thread twice
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 688
> ***
>  
> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0x127fedc   0x42c3ee  Die + 0x2a in ..\src\thread\WIN32\ThreadWin32.m3
> 0x127ff10   0x42b882  XJoin + 0x3c in ..\src\thread\WIN32\ThreadWin32.m3
> 0x127ff38   0x42ba06  Join + 0x46 in ..\src\thread\WIN32\ThreadWin32.m3
> 0x127ff78   0x402777  CApply + 0x12d in ..\src\Main.m3
> 0x127ffb4   0x42b56f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
> .........  .........  ... more frames ...
>  
>  
> Regards,
> Randy Coleburn
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110316/56759756/attachment.html>

From hosking at cs.purdue.edu  Wed Mar 16 22:25:25 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 16 Mar 2011 17:25:25 -0400
Subject: [M3devel] thread tests on NT386 32-bit circa 2008,
	not good so far
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BDAF8@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BDAF8@atlex02-srv>
Message-ID: <B579D06A-BA7D-4739-9954-3B8A4E358AAD@cs.purdue.edu>

I don't remember how stable the collector was at that point.  Running them with @M3nogc indicates there were problems with it.
Now, what happens with the current trunk head when run with @M3nogc?

On Mar 16, 2011, at 2:42 PM, Coleburn, Randy wrote:

> I?ve gone back to a CM3 built on June 21, 2008.
> Platform is IBM ThinkPad T60, Windows XP Professional, 32-bit.
>  
> If I try to put the ?@M3paranoidgc? option on the command line, the thread test program always crashes, even before it reports anything about creating the threads.
>  
> ?read?, ?nxread?, ?tryexcept?, ?fork?, ?forktoomuch?, and ?lock? tests seem to succeed.
>  
> ?creat? and ?alloc? seem to hang the program on the first iteration.  I see one ?.? printed and nothing else.  Have to CTRL-C abort.
> BUT, if you run them with ?@M3nogc? they will run until we run out of memory.  Tony, does this give any hint as to what may be wrong?
>  
> Output of the various runs is shown below:
>  
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read @M3paranoidgc
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
> ***    pc = 0x42fb8c = AllocTraced + 0x3e in ..\src\runtime\common\RTCollector.m3
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 845
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 845
> ***
>  
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests alloc
> Writing file...done
> Creating alloc threads...
>    alloc=15
>    alloc=16
>    alloc=17
> done
> running...printing oldest/median age/newest
> .^C
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests creat
> Writing file...done
> Creating creat threads...
>    creat=18
>    creat=19
>    creat=20
> done
> running...printing oldest/median age/newest
> .^C
>  
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests creat,alloc @M3nogc
> Writing file...done
> Creating alloc threads...
>    alloc=15
>    alloc=16
>    alloc=17
> done
> Creating creat threads...
>    creat=18
>    creat=19
>    creat=20
> done
> running...printing oldest/median age/newest
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 29204 loops.
>    alloc Thread 16 completed 38868 loops.
>    alloc Thread 17 completed 29118 loops.
>    creat Thread 18 completed 111114 loops.
>    creat Thread 19 completed 114913 loops.
>    creat Thread 20 completed 108555 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 6968 loops.
>    alloc Thread 16 completed 6747 loops.
>    alloc Thread 17 completed 6331 loops.
>    creat Thread 18 completed 40626 loops.
>    creat Thread 19 completed 46526 loops.
>    creat Thread 20 completed 43511 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 4857 loops.
>    alloc Thread 16 completed 5409 loops.
>    alloc Thread 17 completed 4601 loops.
>    creat Thread 18 completed 50836 loops.
>    creat Thread 19 completed 50108 loops.
>    creat Thread 20 completed 53645 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 6249 loops.
>    alloc Thread 16 completed 7252 loops.
>    alloc Thread 17 completed 6770 loops.
>    creat Thread 18 completed 62606 loops.
>    creat Thread 19 completed 66036 loops.
>    creat Thread 20 completed 62561 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 7000 loops.
>    alloc Thread 16 completed 7559 loops.
>    alloc Thread 17 completed 7389 loops.
>    creat Thread 18 completed 66873 loops.
>    creat Thread 19 completed 81612 loops.
>    creat Thread 20 completed 62607 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 6666 loops.
>    alloc Thread 16 completed 7579 loops.
>    alloc Thread 17 completed 6964 loops.
>    creat Thread 18 completed 89667 loops.
>    creat Thread 19 completed 90794 loops.
>    creat Thread 20 completed 90528 loops.
> .....
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
> ***    file "..\src\runtime\common\RTCollector.m3", line 1545
> ***
>  
> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0x4e7fe34   0x430197  LongAlloc + 0x89 in ..\src\runtime\common\RTCollector.m3
> 0x4e7fe90   0x42fd06  AllocTraced + 0x1b8 in ..\src\runtime\common\RTCollector.m3
> 0x4e7fed4   0x427ea9  GetOpenArray + 0x80 in ..\src\runtime\common\RTAllocator.m3
> 0x4e7fef8   0x427738  AllocateOpenArray + 0x19 in ..\src\runtime\common\RTAllocator.m3
> 0x4e7ff50   0x402293  AApply + 0x109 in ..\src\Main.m3
> 0x4e7ff88   0x42a34a  RunThread + 0x1f6 in ..\src\thread\WIN32\ThreadWin32.m3
> 0x4e7ffb4   0x42a0e3  ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3
> .........  .........  ... more frames ...
>  
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lock
> Writing file...done
> Creating read threads...
>    read=0
>    read=1
>    read=2
> done
> Creating nxread threads...
>    nxread=3
>    nxread=4
>    nxread=5
> done
> Creating tryexcept threads...
>    tryexcept=6
>    tryexcept=7
>    tryexcept=8
> done
> Creating fork threads...
>    fork=9
>    fork=0
>    fork=11
> done
> Creating forktoomuch threads...
>    forktoomuch=12
>    forktoomuch=13
>    forktoomuch=14
> done
> Creating lock threads...
>    lock=21
>    lock=22
>    lock=23
> done
> running...printing oldest/median age/newest
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 2 loops.
>    read Thread 1 completed 6 loops.
>    read Thread 2 completed 4 loops.
>    nxread Thread 3 completed 3 loops.
>    nxread Thread 4 completed 1 loops.
>    nxread Thread 5 completed 3 loops.
>    tryexcept Thread 6 completed 14293296 loops.
>    tryexcept Thread 7 completed 23332343 loops.
>    tryexcept Thread 8 completed 14563267 loops.
>    fork Thread 9 completed 4 loops.
>    fork Thread 10 completed 4 loops.
>    fork Thread 11 completed 5 loops.
>    forktoomuch Thread 12 completed 6 loops.
>    forktoomuch Thread 13 completed 7 loops.
>    forktoomuch Thread 14 completed 6 loops.
>    lock Thread 21 completed 1395 loops.
>    lock Thread 22 completed 1613 loops.
>    lock Thread 23 completed 2354 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 6 loops.
>    read Thread 1 completed 13 loops.
>    read Thread 2 completed 5 loops.
>    nxread Thread 3 completed 8 loops.
>    nxread Thread 4 completed 7 loops.
>    nxread Thread 5 completed 10 loops.
>    tryexcept Thread 6 completed 15350367 loops.
>    tryexcept Thread 7 completed 22864059 loops.
>    tryexcept Thread 8 completed 14516795 loops.
>    fork Thread 9 completed 6 loops.
>    fork Thread 10 completed 7 loops.
>    fork Thread 11 completed 6 loops.
>    forktoomuch Thread 12 completed 8 loops.
>    forktoomuch Thread 13 completed 9 loops.
>    forktoomuch Thread 14 completed 8 loops.
>    lock Thread 21 completed 3742 loops.
>    lock Thread 22 completed 2342 loops.
>    lock Thread 23 completed 3827 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 5 loops.
>    read Thread 1 completed 10 loops.
>    read Thread 2 completed 4 loops.
>    nxread Thread 3 completed 5 loops.
>    nxread Thread 4 completed 3 loops.
>    nxread Thread 5 completed 4 loops.
>    tryexcept Thread 6 completed 14205335 loops.
>    tryexcept Thread 7 completed 23955466 loops.
>    tryexcept Thread 8 completed 14597334 loops.
>    fork Thread 9 completed 7 loops.
>    fork Thread 10 completed 6 loops.
>    fork Thread 11 completed 7 loops.
>    forktoomuch Thread 12 completed 8 loops.
>    forktoomuch Thread 13 completed 9 loops.
>    forktoomuch Thread 14 completed 8 loops.
>    lock Thread 21 completed 1384 loops.
>    lock Thread 22 completed 3801 loops.
>    lock Thread 23 completed 4735 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 5 loops.
>    read Thread 1 completed 9 loops.
>    read Thread 2 completed 6 loops.
>    nxread Thread 3 completed 5 loops.
>    nxread Thread 4 completed 4 loops.
>    nxread Thread 5 completed 9 loops.
>    tryexcept Thread 6 completed 13962901 loops.
>    tryexcept Thread 7 completed 22999610 loops.
>    tryexcept Thread 8 completed 14123517 loops.
>    fork Thread 9 completed 6 loops.
>    fork Thread 10 completed 6 loops.
>    fork Thread 11 completed 5 loops.
>    forktoomuch Thread 12 completed 7 loops.
>    forktoomuch Thread 13 completed 8 loops.
>    forktoomuch Thread 14 completed 8 loops.
>    lock Thread 21 completed 1744 loops.
>    lock Thread 22 completed 2095 loops.
>    lock Thread 23 completed 1503 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 2 loops.
>    read Thread 1 completed 6 loops.
>    read Thread 2 completed 2 loops.
>    nxread Thread 3 completed 3 loops.
>    nxread Thread 4 completed 3 loops.
>    nxread Thread 5 completed 3 loops.
>    tryexcept Thread 6 completed 15715885 loops.
>    tryexcept Thread 7 completed 24769727 loops.
>    tryexcept Thread 8 completed 15414675 loops.
>    fork Thread 9 completed 7 loops.
>    fork Thread 10 completed 6 loops.
>    fork Thread 11 completed 7 loops.
>    forktoomuch Thread 12 completed 8 loops.
>    forktoomuch Thread 13 completed 8 loops.
>    forktoomuch Thread 14 completed 9 loops.
>    lock Thread 21 completed 1523 loops.
>    lock Thread 22 completed 1922 loops.
>    lock Thread 23 completed 1204 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 5 loops.
>    read Thread 1 completed 9 loops.
>    read Thread 2 completed 6 loops.
>    nxread Thread 3 completed 4 loops.
>    nxread Thread 4 completed 2 loops.
>    nxread Thread 5 completed 8 loops.
>    tryexcept Thread 6 completed 14688224 loops.
>    tryexcept Thread 7 completed 23710577 loops.
>    tryexcept Thread 8 completed 15355622 loops.
>    fork Thread 9 completed 6 loops.
>    fork Thread 10 completed 7 loops.
>    fork Thread 11 completed 6 loops.
>    forktoomuch Thread 12 completed 8 loops.
>    forktoomuch Thread 13 completed 9 loops.
>    forktoomuch Thread 14 completed 7 loops.
>    lock Thread 21 completed 9427 loops.
>    lock Thread 22 completed 3941 loops.
>    lock Thread 23 completed 4421 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 9 loops.
>    read Thread 1 completed 11 loops.
>    read Thread 2 completed 6 loops.
>    nxread Thread 3 completed 7 loops.
>    nxread Thread 4 completed 5 loops.
>    nxread Thread 5 completed 9 loops.
>    tryexcept Thread 6 completed 16315690 loops.
>    tryexcept Thread 7 completed 25110147 loops.
>    tryexcept Thread 8 completed 17291322 loops.
>    fork Thread 9 completed 5 loops.
>    fork Thread 10 completed 4 loops.
>    fork Thread 11 completed 5 loops.
>    forktoomuch Thread 12 completed 8 loops.
>    forktoomuch Thread 13 completed 9 loops.
>    forktoomuch Thread 14 completed 8 loops.
>    lock Thread 21 completed 1648 loops.
>    lock Thread 22 completed 1274 loops.
>    lock Thread 23 completed 975 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 2 loops.
>    read Thread 1 completed 6 loops.
>    read Thread 2 completed 3 loops.
>    nxread Thread 3 completed 7 loops.
>    nxread Thread 4 completed 4 loops.
>    nxread Thread 5 completed 7 loops.
>    tryexcept Thread 6 completed 16955552 loops.
>    tryexcept Thread 7 completed 27781696 loops.
>    tryexcept Thread 8 completed 16151561 loops.
>    fork Thread 9 completed 4 loops.
>    fork Thread 10 completed 3 loops.
>    fork Thread 11 completed 2 loops.
>    forktoomuch Thread 12 completed 7 loops.
>    forktoomuch Thread 13 completed 7 loops.
>    forktoomuch Thread 14 completed 7 loops.
>    lock Thread 21 completed 2148 loops.
>    lock Thread 22 completed 2179 loops.
>    lock Thread 23 completed 1804 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 7 loops.
>    read Thread 1 completed 5 loops.
>    read Thread 2 completed 4 loops.
>    nxread Thread 3 completed 9 loops.
>    nxread Thread 4 completed 6 loops.
>    nxread Thread 5 completed 5 loops.
>    tryexcept Thread 6 completed 14537433 loops.
>    tryexcept Thread 7 completed 24043303 loops.
>    tryexcept Thread 8 completed 14258976 loops.
>    fork Thread 9 completed 6 loops.
>    fork Thread 10 completed 7 loops.
>    fork Thread 11 completed 6 loops.
>    forktoomuch Thread 12 completed 8 loops.
>    forktoomuch Thread 13 completed 8 loops.
>    forktoomuch Thread 14 completed 8 loops.
>    lock Thread 21 completed 6504 loops.
>    lock Thread 22 completed 2290 loops.
>    lock Thread 23 completed 7696 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 5 loops.
>    read Thread 1 completed 6 loops.
>    read Thread 2 completed 2 loops.
>    nxread Thread 3 completed 4 loops.
>    nxread Thread 4 completed 1 loops.
>    nxread Thread 5 completed 3 loops.
>    tryexcept Thread 6 completed 17349384 loops.
>    tryexcept Thread 7 completed 29845941 loops.
>    tryexcept Thread 8 completed 17792587 loops.
>    fork Thread 9 completed 5 loops.
>    fork Thread 10 completed 5 loops.
>    fork Thread 11 completed 6 loops.
>    forktoomuch Thread 12 completed 8 loops.
>    forktoomuch Thread 13 completed 9 loops.
>    forktoomuch Thread 14 completed 9 loops.
>    lock Thread 21 completed 2692 loops.
>    lock Thread 22 completed 4498 loops.
>    lock Thread 23 completed 3600 loops.
> All tests complete.  Congratulations.
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>
>  
> Regards,
> Randy Coleburn
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110316/6a0a5098/attachment.html>

From rcolebur at SCIRES.COM  Wed Mar 16 23:34:53 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Wed, 16 Mar 2011 18:34:53 -0400
Subject: [M3devel] thread tests on NT386 32-bt
In-Reply-To: <B579D06A-BA7D-4739-9954-3B8A4E358AAD@cs.purdue.edu>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BDAF8@atlex02-srv>
	<B579D06A-BA7D-4739-9954-3B8A4E358AAD@cs.purdue.edu>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E603418BDB96@atlex02-srv>

Tony asked:
I don't remember how stable the collector was at that point.  Running them with @M3nogc indicates there were problems with it.
Now, what happens with the current trunk head when run with @M3nogc?
Here you go:

The alloc & create tests ran 9 iterations before running out of memory.

The other tests ran to completion.

See below (these tests run on IBM G40, XP Pro, 32-bit, against current HEAD branch):

C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests alloc,creat @M3nogc
Writing file...done
Creating alloc threads...
   alloc=15
   alloc=16
   alloc=17
done
Creating creat threads...
   creat=18
   creat=19
   creat=20
done
running...printing oldest/median age/newest
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 32400 loops.
   alloc Thread 16 completed 48840 loops.
   alloc Thread 17 completed 36525 loops.
   creat Thread 18 completed 25 loops.
   creat Thread 19 completed 28 loops.
   creat Thread 20 completed 27 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 5850 loops.
   alloc Thread 16 completed 8310 loops.
   alloc Thread 17 completed 8910 loops.
   creat Thread 18 completed 19 loops.
   creat Thread 19 completed 20 loops.
   creat Thread 20 completed 21 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 8505 loops.
   alloc Thread 16 completed 11805 loops.
   alloc Thread 17 completed 13170 loops.
   creat Thread 18 completed 27 loops.
   creat Thread 19 completed 26 loops.
   creat Thread 20 completed 27 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 7035 loops.
   alloc Thread 16 completed 13080 loops.
   alloc Thread 17 completed 5010 loops.
   creat Thread 18 completed 19 loops.
   creat Thread 19 completed 21 loops.
   creat Thread 20 completed 19 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 10260 loops.
   alloc Thread 16 completed 5445 loops.
  alloc Thread 17 completed 6390 loops.
   creat Thread 18 completed 21 loops.
   creat Thread 19 completed 23 loops.
   creat Thread 20 completed 23 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 3240 loops.
   alloc Thread 16 completed 12405 loops.
   alloc Thread 17 completed 6975 loops.
   creat Thread 18 completed 24 loops.
   creat Thread 19 completed 25 loops.
   creat Thread 20 completed 23 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 7410 loops.
   alloc Thread 16 completed 6090 loops.
   alloc Thread 17 completed 8670 loops.
   creat Thread 18 completed 17 loops.
   creat Thread 19 completed 17 loops.
   creat Thread 20 completed 17 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 6105 loops.
   alloc Thread 16 completed 7425 loops.
   alloc Thread 17 completed 10155 loops.
   creat Thread 18 completed 14 loops.
   creat Thread 19 completed 17 loops.
   creat Thread 20 completed 17 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 17160 loops.
   alloc Thread 16 completed 13365 loops.
   alloc Thread 17 completed 13785 loops.
   creat Thread 18 completed 17 loops.
   creat Thread 19 completed 16 loops.
   creat Thread 20 completed 17 loops.
......

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.
***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***
.
***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0xf7fefc   0x44c572  Raise + 0x3f in ..\src\runtime\common\RuntimeError.m3
0xf7ff1c   0x428712  AllocateOpenArray + 0x33 in ..\src\runtime\common\RTAllocator.m3
0xf7ff78   0x402430  AApply + 0x128 in ..\src\Main.m3
0xf7ffb4   0x42b56f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
.........  .........  ... more frames ...



C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lock @M3nogc
Writing file...done
Creating read threads...
   read=0
   read=1
   read=2
done
Creating nxread threads...
   nxread=3
   nxread=4
   nxread=5
done
Creating tryexcept threads...
   tryexcept=6
   tryexcept=7
   tryexcept=8
done
Creating fork threads...
   fork=9
   fork=0
   fork=11
done
Creating forktoomuch threads...
   forktoomuch=12
   forktoomuch=13
   forktoomuch=14
done
Creating lock threads...
   lock=21
   lock=22
   lock=23
done
running...printing oldest/median age/newest
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 98 loops.
   read Thread 1 completed 101 loops.
   read Thread 2 completed 98 loops.
   nxread Thread 3 completed 63 loops.
   nxread Thread 4 completed 64 loops.
   nxread Thread 5 completed 64 loops.
   tryexcept Thread 6 completed 1106827 loops.
   tryexcept Thread 7 completed 1056963 loops.
   tryexcept Thread 8 completed 1124363 loops.
   fork Thread 9 completed 3 loops.
   fork Thread 10 completed 3 loops.
   fork Thread 11 completed 3 loops.
   forktoomuch Thread 12 completed 5 loops.
   forktoomuch Thread 13 completed 5 loops.
   forktoomuch Thread 14 completed 4 loops.
   lock Thread 21 completed 902314 loops.
   lock Thread 22 completed 873503 loops.
   lock Thread 23 completed 946840 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 108 loops.
   read Thread 1 completed 105 loops.
   read Thread 2 completed 108 loops.
   nxread Thread 3 completed 68 loops.
   nxread Thread 4 completed 70 loops.
   nxread Thread 5 completed 67 loops.
   tryexcept Thread 6 completed 1197135 loops.
   tryexcept Thread 7 completed 1248635 loops.
   tryexcept Thread 8 completed 1263743 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 4 loops.
   forktoomuch Thread 12 completed 6 loops.
   forktoomuch Thread 13 completed 7 loops.
   forktoomuch Thread 14 completed 7 loops.
   lock Thread 21 completed 1156474 loops.
   lock Thread 22 completed 1007509 loops.
   lock Thread 23 completed 1072164 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 91 loops.
   read Thread 1 completed 101 loops.
   read Thread 2 completed 99 loops.
   nxread Thread 3 completed 67 loops.
   nxread Thread 4 completed 63 loops.
   nxread Thread 5 completed 64 loops.
   tryexcept Thread 6 completed 1212286 loops.
   tryexcept Thread 7 completed 1115613 loops.
   tryexcept Thread 8 completed 1124737 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 5 loops.
   fork Thread 11 completed 4 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 8 loops.
   forktoomuch Thread 14 completed 7 loops.
   lock Thread 21 completed 1058176 loops.
   lock Thread 22 completed 979426 loops.
   lock Thread 23 completed 1068972 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 103 loops.
   read Thread 1 completed 105 loops.
   read Thread 2 completed 105 loops.
   nxread Thread 3 completed 63 loops.
   nxread Thread 4 completed 63 loops.
   nxread Thread 5 completed 61 loops.
   tryexcept Thread 6 completed 1132672 loops.
   tryexcept Thread 7 completed 1186707 loops.
   tryexcept Thread 8 completed 1136861 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 4 loops.
   forktoomuch Thread 12 completed 6 loops.
   forktoomuch Thread 13 completed 6 loops.
   forktoomuch Thread 14 completed 7 loops.
   lock Thread 21 completed 794204 loops.
   lock Thread 22 completed 1171670 loops.
   lock Thread 23 completed 992164 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 88 loops.
   read Thread 1 completed 93 loops.
   read Thread 2 completed 105 loops.
   nxread Thread 3 completed 60 loops.
   nxread Thread 4 completed 63 loops.
   nxread Thread 5 completed 64 loops.
   tryexcept Thread 6 completed 1213622 loops.
   tryexcept Thread 7 completed 1169506 loops.
   tryexcept Thread 8 completed 1220576 loops.
   fork Thread 9 completed 3 loops.
   fork Thread 10 completed 3 loops.
   fork Thread 11 completed 3 loops.
   forktoomuch Thread 12 completed 5 loops.
   forktoomuch Thread 13 completed 6 loops.
   forktoomuch Thread 14 completed 6 loops.
   lock Thread 21 completed 947532 loops.
   lock Thread 22 completed 1046220 loops.
   lock Thread 23 completed 886815 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 104 loops.
   read Thread 1 completed 104 loops.
   read Thread 2 completed 104 loops.
   nxread Thread 3 completed 69 loops.
   nxread Thread 4 completed 68 loops.
   nxread Thread 5 completed 68 loops.
   tryexcept Thread 6 completed 1225537 loops.
   tryexcept Thread 7 completed 1158824 loops.
   tryexcept Thread 8 completed 1185900 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 5 loops.
   fork Thread 11 completed 4 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 7 loops.
   forktoomuch Thread 14 completed 6 loops.
   lock Thread 21 completed 1116802 loops.
   lock Thread 22 completed 1028306 loops.
   lock Thread 23 completed 1130454 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 107 loops.
   read Thread 1 completed 110 loops.
   read Thread 2 completed 112 loops.
   nxread Thread 3 completed 63 loops.
   nxread Thread 4 completed 63 loops.
   nxread Thread 5 completed 63 loops.
   tryexcept Thread 6 completed 1156252 loops.
   tryexcept Thread 7 completed 1094847 loops.
   tryexcept Thread 8 completed 1199661 loops.
   fork Thread 9 completed 3 loops.
   fork Thread 10 completed 3 loops.
   fork Thread 11 completed 4 loops.
   forktoomuch Thread 12 completed 7 loops.
   forktoomuch Thread 13 completed 7 loops.
   forktoomuch Thread 14 completed 7 loops.
   lock Thread 21 completed 746279 loops.
   lock Thread 22 completed 1069667 loops.
   lock Thread 23 completed 1045028 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 98 loops.
   read Thread 1 completed 99 loops.
   read Thread 2 completed 96 loops.
   nxread Thread 3 completed 64 loops.
   nxread Thread 4 completed 60 loops.
   nxread Thread 5 completed 63 loops.
   tryexcept Thread 6 completed 1185205 loops.
   tryexcept Thread 7 completed 1175381 loops.
   tryexcept Thread 8 completed 1114031 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 5 loops.
   fork Thread 11 completed 4 loops.
   forktoomuch Thread 12 completed 6 loops.
   forktoomuch Thread 13 completed 7 loops.
   forktoomuch Thread 14 completed 6 loops.
   lock Thread 21 completed 1053691 loops.
   lock Thread 22 completed 1009143 loops.
   lock Thread 23 completed 966082 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 111 loops.
   read Thread 1 completed 110 loops.
   read Thread 2 completed 101 loops.
   nxread Thread 3 completed 64 loops.
   nxread Thread 4 completed 65 loops.
   nxread Thread 5 completed 64 loops.
   tryexcept Thread 6 completed 1130609 loops.
   tryexcept Thread 7 completed 1160042 loops.
   tryexcept Thread 8 completed 1110365 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 5 loops.
   forktoomuch Thread 12 completed 7 loops.
   forktoomuch Thread 13 completed 7 loops.
   forktoomuch Thread 14 completed 7 loops.
   lock Thread 21 completed 682298 loops.
   lock Thread 22 completed 1124977 loops.
   lock Thread 23 completed 960154 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 62 loops.
   read Thread 1 completed 65 loops.
   read Thread 2 completed 62 loops.
   nxread Thread 3 completed 45 loops.
   nxread Thread 4 completed 42 loops.
   nxread Thread 5 completed 42 loops.
   tryexcept Thread 6 completed 1569234 loops.
   tryexcept Thread 7 completed 1553679 loops.
   tryexcept Thread 8 completed 1511503 loops.
   fork Thread 9 completed 1 loops.
   fork Thread 10 completed 2 loops.
   fork Thread 11 completed 2 loops.
   forktoomuch Thread 12 completed 4 loops.
   forktoomuch Thread 13 completed 4 loops.
   forktoomuch Thread 14 completed 4 loops.
   lock Thread 21 completed 1311441 loops.
   lock Thread 22 completed 1309196 loops.
   lock Thread 23 completed 1418347 loops.
All tests complete.  Congratulations.

C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>

Regards,
Randy Coleburn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110316/7fb37fc9/attachment.html>

From rcolebur at SCIRES.COM  Wed Mar 16 23:50:55 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Wed, 16 Mar 2011 18:50:55 -0400
Subject: [M3devel] thread test results on Win7 64-bit
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E603418BDB9C@atlex02-srv>

Here are thread test results for Dell Latitude E6510, Windows 7, 64-bit, against current HEAD branch.
I ran each set 3 times:  no @M3 directive, @M3paranoidgc, and @M3nogc
Note 3rd run where the fork thread shows being starved during first iteration, but test did run to completion using @M3nogc.


C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lock
Writing file...done
Creating read threads...
   read=0
   read=1
   read=2
done
Creating nxread threads...
   nxread=3
   nxread=4
   nxread=5
done
Creating tryexcept threads...
   tryexcept=6
   tryexcept=7
   tryexcept=8
done
Creating fork threads...
   fork=9
   fork=0
   fork=11
done
Creating forktoomuch threads...
   forktoomuch=12
   forktoomuch=13
   forktoomuch=14
done
Creating lock threads...
   lock=21
   lock=22
   lock=23
done
running...printing oldest/median age/newest
.

***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\rw\FileRd.m3", line 83
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0xaafa68  0x1198d68  Seek + 0x454 in ..\src\rw\FileRd.m3
0xaafa94  0x119a836  FastEOF + 0xc9 in ..\src\rw\Rd.m3
0xaafabc  0x119a72c  EOF + 0x48 in ..\src\rw\Rd.m3
0xaafb08  0x119176e  NApply + 0x154 in ..\src\Main.m3
0xaafb44  0x11bb56f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
0xaafb50  0x75c53677  <???>
0xaafb90  0x77e39f02  <???>
.........  .........  ... more frames ...


C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lock @M3paranoidgc
Writing file...done
Creating read threads...
   read=0
   read=1
   read=2
done
Creating nxread threads...
   nxread=3
   nxread=4
   nxread=5
done
Creating tryexcept threads...
   tryexcept=6
   tryexcept=7
   tryexcept=8
done
Creating fork threads...
   fork=9
   fork=0
   fork=11
done
Creating forktoomuch threads...
   forktoomuch=12
   forktoomuch=13
   forktoomuch=14
done
Creating lock threads...
   lock=21
   lock=22
   lock=23
done
running...printing oldest/median age/newest
.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0x11986a0 = Init + 0x79 in ..\src\rw\FileRd.m3
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x84fb48  0x11d537b  SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m3
0x84fb90  0x11986a0  Init + 0x79 in ..\src\rw\FileRd.m3
0x84fbbc  0x119861d  Open + 0x4d in ..\src\rw\FileRd.m3
0x84fcf4  0x1191360  RApply + 0x160 in ..\src\Main.m3
0x84fd30  0x11bb56f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
0x84fd3c  0x75c53677  <???>
0x84fd7c  0x77e39f02  <???>
.........  .........  ... more frames ...


C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lock @M3nogc
Writing file...done
Creating read threads...
   read=0
   read=1
   read=2
done
Creating nxread threads...
   nxread=3
   nxread=4
   nxread=5
done
Creating tryexcept threads...
   tryexcept=6
   tryexcept=7
   tryexcept=8
done
Creating fork threads...
   fork=9
   fork=0
   fork=11
done
Creating forktoomuch threads...
   forktoomuch=12
   forktoomuch=13
   forktoomuch=14
done
Creating lock threads...
   lock=21
   lock=22
   lock=23
done
running...printing oldest/median age/newest
..........laziest thread is 0/0/-2 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork -2/-2/-2 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 113 loops.
   read Thread 1 completed 45 loops.
   read Thread 2 completed 56 loops.
   nxread Thread 3 completed 48 loops.
   nxread Thread 4 completed 50 loops.
   nxread Thread 5 completed 41 loops.
   tryexcept Thread 6 completed 19499179 loops.
   tryexcept Thread 7 completed 15275763 loops.
   tryexcept Thread 8 completed 22671986 loops.
fork Thread 9 appears starved or deadlocked !!!
fork Thread 10 appears starved or deadlocked !!!
fork Thread 11 appears starved or deadlocked !!!
   forktoomuch Thread 12 completed 5 loops.
   forktoomuch Thread 13 completed 5 loops.
   forktoomuch Thread 14 completed 5 loops.
   lock Thread 21 completed 9512206 loops.
   lock Thread 22 completed 6619988 loops.
   lock Thread 23 completed 7547029 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 81 loops.
   read Thread 1 completed 71 loops.
   read Thread 2 completed 89 loops.
   nxread Thread 3 completed 66 loops.
   nxread Thread 4 completed 40 loops.
   nxread Thread 5 completed 36 loops.
   tryexcept Thread 6 completed 19628784 loops.
   tryexcept Thread 7 completed 22393679 loops.
   tryexcept Thread 8 completed 19328247 loops.
   fork Thread 9 completed 3 loops.
   fork Thread 10 completed 2 loops.
   fork Thread 11 completed 1 loops.
   forktoomuch Thread 12 completed 5 loops.
   forktoomuch Thread 13 completed 6 loops.
   forktoomuch Thread 14 completed 5 loops.
   lock Thread 21 completed 10152547 loops.
   lock Thread 22 completed 7780818 loops.
   lock Thread 23 completed 8156000 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 151 loops.
   read Thread 1 completed 114 loops.
   read Thread 2 completed 198 loops.
   nxread Thread 3 completed 81 loops.
   nxread Thread 4 completed 102 loops.
   nxread Thread 5 completed 65 loops.
   tryexcept Thread 6 completed 16242018 loops.
   tryexcept Thread 7 completed 18541779 loops.
   tryexcept Thread 8 completed 23687938 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 5 loops.
   fork Thread 11 completed 4 loops.
   forktoomuch Thread 12 completed 7 loops.
   forktoomuch Thread 13 completed 8 loops.
   forktoomuch Thread 14 completed 7 loops.
   lock Thread 21 completed 6189375 loops.
   lock Thread 22 completed 12637746 loops.
   lock Thread 23 completed 6191441 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 158 loops.
   read Thread 1 completed 111 loops.
   read Thread 2 completed 210 loops.
   nxread Thread 3 completed 80 loops.
   nxread Thread 4 completed 107 loops.
   nxread Thread 5 completed 77 loops.
   tryexcept Thread 6 completed 27811791 loops.
   tryexcept Thread 7 completed 14614651 loops.
   tryexcept Thread 8 completed 14962432 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 5 loops.
   forktoomuch Thread 12 completed 9 loops.
   forktoomuch Thread 13 completed 8 loops.
   forktoomuch Thread 14 completed 9 loops.
   lock Thread 21 completed 6021783 loops.
   lock Thread 22 completed 11487180 loops.
   lock Thread 23 completed 6730226 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 85 loops.
   read Thread 1 completed 75 loops.
   read Thread 2 completed 85 loops.
   nxread Thread 3 completed 50 loops.
   nxread Thread 4 completed 58 loops.
   nxread Thread 5 completed 67 loops.
   tryexcept Thread 6 completed 28345540 loops.
   tryexcept Thread 7 completed 14693468 loops.
   tryexcept Thread 8 completed 17065423 loops.
   fork Thread 9 completed 5 loops.
   fork Thread 10 completed 6 loops.
   fork Thread 11 completed 5 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 9 loops.
   forktoomuch Thread 14 completed 8 loops.
   lock Thread 21 completed 6621257 loops.
   lock Thread 22 completed 10815327 loops.
   lock Thread 23 completed 8437962 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 174 loops.
   read Thread 1 completed 133 loops.
   read Thread 2 completed 202 loops.
   nxread Thread 3 completed 85 loops.
   nxread Thread 4 completed 110 loops.
   nxread Thread 5 completed 72 loops.
   tryexcept Thread 6 completed 23348157 loops.
   tryexcept Thread 7 completed 14374032 loops.
   tryexcept Thread 8 completed 19940269 loops.
   fork Thread 9 completed 5 loops.
   fork Thread 10 completed 5 loops.
   fork Thread 11 completed 5 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 8 loops.
   forktoomuch Thread 14 completed 8 loops.
   lock Thread 21 completed 7341139 loops.
   lock Thread 22 completed 10330530 loops.
   lock Thread 23 completed 6812041 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 26 loops.
   read Thread 1 completed 32 loops.
   read Thread 2 completed 36 loops.
   nxread Thread 3 completed 38 loops.
   nxread Thread 4 completed 24 loops.
   nxread Thread 5 completed 27 loops.
   tryexcept Thread 6 completed 17115144 loops.
   tryexcept Thread 7 completed 19179208 loops.
   tryexcept Thread 8 completed 25222246 loops.
   fork Thread 9 completed 5 loops.
   fork Thread 10 completed 6 loops.
   fork Thread 11 completed 5 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 9 loops.
   forktoomuch Thread 14 completed 9 loops.
   lock Thread 21 completed 10391588 loops.
   lock Thread 22 completed 7466890 loops.
   lock Thread 23 completed 8045330 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 68 loops.
   read Thread 1 completed 78 loops.
   read Thread 2 completed 87 loops.
   nxread Thread 3 completed 55 loops.
   nxread Thread 4 completed 49 loops.
   nxread Thread 5 completed 49 loops.
   tryexcept Thread 6 completed 23843674 loops.
   tryexcept Thread 7 completed 23476782 loops.
   tryexcept Thread 8 completed 15668116 loops.
   fork Thread 9 completed 5 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 5 loops.
   forktoomuch Thread 12 completed 9 loops.
   forktoomuch Thread 13 completed 8 loops.
   forktoomuch Thread 14 completed 9 loops.
   lock Thread 21 completed 7504169 loops.
   lock Thread 22 completed 9868443 loops.
  lock Thread 23 completed 8893786 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 191 loops.
   read Thread 1 completed 181 loops.
   read Thread 2 completed 256 loops.
   nxread Thread 3 completed 100 loops.
   nxread Thread 4 completed 116 loops.
   nxread Thread 5 completed 110 loops.
   tryexcept Thread 6 completed 25424753 loops.
   tryexcept Thread 7 completed 16145782 loops.
   tryexcept Thread 8 completed 18178878 loops.
   fork Thread 9 completed 5 loops.
   fork Thread 10 completed 5 loops.
   fork Thread 11 completed 4 loops.
   forktoomuch Thread 12 completed 9 loops.
   forktoomuch Thread 13 completed 9 loops.
   forktoomuch Thread 14 completed 8 loops.
   lock Thread 21 completed 8276088 loops.
   lock Thread 22 completed 8386980 loops.
   lock Thread 23 completed 9006728 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 100 loops.
   read Thread 1 completed 126 loops.
   read Thread 2 completed 180 loops.
   nxread Thread 3 completed 80 loops.
   nxread Thread 4 completed 63 loops.
   nxread Thread 5 completed 96 loops.
   tryexcept Thread 6 completed 24009428 loops.
   tryexcept Thread 7 completed 18997565 loops.
   tryexcept Thread 8 completed 17752747 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 4 loops.
   forktoomuch Thread 12 completed 7 loops.
   forktoomuch Thread 13 completed 8 loops.
   forktoomuch Thread 14 completed 9 loops.
   lock Thread 21 completed 8760970 loops.
   lock Thread 22 completed 6987943 loops.
   lock Thread 23 completed 10012968 loops.
All tests complete.  Congratulations.


C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests alloc,creat
Writing file...done
Creating alloc threads...
   alloc=15
   alloc=16
   alloc=17
done
Creating creat threads...
   creat=18
   creat=19
   creat=20
done
running...printing oldest/median age/newest
.....

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0xdee37d = Move + 0x50 in ..\src\runtime\common\RTCollector.m3
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

^C


C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests alloc,creat @M3paranoidgc
Writing file...done
Creating alloc threads...
   alloc=15
   alloc=16
   alloc=17
done
Creating creat threads...
   creat=18
   creat=19
   creat=20
done
running...printing oldest/median age/newest
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 15465 loops.
   alloc Thread 16 completed 26927 loops.
   alloc Thread 17 completed 32052 loops.
   creat Thread 18 completed 248 loops.
   creat Thread 19 completed 432 loops.
   creat Thread 20 completed 260 loops.
..

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

^C


C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests alloc,creat @M3nogc
Writing file...done
Creating alloc threads...
   alloc=15
   alloc=16
   alloc=17
done
Creating creat threads...
   creat=18
   creat=19
   creat=20
done
running...printing oldest/median age/newest
...

NEW() was unable to al***ate more memory. was unable to allocate more memory.

NEW() was unable to al***ate more memory.

NEW() was unable to al***ate more memory. was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.
***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0xa5fa48   0xeac5a2  Raise + 0x3f in ..\src\runtime\common\RuntimeError.m3
0xa5fa68   0xe88712  AllocateOpenArray + 0x33 in ..\src\runtime\common\RTAllocator.m3
0xa5fac4   0xe62430  AApply + 0x128 in ..\src\Main.m3
0xa5fb00   0xe8b56f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
0xa5fb0c  0x75c53677  <???>
0xa5fb4c  0x77e39f02  <???>
.........  .........  ... more frames ...

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>

Regards,
Randy Coleburn

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

From hosking at cs.purdue.edu  Thu Mar 17 01:13:34 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 16 Mar 2011 20:13:34 -0400
Subject: [M3devel] thread test results on Win7 64-bit
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BDB9C@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BDB9C@atlex02-srv>
Message-ID: <8A030252-DB8E-4505-BA29-70B28329577F@cs.purdue.edu>

This is the offending line:

On Mar 16, 2011, at 6:50 PM, Coleburn, Randy wrote:

> ***
> *** runtime error:
> ***    An array subscript was out of range.
> ***    file "..\src\rw\FileRd.m3", line 83
> ***

      n := rd.sourceH.read(
             SUBARRAY(LOOPHOLE(ADR(rd.buff[0]), ByteArrayPtr)^, 0,
                      MIN (NUMBER(rd.buff^), BIG)), mayBlock := NOT dontBlock)

I am very suspicious about this...  anyone have any insights?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110316/fedb208a/attachment.html>

From hosking at cs.purdue.edu  Thu Mar 17 01:13:47 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 16 Mar 2011 20:13:47 -0400
Subject: [M3devel] thread tests on NT386 32-bt
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BDB96@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BDAF8@atlex02-srv>
	<B579D06A-BA7D-4739-9954-3B8A4E358AAD@cs.purdue.edu>
	<D67F02DDC62F7545A6B84C285F88F3E603418BDB96@atlex02-srv>
Message-ID: <1D3141BB-DB5F-46C9-ACB1-A3B9A95B74AE@cs.purdue.edu>

OK, good.  So I think this is definitely a threads/GC interaction.  Should be diagnosable from here out.

On Mar 16, 2011, at 6:34 PM, Coleburn, Randy wrote:

> Tony asked:
> I don't remember how stable the collector was at that point.  Running them with @M3nogc indicates there were problems with it.
> Now, what happens with the current trunk head when run with @M3nogc?
> 
> Here you go:
>  
> The alloc & create tests ran 9 iterations before running out of memory.
>  
> The other tests ran to completion.
>  
> See below (these tests run on IBM G40, XP Pro, 32-bit, against current HEAD branch):
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests alloc,creat @M3nogc
> Writing file...done
> Creating alloc threads...
>    alloc=15
>    alloc=16
>    alloc=17
> done
> Creating creat threads...
>    creat=18
>    creat=19
>    creat=20
> done
> running...printing oldest/median age/newest
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 32400 loops.
>    alloc Thread 16 completed 48840 loops.
>    alloc Thread 17 completed 36525 loops.
>    creat Thread 18 completed 25 loops.
>    creat Thread 19 completed 28 loops.
>    creat Thread 20 completed 27 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 5850 loops.
>    alloc Thread 16 completed 8310 loops.
>    alloc Thread 17 completed 8910 loops.
>    creat Thread 18 completed 19 loops.
>    creat Thread 19 completed 20 loops.
>    creat Thread 20 completed 21 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 8505 loops.
>    alloc Thread 16 completed 11805 loops.
>    alloc Thread 17 completed 13170 loops.
>    creat Thread 18 completed 27 loops.
>    creat Thread 19 completed 26 loops.
>    creat Thread 20 completed 27 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 7035 loops.
>    alloc Thread 16 completed 13080 loops.
>    alloc Thread 17 completed 5010 loops.
>    creat Thread 18 completed 19 loops.
>    creat Thread 19 completed 21 loops.
>    creat Thread 20 completed 19 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 10260 loops.
>    alloc Thread 16 completed 5445 loops.
>   alloc Thread 17 completed 6390 loops.
>    creat Thread 18 completed 21 loops.
>    creat Thread 19 completed 23 loops.
>    creat Thread 20 completed 23 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 3240 loops.
>    alloc Thread 16 completed 12405 loops.
>    alloc Thread 17 completed 6975 loops.
>    creat Thread 18 completed 24 loops.
>    creat Thread 19 completed 25 loops.
>    creat Thread 20 completed 23 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 7410 loops.
>    alloc Thread 16 completed 6090 loops.
>    alloc Thread 17 completed 8670 loops.
>    creat Thread 18 completed 17 loops.
>    creat Thread 19 completed 17 loops.
>    creat Thread 20 completed 17 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 6105 loops.
>    alloc Thread 16 completed 7425 loops.
>    alloc Thread 17 completed 10155 loops.
>    creat Thread 18 completed 14 loops.
>    creat Thread 19 completed 17 loops.
>    creat Thread 20 completed 17 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 17160 loops.
>    alloc Thread 16 completed 13365 loops.
>    alloc Thread 17 completed 13785 loops.
>    creat Thread 18 completed 17 loops.
>    creat Thread 19 completed 16 loops.
>    creat Thread 20 completed 17 loops.
> ......
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
> ***    file "..\src\runtime\common\RuntimeError.m3", line 63
> ***
>  
> ***    file "..\src\runtime\common\RuntimeError.m3", line 63
> ***
> .
> ***    file "..\src\runtime\common\RuntimeError.m3", line 63
> ***
>  
> ***    file "..\src\runtime\common\RuntimeError.m3", line 63
> ***
>  
> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0xf7fefc   0x44c572  Raise + 0x3f in ..\src\runtime\common\RuntimeError.m3
> 0xf7ff1c   0x428712  AllocateOpenArray + 0x33 in ..\src\runtime\common\RTAllocator.m3
> 0xf7ff78   0x402430  AApply + 0x128 in ..\src\Main.m3
> 0xf7ffb4   0x42b56f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
> .........  .........  ... more frames ...
>  
>  
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lock @M3nogc
> Writing file...done
> Creating read threads...
>    read=0
>    read=1
>    read=2
> done
> Creating nxread threads...
>    nxread=3
>    nxread=4
>    nxread=5
> done
> Creating tryexcept threads...
>    tryexcept=6
>    tryexcept=7
>    tryexcept=8
> done
> Creating fork threads...
>    fork=9
>    fork=0
>    fork=11
> done
> Creating forktoomuch threads...
>    forktoomuch=12
>    forktoomuch=13
>    forktoomuch=14
> done
> Creating lock threads...
>    lock=21
>    lock=22
>    lock=23
> done
> running...printing oldest/median age/newest
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 98 loops.
>    read Thread 1 completed 101 loops.
>    read Thread 2 completed 98 loops.
>    nxread Thread 3 completed 63 loops.
>    nxread Thread 4 completed 64 loops.
>    nxread Thread 5 completed 64 loops.
>    tryexcept Thread 6 completed 1106827 loops.
>    tryexcept Thread 7 completed 1056963 loops.
>    tryexcept Thread 8 completed 1124363 loops.
>    fork Thread 9 completed 3 loops.
>    fork Thread 10 completed 3 loops.
>    fork Thread 11 completed 3 loops.
>    forktoomuch Thread 12 completed 5 loops.
>    forktoomuch Thread 13 completed 5 loops.
>    forktoomuch Thread 14 completed 4 loops.
>    lock Thread 21 completed 902314 loops.
>    lock Thread 22 completed 873503 loops.
>    lock Thread 23 completed 946840 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 108 loops.
>    read Thread 1 completed 105 loops.
>    read Thread 2 completed 108 loops.
>    nxread Thread 3 completed 68 loops.
>    nxread Thread 4 completed 70 loops.
>    nxread Thread 5 completed 67 loops.
>    tryexcept Thread 6 completed 1197135 loops.
>    tryexcept Thread 7 completed 1248635 loops.
>    tryexcept Thread 8 completed 1263743 loops.
>    fork Thread 9 completed 4 loops.
>    fork Thread 10 completed 4 loops.
>    fork Thread 11 completed 4 loops.
>    forktoomuch Thread 12 completed 6 loops.
>    forktoomuch Thread 13 completed 7 loops.
>    forktoomuch Thread 14 completed 7 loops.
>    lock Thread 21 completed 1156474 loops.
>    lock Thread 22 completed 1007509 loops.
>    lock Thread 23 completed 1072164 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 91 loops.
>    read Thread 1 completed 101 loops.
>    read Thread 2 completed 99 loops.
>    nxread Thread 3 completed 67 loops.
>    nxread Thread 4 completed 63 loops.
>    nxread Thread 5 completed 64 loops.
>    tryexcept Thread 6 completed 1212286 loops.
>    tryexcept Thread 7 completed 1115613 loops.
>    tryexcept Thread 8 completed 1124737 loops.
>    fork Thread 9 completed 4 loops.
>    fork Thread 10 completed 5 loops.
>    fork Thread 11 completed 4 loops.
>    forktoomuch Thread 12 completed 8 loops.
>    forktoomuch Thread 13 completed 8 loops.
>    forktoomuch Thread 14 completed 7 loops.
>    lock Thread 21 completed 1058176 loops.
>    lock Thread 22 completed 979426 loops.
>    lock Thread 23 completed 1068972 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 103 loops.
>    read Thread 1 completed 105 loops.
>    read Thread 2 completed 105 loops.
>    nxread Thread 3 completed 63 loops.
>    nxread Thread 4 completed 63 loops.
>    nxread Thread 5 completed 61 loops.
>    tryexcept Thread 6 completed 1132672 loops.
>    tryexcept Thread 7 completed 1186707 loops.
>    tryexcept Thread 8 completed 1136861 loops.
>    fork Thread 9 completed 4 loops.
>    fork Thread 10 completed 4 loops.
>    fork Thread 11 completed 4 loops.
>    forktoomuch Thread 12 completed 6 loops.
>    forktoomuch Thread 13 completed 6 loops.
>    forktoomuch Thread 14 completed 7 loops.
>    lock Thread 21 completed 794204 loops.
>    lock Thread 22 completed 1171670 loops.
>    lock Thread 23 completed 992164 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 88 loops.
>    read Thread 1 completed 93 loops.
>    read Thread 2 completed 105 loops.
>    nxread Thread 3 completed 60 loops.
>    nxread Thread 4 completed 63 loops.
>    nxread Thread 5 completed 64 loops.
>    tryexcept Thread 6 completed 1213622 loops.
>    tryexcept Thread 7 completed 1169506 loops.
>    tryexcept Thread 8 completed 1220576 loops.
>    fork Thread 9 completed 3 loops.
>    fork Thread 10 completed 3 loops.
>    fork Thread 11 completed 3 loops.
>    forktoomuch Thread 12 completed 5 loops.
>    forktoomuch Thread 13 completed 6 loops.
>    forktoomuch Thread 14 completed 6 loops.
>    lock Thread 21 completed 947532 loops.
>    lock Thread 22 completed 1046220 loops.
>    lock Thread 23 completed 886815 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 104 loops.
>    read Thread 1 completed 104 loops.
>    read Thread 2 completed 104 loops.
>    nxread Thread 3 completed 69 loops.
>    nxread Thread 4 completed 68 loops.
>    nxread Thread 5 completed 68 loops.
>    tryexcept Thread 6 completed 1225537 loops.
>    tryexcept Thread 7 completed 1158824 loops.
>    tryexcept Thread 8 completed 1185900 loops.
>    fork Thread 9 completed 4 loops.
>    fork Thread 10 completed 5 loops.
>    fork Thread 11 completed 4 loops.
>    forktoomuch Thread 12 completed 8 loops.
>    forktoomuch Thread 13 completed 7 loops.
>    forktoomuch Thread 14 completed 6 loops.
>    lock Thread 21 completed 1116802 loops.
>    lock Thread 22 completed 1028306 loops.
>    lock Thread 23 completed 1130454 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 107 loops.
>    read Thread 1 completed 110 loops.
>    read Thread 2 completed 112 loops.
>    nxread Thread 3 completed 63 loops.
>    nxread Thread 4 completed 63 loops.
>    nxread Thread 5 completed 63 loops.
>    tryexcept Thread 6 completed 1156252 loops.
>    tryexcept Thread 7 completed 1094847 loops.
>    tryexcept Thread 8 completed 1199661 loops.
>    fork Thread 9 completed 3 loops.
>    fork Thread 10 completed 3 loops.
>    fork Thread 11 completed 4 loops.
>    forktoomuch Thread 12 completed 7 loops.
>    forktoomuch Thread 13 completed 7 loops.
>    forktoomuch Thread 14 completed 7 loops.
>    lock Thread 21 completed 746279 loops.
>    lock Thread 22 completed 1069667 loops.
>    lock Thread 23 completed 1045028 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 98 loops.
>    read Thread 1 completed 99 loops.
>    read Thread 2 completed 96 loops.
>    nxread Thread 3 completed 64 loops.
>    nxread Thread 4 completed 60 loops.
>    nxread Thread 5 completed 63 loops.
>    tryexcept Thread 6 completed 1185205 loops.
>    tryexcept Thread 7 completed 1175381 loops.
>    tryexcept Thread 8 completed 1114031 loops.
>    fork Thread 9 completed 4 loops.
>    fork Thread 10 completed 5 loops.
>    fork Thread 11 completed 4 loops.
>    forktoomuch Thread 12 completed 6 loops.
>    forktoomuch Thread 13 completed 7 loops.
>    forktoomuch Thread 14 completed 6 loops.
>    lock Thread 21 completed 1053691 loops.
>    lock Thread 22 completed 1009143 loops.
>    lock Thread 23 completed 966082 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 111 loops.
>    read Thread 1 completed 110 loops.
>    read Thread 2 completed 101 loops.
>    nxread Thread 3 completed 64 loops.
>    nxread Thread 4 completed 65 loops.
>    nxread Thread 5 completed 64 loops.
>    tryexcept Thread 6 completed 1130609 loops.
>    tryexcept Thread 7 completed 1160042 loops.
>    tryexcept Thread 8 completed 1110365 loops.
>    fork Thread 9 completed 4 loops.
>    fork Thread 10 completed 4 loops.
>    fork Thread 11 completed 5 loops.
>    forktoomuch Thread 12 completed 7 loops.
>    forktoomuch Thread 13 completed 7 loops.
>    forktoomuch Thread 14 completed 7 loops.
>    lock Thread 21 completed 682298 loops.
>    lock Thread 22 completed 1124977 loops.
>    lock Thread 23 completed 960154 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 62 loops.
>    read Thread 1 completed 65 loops.
>    read Thread 2 completed 62 loops.
>    nxread Thread 3 completed 45 loops.
>    nxread Thread 4 completed 42 loops.
>    nxread Thread 5 completed 42 loops.
>    tryexcept Thread 6 completed 1569234 loops.
>    tryexcept Thread 7 completed 1553679 loops.
>    tryexcept Thread 8 completed 1511503 loops.
>    fork Thread 9 completed 1 loops.
>    fork Thread 10 completed 2 loops.
>    fork Thread 11 completed 2 loops.
>    forktoomuch Thread 12 completed 4 loops.
>    forktoomuch Thread 13 completed 4 loops.
>    forktoomuch Thread 14 completed 4 loops.
>    lock Thread 21 completed 1311441 loops.
>    lock Thread 22 completed 1309196 loops.
>    lock Thread 23 completed 1418347 loops.
> All tests complete.  Congratulations.
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>
>  
> Regards,
> Randy Coleburn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110316/40c031b5/attachment.html>

From rcolebur at SCIRES.COM  Thu Mar 17 20:46:00 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 17 Mar 2011 15:46:00 -0400
Subject: [M3devel] thread test results on Win7 64-bit
In-Reply-To: <8A030252-DB8E-4505-BA29-70B28329577F@cs.purdue.edu>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BDB9C@atlex02-srv>
	<8A030252-DB8E-4505-BA29-70B28329577F@cs.purdue.edu>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E603418BDDEC@atlex02-srv>

Tony et al:

On the surface, it would seem this convoluted code is doing the following:

1.       Making rd.buff appear as an "ARRAY OF Byte", vice an "ARRAY OF CHAR, so as to meet the requirements of the File.T.read interface.

2.       Limiting the buffer to be the smaller of "BIG", or the actual number of elements in rd.buff

Now, re #2, the code in FileRd seems to allocate buffers in 4096-char arrays, and BIG is 16M, so I don't quite see why the need to ensure the buffer is limited to no more than BIG, as it should never be more than 4096.

All that aside, are you concerned that the GC could be relocating rd.buff after its address is obtained and fed to the File.T.read (rd.sourceH.read) procedure?

If indeed this movement can occur, this code definitely needs to change.

How can we force the GC not to move rd.buff, or is there another "safe" way to make rd.buff appear as an "ARRAY OF Byte" to satisfy the File.T.read interface?

Buffers are allocated in line #45 as a traced reference to an ARRAY OF CHAR via:
      rd.buff := NEW(CharBuffer, BufferSize);
Yet, the ByteArrayPtr in FileRd.m3 (line 25) is an untraced reference (to an array of Byte).

Should we be allocating buffers (rd.buff) as untraced refs instead, and then explicitly freeing?  Or, is there a way to keep them as traced refs, but avoid collection/movement while being used in an unsafe manner?

Finally, there are multiple statements in the FileRd.m3 module similar to line #83 that must be dealt with (e.g., 114, 119).

Regards,
Randy Coleburn

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Wednesday, March 16, 2011 8:14 PM
To: Coleburn, Randy
Cc: m3devel
Subject: Re: [M3devel] thread test results on Win7 64-bit

This is the offending line:
On Mar 16, 2011, at 6:50 PM, Coleburn, Randy wrote:

***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\rw\FileRd.m3", line 83
***

      n := rd.sourceH.read(
             SUBARRAY(LOOPHOLE(ADR(rd.buff[0]), ByteArrayPtr)^, 0,
                      MIN (NUMBER(rd.buff^), BIG)), mayBlock := NOT dontBlock)

I am very suspicious about this...  anyone have any insights?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110317/006cbf1a/attachment.html>

From dabenavidesd at yahoo.es  Fri Mar 18 01:31:35 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 18 Mar 2011 00:31:35 +0000 (GMT)
Subject: [M3devel] thread test results on Win7 64-bit
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BDDEC@atlex02-srv>
Message-ID: <46694.52575.qm@web29710.mail.ird.yahoo.com>

Hi all:
reading through the green book chapter on IO streams, p160, it seems, there should not be such a range violation cause its actually allowed to be NIL (see? ftp://gatekeeper.research.compaq.com/pub/DEC/SRC/research-reports/abstracts/src-rr-053.html
p 30 and above) so this must be related to the fact there is some missing a conditional if so as it is unsafely checked by the compiler, but it might not be necessarily that, I mean unsafe perse, but in that case just for that may get a RT error unneeded to argue for that (i.e it might not), indeed most of the crashes might come by this classes, but as I read TextWr seek method style was to raise an unlisted exception which is by itself a RT error as a policy, however subclasses of Rd.T must be aware of their obligations that is, they have invariants so we could? check for those I believe they are there in safe MODULES (as I think is checked already) and manner that is even as one could argue in UNSAFE modules they hold (if they don't hold just the first case), we could if this is really broken get it in safe modules to check for them in an ESC, actually first RW lib was absolutely according to their comments unsafe for speed performance but after
 crashed many times decided to made safe interfaces to look for those kind of errors. So it might be need a middle layer not UNSAFE module of FileRd INTERFACE to look for those errors closely, e.g implement that method failing (FileRd.seek) and related safely and check them by ESC.
Specifically from the three invariants the most feasible mentioned in RdClass interface which might be not be satisfied and should be checked in a debugger is the first of the three (because would cause same RT error shown there):
rd is valid if =>
[rd.lo .. rd.hi-i] 
where i can be 0 and so buff=NIL, 
so its possible though would need confirmation a breakpoint there in line FileRd.m3:83 to see rd.buff
the others that come after this, 
cur(rd) = MIN(rd.cur,? len(rd))
from what
rd.cur>len(rd) or rd.cur = len(rd)
and third:
NOT (rd.intermittent AND rd.seekable)
That said I would recommend the latter method a mechanic debugger meanwhile, tough if positive we would follow the guideline of Greg and the gang to specify it in a safe module, at least the method. Then in an automatic debugger might help to proof that for us too if so.
Indeed there are more classes of invariants there for declare clean and also private invariants too. Will check for that too.  
Thanks in advance

--- El jue, 17/3/11, Coleburn, Randy <rcolebur at SCIRES.COM> escribi?:

De: Coleburn, Randy <rcolebur at SCIRES.COM>
Asunto: Re: [M3devel] thread test results on Win7 64-bit
Para: "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 17 de marzo, 2011 14:46

Tony et al: ?On the surface, it would seem this convoluted code is doing the following:1.?????? Making rd.buff appear as an ?ARRAY OF Byte?, vice an ?ARRAY OF CHAR, so as to meet the requirements of the File.T.read interface.2.?????? Limiting the buffer to be the smaller of ?BIG?, or the actual number of elements in rd.buff ?Now, re #2, the code in FileRd seems to allocate buffers in 4096-char arrays, and BIG is 16M, so I don?t quite see why the need to ensure the buffer is limited to no more than BIG, as it should never be more than 4096. ?All that aside, are you concerned that the GC could be relocating rd.buff after its address is obtained and fed to the File.T.read (rd.sourceH.read) procedure? ?If indeed this movement can occur, this code definitely needs to change. ?How can we force the GC not to move rd.buff, or is there another ?safe? way to make rd.buff appear as an ?ARRAY OF Byte? to satisfy the File.T.read
 interface? ?Buffers are allocated in line #45 as a traced reference to an ARRAY OF CHAR via:????? rd.buff := NEW(CharBuffer, BufferSize);Yet, the ByteArrayPtr in FileRd.m3 (line 25) is an untraced reference (to an array of Byte). ?Should we be allocating buffers (rd.buff) as untraced refs instead, and then explicitly freeing?? Or, is there a way to keep them as traced refs, but avoid collection/movement while being used in an unsafe manner? ?Finally, there are multiple statements in the FileRd.m3 module similar to line #83 that must be dealt with (e.g., 114, 119). ?Regards,Randy Coleburn ?From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
Sent: Wednesday, March 16, 2011 8:14 PM
To: Coleburn, Randy
Cc: m3devel
Subject: Re: [M3devel] thread test results on Win7 64-bit ?This is the offending line:On Mar 16, 2011, at 6:50 PM, Coleburn, Randy wrote: ?****** runtime error:***??? An array subscript was out of range.***??? file "..\src\rw\FileRd.m3", line 83*** ??? ? ?n := rd.sourceH.read(?? ? ? ? ? ? SUBARRAY(LOOPHOLE(ADR(rd.buff[0]), ByteArrayPtr)^, 0,?? ? ? ? ? ? ? ? ? ? ?MIN (NUMBER(rd.buff^), BIG)), mayBlock := NOT dontBlock) ?I am very suspicious about this... ?anyone have any insights? ?


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110318/0138ec00/attachment.html>

From jay.krell at cornell.edu  Sun Mar 20 22:08:46 2011
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 20 Mar 2011 21:08:46 +0000
Subject: [M3devel] runaway hudson/pgm
Message-ID: <COL101-W63D86DE03E6E0EF01D5ABEE6B20@phx.gbl>


Some "pgm" (a common name for test cases) running as Hudson was eating CPU and laptop was noticably hot/slow, so I killed it.

 - Jay




 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110320/71efb57d/attachment.html>

From rodney_bates at lcwb.coop  Tue Mar 22 19:45:28 2011
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Tue, 22 Mar 2011 13:45:28 -0500
Subject: [M3devel] thread test results on Win7 64-bit
Message-ID: <4D88EE48.70608@lcwb.coop>



The only subscript operation in this line is rd.buff[0].
 From the declaration of buff in RdClass.i3:32, buff has
type REF ARRAY OF CHAR.  If buff were NIL, it should give
a different runtime error (probably segfault).  With the
subscript being statically zero, the only way this could
happen is if buff was allocated with a zero NUMBER.  I
didn't go looking for that, but it seems unlikely.

Otherwise, it would have to be a corrupted heap object or
maybe miscompiled code.  Or the runtime error message is
wrong.  From this shallow reasoning, I would put my bet on
the corrupted object.

On 03/16/2011 07:13 PM, Tony Hosking wrote:
> This is the offending line:
>
> On Mar 16, 2011, at 6:50 PM, Coleburn, Randy wrote:
>
>> ***
>> *** runtime error:
>> *** An array subscript was out of range.
>> *** file "..\src\rw\FileRd.m3", line 83
>> ***
>
> n := rd.sourceH.read(
> SUBARRAY(LOOPHOLE(ADR(rd.buff[0]), ByteArrayPtr)^, 0,
> MIN (NUMBER(rd.buff^), BIG)), mayBlock := NOT dontBlock)
>
> I am very suspicious about this... anyone have any insights?
>



From dabenavidesd at yahoo.es  Thu Mar 24 00:41:35 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 23 Mar 2011 23:41:35 +0000 (GMT)
Subject: [M3devel] thread test results on Win7 64-bit
Message-ID: <634095.3089.qm@web29701.mail.ird.yahoo.com>

Hi all:
that is correct, it could be not NIL and still be wrong if V1 doesn't hold the characters of src are not those of buff mentione cin green book, page 160 or p 37 of:
ftp://apotheca.hpl.hp.com/pub/dec/SRC/research-reports/SRC-053.pdf

rd.buff[rd.st + i - rd.lo] = src(rd)[i]

The other thing is that as WrRep module section 6.8 in green book, page 151 says is needed or in SRC-RR-053, p 21 sec 8, collector is not relocating, does it hold this?


Aside, does a procedure type hold ADDRESS and its values are valid, as we could trace untraced objects, records, procedures in an unmovable heap and change them absolutely but in terms of an unsafe RT, that is to communicate better its abstraction low level in the RT, or high level like with traced ones.

Thanks in advance


--- El mar, 22/3/11, Rodney M. Bates <rodney_bates at lcwb.coop> escribi?:

> De: Rodney M. Bates <rodney_bates at lcwb.coop>
> Asunto: Re: [M3devel] thread test results on Win7 64-bit
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: martes, 22 de marzo, 2011 13:45
> 
> 
> The only subscript operation in this line is rd.buff[0].
>  From the declaration of buff in RdClass.i3:32, buff has
> type REF ARRAY OF CHAR.  If buff were NIL, it should
> give
> a different runtime error (probably segfault).  With
> the
> subscript being statically zero, the only way this could
> happen is if buff was allocated with a zero NUMBER. 
> I
> didn't go looking for that, but it seems unlikely.
> 
> Otherwise, it would have to be a corrupted heap object or
> maybe miscompiled code.  Or the runtime error message
> is
> wrong.  From this shallow reasoning, I would put my
> bet on
> the corrupted object.
> 
> On 03/16/2011 07:13 PM, Tony Hosking wrote:
> > This is the offending line:
> >
> > On Mar 16, 2011, at 6:50 PM, Coleburn, Randy wrote:
> >
> >> ***
> >> *** runtime error:
> >> *** An array subscript was out of range.
> >> *** file "..\src\rw\FileRd.m3", line 83
> >> ***
> >
> > n := rd.sourceH.read(
> > SUBARRAY(LOOPHOLE(ADR(rd.buff[0]), ByteArrayPtr)^, 0,
> > MIN (NUMBER(rd.buff^), BIG)), mayBlock := NOT
> dontBlock)
> >
> > I am very suspicious about this... anyone have any
> insights?
> >
> 
>



      


From rodney_bates at lcwb.coop  Mon Mar 28 18:16:23 2011
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Mon, 28 Mar 2011 11:16:23 -0500
Subject: [M3devel] How to install cm3 at a nonstandard location
Message-ID: <4D90B457.90305@lcwb.coop>

I tried to build cm3 head and install at /usr/local/cm3-head.
 From the installation notes, I set environment variable
CM3_INSTALL to this path.  After fixing several failures
involving merges by cvs, I discovered it had been putting
things into /usr/local/cm3, where I have the latest cm3
release, giving me a mixture of stuff from the head and
the release, which I certainly don't trust.

I was building instead of using cminstall, like the the install
notes were referring to.  However, before I started, I found
code in scripts/sysinfo.sh setting up CM3_INSTALL to the default,
unless already set, which I took to mean this was the way to
do it when building too.

I did double and triple check my spelling and value of
CM3_INSTALL, before and after the failed builds.

So how do I get this to work?

This was on LINUXLIBC6.

Rodney Bates




From mika at async.caltech.edu  Mon Mar 28 18:51:33 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Mon, 28 Mar 2011 09:51:33 -0700
Subject: [M3devel] How to install cm3 at a nonstandard location
In-Reply-To: <4D90B457.90305@lcwb.coop> 
References: <4D90B457.90305@lcwb.coop>
Message-ID: <20110328165133.7504B1A2078@async.async.caltech.edu>

I think I pass the target directory to cminstall on the cmd. line, something like:

./cminstall /path/to/installation/root

"Rodney M. Bates" writes:
>I tried to build cm3 head and install at /usr/local/cm3-head.
> From the installation notes, I set environment variable
>CM3_INSTALL to this path.  After fixing several failures
>involving merges by cvs, I discovered it had been putting
>things into /usr/local/cm3, where I have the latest cm3
>release, giving me a mixture of stuff from the head and
>the release, which I certainly don't trust.
>
>I was building instead of using cminstall, like the the install
>notes were referring to.  However, before I started, I found
>code in scripts/sysinfo.sh setting up CM3_INSTALL to the default,
>unless already set, which I took to mean this was the way to
>do it when building too.
>
>I did double and triple check my spelling and value of
>CM3_INSTALL, before and after the failed builds.
>
>So how do I get this to work?
>
>This was on LINUXLIBC6.
>
>Rodney Bates
>


From dabenavidesd at yahoo.es  Mon Mar 28 21:24:52 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 28 Mar 2011 20:24:52 +0100 (BST)
Subject: [M3devel] About Simplify build script platforms and cm3ide service
Message-ID: <402597.44437.qm@web29712.mail.ird.yahoo.com>

Hi all:
I was wondering as I remember Simplify has a component to show IO (not sure for input) web page to show results or the theorems being proved and their proof and some test suites contain test compliant test suites, it seems we surely will have to display that for other clients than us, so it might be useful to put this tests or runs in the cm3ide server, as it allows to show a centralized approach rather than running simplify from old binary versions. It is also an opportunity to show an application of it, Modula-3 and of an application itself and by the way make cm3 improved performance for long runs of it since this is really an used tool, thus we can show how the compiler can take and how much can be optimized for every platform (perhaps to rethink a build script for it and perhaps to add optimization backend support port of  DS3100 burs based? or full 64 bit support in Win2k, xp, 2003, Server, Vista, 7, etc platforms, perhaps better to make an
 improvement over current Win*nix Platforms?
There are some tools which might use that, I know from two sources test suites mentioned coming from ESC in Modula-3, Java and later versions
Originally from the ESC/Modula-3 VCG:
http://portal.acm.org/citation.cfm?id=1066102&dl=guide&coll=GUIDE

(In section Source Materials, the second tab, inside simplify_benchmarks hyperlink and see simplify_benchmarks/format.txt for thge big and small suites or download directly from:
http://delivery.acm.org/10.1145/1070000/1066102/supp/simplify_benchmarks.tar.gz?key1=1066102&key2=3798331031&coll=DL&dl=ACM&CFID=15503308&CFTOKEN=88865083 

)

later modification of ESC/Java VCG relevant originally in:
http://replay.waybackmachine.org/20090422004503/http://nemerle.org/~malekith/smt/benchmarks/
Even other systems like JVM based Whiley, and or so any ESC/JVM itself, etc.
  
Thanks in advance


From jay.krell at cornell.edu  Tue Mar 29 02:03:03 2011
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 29 Mar 2011 00:03:03 +0000
Subject: [M3devel] How to install cm3 at a nonstandard location
In-Reply-To: <20110328165133.7504B1A2078@async.async.caltech.edu>
References: <4D90B457.90305@lcwb.coop>,
	<20110328165133.7504B1A2078@async.async.caltech.edu>
Message-ID: <COL101-W63008765882635E26EA9B1E6BD0@phx.gbl>


Another approach is to copy a few things to the new location, e.g. config files, cm3, cm3cg, and then use those to build/ship.
That is how make-dist.py works, for example.
And be sure the config files use path() to find themselves, instead of hardcoding their location.

 - Jay

> To: rodney_bates at lcwb.coop
> Date: Mon, 28 Mar 2011 09:51:33 -0700
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] How to install cm3 at a nonstandard location
> 
> I think I pass the target directory to cminstall on the cmd. line, something like:
> 
> ./cminstall /path/to/installation/root
> 
> "Rodney M. Bates" writes:
> >I tried to build cm3 head and install at /usr/local/cm3-head.
> > From the installation notes, I set environment variable
> >CM3_INSTALL to this path.  After fixing several failures
> >involving merges by cvs, I discovered it had been putting
> >things into /usr/local/cm3, where I have the latest cm3
> >release, giving me a mixture of stuff from the head and
> >the release, which I certainly don't trust.
> >
> >I was building instead of using cminstall, like the the install
> >notes were referring to.  However, before I started, I found
> >code in scripts/sysinfo.sh setting up CM3_INSTALL to the default,
> >unless already set, which I took to mean this was the way to
> >do it when building too.
> >
> >I did double and triple check my spelling and value of
> >CM3_INSTALL, before and after the failed builds.
> >
> >So how do I get this to work?
> >
> >This was on LINUXLIBC6.
> >
> >Rodney Bates
> >
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110329/c26447fc/attachment.html>

From dabenavidesd at yahoo.es  Tue Mar 29 01:57:23 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 29 Mar 2011 00:57:23 +0100 (BST)
Subject: [M3devel] About CM3_IDE_UsersGuide format if so
Message-ID: <667386.49334.qm@web29719.mail.ird.yahoo.com>

Hi all:
I wanted to know whether you agree on reformat the CM3_IDE_UserGuide doc file into a standard linear one, like of the doc tools used in cm3 and pm3 repository are based on either tex, html (and back and forth see belo ) or even gnuinfo files, although there some small ones of mtex that I don't know much about and also the noweb files (literate programming like native burs backend is coded or ldb, where still is to be seeing whether generic files are post processed as expected by cm3) that are also plain text files.
I was thinking in make some docs more widely available specifically some improvement over Net Object collector information, since there are two formal proofs of that I believe one is current there (Birrell's collection scheme) and "new" one distributed cyclic garbage collection.
This would allows us to alter proof them by formal and automatic mechanical checking and such gain some more interest in the platform and its collection algorithms:
http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-116.pdf

And subsequent work:
http://kar.kent.ac.uk/21327/

http://www.cs.kent.ac.uk/pubs/1998/926/index.html

and last but not least:
http://www.cs.kent.ac.uk/pubs/2003/1650/

With mechanism such as of the pm3 sgml-obliq it could be shown to convert from ps (with see doi:10.1109/ICDAR.1997.619868 [1]) to html to tex and so on keep improving the situation with respect of lack of annotation information with the current papers, as of anybody who wants to write informally knowledge about it let him do it freely.

Well, just in case you don't mind I will try to add extra converted this docs to lyx, from where it could be later compiled to tex or displayed directly in any other format if so.

Thanks in advance

[1] B. Poirier and M. Dagenais, ?An interactive system to extract structured text from a geometrical representation,? in Document Analysis and Recognition, 1997., Proceedings of the Fourth International Conference on, 1997, vol. 1, pp. 342-346 vol.1.


From jay.krell at cornell.edu  Tue Mar 29 02:04:00 2011
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 29 Mar 2011 00:04:00 +0000
Subject: [M3devel] FW: GCC 4.6.0 Released
In-Reply-To: <20110328072557.GG11563@sunsite.ms.mff.cuni.cz>
References: <20110328072557.GG11563@sunsite.ms.mff.cuni.cz>
Message-ID: <COL101-W2D287BFCAEBA44A26313CE6BD0@phx.gbl>


for us to consider..


> Date: Mon, 28 Mar 2011 09:25:57 +0200
> From: jakub at redhat.com
> To: gcc-announce at gcc.gnu.org
> CC: gcc at gcc.gnu.org
> Subject: GCC 4.6.0 Released
> 
> The GNU Compiler Collection version 4.6.0 has been released.
> 
> GCC 4.6.0 is a major release, containing substantial new functionality
> not available in GCC 4.5.x or previous GCC releases.
> 
> The "link-time optimization" framework introduced in GCC 4.5.0 has been
> significantly improved in this release, it is now possible to compile
> very large applications like Mozilla or GCC itself with LTO.
> GCC can now partially inline functions, inlining just hot short path
> to exit and keeping the rest of the function out of line.
> Support for the upcoming C++0x standard has been notably improved,
> Fortran 2003 and 2008 has been greatly extended and many other frontends
> undergone substantial changes as well.
> Many other improvements have been added and more than thousand of bugs
> have been fixed in various parts of the compiler collection.
> 
> See:
> 
>   http://gcc.gnu.org/gcc-4.6/changes.html
> 
> for more information about changes in GCC 4.6.0.
> 
> This release is available from the FTP servers listed here:
> 
>   http://www.gnu.org/order/ftp.html
> 
> The release is in gcc/gcc-4.6.0/ subdirectory.
> 
> If you encounter difficulties using GCC 4.6, please do not contact me
> directly.  Instead, please visit http://gcc.gnu.org for information
> about getting help.
> 
> As always, a vast number of people contributed to this GCC releases --
> far too many to thank individually!
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110329/eb0cebe0/attachment.html>

From hosking at cs.purdue.edu  Tue Mar 29 04:38:00 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 28 Mar 2011 22:38:00 -0400
Subject: [M3devel] FW: GCC 4.6.0 Released
In-Reply-To: <COL101-W2D287BFCAEBA44A26313CE6BD0@phx.gbl>
References: <20110328072557.GG11563@sunsite.ms.mff.cuni.cz>
	<COL101-W2D287BFCAEBA44A26313CE6BD0@phx.gbl>
Message-ID: <4D4B822F-1820-4E91-8543-AA35097A3766@cs.purdue.edu>

Are you volunteering?  ;-)


On Mar 28, 2011, at 8:04 PM, Jay K wrote:

> for us to consider..
> 
> 
> > Date: Mon, 28 Mar 2011 09:25:57 +0200
> > From: jakub at redhat.com
> > To: gcc-announce at gcc.gnu.org
> > CC: gcc at gcc.gnu.org
> > Subject: GCC 4.6.0 Released
> > 
> > The GNU Compiler Collection version 4.6.0 has been released.
> > 
> > GCC 4.6.0 is a major release, containing substantial new functionality
> > not available in GCC 4.5.x or previous GCC releases.
> > 
> > The "link-time optimization" framework introduced in GCC 4.5.0 has been
> > significantly improved in this release, it is now possible to compile
> > very large applications like Mozilla or GCC itself with LTO.
> > GCC can now partially inline functions, inlining just hot short path
> > to exit and keeping the rest of the function out of line.
> > Support for the upcoming C++0x standard has been notably improved,
> > Fortran 2003 and 2008 has been greatly extended and many other frontends
> > undergone substantial changes as well.
> > Many other improvements have been added and more than thousand of bugs
> > have been fixed in various parts of the compiler collection.
> > 
> > See:
> > 
> > http://gcc.gnu.org/gcc-4.6/changes.html
> > 
> > for more information about changes in GCC 4.6.0.
> > 
> > This release is available from the FTP servers listed here:
> > 
> > http://www.gnu.org/order/ftp.html
> > 
> > The release is in gcc/gcc-4.6.0/ subdirectory.
> > 
> > If you encounter difficulties using GCC 4.6, please do not contact me
> > directly. Instead, please visit http://gcc.gnu.org for information
> > about getting help.
> > 
> > As always, a vast number of people contributed to this GCC releases --
> > far too many to thank individually!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110328/bc44c277/attachment.html>

From dabenavidesd at yahoo.es  Tue Mar 29 05:07:56 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 29 Mar 2011 04:07:56 +0100 (BST)
Subject: [M3devel] About Simplify build script platforms and cm3ide
	service
In-Reply-To: <402597.44437.qm@web29712.mail.ird.yahoo.com>
Message-ID: <428050.39604.qm@web29720.mail.ird.yahoo.com>

Hi all:
some refs I didn't mention where it came from, here:
http://www.cs.nyu.edu/pipermail/smt-lib/2007/000149.html

And further for same knowledge and software theories improvement [1] in:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.22.4306

[2] in:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.28.6492

and realized retrospectively on [3], and a newer one [4]

[1] U. Nestmann, H. H?ttel, J. Kleist, and M. Merro, ?Aliasing Models for Mobile Objects,? Information and Computation, vol. 175, no. 1, pp. 3-33, May. 2002.

[2] M. Merro, J. Kleist, and U. Nestmann, ?Mobile Objects as Mobile Processes,? Information and Computation, vol. 177, no. 2, pp. 195-241, Sep. 2002.

[3] D. Caromel and L. Henrio, A Theory of Distributed Objects, 1st ed. Springer, 2005.

[4] M. Hennessy, A Distributed Pi-Calculus, 1st ed. Cambridge University Press, 2007.

Again, this would useful for such an application extension of DCVS like mercurial, perforce and git rewrite from scratch but in something rely fast and reliable for really distributed computations, don't you think? :)
 
Thanks in advance

--- El lun, 28/3/11, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

> De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
> Asunto: [M3devel] About Simplify build script platforms and cm3ide service
> Para: m3devel at elegosoft.com
> Fecha: lunes, 28 de marzo, 2011 14:24
> Hi all:
> I was wondering as I remember Simplify has a component to
> show IO (not sure for input) web page to show results or the
> theorems being proved and their proof and some test suites
> contain test compliant test suites, it seems we surely will
> have to display that for other clients than us, so it might
> be useful to put this tests or runs in the cm3ide server, as
> it allows to show a centralized approach rather than running
> simplify from old binary versions. It is also an opportunity
> to show an application of it, Modula-3 and of an application
> itself and by the way make cm3 improved performance for long
> runs of it since this is really an used tool, thus we can
> show how the compiler can take and how much can be optimized
> for every platform (perhaps to rethink a build script for it
> and perhaps to add optimization backend support port
> of  DS3100 burs based? or full 64 bit support in Win2k,
> xp, 2003, Server, Vista, 7, etc platforms, perhaps better to
> make an
>  improvement over current Win*nix Platforms?
> There are some tools which might use that, I know from two
> sources test suites mentioned coming from ESC in Modula-3,
> Java and later versions
> Originally from the ESC/Modula-3 VCG:
> http://portal.acm.org/citation.cfm?id=1066102&dl=guide&coll=GUIDE
> 
> (In section Source Materials, the second tab, inside
> simplify_benchmarks hyperlink and see
> simplify_benchmarks/format.txt for thge big and small suites
> or download directly from:
> http://delivery.acm.org/10.1145/1070000/1066102/supp/simplify_benchmarks.tar.gz?key1=1066102&key2=3798331031&coll=DL&dl=ACM&CFID=15503308&CFTOKEN=88865083
> 
> 
> )
> 
> later modification of ESC/Java VCG relevant originally in:
> http://replay.waybackmachine.org/20090422004503/http://nemerle.org/~malekith/smt/benchmarks/
> Even other systems like JVM based Whiley, and or so any
> ESC/JVM itself, etc.
>   
> Thanks in advance
> 


From wagner at elegosoft.com  Tue Mar 29 09:18:52 2011
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 29 Mar 2011 09:18:52 +0200
Subject: [M3devel] How to install cm3 at a nonstandard location
In-Reply-To: <4D90B457.90305@lcwb.coop>
References: <4D90B457.90305@lcwb.coop>
Message-ID: <20110329091852.sdnxriui04s880go@mail.elegosoft.com>

Quoting "Rodney M. Bates" <rodney_bates at lcwb.coop>:

> I tried to build cm3 head and install at /usr/local/cm3-head.
> From the installation notes, I set environment variable
> CM3_INSTALL to this path.  After fixing several failures
> involving merges by cvs, I discovered it had been putting
> things into /usr/local/cm3, where I have the latest cm3
> release, giving me a mixture of stuff from the head and
> the release, which I certainly don't trust.
>
> I was building instead of using cminstall, like the the install
> notes were referring to.  However, before I started, I found
> code in scripts/sysinfo.sh setting up CM3_INSTALL to the default,
> unless already set, which I took to mean this was the way to
> do it when building too.
>
> I did double and triple check my spelling and value of
> CM3_INSTALL, before and after the failed builds.
>
> So how do I get this to work?
>
> This was on LINUXLIBC6.

It certainly used to work, but scripts have changed much in recent
years, and some people rather use python or Windows' cmd scripts etc.

I always need to make sure myself when I try something like that again.
The main thing to look for is the central configuration file or
the set of configuration files that the builder reads. These are
quake scripts of course, and I think there's INSTALL_ROOT.

The current cm3.cfg seems to use a combination of CM3_INSTALL and
INSATLL_ROOT:

1.1       jkrell     14: proc CM3SetInstallRoot() is
                      15:     if defined("INSTALL_ROOT")
                      16:         return
                      17:     end
                      18:     if not equal ($CM3_INSTALL, "")
                      19:         INSTALL_ROOT = $CM3_INSTALL
                      20:         return
                      21:     end
                      22:     INSTALL_ROOT = (path() & SL & "..")
                      23: end

Of course this file may look completely different if you've got an
older installed version of cm3...

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Tue Mar 29 10:07:08 2011
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 29 Mar 2011 08:07:08 +0000
Subject: [M3devel] FW: GCC 4.6.0 Released
In-Reply-To: <4D4B822F-1820-4E91-8543-AA35097A3766@cs.purdue.edu>
References: <20110328072557.GG11563@sunsite.ms.mff.cuni.cz>,
	<COL101-W2D287BFCAEBA44A26313CE6BD0@phx.gbl>,
	<4D4B822F-1820-4E91-8543-AA35097A3766@cs.purdue.edu>
Message-ID: <COL101-W26BEC4765D7A10521AAA4FE6BD0@phx.gbl>


I assume we want it and yeah I might get to it.
I'd like to continue to avoid the gmp/mpfr/mpc dependencies, as well as not bothering with LTO for the forseable future.

 - Jay

From: hosking at cs.purdue.edu
Date: Mon, 28 Mar 2011 22:38:00 -0400
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] FW: GCC 4.6.0 Released



Are you volunteering?  ;-)


On Mar 28, 2011, at 8:04 PM, Jay K wrote:for us to consider..


> Date: Mon, 28 Mar 2011 09:25:57 +0200
> From: jakub at redhat.com
> To: gcc-announce at gcc.gnu.org
> CC: gcc at gcc.gnu.org
> Subject: GCC 4.6.0 Released
> 
> The GNU Compiler Collection version 4.6.0 has been released.
> 
> GCC 4.6.0 is a major release, containing substantial new functionality
> not available in GCC 4.5.x or previous GCC releases.
> 
> The "link-time optimization" framework introduced in GCC 4.5.0 has been
> significantly improved in this release, it is now possible to compile
> very large applications like Mozilla or GCC itself with LTO.
> GCC can now partially inline functions, inlining just hot short path
> to exit and keeping the rest of the function out of line.
> Support for the upcoming C++0x standard has been notably improved,
> Fortran 2003 and 2008 has been greatly extended and many other frontends
> undergone substantial changes as well.
> Many other improvements have been added and more than thousand of bugs
> have been fixed in various parts of the compiler collection.
> 
> See:
> 
> http://gcc.gnu.org/gcc-4.6/changes.html
> 
> for more information about changes in GCC 4.6.0.
> 
> This release is available from the FTP servers listed here:
> 
> http://www.gnu.org/order/ftp.html
> 
> The release is in gcc/gcc-4.6.0/ subdirectory.
> 
> If you encounter difficulties using GCC 4.6, please do not contact me
> directly. Instead, please visit http://gcc.gnu.org for information
> about getting help.
> 
> As always, a vast number of people contributed to this GCC releases --
> far too many to thank individually!

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110329/2599da1f/attachment.html>

From rcolebur at SCIRES.COM  Tue Mar 29 21:40:16 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Tue, 29 Mar 2011 15:40:16 -0400
Subject: [M3devel] About CM3_IDE_UsersGuide format if so
In-Reply-To: <667386.49334.qm@web29719.mail.ird.yahoo.com>
References: <667386.49334.qm@web29719.mail.ird.yahoo.com>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E60341B189BC@atlex02-srv>

Daniel:

I am ok with you or anyone else providing the user guide in additional formats.
I simply provided it in the formats readily available to me at the time.

Regards,
Randy Coleburn

-----Original Message-----
From: Daniel Alejandro Benavides D. [mailto:dabenavidesd at yahoo.es] 
Sent: Monday, March 28, 2011 7:57 PM
To: m3devel at elegosoft.com
Subject: [M3devel] About CM3_IDE_UsersGuide format if so

Hi all:
I wanted to know whether you agree on reformat the CM3_IDE_UserGuide doc file into a standard linear one, like of the doc tools used in cm3 and pm3 repository are based on either tex, html (and back and forth see belo ) or even gnuinfo files, although there some small ones of mtex that I don't know much about and also the noweb files (literate programming like native burs backend is coded or ldb, where still is to be seeing whether generic files are post processed as expected by cm3) that are also plain text files.
I was thinking in make some docs more widely available specifically some improvement over Net Object collector information, since there are two formal proofs of that I believe one is current there (Birrell's collection scheme) and "new" one distributed cyclic garbage collection.
This would allows us to alter proof them by formal and automatic mechanical checking and such gain some more interest in the platform and its collection algorithms:
http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-116.pdf

And subsequent work:
http://kar.kent.ac.uk/21327/

http://www.cs.kent.ac.uk/pubs/1998/926/index.html

and last but not least:
http://www.cs.kent.ac.uk/pubs/2003/1650/

With mechanism such as of the pm3 sgml-obliq it could be shown to convert from ps (with see doi:10.1109/ICDAR.1997.619868 [1]) to html to tex and so on keep improving the situation with respect of lack of annotation information with the current papers, as of anybody who wants to write informally knowledge about it let him do it freely.

Well, just in case you don't mind I will try to add extra converted this docs to lyx, from where it could be later compiled to tex or displayed directly in any other format if so.

Thanks in advance

[1] B. Poirier and M. Dagenais, ?An interactive system to extract structured text from a geometrical representation,? in Document Analysis and Recognition, 1997., Proceedings of the Fourth International Conference on, 1997, vol. 1, pp. 342-346 vol.1.

From dabenavidesd at yahoo.es  Tue Mar 29 22:36:42 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 29 Mar 2011 21:36:42 +0100 (BST)
Subject: [M3devel] About CM3_IDE_UsersGuide format if so
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E60341B189BC@atlex02-srv>
Message-ID: <630972.93901.qm@web29718.mail.ird.yahoo.com>

Hi all:
yes, thanks for the info, would be nice to see some level of integration between the ESC and Modula-3 in cm3ide as I said it shall be pretty easy to deploy network management display of test sessions with the cm3ide tool with Simplify too, so is nice to have documentation on it about that. I guess it would be possible to handle that too in any format, if hosts are kind enough for that, as our hosts allows us to do so, if I am right. Also a good and nice option is for Mobile sessions, to keep an eye on each task, for instance I know you can use some editor for showing error messages, I guess one would be able to reproduce that behavior with ESC errors right, i.e cm3 errors displays line an hyperlinks a editor on line. Thus for instance you can get a report on error messages from the web server and so display a line in the code directly to modify it and run again, I believe.
This is something really useful if we have such an automation of tasks one could think in programming or getting the marked line via twits for instance :) if such agreement is allowed too.
Thanks in advance


--- El mar, 29/3/11, Coleburn, Randy <rcolebur at SCIRES.COM> escribi?:

> De: Coleburn, Randy <rcolebur at SCIRES.COM>
> Asunto: RE: [M3devel] About CM3_IDE_UsersGuide format if so
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>, "m3devel at elegosoft.com" <m3devel at elegosoft.com>
> Fecha: martes, 29 de marzo, 2011 14:40
> Daniel:
> 
> I am ok with you or anyone else providing the user guide in
> additional formats.
> I simply provided it in the formats readily available to me
> at the time.
> 
> Regards,
> Randy Coleburn
> 
> -----Original Message-----
> From: Daniel Alejandro Benavides D. [mailto:dabenavidesd at yahoo.es]
> 
> Sent: Monday, March 28, 2011 7:57 PM
> To: m3devel at elegosoft.com
> Subject: [M3devel] About CM3_IDE_UsersGuide format if so
> 
> Hi all:
> I wanted to know whether you agree on reformat the
> CM3_IDE_UserGuide doc file into a standard linear one, like
> of the doc tools used in cm3 and pm3 repository are based on
> either tex, html (and back and forth see belo ) or even
> gnuinfo files, although there some small ones of mtex that I
> don't know much about and also the noweb files (literate
> programming like native burs backend is coded or ldb, where
> still is to be seeing whether generic files are post
> processed as expected by cm3) that are also plain text
> files.
> I was thinking in make some docs more widely available
> specifically some improvement over Net Object collector
> information, since there are two formal proofs of that I
> believe one is current there (Birrell's collection scheme)
> and "new" one distributed cyclic garbage collection.
> This would allows us to alter proof them by formal and
> automatic mechanical checking and such gain some more
> interest in the platform and its collection algorithms:
> http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-116.pdf

> 
> And subsequent work:
> http://kar.kent.ac.uk/21327/

> 
> http://www.cs.kent.ac.uk/pubs/1998/926/index.html

> 
> and last but not least:
> http://www.cs.kent.ac.uk/pubs/2003/1650/

> 
> With mechanism such as of the pm3 sgml-obliq it could be
> shown to convert from ps (with see
> doi:10.1109/ICDAR.1997.619868 [1]) to html to tex and so on
> keep improving the situation with respect of lack of
> annotation information with the current papers, as of
> anybody who wants to write informally knowledge about it let
> him do it freely.
> 
> Well, just in case you don't mind I will try to add extra
> converted this docs to lyx, from where it could be later
> compiled to tex or displayed directly in any other format if
> so.
> 
> Thanks in advance
> 
> [1] B. Poirier and M. Dagenais, ?An interactive system to
> extract structured text from a geometrical
> representation,? in Document Analysis and Recognition,
> 1997., Proceedings of the Fourth International Conference
> on, 1997, vol. 1, pp. 342-346 vol.1.
> 


From rcolebur at SCIRES.COM  Tue Mar 29 23:26:19 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Tue, 29 Mar 2011 17:26:19 -0400
Subject: [M3devel] About CM3_IDE_UsersGuide format if so
In-Reply-To: <630972.93901.qm@web29718.mail.ird.yahoo.com>
References: <D67F02DDC62F7545A6B84C285F88F3E60341B189BC@atlex02-srv>
	<630972.93901.qm@web29718.mail.ird.yahoo.com>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E60341B18A02@atlex02-srv>

Daniel:

I'm sorry, but I'm not sure I follow your entire train of thought.

If you use CM3IDE to invoke the CM3 builder, any errors during the compilation/build process will be displayed in the browser with a hyperlink to invoke your editor and jump to the line identified as the source of the problem.

The CM3IDE configuration page allows you to specify the editor to be invoked, among other options.

Regards,
Randy Coleburn

-----Original Message-----
From: Daniel Alejandro Benavides D. [mailto:dabenavidesd at yahoo.es] 
Sent: Tuesday, March 29, 2011 4:37 PM
To: m3devel at elegosoft.com; Coleburn, Randy
Subject: RE: [M3devel] About CM3_IDE_UsersGuide format if so

Hi all:
yes, thanks for the info, would be nice to see some level of integration between the ESC and Modula-3 in cm3ide as I said it shall be pretty easy to deploy network management display of test sessions with the cm3ide tool with Simplify too, so is nice to have documentation on it about that. I guess it would be possible to handle that too in any format, if hosts are kind enough for that, as our hosts allows us to do so, if I am right. Also a good and nice option is for Mobile sessions, to keep an eye on each task, for instance I know you can use some editor for showing error messages, I guess one would be able to reproduce that behavior with ESC errors right, i.e cm3 errors displays line an hyperlinks a editor on line. Thus for instance you can get a report on error messages from the web server and so display a line in the code directly to modify it and run again, I believe.
This is something really useful if we have such an automation of tasks one could think in programming or getting the marked line via twits for instance :) if such agreement is allowed too.
Thanks in advance


--- El mar, 29/3/11, Coleburn, Randy <rcolebur at SCIRES.COM> escribi?:

> De: Coleburn, Randy <rcolebur at SCIRES.COM>
> Asunto: RE: [M3devel] About CM3_IDE_UsersGuide format if so
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>, "m3devel at elegosoft.com" <m3devel at elegosoft.com>
> Fecha: martes, 29 de marzo, 2011 14:40
> Daniel:
> 
> I am ok with you or anyone else providing the user guide in
> additional formats.
> I simply provided it in the formats readily available to me
> at the time.
> 
> Regards,
> Randy Coleburn
> 
> -----Original Message-----
> From: Daniel Alejandro Benavides D. [mailto:dabenavidesd at yahoo.es]
> 
> Sent: Monday, March 28, 2011 7:57 PM
> To: m3devel at elegosoft.com
> Subject: [M3devel] About CM3_IDE_UsersGuide format if so
> 
> Hi all:
> I wanted to know whether you agree on reformat the
> CM3_IDE_UserGuide doc file into a standard linear one, like
> of the doc tools used in cm3 and pm3 repository are based on
> either tex, html (and back and forth see belo ) or even
> gnuinfo files, although there some small ones of mtex that I
> don't know much about and also the noweb files (literate
> programming like native burs backend is coded or ldb, where
> still is to be seeing whether generic files are post
> processed as expected by cm3) that are also plain text
> files.
> I was thinking in make some docs more widely available
> specifically some improvement over Net Object collector
> information, since there are two formal proofs of that I
> believe one is current there (Birrell's collection scheme)
> and "new" one distributed cyclic garbage collection.
> This would allows us to alter proof them by formal and
> automatic mechanical checking and such gain some more
> interest in the platform and its collection algorithms:
> http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-116.pdf

> 
> And subsequent work:
> http://kar.kent.ac.uk/21327/

> 
> http://www.cs.kent.ac.uk/pubs/1998/926/index.html

> 
> and last but not least:
> http://www.cs.kent.ac.uk/pubs/2003/1650/

> 
> With mechanism such as of the pm3 sgml-obliq it could be
> shown to convert from ps (with see
> doi:10.1109/ICDAR.1997.619868 [1]) to html to tex and so on
> keep improving the situation with respect of lack of
> annotation information with the current papers, as of
> anybody who wants to write informally knowledge about it let
> him do it freely.
> 
> Well, just in case you don't mind I will try to add extra
> converted this docs to lyx, from where it could be later
> compiled to tex or displayed directly in any other format if
> so.
> 
> Thanks in advance
> 
> [1] B. Poirier and M. Dagenais, ?An interactive system to
> extract structured text from a geometrical
> representation,? in Document Analysis and Recognition,
> 1997., Proceedings of the Fourth International Conference
> on, 1997, vol. 1, pp. 342-346 vol.1.
> 

From dabenavidesd at yahoo.es  Wed Mar 30 02:21:44 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 30 Mar 2011 01:21:44 +0100 (BST)
Subject: [M3devel] About CM3_IDE_UsersGuide format if so
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E60341B18A02@atlex02-srv>
Message-ID: <242549.67696.qm@web29703.mail.ird.yahoo.com>

Hi all:
thanks for your message, and it's Ok, indeed I'm very sorry about that; now the idea behind is that we can invoke "m3build" process (aka cm3) to ESC via esc() quake directive and so subsequently it will call Simplify theorem prover as many times as needed.
As Simplify is able to display its output via ESC command line input parameter and then call the output of it and postprocessed it in ESC to show a source code line number error, e.g array index out of bounds line number xyz, nil deref attempt, unchecked exception, deadlock, etc, so we can get a line number from it and then pass it trough cm3ide to its web output (if Verification Condition VC is correctly generated in ESC that is, Simplify's input and if implied results are positive for source code "errors" at least by its conservatism or formal proof, as also it might be silent in absence of errors either by possible insufficient or too much rigorousness in VCs or if not pass it back to ESC if so to get an error message because of theorem proof is not true or if it doesn't find it, again conservatively speaking), we surely may get this passed through from ESC back to cm3ide to show a similar message hyperlink and "error" line number.
Now in behalf of us we don't have any time to waste we could continue our duties and get a editor call or a twit a message with line and error and enter or twit back the intended solution if so in that line whenever that happens.
As the the Simplify output has html output support for VC falsity, etc, and ESC I still wonder how it will communicate its results, we could adjust that for us in the cm3ide to make that display for us too and show its line number and warning message. Perhaps another cm3ide object method might do that as well, as this "errors" are not fatal, still, it can be shown as warnings (as they really are), then does CM3IDE warning messages come too in same way cm3 errors are shown? If so perhaps this is the way to go. We could select whether to stop compilation process if so if there are selected warnings to do so or if it's asked to continue to do so and don't halt until another instruction is given or it finishes its process. 
As ESC is concerned it would take same time parsing and compiling as cm3 but then another equivalent or more time to check it in VCs theorem proving   meanwhile it might be useful to have that view or display, if for instance it is not happy or unable to prove a given formula to display its VC, in case of false alarm say, or if they are successful steps as they are PROCEDURE by PROCEDURE as ESC goes along each MODULE, so in the end it would take slower time to compile and then recompile it if so as any given module might have a failed proof in a procedure before it checks everything of it. 
Main issue here is that parse trees are different so we can't share their time to type check (assuming we both want to compile and statically check), at least as Verification condition generation is concerned, besides dependency order is determined by cm3 driver and I don't know how it might be get it by m3tk independently if so, so it will for now wait for its type checking and then redo type inference and so and continue to proof so best case scenario both systems will have that to do same type checking and inference to produce a parse tree that will give us a proof that must be verified and if it doesn't satisfy its condition return as an ESC "error" or warning, or finish without complaints if it really does.   
Thanks in advance

--- El mar, 29/3/11, Coleburn, Randy <rcolebur at SCIRES.COM> escribi?:

> De: Coleburn, Randy <rcolebur at SCIRES.COM>
> Asunto: RE: [M3devel] About CM3_IDE_UsersGuide format if so
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>, "m3devel at elegosoft.com" <m3devel at elegosoft.com>
> Fecha: martes, 29 de marzo, 2011 16:26
> Daniel:
> 
> I'm sorry, but I'm not sure I follow your entire train of
> thought.
> 
> If you use CM3IDE to invoke the CM3 builder, any errors
> during the compilation/build process will be displayed in
> the browser with a hyperlink to invoke your editor and jump
> to the line identified as the source of the problem.
> 
> The CM3IDE configuration page allows you to specify the
> editor to be invoked, among other options.
> 
> Regards,
> Randy Coleburn
> 
> -----Original Message-----
> From: Daniel Alejandro Benavides D. [mailto:dabenavidesd at yahoo.es]
> 
> Sent: Tuesday, March 29, 2011 4:37 PM
> To: m3devel at elegosoft.com;
> Coleburn, Randy
> Subject: RE: [M3devel] About CM3_IDE_UsersGuide format if
> so
> 
> Hi all:
> yes, thanks for the info, would be nice to see some level
> of integration between the ESC and Modula-3 in cm3ide as I
> said it shall be pretty easy to deploy network management
> display of test sessions with the cm3ide tool with Simplify
> too, so is nice to have documentation on it about that. I
> guess it would be possible to handle that too in any format,
> if hosts are kind enough for that, as our hosts allows us to
> do so, if I am right. Also a good and nice option is for
> Mobile sessions, to keep an eye on each task, for instance I
> know you can use some editor for showing error messages, I
> guess one would be able to reproduce that behavior with ESC
> errors right, i.e cm3 errors displays line an hyperlinks a
> editor on line. Thus for instance you can get a report on
> error messages from the web server and so display a line in
> the code directly to modify it and run again, I believe.
> This is something really useful if we have such an
> automation of tasks one could think in programming or
> getting the marked line via twits for instance :) if such
> agreement is allowed too.
> Thanks in advance
> 
> 
> --- El mar, 29/3/11, Coleburn, Randy <rcolebur at SCIRES.COM>
> escribi?:
> 
> > De: Coleburn, Randy <rcolebur at SCIRES.COM>
> > Asunto: RE: [M3devel] About CM3_IDE_UsersGuide format
> if so
> > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>,
> "m3devel at elegosoft.com"
> <m3devel at elegosoft.com>
> > Fecha: martes, 29 de marzo, 2011 14:40
> > Daniel:
> > 
> > I am ok with you or anyone else providing the user
> guide in
> > additional formats.
> > I simply provided it in the formats readily available
> to me
> > at the time.
> > 
> > Regards,
> > Randy Coleburn
> > 
> > -----Original Message-----
> > From: Daniel Alejandro Benavides D. [mailto:dabenavidesd at yahoo.es]
> > 
> > Sent: Monday, March 28, 2011 7:57 PM
> > To: m3devel at elegosoft.com
> > Subject: [M3devel] About CM3_IDE_UsersGuide format if
> so
> > 
> > Hi all:
> > I wanted to know whether you agree on reformat the
> > CM3_IDE_UserGuide doc file into a standard linear one,
> like
> > of the doc tools used in cm3 and pm3 repository are
> based on
> > either tex, html (and back and forth see belo ) or
> even
> > gnuinfo files, although there some small ones of mtex
> that I
> > don't know much about and also the noweb files
> (literate
> > programming like native burs backend is coded or ldb,
> where
> > still is to be seeing whether generic files are post
> > processed as expected by cm3) that are also plain
> text
> > files.
> > I was thinking in make some docs more widely
> available
> > specifically some improvement over Net Object
> collector
> > information, since there are two formal proofs of that
> I
> > believe one is current there (Birrell's collection
> scheme)
> > and "new" one distributed cyclic garbage collection.
> > This would allows us to alter proof them by formal
> and
> > automatic mechanical checking and such gain some more
> > interest in the platform and its collection
> algorithms:
> > http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-116.pdf

> 
> > 
> > And subsequent work:
> > http://kar.kent.ac.uk/21327/

> 
> > 
> > http://www.cs.kent.ac.uk/pubs/1998/926/index.html

> 
> > 
> > and last but not least:
> > http://www.cs.kent.ac.uk/pubs/2003/1650/

> 
> > 
> > With mechanism such as of the pm3 sgml-obliq it could
> be
> > shown to convert from ps (with see
> > doi:10.1109/ICDAR.1997.619868 [1]) to html to tex and
> so on
> > keep improving the situation with respect of lack of
> > annotation information with the current papers, as of
> > anybody who wants to write informally knowledge about
> it let
> > him do it freely.
> > 
> > Well, just in case you don't mind I will try to add
> extra
> > converted this docs to lyx, from where it could be
> later
> > compiled to tex or displayed directly in any other
> format if
> > so.
> > 
> > Thanks in advance
> > 
> > [1] B. Poirier and M. Dagenais, ?An interactive
> system to
> > extract structured text from a geometrical
> > representation,? in Document Analysis and
> Recognition,
> > 1997., Proceedings of the Fourth International
> Conference
> > on, 1997, vol. 1, pp. 342-346 vol.1.
> > 
> 


From mika at async.caltech.edu  Tue Mar  1 02:49:49 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Mon, 28 Feb 2011 17:49:49 -0800
Subject: [M3devel] Has anyone seen this crash before?
Message-ID: <20110301014949.B70F01A2078@async.async.caltech.edu>


shownew crashing on LINUXLIBC6 (works fine on e.g., AMD64_LINUX):

This GDB was configured as "i386-redhat-linux-gnu"...
(gdb) run
Starting program: /home/user/mnystrom/cm3/bin/shownew 
[Thread debugging using libthread_db enabled]
[New Thread 0xb7fb16c0 (LWP 30122)]

Program received signal SIGSEGV, Segmentation fault.
0x00be406c in ?? () from /usr/lib/libXcursor.so.1
(gdb) where
#0  0x00be406c in ?? () from /usr/lib/libXcursor.so.1
#1  0x00be44ae in ?? () from /usr/lib/libXcursor.so.1
#2  0x00be45de in XcursorLibraryLoadImages () from /usr/lib/libXcursor.so.1
#3  0x00be462b in XcursorShapeLoadImages () from /usr/lib/libXcursor.so.1
#4  0x00be4f63 in XcursorTryShapeCursor () from /usr/lib/libXcursor.so.1
#5  0x00442d02 in XCreateGlyphCursor () from /usr/lib/libX11.so.6
#6  0x0044318d in XCreateFontCursor () from /usr/lib/libX11.so.6
#7  0x00eb5a8c in XScrnCrsr__CursorLookup (orc=0xb7db6f14, name=0xf50ee4)
    at ../src/xvbt/XScrnCrsr.m3:166
#8  0x00ee491d in Cursor__NameApply (cl=0xb7db4da4, st=0xb7db6ae4)
    at ../src/vbt/Cursor.m3:104
#9  0x00ed44d1 in VBTRep__CursorApply (st=0xb7db6ae4, cl=0xb7db4da4, 
    cs={<No data fields>}) at ../src/vbt/VBTRep.m3:82
#10 0x00ee2b5c in Palette__ResolveCursor (st=0xb7db6ae4, 
    curs={<No data fields>}) at ../src/vbt/Palette.m3:294
#11 0x00ed6738 in VBTRep__CursorResolver (self=0xb7dd1aac)
    at ../src/vbt/VBTRep.m3:488
#12 0x00f9d9ed in ThreadPosix__RunThread ()
    at ../src/thread/POSIX/ThreadPosix.m3:1107
#13 0x0097aa1b in makecontext () from /lib/libc.so.6
#14 0x00000000 in ?? ()
(gdb) 

     Mika


From jay.krell at cornell.edu  Tue Mar  1 11:59:29 2011
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 1 Mar 2011 10:59:29 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <20110227231125.3DC611A2078@async.async.caltech.edu>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>,
	<20110227231125.3DC611A2078@async.async.caltech.edu>
Message-ID: <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>


I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Ah, it just doesn't check command-line arguments that carefully.
> 
> I think what you did is equivalent to "-tests STD".
> 
>      Mika
> 
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist:  On Windows 7, I thought I'd see what the command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash.  Then, I trie=
> >d it again and it ran to completion.  Something seems non-deterministic her=
> >e.  See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >***    Attempt to reference an illegal memory location.
> >***    pc =3D 0x77762262
> >***
> >
> >Stack trace:
> >   FP         PC      Procedure
> >---------  ---------  -------------------------------
> > 0xcdf998  0x130351b  SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0  0x77762262  <???>
> > 0xcdf9d8  0x12e83b7  LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00  0x12c7b08  GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38  0x12c12e3  RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74  0x12e971f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80  0x76543677  <???>
> > 0xcdfbc0  0x77779f02  <???>
> >.........  .........  ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete.  Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2.  That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> >     Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008.  This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung.  I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>***    An array subscript was out of range.
> >>***    file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
> >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>***    <*ASSERT*> failed.
> >>***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >>   threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >>   threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >>     Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results.  Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>***    An enumeration or subrange value was out of range.
> >>>***    file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>>   FP         PC      Procedure
> >>>---------  ---------  -------------------------------
> >>>0x30fbd0  0x127218a  PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0  0x1273825  Main_M3 + 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110301/6c051b49/attachment-0001.html>

From jay.krell at cornell.edu  Tue Mar  1 18:27:40 2011
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 1 Mar 2011 17:27:40 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>
Message-ID: <COL101-W6172E969583BD60401B836E6C10@phx.gbl>


I also haven't seen it fail on OpenBSD/x86/4.7. I'm pretty sure using pthreads there.
But on Solaris/5.10/sparc it hangs, for many hours.

-bash-4.1$ ./threadtest 
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
.

Are we guranteed forward progress in suspending all threads?

I do see it fail usually on Darwin. e.g.:
........pthread_mutex_destroy:EBUSY
pthread_mutex_destroy:EBUSY
..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:
***    An array subscript was out of range.
***    file "../src/runtime/common/RTCollector.m3", line 418
***

I haven't tried Linux yet.
Do note that we have some variance in the pthreads implementation.
The "portable" implementation is used on Linux, Solaris, NetBSD.
And then OpenBSD, Darwin, FreeBSD each have slight differences.

Mika are your machines all multiprocessors?
I do wonder if that helps increase the stress and if I should be sure to use multiprocessors.

I'm also considering taking the time to try various historical versions, either releases or dates in CVS.

 - Jay

From: jay.krell at cornell.edu
To: mika at async.caltech.edu; rcolebur at scires.com
Date: Tue, 1 Mar 2011 10:59:29 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] results of threadtest program on Windows7








I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Ah, it just doesn't check command-line arguments that carefully.
> 
> I think what you did is equivalent to "-tests STD".
> 
>      Mika
> 
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist:  On Windows 7, I thought I'd see what the command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash.  Then, I trie=
> >d it again and it ran to completion.  Something seems non-deterministic her=
> >e.  See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >***    Attempt to reference an illegal memory location.
> >***    pc =3D 0x77762262
> >***
> >
> >Stack trace:
> >   FP         PC      Procedure
> >---------  ---------  -------------------------------
> > 0xcdf998  0x130351b  SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0  0x77762262  <???>
> > 0xcdf9d8  0x12e83b7  LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00  0x12c7b08  GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38  0x12c12e3  RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74  0x12e971f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80  0x76543677  <???>
> > 0xcdfbc0  0x77779f02  <???>
> >.........  .........  ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete.  Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2.  That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> >     Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008.  This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung.  I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>***    An array subscript was out of range.
> >>***    file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
> >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>***    <*ASSERT*> failed.
> >>***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >>   threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >>   threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >>     Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results.  Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>***    An enumeration or subrange value was out of range.
> >>>***    file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>>   FP         PC      Procedure
> >>>---------  ---------  -------------------------------
> >>>0x30fbd0  0x127218a  PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0  0x1273825  Main_M3 + 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110301/8f3b432d/attachment-0001.html>

From mika at async.caltech.edu  Tue Mar  1 19:17:18 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Tue, 01 Mar 2011 10:17:18 -0800
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W6172E969583BD60401B836E6C10@phx.gbl> 
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>
	<COL101-W6172E969583BD60401B836E6C10@phx.gbl>
Message-ID: <20110301181718.12EFC1A2078@async.async.caltech.edu>


Hi Jay,

1. I think you should get forward progress no matter what, although it
might be very slow on some systems.

2. Not sure how you could get negative timings.  That would suggest that
Time.Now() is decreasing---which seems contrary to its specification.
Although the code is doing some nasty stuff with the timings, mainly
reading and writing them without locks.  But it's using INTEGER for
the results so I don't think there can be an atomicity problem there.
Even if there were coherence problems between processors (is this
technically possible?) the "now" value has to be coherent since it's
from the thread that prints the results, and the "then" values could
only be getting older, not newer...

3. Note that there are systems (FreeBSD 4 is an example) that have a
"pthreads" library but where the pthreads library is implemented with
user threads.  Could that be related to why OpenBSD is working?

4. Hm.  I think I am only using multiprocessor systems, yes.  Hard to
find single-CPU systems nowadays!  I think actually the only one I have
is PPC_DARWIN, and I haven't tried the code on that.  So yes this is a
possibility as far as explaining differences...

     Mika

Jay K writes:
>--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>I also haven't seen it fail on OpenBSD/x86/4.7. I'm pretty sure using pthre=
>ads there.
>But on Solaris/5.10/sparc it hangs=2C for many hours.
>
>-bash-4.1$ ./threadtest=20
>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
>.
>
>Are we guranteed forward progress in suspending all threads?
>
>I do see it fail usually on Darwin. e.g.:
>........pthread_mutex_destroy:EBUSY
>pthread_mutex_destroy:EBUSY
>..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:
>***    An array subscript was out of range.
>***    file "../src/runtime/common/RTCollector.m3"=2C line 418
>***
>
>I haven't tried Linux yet.
>Do note that we have some variance in the pthreads implementation.
>The "portable" implementation is used on Linux=2C Solaris=2C NetBSD.
>And then OpenBSD=2C Darwin=2C FreeBSD each have slight differences.
>
>Mika are your machines all multiprocessors?
>I do wonder if that helps increase the stress and if I should be sure to us=
>e multiprocessors.
>
>I'm also considering taking the time to try various historical versions=2C =
>either releases or dates in CVS.
>
> - Jay
>
>From: jay.krell at cornell.edu
>To: mika at async.caltech.edu=3B rcolebur at scires.com
>Date: Tue=2C 1 Mar 2011 10:59:29 +0000
>CC: m3devel at elegosoft.com
>Subject: Re: [M3devel] results of threadtest program on Windows7
>
>
>
>
>
>
>
>
>I haven't seen it fail on NT=2C except for PutCard in the test itself getti=
>ng negative numbers.
>I've run it just a few times now. One single and dual processor virtual mac=
>hines.
>Randy=2C has it failed many times for you?
>
> - Jay
>
>> To: rcolebur at SCIRES.COM
>> Date: Sun=2C 27 Feb 2011 15:11:25 -0800
>> From: mika at async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] results of threadtest program on Windows7
>>=20
>> Ah=2C it just doesn't check command-line arguments that carefully.
>>=20
>> I think what you did is equivalent to "-tests STD".
>=20
>>      Mika
>>=20
>> "Coleburn=2C Randy" writes:
>> >Mika:
>> >
>> >No change with "-tests POSIX".
>> >
>> >Interesting twist:  On Windows 7=2C I thought I'd see what the command l=
>ine o=3D
>> >ptions are=2C and I typed "threadtest -help" rather than reading the cod=
>e.
>> >
>> >First time=2C it produced what appears to be a NIL deref crash.  Then=2C=
> I trie=3D
>> >d it again and it ran to completion.  Something seems non-deterministic =
>her=3D
>> >e.  See below.
>> >
>> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
>> >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
>> >.
>> >
>> >***
>> >*** runtime error:
>> >***    Attempt to reference an illegal memory location.
>> >***    pc =3D3D 0x77762262
>> >***
>> >
>> >Stack trace:
>> >   FP         PC      Procedure
>> >---------  ---------  -------------------------------
>> > 0xcdf998  0x130351b  SystemError + 0x64 in ..\src\runtime\NT386\RTSigna=
>l.m=3D
>> >3
>> > 0xcdf9c0  0x77762262  <???>
>> > 0xcdf9d8  0x12e83b7  LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin3=
>2.m=3D
>> >3
>> > 0xcdfa00  0x12c7b08  GetChar + 0x28 in ..\src\rw\Rd.m3
>> > 0xcdfb38  0x12c12e3  RApply + 0xd3 in ..\src\Main.m3
>> > 0xcdfb74  0x12e971f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWi=
>n32=3D
>> >.m3
>> > 0xcdfb80  0x76543677  <???>
>> > 0xcdfbc0  0x77779f02  <???>
>> >.........  .........  ... more frames ...
>> >
>> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
>> >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
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >All tests complete.  Congratulations.
>> >
>> >Regards=2C
>> >Randy Coleburn
>> >
>> >-----Original Message-----
>> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
>> >Sent: Sunday=2C February 27=2C 2011 3:30 PM
>> >To: Coleburn=2C Randy
>> >Cc: m3devel at elegosoft.com
>> >Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
>> >
>> >Hi Randy=2C
>> >
>> >You can try it with -tests POSIX as well.
>> >
>> >I find on user threads it runs very slowly (but it does run) because of =
>how=3D
>> > unfair
>> >the thread scheduler is.
>> >
>> >Next step might be to whittle down the tests and see if you can get a fa=
>ilu=3D
>> >re with
>> >a single test running and -n 2.  That would likely be the simplest scena=
>rio=3D
>> > to
>> >start further debugging from.
>> >
>> >     Mika
>> >
>> >"Coleburn=2C Randy" writes:
>> >>Mika et al:
>> >>
>> >>Thought I would try something else.
>> >>
>> >>I took the sources of your thread test program to an older XP machine t=
>hat=3D
>> > =3D3D
>> >>has CM3 circa August 2008.  This is the machine and implementation I us=
>ed =3D
>> >w=3D3D
>> >>hen building a major project I did a couple years back.
>> >>
>> >>The thread test program does indeed build on this old system=2C but whe=
>n I r=3D
>> >u=3D3D
>> >>n it=2C I get different results than with the latest HEAD branch code. =
>=3D3D20
>> >>
>> >>After it prints "running...printing oldest/median age/newest"=2C on the=
> next=3D
>> > =3D3D
>> >>line I get two periods ".." and now the program seems hung.  I'll let i=
>t "=3D
>> >r=3D3D
>> >>un" for a few more minutes to see if anything else happens before killi=
>ng =3D
>> >i=3D3D
>> >>t.
>> >>
>> >>At least we don't get the subscript and assertion failures on this olde=
>r C=3D
>> >M=3D3D
>> >>3 platform.
>> >>
>> >>Regards=2C
>> >>Randy Coleburn
>> >>
>> >>
>> >>-----Original Message-----
>> >>From: Coleburn=2C Randy=3D3D20
>> >>Sent: Sunday=2C February 27=2C 2011 2:09 PM
>> >>To: m3devel at elegosoft.com
>> >>Subject: Re: [M3devel] results of threadtest program on Windows7
>> >>
>> >>Mika:
>> >>
>> >>Ok=2C I've updated to latest HEAD and I've also built Jay's m3sleep pro=
>gram.
>> >>
>> >>Here is what happens now when I run your threadtest program on Windows =
>7.
>> >>
>> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL=
>=2C-fo=3D
>> >r=3D3D
>> >>k
>> >>Writing file...done
>> >>Creating read threads...done
>> >>Creating nxread threads...done
>> >>Creating tryexcept threads...done
>> >>Creating forktoomuch threads...done
>> >>Creating alloc threads...done
>> >>Creating creat threads...done
>> >>Creating lock threads...done
>> >>running...printing oldest/median age/newest
>> >>
>> >>
>> >>***
>> >>*** runtime error:
>> >>***    An array subscript was out of range.
>> >>***    file "..\src\runtime\common\RTCollector.m3"=2C line 418
>> >>***
>> >>
>> >>
>> >>
>> >>***
>> >>*** runtime error:
>> >>***    <*ASSERT*> failed.
>> >>***    file "..\src\thread\WIN32\ThreadWin32.m3"=2C line 841
>> >>***
>> >>
>> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
>> >>
>> >>I'll send more info on the Windows install of Modula3 in a subsequent p=
>ost=3D
>> >.
>> >>
>> >>Regards=2C
>> >>Randy Coleburn
>> >>
>> >>-----Original Message-----
>> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D3D20
>> >>Sent: Saturday=2C February 26=2C 2011 12:55 PM
>> >>To: Coleburn=2C Randy
>> >>Cc: m3devel at elegosoft.com
>> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D3D20
>> >>
>> >>Hi Randy=2C
>> >>
>> >>Hm yes it looks like my Windows programming skills leave something
>> >>to be desired.
>> >>
>> >>You can run the thread tester while skipping a test as follows
>> >>
>> >>   threadtest -tests ALL=2C-fork
>> >>
>> >>(for instance)
>> >>
>> >>if you just run=3D3D20
>> >>
>> >>   threadtest -sadfassdaf
>> >>
>> >>it'll print the tests that are available.
>> >>
>> >>As it happens=2C I just had to upgrade my windows 2000 system to window=
>s 7.
>> >>Can you give me a very brief description of what you did to install Mod=
>ula=3D
>> >-=3D3D
>> >>3
>> >>on this system?
>> >>
>> >>     Mika
>> >>
>> >>"Coleburn=2C Randy" writes:
>> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
>> >>>Content-Type: text/plain=3B charset=3D3D3D"us-ascii"
>> >>>Content-Transfer-Encoding: quoted-printable
>> >>>
>> >>>Mika:
>> >>>
>> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
>> >>>
>> >>>So=2C I ran your threadtest program.
>> >>>
>> >>>Here are the results.  Note the "..." is where I cut out a bunch of th=
>e r=3D
>> >e=3D3D
>> >>p=3D3D3D
>> >>>eating "ERROR FApply" messages.
>> >>>
>> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
>> >>>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
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>.
>> >>>.
>> >>>.
>> >>>***
>> >>>*** runtime error:
>> >>>***    An enumeration or subrange value was out of range.
>> >>>***    file "..\src\Main.m3"=2C line 340
>> >>>***
>> >>>
>> >>>laziest thread is 0/0/ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: T=
>he sy=3D
>> >ste=3D3D
>> >>m c=3D3D3D
>> >>>annot find the file specified.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>.
>> >>>.
>> >>>.
>> >>>laziest thread is 0/0/ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: T=
>he sy=3D
>> >ste=3D3D
>> >>m c=3D3D3D
>> >>>annot find the file specified.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>.
>> >>>.
>> >>>.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>Stack trace:
>> >>>   FP         PC      Procedure
>> >>>---------  ---------  -------------------------------
>> >>>0x30fbd0  0x127218a  PutStats + 0x1a3 in ..\src\Main.m3
>> >>>0x30fcc0  0x1273825  Main_M3 + 0x11db(!) in ..\src\Main.m3
>> >>>
>> >>>Regards=2C
>> >>>Randy Coleburn
>> >>>
>> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
>> >>>Content-Type: text/html=3B charset=3D3D3D"us-ascii"
>> >>>Content-Transfer-Encoding: quoted-printable
>> >>>
> 		 	   		  =
>
>--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Tahoma
>}
>--></style>
></head>
><body class=3D'hmmessage'>
>I also haven't seen it fail on OpenBSD/x86/4.7. I'm pretty sure using pthre=
>ads there.<br>But on Solaris/5.10/sparc it hangs=2C for many hours.<br><br>=
>-bash-4.1$ ./threadtest <br>Writing file...done<br>Creating read threads...=
>done<br>Creating fork threads...done<br>Creating alloc threads...done<br>Cr=
>eating lock threads...done<br>running...printing oldest/median age/newest<b=
>r>.<br><br>Are we guranteed forward progress in suspending all threads?<br>=
><br>I do see it fail usually on Darwin. e.g.:<br>........pthread_mutex_dest=
>roy:EBUSY<br>pthread_mutex_destroy:EBUSY<br>..laziest thread is 0/0/0 (test=
>s: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)<br>...<br><br>***<br>*** r=
>untime error:<br>***&nbsp=3B&nbsp=3B&nbsp=3B An array subscript was out of =
>range.<br>***&nbsp=3B&nbsp=3B&nbsp=3B file "../src/runtime/common/RTCollect=
>or.m3"=2C line 418<br>***<br><br>I haven't tried Linux yet.<br>Do note that=
> we have some variance in the pthreads implementation.<br>The "portable" im=
>plementation is used on Linux=2C Solaris=2C NetBSD.<br>And then OpenBSD=2C =
>Darwin=2C FreeBSD each have slight differences.<br><br>Mika are your machin=
>es all multiprocessors?<br>I do wonder if that helps increase the stress an=
>d if I should be sure to use multiprocessors.<br><br>I'm also considering t=
>aking the time to try various historical versions=2C either releases or dat=
>es in CVS.<br><br>&nbsp=3B- Jay<br><br><hr id=3D"stopSpelling">From: jay.kr=
>ell at cornell.edu<br>To: mika at async.caltech.edu=3B rcolebur at scires.com<br>Dat=
>e: Tue=2C 1 Mar 2011 10:59:29 +0000<br>CC: m3devel at elegosoft.com<br>Subject=
>: Re: [M3devel] results of threadtest program on Windows7<br><br>
>
><meta http-equiv=3D"Content-Type" content=3D"text/html=3B charset=3Dunicode=
>">
><meta name=3D"Generator" content=3D"Microsoft SafeHTML">
><style>
>.ExternalClass .ecxhmmessage P
>{padding:0px=3B}
>.ExternalClass body.ecxhmmessage
>{font-size:10pt=3Bfont-family:Tahoma=3B}
>
></style>
>
>
>I haven't seen it fail on NT=2C except for PutCard in the test itself getti=
>ng negative numbers.<br>I've run it just a few times now. One single and du=
>al processor virtual machines.<br>Randy=2C has it failed many times for you=
>?<br><br>&nbsp=3B- Jay<br><br>&gt=3B To: rcolebur at SCIRES.COM<br>&gt=3B Date=
>: Sun=2C 27 Feb 2011 15:11:25 -0800<br>&gt=3B From: mika at async.caltech.edu<=
>br>&gt=3B CC: m3devel at elegosoft.com<br>&gt=3B Subject: Re: [M3devel] result=
>s of threadtest program on Windows7<br>&gt=3B <br>&gt=3B Ah=2C it just does=
>n't check command-line arguments that carefully.<br>&gt=3B <br>&gt=3B I thi=
>nk what you did is equivalent to "-tests STD".<br>&gt=3B <br>&gt=3B      Mi=
>ka<br>&gt=3B <br>&gt=3B "Coleburn=2C Randy" writes:<br>&gt=3B &gt=3BMika:<b=
>r>&gt=3B &gt=3B<br>&gt=3B &gt=3BNo change with "-tests POSIX".<br>&gt=3B &g=
>t=3B<br>&gt=3B &gt=3BInteresting twist:  On Windows 7=2C I thought I'd see =
>what the command line o=3D<br>&gt=3B &gt=3Bptions are=2C and I typed "threa=
>dtest -help" rather than reading the code.<br>&gt=3B &gt=3B<br>&gt=3B &gt=
>=3BFirst time=2C it produced what appears to be a NIL deref crash.  Then=2C=
> I trie=3D<br>&gt=3B &gt=3Bd it again and it ran to completion.  Something =
>seems non-deterministic her=3D<br>&gt=3B &gt=3Be.  See below.<br>&gt=3B &gt=
>=3B<br>&gt=3B &gt=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bt=
>hreadtest.exe -help<br>&gt=3B &gt=3BWriting file...done<br>&gt=3B &gt=3BCre=
>ating read threads...done<br>&gt=3B &gt=3BCreating fork threads...done<br>&=
>gt=3B &gt=3BCreating alloc threads...done<br>&gt=3B &gt=3BCreating lock thr=
>eads...done<br>&gt=3B &gt=3Brunning...printing oldest/median age/newest<br>=
>&gt=3B &gt=3B.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B***<br>&gt=3B &gt=3B*** run=
>time error:<br>&gt=3B &gt=3B***    Attempt to reference an illegal memory l=
>ocation.<br>&gt=3B &gt=3B***    pc =3D3D 0x77762262<br>&gt=3B &gt=3B***<br>=
>&gt=3B &gt=3B<br>&gt=3B &gt=3BStack trace:<br>&gt=3B &gt=3B   FP         PC=
>      Procedure<br>&gt=3B &gt=3B---------  ---------  ---------------------=
>----------<br>&gt=3B &gt=3B 0xcdf998  0x130351b  SystemError + 0x64 in ..\s=
>rc\runtime\NT386\RTSignal.m=3D<br>&gt=3B &gt=3B3<br>&gt=3B &gt=3B 0xcdf9c0 =
> 0x77762262  &lt=3B???&gt=3B<br>&gt=3B &gt=3B 0xcdf9d8  0x12e83b7  LockMute=
>x + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=3D<br>&gt=3B &gt=3B3<br>&gt=
>=3B &gt=3B 0xcdfa00  0x12c7b08  GetChar + 0x28 in ..\src\rw\Rd.m3<br>&gt=3B=
> &gt=3B 0xcdfb38  0x12c12e3  RApply + 0xd3 in ..\src\Main.m3<br>&gt=3B &gt=
>=3B 0xcdfb74  0x12e971f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWi=
>n32=3D<br>&gt=3B &gt=3B.m3<br>&gt=3B &gt=3B 0xcdfb80  0x76543677  &lt=3B???=
>&gt=3B<br>&gt=3B &gt=3B 0xcdfbc0  0x77779f02  &lt=3B???&gt=3B<br>&gt=3B &gt=
>=3B.........  .........  ... more frames ...<br>&gt=3B &gt=3B<br>&gt=3B &gt=
>=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest.exe -he=
>lp<br>&gt=3B &gt=3BWriting file...done<br>&gt=3B &gt=3BCreating read thread=
>s...done<br>&gt=3B &gt=3BCreating fork threads...done<br>&gt=3B &gt=3BCreat=
>ing alloc threads...done<br>&gt=3B &gt=3BCreating lock threads...done<br>&g=
>t=3B &gt=3Brunning...printing oldest/median age/newest<br>&gt=3B &gt=3B....=
>......laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=3D<=
>br>&gt=3B &gt=3B lock 0/0/0)<br>&gt=3B &gt=3B..........laziest thread is 0/=
>0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/=
>0)<br>&gt=3B &gt=3B..........laziest thread is 0/0/0 (tests: read 0/0/0 for=
>k 0/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/0)<br>&gt=3B &gt=3B.......=
>...laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=3D<br>=
>&gt=3B &gt=3B lock 0/0/0)<br>&gt=3B &gt=3B..........laziest thread is 0/0/0=
> (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/0)<=
>br>&gt=3B &gt=3B..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0=
>/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/0)<br>&gt=3B &gt=3B..........=
>laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=3D<br>&gt=
>=3B &gt=3B lock 0/0/0)<br>&gt=3B &gt=3B..........laziest thread is 0/0/0 (t=
ests: read 0/0/0 fork 0/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/0)<br>=
>&gt=3B &gt=3B..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/=
>0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/0)<br>&gt=3B &gt=3B..........laz=
>iest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=3D<br>&gt=3B=
> &gt=3B lock 0/0/0)<br>&gt=3B &gt=3BAll tests complete.  Congratulations.<b=
>r>&gt=3B &gt=3B<br>&gt=3B &gt=3BRegards=2C<br>&gt=3B &gt=3BRandy Coleburn<b=
>r>&gt=3B &gt=3B<br>&gt=3B &gt=3B-----Original Message-----<br>&gt=3B &gt=3B=
>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20<br>&gt=3B &gt=3BSen=
>t: Sunday=2C February 27=2C 2011 3:30 PM<br>&gt=3B &gt=3BTo: Coleburn=2C Ra=
>ndy<br>&gt=3B &gt=3BCc: m3devel at elegosoft.com<br>&gt=3B &gt=3BSubject: Re: =
>[M3devel] results of threadtest program on Windows7=3D20<br>&gt=3B &gt=3B<b=
>r>&gt=3B &gt=3BHi Randy=2C<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BYou can try it =
>with -tests POSIX as well.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BI find on user =
>threads it runs very slowly (but it does run) because of how=3D<br>&gt=3B &=
>gt=3B unfair<br>&gt=3B &gt=3Bthe thread scheduler is.<br>&gt=3B &gt=3B<br>&=
>gt=3B &gt=3BNext step might be to whittle down the tests and see if you can=
> get a failu=3D<br>&gt=3B &gt=3Bre with<br>&gt=3B &gt=3Ba single test runni=
>ng and -n 2.  That would likely be the simplest scenario=3D<br>&gt=3B &gt=
>=3B to<br>&gt=3B &gt=3Bstart further debugging from.<br>&gt=3B &gt=3B<br>&g=
>t=3B &gt=3B     Mika<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B"Coleburn=2C Randy" w=
>rites:<br>&gt=3B &gt=3B&gt=3BMika et al:<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &=
>gt=3B&gt=3BThought I would try something else.<br>&gt=3B &gt=3B&gt=3B<br>&g=
>t=3B &gt=3B&gt=3BI took the sources of your thread test program to an older=
> XP machine that=3D<br>&gt=3B &gt=3B =3D3D<br>&gt=3B &gt=3B&gt=3Bhas CM3 ci=
>rca August 2008.  This is the machine and implementation I used =3D<br>&gt=
>=3B &gt=3Bw=3D3D<br>&gt=3B &gt=3B&gt=3Bhen building a major project I did a=
> couple years back.<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3BThe thread=
> test program does indeed build on this old system=2C but when I r=3D<br>&g=
>t=3B &gt=3Bu=3D3D<br>&gt=3B &gt=3B&gt=3Bn it=2C I get different results tha=
>n with the latest HEAD branch code. =3D3D20<br>&gt=3B &gt=3B&gt=3B<br>&gt=
>=3B &gt=3B&gt=3BAfter it prints "running...printing oldest/median age/newes=
>t"=2C on the next=3D<br>&gt=3B &gt=3B =3D3D<br>&gt=3B &gt=3B&gt=3Bline I ge=
>t two periods ".." and now the program seems hung.  I'll let it "=3D<br>&gt=
>=3B &gt=3Br=3D3D<br>&gt=3B &gt=3B&gt=3Bun" for a few more minutes to see if=
> anything else happens before killing =3D<br>&gt=3B &gt=3Bi=3D3D<br>&gt=3B =
>&gt=3B&gt=3Bt.<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3BAt least we don=
>'t get the subscript and assertion failures on this older C=3D<br>&gt=3B &g=
>t=3BM=3D3D<br>&gt=3B &gt=3B&gt=3B3 platform.<br>&gt=3B &gt=3B&gt=3B<br>&gt=
>=3B &gt=3B&gt=3BRegards=2C<br>&gt=3B &gt=3B&gt=3BRandy Coleburn<br>&gt=3B &=
>gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B-----Original Mess=
>age-----<br>&gt=3B &gt=3B&gt=3BFrom: Coleburn=2C Randy=3D3D20<br>&gt=3B &gt=
>=3B&gt=3BSent: Sunday=2C February 27=2C 2011 2:09 PM<br>&gt=3B &gt=3B&gt=3B=
>To: m3devel at elegosoft.com<br>&gt=3B &gt=3B&gt=3BSubject: Re: [M3devel] resu=
>lts of threadtest program on Windows7<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=
>=3B&gt=3BMika:<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3BOk=2C I've upda=
>ted to latest HEAD and I've also built Jay's m3sleep program.<br>&gt=3B &gt=
>=3B&gt=3B<br>&gt=3B &gt=3B&gt=3BHere is what happens now when I run your th=
>readtest program on Windows 7.<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
>=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest -tests =
>ALL=2C-fo=3D<br>&gt=3B &gt=3Br=3D3D<br>&gt=3B &gt=3B&gt=3Bk<br>&gt=3B &gt=
>=3B&gt=3BWriting file...done<br>&gt=3B &gt=3B&gt=3BCreating read threads...=
>done<br>&gt=3B &gt=3B&gt=3BCreating nxread threads...done<br>&gt=3B &gt=3B&=
>gt=3BCreating tryexcept threads...done<br>&gt=3B &gt=3B&gt=3BCreating forkt=
>oomuch threads...done<br>&gt=3B &gt=3B&gt=3BCreating alloc threads...done<b=
>r>&gt=3B &gt=3B&gt=3BCreating creat threads...done<br>&gt=3B &gt=3B&gt=3BCr=
>eating lock threads...done<br>&gt=3B &gt=3B&gt=3Brunning...printing oldest/=
>median age/newest<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &=
>gt=3B&gt=3B***<br>&gt=3B &gt=3B&gt=3B*** runtime error:<br>&gt=3B &gt=3B&gt=
>=3B***    An array subscript was out of range.<br>&gt=3B &gt=3B&gt=3B***   =
> file "..\src\runtime\common\RTCollector.m3"=2C line 418<br>&gt=3B &gt=3B&g=
>t=3B***<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
>=3B<br>&gt=3B &gt=3B&gt=3B***<br>&gt=3B &gt=3B&gt=3B*** runtime error:<br>&=
>gt=3B &gt=3B&gt=3B***    &lt=3B*ASSERT*&gt=3B failed.<br>&gt=3B &gt=3B&gt=
>=3B***    file "..\src\thread\WIN32\ThreadWin32.m3"=2C line 841<br>&gt=3B &=
>gt=3B&gt=3B***<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3BThe last error =
>repeats ad infinitum until I press CNTRL-C to abort.<br>&gt=3B &gt=3B&gt=3B=
><br>&gt=3B &gt=3B&gt=3BI'll send more info on the Windows install of Modula=
>3 in a subsequent post=3D<br>&gt=3B &gt=3B.<br>&gt=3B &gt=3B&gt=3B<br>&gt=
>=3B &gt=3B&gt=3BRegards=2C<br>&gt=3B &gt=3B&gt=3BRandy Coleburn<br>&gt=3B &=
>gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B-----Original Message-----<br>&gt=3B &gt=
>=3B&gt=3BFrom: Mika Nystrom [mailto:mika at async.caltech.edu]=3D3D20<br>&gt=
>=3B &gt=3B&gt=3BSent: Saturday=2C February 26=2C 2011 12:55 PM<br>&gt=3B &g=
>t=3B&gt=3BTo: Coleburn=2C Randy<br>&gt=3B &gt=3B&gt=3BCc: m3devel at elegosoft=
>.com<br>&gt=3B &gt=3B&gt=3BSubject: Re: [M3devel] results of threadtest pro=
>gram on Windows7=3D3D20<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3BHi Ran=
>dy=2C<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3BHm yes it looks like my =
>Windows programming skills leave something<br>&gt=3B &gt=3B&gt=3Bto be desi=
>red.<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3BYou can run the thread te=
>ster while skipping a test as follows<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=
>=3B&gt=3B   threadtest -tests ALL=2C-fork<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B =
>&gt=3B&gt=3B(for instance)<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3Bif =
>you just run=3D3D20<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B   threadt=
>est -sadfassdaf<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3Bit'll print th=
>e tests that are available.<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3BAs=
> it happens=2C I just had to upgrade my windows 2000 system to windows 7.<b=
>r>&gt=3B &gt=3B&gt=3BCan you give me a very brief description of what you d=
>id to install Modula=3D<br>&gt=3B &gt=3B-=3D3D<br>&gt=3B &gt=3B&gt=3B3<br>&=
>gt=3B &gt=3B&gt=3Bon this system?<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&g=
>t=3B     Mika<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B"Coleburn=2C Ran=
>dy" writes:<br>&gt=3B &gt=3B&gt=3B&gt=3B--_000_D67F02DDC62F7545A6B84C285F88=
>F3E6EE25C849atlex02srv_<br>&gt=3B &gt=3B&gt=3B&gt=3BContent-Type: text/plai=
>n=3B charset=3D3D3D"us-ascii"<br>&gt=3B &gt=3B&gt=3B&gt=3BContent-Transfer-=
>Encoding: quoted-printable<br>&gt=3B &gt=3B&gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
>=3B&gt=3BMika:<br>&gt=3B &gt=3B&gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B&gt=3BI'v=
>e finally managed to get cm3 rebuilt on Windows 7 again.<br>&gt=3B &gt=3B&g=
>t=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B&gt=3BSo=2C I ran your threadtest program.=
><br>&gt=3B &gt=3B&gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B&gt=3BHere are the resu=
>lts.  Note the "..." is where I cut out a bunch of the r=3D<br>&gt=3B &gt=
>=3Be=3D3D<br>&gt=3B &gt=3B&gt=3Bp=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Beating=
> "ERROR FApply" messages.<br>&gt=3B &gt=3B&gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
>=3B&gt=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest.e=
>xe<br>&gt=3B &gt=3B&gt=3B&gt=3BWriting file...done<br>&gt=3B &gt=3B&gt=3B&g=
>t=3BCreating read threads...done<br>&gt=3B &gt=3B&gt=3B&gt=3BCreating fork =
>threads...done<br>&gt=3B &gt=3B&gt=3B&gt=3BCreating alloc threads...done<br=
>>&gt=3B &gt=3B&gt=3B&gt=3BCreating lock threads...done<br>&gt=3B &gt=3B&gt=
>=3B&gt=3Brunning...printing oldest/median age/newest<br>&gt=3B &gt=3B&gt=3B=
>&gt=3BERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find=
> the f=3D<br>&gt=3B &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B sp=3D3D3D<br>&gt=
>=3B &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B &gt=3B&gt=3B&gt=3BERROR FApply: OS=
>Error.E:  ErrorCode=3D3D3D3D2: The system cannot find the f=3D<br>&gt=3B &g=
>t=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B sp=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Be=
>cified.<br>&gt=3B &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E:  ErrorCode=3D3=
>D3D3D2: The system cannot find the f=3D<br>&gt=3B &gt=3Bile=3D3D<br>&gt=3B =
>&gt=3B&gt=3B sp=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B &gt=
>=3B&gt=3B&gt=3B.<br>&gt=3B &gt=3B&gt=3B&gt=3B.<br>&gt=3B &gt=3B&gt=3B&gt=3B=
>.<br>&gt=3B &gt=3B&gt=3B&gt=3B***<br>&gt=3B &gt=3B&gt=3B&gt=3B*** runtime e=
>rror:<br>&gt=3B &gt=3B&gt=3B&gt=3B***    An enumeration or subrange value w=
>as out of range.<br>&gt=3B &gt=3B&gt=3B&gt=3B***    file "..\src\Main.m3"=
>=2C line 340<br>&gt=3B &gt=3B&gt=3B&gt=3B***<br>&gt=3B &gt=3B&gt=3B&gt=3B<b=
>r>&gt=3B &gt=3B&gt=3B&gt=3Blaziest thread is 0/0/ERROR FApply: OSError.E:  =
>ErrorCode=3D3D3D3D2: The sy=3D<br>&gt=3B &gt=3Bste=3D3D<br>&gt=3B &gt=3B&gt=
>=3Bm c=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Bannot find the file specified.<br=
>>&gt=3B &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: Th=
>e system cannot find the f=3D<br>&gt=3B &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=
>=3B sp=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B &gt=3B&gt=3B&g=
>t=3BERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find t=
>he f=3D<br>&gt=3B &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B sp=3D3D3D<br>&gt=3B=
> &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B &gt=3B&gt=3B&gt=3BERROR FApply: OSErr=
>or.E:  ErrorCode=3D3D3D3D2: The system cannot find the f=3D<br>&gt=3B &gt=
>=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B sp=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Bec=
>ified.<br>&gt=3B &gt=3B&gt=3B&gt=3B.<br>&gt=3B &gt=3B&gt=3B&gt=3B.<br>&gt=
>=3B &gt=3B&gt=3B&gt=3B.<br>&gt=3B &gt=3B&gt=3B&gt=3Blaziest thread is 0/0/E=
>RROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The sy=3D<br>&gt=3B &gt=3Bste=
>=3D3D<br>&gt=3B &gt=3B&gt=3Bm c=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Bannot fi=
>nd the file specified.<br>&gt=3B &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E:=
>  ErrorCode=3D3D3D3D2: The system cannot find the f=3D<br>&gt=3B &gt=3Bile=
>=3D3D<br>&gt=3B &gt=3B&gt=3B sp=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Becified.=
><br>&gt=3B &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2:=
> The system cannot find the f=3D<br>&gt=3B &gt=3Bile=3D3D<br>&gt=3B &gt=3B&=
>gt=3B sp=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B &gt=3B&gt=3B=
>&gt=3BERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find=
> the f=3D<br>&gt=3B &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B sp=3D3D3D<br>&gt=
>=3B &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B &gt=3B&gt=3B&gt=3B.<br>&gt=3B &gt=
>=3B&gt=3B&gt=3B.<br>&gt=3B &gt=3B&gt=3B&gt=3B.<br>&gt=3B &gt=3B&gt=3B&gt=3B=
>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find the f=
>=3D<br>&gt=3B &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B sp=3D3D3D<br>&gt=3B &gt=
>=3B&gt=3B&gt=3Becified.<br>&gt=3B &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E=
>:  ErrorCode=3D3D3D3D2: The system cannot find the f=3D<br>&gt=3B &gt=3Bile=
>=3D3D<br>&gt=3B &gt=3B&gt=3B sp=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Becified.=
><br>&gt=3B &gt=3B&gt=3B&gt=3BStack trace:<br>&gt=3B &gt=3B&gt=3B&gt=3B   FP=
>         PC      Procedure<br>&gt=3B &gt=3B&gt=3B&gt=3B---------  ---------=
>  -------------------------------<br>&gt=3B &gt=3B&gt=3B&gt=3B0x30fbd0  0x1=
>27218a  PutStats + 0x1a3 in ..\src\Main.m3<br>&gt=3B &gt=3B&gt=3B&gt=3B0x30=
>fcc0  0x1273825  Main_M3 + 0x11db(!) in ..\src\Main.m3<br>&gt=3B &gt=3B&gt=
>=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B&gt=3BRegards=2C<br>&gt=3B &gt=3B&gt=3B&gt=
>=3BRandy Coleburn<br>&gt=3B &gt=3B&gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B&gt=3B=
>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_<br>&gt=3B &gt=3B=
>&gt=3B&gt=3BContent-Type: text/html=3B charset=3D3D3D"us-ascii"<br>&gt=3B &=
>gt=3B&gt=3B&gt=3BContent-Transfer-Encoding: quoted-printable<br>&gt=3B &gt=
>=3B&gt=3B&gt=3B<br> 		 	   		  </body>
></html>=
>
>--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_--


From dabenavidesd at yahoo.es  Tue Mar  1 23:10:55 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 1 Mar 2011 22:10:55 +0000 (GMT)
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <20110301181718.12EFC1A2078@async.async.caltech.edu>
Message-ID: <452042.5906.qm@web29706.mail.ird.yahoo.com>

Hi all:
but you could still run a *nix image with uniprocessor support kernel and try on the vbox, qemu, etc.
Perhaps you would get enough simulation to detect that the problem is on the hardware layer (either physically or its abstraction) rather than the execution model (the pthreads scheduling policy), if it does no work may be there is a problem in ThreadPthread implementation of pthreads (don't need to switch its default is - smp 1).
commands i.e in qemu:
qemu -cdrom /path/to/system.iso -smp 2 
and run threadtest from there

Thanks in advance


 



--- El mar, 1/3/11, Mika Nystrom <mika at async.caltech.edu> escribi?:

> De: Mika Nystrom <mika at async.caltech.edu>
> Asunto: Re: [M3devel] results of threadtest program on Windows7
> Para: "Jay K" <jay.krell at cornell.edu>
> CC: m3devel at elegosoft.com
> Fecha: martes, 1 de marzo, 2011 13:17
> 
> Hi Jay,
> 
> 1. I think you should get forward progress no matter what,
> although it
> might be very slow on some systems.
> 
> 2. Not sure how you could get negative timings.  That
> would suggest that
> Time.Now() is decreasing---which seems contrary to its
> specification.
> Although the code is doing some nasty stuff with the
> timings, mainly
> reading and writing them without locks.  But it's
> using INTEGER for
> the results so I don't think there can be an atomicity
> problem there.
> Even if there were coherence problems between processors
> (is this
> technically possible?) the "now" value has to be coherent
> since it's
> from the thread that prints the results, and the "then"
> values could
> only be getting older, not newer...
> 
> 3. Note that there are systems (FreeBSD 4 is an example)
> that have a
> "pthreads" library but where the pthreads library is
> implemented with
> user threads.  Could that be related to why OpenBSD is
> working?
> 
> 4. Hm.  I think I am only using multiprocessor
> systems, yes.  Hard to
> find single-CPU systems nowadays!  I think actually
> the only one I have
> is PPC_DARWIN, and I haven't tried the code on that. 
> So yes this is a
> possibility as far as explaining differences...
> 
>      Mika
> 
> Jay K writes:
> >--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_
> >Content-Type: text/plain; charset="iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
> >
> >
> >I also haven't seen it fail on OpenBSD/x86/4.7. I'm
> pretty sure using pthre=
> >ads there.
> >But on Solaris/5.10/sparc it hangs=2C for many hours.
> >
> >-bash-4.1$ ./threadtest=20
> >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
> >.
> >
> >Are we guranteed forward progress in suspending all
> threads?
> >
> >I do see it fail usually on Darwin. e.g.:
> >........pthread_mutex_destroy:EBUSY
> >pthread_mutex_destroy:EBUSY
> >..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:
> >***    An array subscript was out of range.
> >***    file
> "../src/runtime/common/RTCollector.m3"=2C line 418
> >***
> >
> >I haven't tried Linux yet.
> >Do note that we have some variance in the pthreads
> implementation.
> >The "portable" implementation is used on Linux=2C
> Solaris=2C NetBSD.
> >And then OpenBSD=2C Darwin=2C FreeBSD each have slight
> differences.
> >
> >Mika are your machines all multiprocessors?
> >I do wonder if that helps increase the stress and if I
> should be sure to us=
> >e multiprocessors.
> >
> >I'm also considering taking the time to try various
> historical versions=2C =
> >either releases or dates in CVS.
> >
> > - Jay
> >
> >From: jay.krell at cornell.edu
> >To: mika at async.caltech.edu=3B
> rcolebur at scires.com
> >Date: Tue=2C 1 Mar 2011 10:59:29 +0000
> >CC: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on
> Windows7
> >
> >
> >
> >
> >
> >
> >
> >
> >I haven't seen it fail on NT=2C except for PutCard in
> the test itself getti=
> >ng negative numbers.
> >I've run it just a few times now. One single and dual
> processor virtual mac=
> >hines.
> >Randy=2C has it failed many times for you?
> >
> > - Jay
> >
> >> To: rcolebur at SCIRES.COM
> >> Date: Sun=2C 27 Feb 2011 15:11:25 -0800
> >> From: mika at async.caltech.edu
> >> CC: m3devel at elegosoft.com
> >> Subject: Re: [M3devel] results of threadtest
> program on Windows7
> >>=20
> >> Ah=2C it just doesn't check command-line arguments
> that carefully.
> >>=20
> >> I think what you did is equivalent to "-tests
> STD".
> >=20
> >>      Mika
> >>=20
> >> "Coleburn=2C Randy" writes:
> >> >Mika:
> >> >
> >> >No change with "-tests POSIX".
> >> >
> >> >Interesting twist:  On Windows 7=2C I
> thought I'd see what the command l=
> >ine o=3D
> >> >ptions are=2C and I typed "threadtest -help"
> rather than reading the cod=
> >e.
> >> >
> >> >First time=2C it produced what appears to be a
> NIL deref crash.  Then=2C=
> > I trie=3D
> >> >d it again and it ran to completion. 
> Something seems non-deterministic =
> >her=3D
> >> >e.  See below.
> >> >
> >>
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> -help
> >> >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
> >> >.
> >> >
> >> >***
> >> >*** runtime error:
> >> >***    Attempt to reference an
> illegal memory location.
> >> >***    pc =3D3D 0x77762262
> >> >***
> >> >
> >> >Stack trace:
> >> >   FP     
>    PC      Procedure
> >> >---------  --------- 
> -------------------------------
> >> > 0xcdf998  0x130351b  SystemError +
> 0x64 in ..\src\runtime\NT386\RTSigna=
> >l.m=3D
> >> >3
> >> > 0xcdf9c0  0x77762262  <???>
> >> > 0xcdf9d8  0x12e83b7  LockMutex +
> 0x4f in ..\src\thread\WIN32\ThreadWin3=
> >2.m=3D
> >> >3
> >> > 0xcdfa00  0x12c7b08  GetChar + 0x28
> in ..\src\rw\Rd.m3
> >> > 0xcdfb38  0x12c12e3  RApply + 0xd3
> in ..\src\Main.m3
> >> > 0xcdfb74  0x12e971f  ThreadBase +
> 0x254 in ..\src\thread\WIN32\ThreadWi=
> >n32=3D
> >> >.m3
> >> > 0xcdfb80  0x76543677  <???>
> >> > 0xcdfbc0  0x77779f02  <???>
> >> >.........  .........  ... more
> frames ...
> >> >
> >>
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> -help
> >> >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
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >All tests complete.  Congratulations.
> >> >
> >> >Regards=2C
> >> >Randy Coleburn
> >> >
> >> >-----Original Message-----
> >> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >> >Sent: Sunday=2C February 27=2C 2011 3:30 PM
> >> >To: Coleburn=2C Randy
> >> >Cc: m3devel at elegosoft.com
> >> >Subject: Re: [M3devel] results of threadtest
> program on Windows7=3D20
> >> >
> >> >Hi Randy=2C
> >> >
> >> >You can try it with -tests POSIX as well.
> >> >
> >> >I find on user threads it runs very slowly
> (but it does run) because of =
> >how=3D
> >> > unfair
> >> >the thread scheduler is.
> >> >
> >> >Next step might be to whittle down the tests
> and see if you can get a fa=
> >ilu=3D
> >> >re with
> >> >a single test running and -n 2.  That
> would likely be the simplest scena=
> >rio=3D
> >> > to
> >> >start further debugging from.
> >> >
> >> >     Mika
> >> >
> >> >"Coleburn=2C Randy" writes:
> >> >>Mika et al:
> >> >>
> >> >>Thought I would try something else.
> >> >>
> >> >>I took the sources of your thread test
> program to an older XP machine t=
> >hat=3D
> >> > =3D3D
> >> >>has CM3 circa August 2008.  This is
> the machine and implementation I us=
> >ed =3D
> >> >w=3D3D
> >> >>hen building a major project I did a
> couple years back.
> >> >>
> >> >>The thread test program does indeed build
> on this old system=2C but whe=
> >n I r=3D
> >> >u=3D3D
> >> >>n it=2C I get different results than with
> the latest HEAD branch code. =
> >=3D3D20
> >> >>
> >> >>After it prints "running...printing
> oldest/median age/newest"=2C on the=
> > next=3D
> >> > =3D3D
> >> >>line I get two periods ".." and now the
> program seems hung.  I'll let i=
> >t "=3D
> >> >r=3D3D
> >> >>un" for a few more minutes to see if
> anything else happens before killi=
> >ng =3D
> >> >i=3D3D
> >> >>t.
> >> >>
> >> >>At least we don't get the subscript and
> assertion failures on this olde=
> >r C=3D
> >> >M=3D3D
> >> >>3 platform.
> >> >>
> >> >>Regards=2C
> >> >>Randy Coleburn
> >> >>
> >> >>
> >> >>-----Original Message-----
> >> >>From: Coleburn=2C Randy=3D3D20
> >> >>Sent: Sunday=2C February 27=2C 2011 2:09
> PM
> >> >>To: m3devel at elegosoft.com
> >> >>Subject: Re: [M3devel] results of
> threadtest program on Windows7
> >> >>
> >> >>Mika:
> >> >>
> >> >>Ok=2C I've updated to latest HEAD and I've
> also built Jay's m3sleep pro=
> >gram.
> >> >>
> >> >>Here is what happens now when I run your
> threadtest program on Windows =
> >7.
> >> >>
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest
> -tests ALL=
> >=2C-fo=3D
> >> >r=3D3D
> >> >>k
> >> >>Writing file...done
> >> >>Creating read threads...done
> >> >>Creating nxread threads...done
> >> >>Creating tryexcept threads...done
> >> >>Creating forktoomuch threads...done
> >> >>Creating alloc threads...done
> >> >>Creating creat threads...done
> >> >>Creating lock threads...done
> >> >>running...printing oldest/median
> age/newest
> >> >>
> >> >>
> >> >>***
> >> >>*** runtime error:
> >> >>***    An array subscript was
> out of range.
> >> >>***    file
> "..\src\runtime\common\RTCollector.m3"=2C line 418
> >> >>***
> >> >>
> >> >>
> >> >>
> >> >>***
> >> >>*** runtime error:
> >> >>***    <*ASSERT*> failed.
> >> >>***    file
> "..\src\thread\WIN32\ThreadWin32.m3"=2C line 841
> >> >>***
> >> >>
> >> >>The last error repeats ad infinitum until
> I press CNTRL-C to abort.
> >> >>
> >> >>I'll send more info on the Windows install
> of Modula3 in a subsequent p=
> >ost=3D
> >> >.
> >> >>
> >> >>Regards=2C
> >> >>Randy Coleburn
> >> >>
> >> >>-----Original Message-----
> >> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D3D20
> >> >>Sent: Saturday=2C February 26=2C 2011
> 12:55 PM
> >> >>To: Coleburn=2C Randy
> >> >>Cc: m3devel at elegosoft.com
> >> >>Subject: Re: [M3devel] results of
> threadtest program on Windows7=3D3D20
> >> >>
> >> >>Hi Randy=2C
> >> >>
> >> >>Hm yes it looks like my Windows
> programming skills leave something
> >> >>to be desired.
> >> >>
> >> >>You can run the thread tester while
> skipping a test as follows
> >> >>
> >> >>   threadtest -tests
> ALL=2C-fork
> >> >>
> >> >>(for instance)
> >> >>
> >> >>if you just run=3D3D20
> >> >>
> >> >>   threadtest -sadfassdaf
> >> >>
> >> >>it'll print the tests that are available.
> >> >>
> >> >>As it happens=2C I just had to upgrade my
> windows 2000 system to window=
> >s 7.
> >> >>Can you give me a very brief description
> of what you did to install Mod=
> >ula=3D
> >> >-=3D3D
> >> >>3
> >> >>on this system?
> >> >>
> >> >>     Mika
> >> >>
> >> >>"Coleburn=2C Randy" writes:
> >>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >> >>>Content-Type: text/plain=3B
> charset=3D3D3D"us-ascii"
> >> >>>Content-Transfer-Encoding:
> quoted-printable
> >> >>>
> >> >>>Mika:
> >> >>>
> >> >>>I've finally managed to get cm3
> rebuilt on Windows 7 again.
> >> >>>
> >> >>>So=2C I ran your threadtest program.
> >> >>>
> >> >>>Here are the results.  Note the
> "..." is where I cut out a bunch of th=
> >e r=3D
> >> >e=3D3D
> >> >>p=3D3D3D
> >> >>>eating "ERROR FApply" messages.
> >> >>>
> >>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >> >>>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
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>.
> >> >>>.
> >> >>>.
> >> >>>***
> >> >>>*** runtime error:
> >> >>>***    An enumeration or
> subrange value was out of range.
> >> >>>***    file
> "..\src\Main.m3"=2C line 340
> >> >>>***
> >> >>>
> >> >>>laziest thread is 0/0/ERROR FApply:
> OSError.E:  ErrorCode=3D3D3D3D2: T=
> >he sy=3D
> >> >ste=3D3D
> >> >>m c=3D3D3D
> >> >>>annot find the file specified.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>.
> >> >>>.
> >> >>>.
> >> >>>laziest thread is 0/0/ERROR FApply:
> OSError.E:  ErrorCode=3D3D3D3D2: T=
> >he sy=3D
> >> >ste=3D3D
> >> >>m c=3D3D3D
> >> >>>annot find the file specified.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>.
> >> >>>.
> >> >>>.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>Stack trace:
> >> >>>   FP   
>      PC      Procedure
> >> >>>---------  --------- 
> -------------------------------
> >> >>>0x30fbd0  0x127218a 
> PutStats + 0x1a3 in ..\src\Main.m3
> >> >>>0x30fcc0  0x1273825  Main_M3
> + 0x11db(!) in ..\src\Main.m3
> >> >>>
> >> >>>Regards=2C
> >> >>>Randy Coleburn
> >> >>>
> >>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >> >>>Content-Type: text/html=3B
> charset=3D3D3D"us-ascii"
> >> >>>Content-Transfer-Encoding:
> quoted-printable
> >> >>>
> >    
>         
>           
>   =
> >
> >--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_
> >Content-Type: text/html; charset="iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
> >
> ><html>
> ><head>
> ><style><!--
> >.hmmessage P
> >{
> >margin:0px=3B
> >padding:0px
> >}
> >body.hmmessage
> >{
> >font-size: 10pt=3B
> >font-family:Tahoma
> >}
> >--></style>
> ></head>
> ><body class=3D'hmmessage'>
> >I also haven't seen it fail on OpenBSD/x86/4.7. I'm
> pretty sure using pthre=
> >ads there.<br>But on Solaris/5.10/sparc it
> hangs=2C for many hours.<br><br>=
> >-bash-4.1$ ./threadtest <br>Writing
> file...done<br>Creating read threads...=
> >done<br>Creating fork
> threads...done<br>Creating alloc
> threads...done<br>Cr=
> >eating lock threads...done<br>running...printing
> oldest/median age/newest<b=
> >r>.<br><br>Are we guranteed forward
> progress in suspending all threads?<br>=
> ><br>I do see it fail usually on Darwin.
> e.g.:<br>........pthread_mutex_dest=
> >roy:EBUSY<br>pthread_mutex_destroy:EBUSY<br>..laziest
> thread is 0/0/0 (test=
> >s: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock
> 0/0/0)<br>...<br><br>***<br>*** r=
> >untime
> error:<br>***&nbsp=3B&nbsp=3B&nbsp=3B An
> array subscript was out of =
> >range.<br>***&nbsp=3B&nbsp=3B&nbsp=3B
> file "../src/runtime/common/RTCollect=
> >or.m3"=2C line 418<br>***<br><br>I
> haven't tried Linux yet.<br>Do note that=
> > we have some variance in the pthreads
> implementation.<br>The "portable" im=
> >plementation is used on Linux=2C Solaris=2C
> NetBSD.<br>And then OpenBSD=2C =
> >Darwin=2C FreeBSD each have slight
> differences.<br><br>Mika are your machin=
> >es all multiprocessors?<br>I do wonder if that
> helps increase the stress an=
> >d if I should be sure to use
> multiprocessors.<br><br>I'm also considering t=
> >aking the time to try various historical versions=2C
> either releases or dat=
> >es in CVS.<br><br>&nbsp=3B-
> Jay<br><br><hr id=3D"stopSpelling">From:
> jay.kr=
> >ell at cornell.edu<br>To:
> mika at async.caltech.edu=3B
> rcolebur at scires.com<br>Dat=
> >e: Tue=2C 1 Mar 2011 10:59:29 +0000<br>CC: m3devel at elegosoft.com<br>Subject=
> >: Re: [M3devel] results of threadtest program on
> Windows7<br><br>
> >
> ><meta http-equiv=3D"Content-Type"
> content=3D"text/html=3B charset=3Dunicode=
> >">
> ><meta name=3D"Generator" content=3D"Microsoft
> SafeHTML">
> ><style>
> >.ExternalClass .ecxhmmessage P
> >{padding:0px=3B}
> >.ExternalClass body.ecxhmmessage
> >{font-size:10pt=3Bfont-family:Tahoma=3B}
> >
> ></style>
> >
> >
> >I haven't seen it fail on NT=2C except for PutCard in
> the test itself getti=
> >ng negative numbers.<br>I've run it just a few
> times now. One single and du=
> >al processor virtual machines.<br>Randy=2C has it
> failed many times for you=
> >?<br><br>&nbsp=3B-
> Jay<br><br>&gt=3B To: rcolebur at SCIRES.COM<br>&gt=3B
> Date=
> >: Sun=2C 27 Feb 2011 15:11:25 -0800<br>&gt=3B
> From: mika at async.caltech.edu<=
> >br>&gt=3B CC: m3devel at elegosoft.com<br>&gt=3B
> Subject: Re: [M3devel] result=
> >s of threadtest program on Windows7<br>&gt=3B
> <br>&gt=3B Ah=2C it just does=
> >n't check command-line arguments that
> carefully.<br>&gt=3B <br>&gt=3B I thi=
> >nk what you did is equivalent to "-tests
> STD".<br>&gt=3B <br>&gt=3B   
>   Mi=
> >ka<br>&gt=3B <br>&gt=3B
> "Coleburn=2C Randy" writes:<br>&gt=3B
> &gt=3BMika:<b=
> >r>&gt=3B &gt=3B<br>&gt=3B
> &gt=3BNo change with "-tests POSIX".<br>&gt=3B
> &g=
> >t=3B<br>&gt=3B &gt=3BInteresting
> twist:  On Windows 7=2C I thought I'd see =
> >what the command line o=3D<br>&gt=3B
> &gt=3Bptions are=2C and I typed "threa=
> >dtest -help" rather than reading the
> code.<br>&gt=3B &gt=3B<br>&gt=3B
> &gt=
> >=3BFirst time=2C it produced what appears to be a NIL
> deref crash.  Then=2C=
> > I trie=3D<br>&gt=3B &gt=3Bd it again and
> it ran to completion.  Something =
> >seems non-deterministic her=3D<br>&gt=3B
> &gt=3Be.  See below.<br>&gt=3B &gt=
> >=3B<br>&gt=3B
> &gt=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bt=
> >hreadtest.exe -help<br>&gt=3B
> &gt=3BWriting file...done<br>&gt=3B
> &gt=3BCre=
> >ating read threads...done<br>&gt=3B
> &gt=3BCreating fork threads...done<br>&=
> >gt=3B &gt=3BCreating alloc
> threads...done<br>&gt=3B &gt=3BCreating lock
> thr=
> >eads...done<br>&gt=3B
> &gt=3Brunning...printing oldest/median
> age/newest<br>=
> >&gt=3B &gt=3B.<br>&gt=3B
> &gt=3B<br>&gt=3B
> &gt=3B***<br>&gt=3B &gt=3B*** run=
> >time error:<br>&gt=3B &gt=3B*** 
>   Attempt to reference an illegal memory l=
> >ocation.<br>&gt=3B &gt=3B***   
> pc =3D3D 0x77762262<br>&gt=3B
> &gt=3B***<br>=
> >&gt=3B &gt=3B<br>&gt=3B
> &gt=3BStack trace:<br>&gt=3B
> &gt=3B   FP     
>    PC=
> >      Procedure<br>&gt=3B
> &gt=3B---------  --------- 
> ---------------------=
> >----------<br>&gt=3B &gt=3B
> 0xcdf998  0x130351b  SystemError + 0x64 in ..\s=
> >rc\runtime\NT386\RTSignal.m=3D<br>&gt=3B
> &gt=3B3<br>&gt=3B &gt=3B 0xcdf9c0 =
> > 0x77762262 
> &lt=3B???&gt=3B<br>&gt=3B &gt=3B
> 0xcdf9d8  0x12e83b7  LockMute=
> >x + 0x4f in
> ..\src\thread\WIN32\ThreadWin32.m=3D<br>&gt=3B
> &gt=3B3<br>&gt=
> >=3B &gt=3B 0xcdfa00  0x12c7b08  GetChar +
> 0x28 in ..\src\rw\Rd.m3<br>&gt=3B=
> > &gt=3B 0xcdfb38  0x12c12e3  RApply +
> 0xd3 in ..\src\Main.m3<br>&gt=3B &gt=
> >=3B 0xcdfb74  0x12e971f  ThreadBase + 0x254
> in ..\src\thread\WIN32\ThreadWi=
> >n32=3D<br>&gt=3B
> &gt=3B.m3<br>&gt=3B &gt=3B 0xcdfb80 
> 0x76543677  &lt=3B???=
> >&gt=3B<br>&gt=3B &gt=3B
> 0xcdfbc0  0x77779f02 
> &lt=3B???&gt=3B<br>&gt=3B &gt=
> >=3B.........  .........  ... more frames
> ...<br>&gt=3B &gt=3B<br>&gt=3B
> &gt=
> >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest.exe
> -he=
> >lp<br>&gt=3B &gt=3BWriting
> file...done<br>&gt=3B &gt=3BCreating read
> thread=
> >s...done<br>&gt=3B &gt=3BCreating fork
> threads...done<br>&gt=3B &gt=3BCreat=
> >ing alloc threads...done<br>&gt=3B
> &gt=3BCreating lock threads...done<br>&g=
> >t=3B &gt=3Brunning...printing oldest/median
> age/newest<br>&gt=3B &gt=3B....=
> >......laziest thread is 0/0/0 (tests: read 0/0/0 fork
> 0/0/0 alloc 0/0/0=3D<=
> >br>&gt=3B &gt=3B lock
> 0/0/0)<br>&gt=3B &gt=3B..........laziest
> thread is 0/=
> >0/0 (tests: read 0/0/0 fork 0/0/0 alloc
> 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/=
> >0)<br>&gt=3B &gt=3B..........laziest
> thread is 0/0/0 (tests: read 0/0/0 for=
> >k 0/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B
> lock 0/0/0)<br>&gt=3B &gt=3B.......=
> >...laziest thread is 0/0/0 (tests: read 0/0/0 fork
> 0/0/0 alloc 0/0/0=3D<br>=
> >&gt=3B &gt=3B lock 0/0/0)<br>&gt=3B
> &gt=3B..........laziest thread is 0/0/0=
> > (tests: read 0/0/0 fork 0/0/0 alloc
> 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/0)<=
> >br>&gt=3B &gt=3B..........laziest thread is
> 0/0/0 (tests: read 0/0/0 fork 0=
> >/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock
> 0/0/0)<br>&gt=3B &gt=3B..........=
> >laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0
> alloc 0/0/0=3D<br>&gt=
> >=3B &gt=3B lock 0/0/0)<br>&gt=3B
> &gt=3B..........laziest thread is 0/0/0 (t=
> ests: read 0/0/0 fork 0/0/0 alloc
> 0/0/0=3D<br>&gt=3B &gt=3B lock
> 0/0/0)<br>=
> >&gt=3B &gt=3B..........laziest thread is 0/0/0
> (tests: read 0/0/0 fork 0/0/=
> >0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock
> 0/0/0)<br>&gt=3B &gt=3B..........laz=
> >iest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0
> alloc 0/0/0=3D<br>&gt=3B=
> > &gt=3B lock 0/0/0)<br>&gt=3B
> &gt=3BAll tests complete.  Congratulations.<b=
> >r>&gt=3B &gt=3B<br>&gt=3B
> &gt=3BRegards=2C<br>&gt=3B &gt=3BRandy
> Coleburn<b=
> >r>&gt=3B &gt=3B<br>&gt=3B
> &gt=3B-----Original Message-----<br>&gt=3B
> &gt=3B=
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20<br>&gt=3B
> &gt=3BSen=
> >t: Sunday=2C February 27=2C 2011 3:30
> PM<br>&gt=3B &gt=3BTo: Coleburn=2C Ra=
> >ndy<br>&gt=3B &gt=3BCc: m3devel at elegosoft.com<br>&gt=3B
> &gt=3BSubject: Re: =
> >[M3devel] results of threadtest program on
> Windows7=3D20<br>&gt=3B &gt=3B<b=
> >r>&gt=3B &gt=3BHi
> Randy=2C<br>&gt=3B &gt=3B<br>&gt=3B
> &gt=3BYou can try it =
> >with -tests POSIX as well.<br>&gt=3B
> &gt=3B<br>&gt=3B &gt=3BI find on user =
> >threads it runs very slowly (but it does run) because
> of how=3D<br>&gt=3B &=
> >gt=3B unfair<br>&gt=3B &gt=3Bthe thread
> scheduler is.<br>&gt=3B
> &gt=3B<br>&=
> >gt=3B &gt=3BNext step might be to whittle down the
> tests and see if you can=
> > get a failu=3D<br>&gt=3B &gt=3Bre
> with<br>&gt=3B &gt=3Ba single test runni=
> >ng and -n 2.  That would likely be the simplest
> scenario=3D<br>&gt=3B &gt=
> >=3B to<br>&gt=3B &gt=3Bstart further
> debugging from.<br>&gt=3B
> &gt=3B<br>&g=
> >t=3B &gt=3B 
>    Mika<br>&gt=3B
> &gt=3B<br>&gt=3B &gt=3B"Coleburn=2C Randy"
> w=
> >rites:<br>&gt=3B &gt=3B&gt=3BMika et
> al:<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B &=
> >gt=3B&gt=3BThought I would try something
> else.<br>&gt=3B
> &gt=3B&gt=3B<br>&g=
> >t=3B &gt=3B&gt=3BI took the sources of your
> thread test program to an older=
> > XP machine that=3D<br>&gt=3B &gt=3B
> =3D3D<br>&gt=3B &gt=3B&gt=3Bhas CM3 ci=
> >rca August 2008.  This is the machine and
> implementation I used =3D<br>&gt=
> >=3B &gt=3Bw=3D3D<br>&gt=3B
> &gt=3B&gt=3Bhen building a major project I did a=
> > couple years back.<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3BThe thread=
> > test program does indeed build on this old system=2C
> but when I r=3D<br>&g=
> >t=3B &gt=3Bu=3D3D<br>&gt=3B
> &gt=3B&gt=3Bn it=2C I get different results tha=
> >n with the latest HEAD branch code.
> =3D3D20<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=
> >=3B &gt=3B&gt=3BAfter it prints
> "running...printing oldest/median age/newes=
> >t"=2C on the next=3D<br>&gt=3B &gt=3B
> =3D3D<br>&gt=3B &gt=3B&gt=3Bline I ge=
> >t two periods ".." and now the program seems
> hung.  I'll let it "=3D<br>&gt=
> >=3B &gt=3Br=3D3D<br>&gt=3B
> &gt=3B&gt=3Bun" for a few more minutes to see if=
> > anything else happens before killing
> =3D<br>&gt=3B &gt=3Bi=3D3D<br>&gt=3B
> =
> >&gt=3B&gt=3Bt.<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3BAt least we don=
> >'t get the subscript and assertion failures on this
> older C=3D<br>&gt=3B &g=
> >t=3BM=3D3D<br>&gt=3B &gt=3B&gt=3B3
> platform.<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=
> >=3B &gt=3B&gt=3BRegards=2C<br>&gt=3B
> &gt=3B&gt=3BRandy Coleburn<br>&gt=3B
> &=
> >gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B-----Original Mess=
> >age-----<br>&gt=3B &gt=3B&gt=3BFrom:
> Coleburn=2C Randy=3D3D20<br>&gt=3B &gt=
> >=3B&gt=3BSent: Sunday=2C February 27=2C 2011 2:09
> PM<br>&gt=3B &gt=3B&gt=3B=
> >To: m3devel at elegosoft.com<br>&gt=3B
> &gt=3B&gt=3BSubject: Re: [M3devel] resu=
> >lts of threadtest program on
> Windows7<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B &gt=
> >=3B&gt=3BMika:<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3BOk=2C I've upda=
> >ted to latest HEAD and I've also built Jay's m3sleep
> program.<br>&gt=3B &gt=
> >=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3BHere is what happens now when I run your
> th=
> >readtest program on Windows 7.<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
> >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest
> -tests =
> >ALL=2C-fo=3D<br>&gt=3B
> &gt=3Br=3D3D<br>&gt=3B
> &gt=3B&gt=3Bk<br>&gt=3B &gt=
> >=3B&gt=3BWriting file...done<br>&gt=3B
> &gt=3B&gt=3BCreating read threads...=
> >done<br>&gt=3B &gt=3B&gt=3BCreating
> nxread threads...done<br>&gt=3B &gt=3B&=
> >gt=3BCreating tryexcept
> threads...done<br>&gt=3B
> &gt=3B&gt=3BCreating forkt=
> >oomuch threads...done<br>&gt=3B
> &gt=3B&gt=3BCreating alloc threads...done<b=
> >r>&gt=3B &gt=3B&gt=3BCreating creat
> threads...done<br>&gt=3B &gt=3B&gt=3BCr=
> >eating lock threads...done<br>&gt=3B
> &gt=3B&gt=3Brunning...printing oldest/=
> >median age/newest<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B &=
> >gt=3B&gt=3B***<br>&gt=3B
> &gt=3B&gt=3B*** runtime error:<br>&gt=3B
> &gt=3B&gt=
> >=3B***    An array subscript was out of
> range.<br>&gt=3B
> &gt=3B&gt=3B***   =
> > file "..\src\runtime\common\RTCollector.m3"=2C line
> 418<br>&gt=3B &gt=3B&g=
> >t=3B***<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
> >=3B<br>&gt=3B
> &gt=3B&gt=3B***<br>&gt=3B
> &gt=3B&gt=3B*** runtime error:<br>&=
> >gt=3B &gt=3B&gt=3B***   
> &lt=3B*ASSERT*&gt=3B failed.<br>&gt=3B
> &gt=3B&gt=
> >=3B***    file
> "..\src\thread\WIN32\ThreadWin32.m3"=2C line
> 841<br>&gt=3B &=
> >gt=3B&gt=3B***<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3BThe last error =
> >repeats ad infinitum until I press CNTRL-C to
> abort.<br>&gt=3B &gt=3B&gt=3B=
> ><br>&gt=3B &gt=3B&gt=3BI'll send more
> info on the Windows install of Modula=
> >3 in a subsequent post=3D<br>&gt=3B
> &gt=3B.<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=
> >=3B &gt=3B&gt=3BRegards=2C<br>&gt=3B
> &gt=3B&gt=3BRandy Coleburn<br>&gt=3B
> &=
> >gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B-----Original
> Message-----<br>&gt=3B &gt=
> >=3B&gt=3BFrom: Mika Nystrom [mailto:mika at async.caltech.edu]=3D3D20<br>&gt=
> >=3B &gt=3B&gt=3BSent: Saturday=2C February
> 26=2C 2011 12:55 PM<br>&gt=3B &g=
> >t=3B&gt=3BTo: Coleburn=2C Randy<br>&gt=3B
> &gt=3B&gt=3BCc: m3devel at elegosoft=
> >.com<br>&gt=3B &gt=3B&gt=3BSubject:
> Re: [M3devel] results of threadtest pro=
> >gram on Windows7=3D3D20<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3BHi Ran=
> >dy=2C<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3BHm yes it looks like my =
> >Windows programming skills leave
> something<br>&gt=3B &gt=3B&gt=3Bto be
> desi=
> >red.<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3BYou can run the thread te=
> >ster while skipping a test as
> follows<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B &gt=
> >=3B&gt=3B   threadtest -tests
> ALL=2C-fork<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B =
> >&gt=3B&gt=3B(for instance)<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3Bif =
> >you just run=3D3D20<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B   threadt=
> >est -sadfassdaf<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3Bit'll print th=
> >e tests that are available.<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3BAs=
> > it happens=2C I just had to upgrade my windows 2000
> system to windows 7.<b=
> >r>&gt=3B &gt=3B&gt=3BCan you give me a
> very brief description of what you d=
> >id to install Modula=3D<br>&gt=3B
> &gt=3B-=3D3D<br>&gt=3B
> &gt=3B&gt=3B3<br>&=
> >gt=3B &gt=3B&gt=3Bon this
> system?<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B &gt=3B&g=
> >t=3B     Mika<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B"Coleburn=2C Ran=
> >dy" writes:<br>&gt=3B
> &gt=3B&gt=3B&gt=3B--_000_D67F02DDC62F7545A6B84C285F88=
> >F3E6EE25C849atlex02srv_<br>&gt=3B
> &gt=3B&gt=3B&gt=3BContent-Type: text/plai=
> >n=3B charset=3D3D3D"us-ascii"<br>&gt=3B
> &gt=3B&gt=3B&gt=3BContent-Transfer-=
> >Encoding: quoted-printable<br>&gt=3B
> &gt=3B&gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=
> >=3B&gt=3BMika:<br>&gt=3B
> &gt=3B&gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B&gt=3BI'v=
> >e finally managed to get cm3 rebuilt on Windows 7
> again.<br>&gt=3B &gt=3B&g=
> >t=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B&gt=3BSo=2C I ran your threadtest
> program.=
> ><br>&gt=3B
> &gt=3B&gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B&gt=3BHere are the resu=
> >lts.  Note the "..." is where I cut out a bunch of
> the r=3D<br>&gt=3B &gt=
> >=3Be=3D3D<br>&gt=3B
> &gt=3B&gt=3Bp=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Beating=
> > "ERROR FApply" messages.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=
> >=3B&gt=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest.e=
> >xe<br>&gt=3B
> &gt=3B&gt=3B&gt=3BWriting
> file...done<br>&gt=3B &gt=3B&gt=3B&g=
> >t=3BCreating read threads...done<br>&gt=3B
> &gt=3B&gt=3B&gt=3BCreating fork =
> >threads...done<br>&gt=3B
> &gt=3B&gt=3B&gt=3BCreating alloc
> threads...done<br=
> >>&gt=3B &gt=3B&gt=3B&gt=3BCreating
> lock threads...done<br>&gt=3B &gt=3B&gt=
> >=3B&gt=3Brunning...printing oldest/median
> age/newest<br>&gt=3B &gt=3B&gt=3B=
> >&gt=3BERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find=
> > the f=3D<br>&gt=3B
> &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> sp=3D3D3D<br>&gt=
> >=3B
> &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> &gt=3B&gt=3B&gt=3BERROR FApply: OS=
> >Error.E:  ErrorCode=3D3D3D3D2: The system cannot
> find the f=3D<br>&gt=3B &g=
> >t=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> sp=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Be=
> >cified.<br>&gt=3B
> &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E: 
> ErrorCode=3D3=
> >D3D3D2: The system cannot find the
> f=3D<br>&gt=3B
> &gt=3Bile=3D3D<br>&gt=3B =
> >&gt=3B&gt=3B sp=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> &gt=
> >=3B&gt=3B&gt=3B.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B=
> >.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B***<br>&gt=3B
> &gt=3B&gt=3B&gt=3B*** runtime e=
> >rror:<br>&gt=3B
> &gt=3B&gt=3B&gt=3B***    An
> enumeration or subrange value w=
> >as out of range.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B***    file
> "..\src\Main.m3"=
> >=2C line 340<br>&gt=3B
> &gt=3B&gt=3B&gt=3B***<br>&gt=3B
> &gt=3B&gt=3B&gt=3B<b=
> >r>&gt=3B &gt=3B&gt=3B&gt=3Blaziest
> thread is 0/0/ERROR FApply: OSError.E:  =
> >ErrorCode=3D3D3D3D2: The sy=3D<br>&gt=3B
> &gt=3Bste=3D3D<br>&gt=3B &gt=3B&gt=
> >=3Bm c=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Bannot find the file
> specified.<br=
> >>&gt=3B &gt=3B&gt=3B&gt=3BERROR
> FApply: OSError.E:  ErrorCode=3D3D3D3D2: Th=
> >e system cannot find the f=3D<br>&gt=3B
> &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=
> >=3B sp=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> &gt=3B&gt=3B&g=
> >t=3BERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2:
> The system cannot find t=
> >he f=3D<br>&gt=3B
> &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> sp=3D3D3D<br>&gt=3B=
> >
> &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> &gt=3B&gt=3B&gt=3BERROR FApply: OSErr=
> >or.E:  ErrorCode=3D3D3D3D2: The system cannot find
> the f=3D<br>&gt=3B &gt=
> >=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> sp=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Bec=
> >ified.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B.<br>&gt=
> >=3B &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> &gt=3B&gt=3B&gt=3Blaziest thread is 0/0/E=
> >RROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The
> sy=3D<br>&gt=3B &gt=3Bste=
> >=3D3D<br>&gt=3B &gt=3B&gt=3Bm
> c=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Bannot fi=
> >nd the file specified.<br>&gt=3B
> &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E:=
> >  ErrorCode=3D3D3D3D2: The system cannot find the
> f=3D<br>&gt=3B &gt=3Bile=
> >=3D3D<br>&gt=3B &gt=3B&gt=3B
> sp=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Becified.=
> ><br>&gt=3B
> &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2:=
> > The system cannot find the f=3D<br>&gt=3B
> &gt=3Bile=3D3D<br>&gt=3B &gt=3B&=
> >gt=3B sp=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> &gt=3B&gt=3B=
> >&gt=3BERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find=
> > the f=3D<br>&gt=3B
> &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> sp=3D3D3D<br>&gt=
> >=3B
> &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> &gt=
> >=3B&gt=3B&gt=3B.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B=
> >ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The
> system cannot find the f=
> >=3D<br>&gt=3B
> &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> sp=3D3D3D<br>&gt=3B &gt=
> >=3B&gt=3B&gt=3Becified.<br>&gt=3B
> &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E=
> >:  ErrorCode=3D3D3D3D2: The system cannot find the
> f=3D<br>&gt=3B &gt=3Bile=
> >=3D3D<br>&gt=3B &gt=3B&gt=3B
> sp=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Becified.=
> ><br>&gt=3B
> &gt=3B&gt=3B&gt=3BStack
> trace:<br>&gt=3B
> &gt=3B&gt=3B&gt=3B   FP=
> >         PC   
>   Procedure<br>&gt=3B
> &gt=3B&gt=3B&gt=3B---------  ---------=
> > 
> -------------------------------<br>&gt=3B
> &gt=3B&gt=3B&gt=3B0x30fbd0  0x1=
> >27218a  PutStats + 0x1a3 in
> ..\src\Main.m3<br>&gt=3B
> &gt=3B&gt=3B&gt=3B0x30=
> >fcc0  0x1273825  Main_M3 + 0x11db(!) in
> ..\src\Main.m3<br>&gt=3B &gt=3B&gt=
> >=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B&gt=3BRegards=2C<br>&gt=3B
> &gt=3B&gt=3B&gt=
> >=3BRandy Coleburn<br>&gt=3B
> &gt=3B&gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B&gt=3B=
> >--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_<br>&gt=3B
> &gt=3B=
> >&gt=3B&gt=3BContent-Type: text/html=3B
> charset=3D3D3D"us-ascii"<br>&gt=3B &=
> >gt=3B&gt=3B&gt=3BContent-Transfer-Encoding:
> quoted-printable<br>&gt=3B &gt=
> >=3B&gt=3B&gt=3B<br>    
>         
>           
>   </body>
> ></html>=
> >
> >--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_--
> 


      


From jay.krell at cornell.edu  Wed Mar  2 04:11:49 2011
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Mar 2011 03:11:49 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <452042.5906.qm@web29706.mail.ird.yahoo.com>
References: <20110301181718.12EFC1A2078@async.async.caltech.edu>,
	<452042.5906.qm@web29706.mail.ird.yahoo.com>
Message-ID: <COL101-W3670B74A99994199607C6BE6C00@phx.gbl>


I have still have mostly uniprocessors (though busy selling stuff off...)
  I do have a MacBook Pro and Dell laptop with 2 processors each though.
  It is that MacBook Pro where I can consistently get Darwin to fail, and a 1 and 2 proc Windows virtual machine on the MacBook Pro that consistently works.
  While Modula-3 user threads never run anything truly concurrently, i.e. on multiple prcoessors, there should still be almost arbitrary preemption.
 
 
I'm skeptical of any emulation's or virtualization's ability to simulate more processors than underlying physical processors.
 
 
Most of the runs error or succeed within 10 minutes. The one Solaris/sparc run I made ran for well over 4 hours and didn't get very far. I'd say it was hung forever.
 
 
I didn't debug it.
 
 
Yes, OpenBSD pthreads are user threads and therefore probably only ever use one processor.
But that machine only has one. :)

 
I think this will quite difficult to track down.
It might be useful to find an old starting point that succeeds and upgrade forward looking for when things fail.
That is tedious and has its own set of difficulties, granted.
 There are many points in time that don't compile, many are my fault, and there are also many combinations of starting/ending points that don't compile due to some mismatches between start/end.
 
 
I have to try Linux and/or FreeBSD still.
 
 
The errors on Darwin imply to me that memory is being prematurely reclaimed by the garbage collector -- e.g. EBUSY from pthread_mutex_destroy.
But it could also be arbitrary memory corruption (sort of the same thing), same example, but rather than an actually busy mutex, it could be a corrupted mutex or random pointer. Some of that might be easy to track down, e.g. by tracing which addresses are initialized as mutexes, and maybe by putting pad bytes around mutexes and seeing if they get changed.
I'm reluctant to try draw any conclusions yet though, since I have very very little information/knowledge.
 
 
I also forgot to check if I was using any optimization. I'll be sure to not.
 
 
 - Jay

 
> Date: Tue, 1 Mar 2011 22:10:55 +0000
> From: dabenavidesd at yahoo.es
> To: jay.krell at cornell.edu; mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Hi all:
> but you could still run a *nix image with uniprocessor support kernel and try on the vbox, qemu, etc.
> Perhaps you would get enough simulation to detect that the problem is on the hardware layer (either physically or its abstraction) rather than the execution model (the pthreads scheduling policy), if it does no work may be there is a problem in ThreadPthread implementation of pthreads (don't need to switch its default is - smp 1).
> commands i.e in qemu:
> qemu -cdrom /path/to/system.iso -smp 2 
> and run threadtest from there
> 
> Thanks in advance
> 
> 
> 
> 
> 
> 
> --- El mar, 1/3/11, Mika Nystrom <mika at async.caltech.edu> escribi?:
> 
> > De: Mika Nystrom <mika at async.caltech.edu>
> > Asunto: Re: [M3devel] results of threadtest program on Windows7
> > Para: "Jay K" <jay.krell at cornell.edu>
> > CC: m3devel at elegosoft.com
> > Fecha: martes, 1 de marzo, 2011 13:17
> > 
> > Hi Jay,
> > 
> > 1. I think you should get forward progress no matter what,
> > although it
> > might be very slow on some systems.
> > 
> > 2. Not sure how you could get negative timings. That
> > would suggest that
> > Time.Now() is decreasing---which seems contrary to its
> > specification.
> > Although the code is doing some nasty stuff with the
> > timings, mainly
> > reading and writing them without locks. But it's
> > using INTEGER for
> > the results so I don't think there can be an atomicity
> > problem there.
> > Even if there were coherence problems between processors
> > (is this
> > technically possible?) the "now" value has to be coherent
> > since it's
> > from the thread that prints the results, and the "then"
> > values could
> > only be getting older, not newer...
> > 
> > 3. Note that there are systems (FreeBSD 4 is an example)
> > that have a
> > "pthreads" library but where the pthreads library is
> > implemented with
> > user threads. Could that be related to why OpenBSD is
> > working?
> > 
> > 4. Hm. I think I am only using multiprocessor
> > systems, yes. Hard to
> > find single-CPU systems nowadays! I think actually
> > the only one I have
> > is PPC_DARWIN, and I haven't tried the code on that. 
> > So yes this is a
> > possibility as far as explaining differences...
> > 
> > Mika
> > 
> > Jay K writes:
> > >--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_
> > >Content-Type: text/plain; charset="iso-8859-1"
> > >Content-Transfer-Encoding: quoted-printable
> > >
> > >
> > >I also haven't seen it fail on OpenBSD/x86/4.7. I'm
> > pretty sure using pthre=
> > >ads there.
> > >But on Solaris/5.10/sparc it hangs=2C for many hours.
> > >
> > >-bash-4.1$ ./threadtest=20
> > >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
> > >.
> > >
> > >Are we guranteed forward progress in suspending all
> > threads?
> > >
> > >I do see it fail usually on Darwin. e.g.:
> > >........pthread_mutex_destroy:EBUSY
> > >pthread_mutex_destroy:EBUSY
> > >..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:
> > >*** An array subscript was out of range.
> > >*** file
> > "../src/runtime/common/RTCollector.m3"=2C line 418
> > >***
> > >
> > >I haven't tried Linux yet.
> > >Do note that we have some variance in the pthreads
> > implementation.
> > >The "portable" implementation is used on Linux=2C
> > Solaris=2C NetBSD.
> > >And then OpenBSD=2C Darwin=2C FreeBSD each have slight
> > differences.
> > >
> > >Mika are your machines all multiprocessors?
> > >I do wonder if that helps increase the stress and if I
> > should be sure to us=
> > >e multiprocessors.
> > >
> > >I'm also considering taking the time to try various
> > historical versions=2C =
> > >either releases or dates in CVS.
> > >
> > > - Jay
> > >
> > >From: jay.krell at cornell.edu
> > >To: mika at async.caltech.edu=3B
> > rcolebur at scires.com
> > >Date: Tue=2C 1 Mar 2011 10:59:29 +0000
> > >CC: m3devel at elegosoft.com
> > >Subject: Re: [M3devel] results of threadtest program on
> > Windows7
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >I haven't seen it fail on NT=2C except for PutCard in
> > the test itself getti=
> > >ng negative numbers.
> > >I've run it just a few times now. One single and dual
> > processor virtual mac=
> > >hines.
> > >Randy=2C has it failed many times for you?
> > >
> > > - Jay
> > >
> > >> To: rcolebur at SCIRES.COM
> > >> Date: Sun=2C 27 Feb 2011 15:11:25 -0800
> > >> From: mika at async.caltech.edu
> > >> CC: m3devel at elegosoft.com
> > >> Subject: Re: [M3devel] results of threadtest
> > program on Windows7
> > >>=20
> > >> Ah=2C it just doesn't check command-line arguments
> > that carefully.
> > >>=20
> > >> I think what you did is equivalent to "-tests
> > STD".
> > >=20
> > >> Mika
> > >>=20
> > >> "Coleburn=2C Randy" writes:
> > >> >Mika:
> > >> >
> > >> >No change with "-tests POSIX".
> > >> >
> > >> >Interesting twist: On Windows 7=2C I
> > thought I'd see what the command l=
> > >ine o=3D
> > >> >ptions are=2C and I typed "threadtest -help"
> > rather than reading the cod=
> > >e.
> > >> >
> > >> >First time=2C it produced what appears to be a
> > NIL deref crash. Then=2C=
> > > I trie=3D
> > >> >d it again and it ran to completion. 
> > Something seems non-deterministic =
> > >her=3D
> > >> >e. See below.
> > >> >
> > >>
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > -help
> > >> >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
> > >> >.
> > >> >
> > >> >***
> > >> >*** runtime error:
> > >> >*** Attempt to reference an
> > illegal memory location.
> > >> >*** pc =3D3D 0x77762262
> > >> >***
> > >> >
> > >> >Stack trace:
> > >> > FP 
> > PC Procedure
> > >> >--------- --------- 
> > -------------------------------
> > >> > 0xcdf998 0x130351b SystemError +
> > 0x64 in ..\src\runtime\NT386\RTSigna=
> > >l.m=3D
> > >> >3
> > >> > 0xcdf9c0 0x77762262 <???>
> > >> > 0xcdf9d8 0x12e83b7 LockMutex +
> > 0x4f in ..\src\thread\WIN32\ThreadWin3=
> > >2.m=3D
> > >> >3
> > >> > 0xcdfa00 0x12c7b08 GetChar + 0x28
> > in ..\src\rw\Rd.m3
> > >> > 0xcdfb38 0x12c12e3 RApply + 0xd3
> > in ..\src\Main.m3
> > >> > 0xcdfb74 0x12e971f ThreadBase +
> > 0x254 in ..\src\thread\WIN32\ThreadWi=
> > >n32=3D
> > >> >.m3
> > >> > 0xcdfb80 0x76543677 <???>
> > >> > 0xcdfbc0 0x77779f02 <???>
> > >> >......... ......... ... more
> > frames ...
> > >> >
> > >>
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > -help
> > >> >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
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >All tests complete. Congratulations.
> > >> >
> > >> >Regards=2C
> > >> >Randy Coleburn
> > >> >
> > >> >-----Original Message-----
> > >> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> > >> >Sent: Sunday=2C February 27=2C 2011 3:30 PM
> > >> >To: Coleburn=2C Randy
> > >> >Cc: m3devel at elegosoft.com
> > >> >Subject: Re: [M3devel] results of threadtest
> > program on Windows7=3D20
> > >> >
> > >> >Hi Randy=2C
> > >> >
> > >> >You can try it with -tests POSIX as well.
> > >> >
> > >> >I find on user threads it runs very slowly
> > (but it does run) because of =
> > >how=3D
> > >> > unfair
> > >> >the thread scheduler is.
> > >> >
> > >> >Next step might be to whittle down the tests
> > and see if you can get a fa=
> > >ilu=3D
> > >> >re with
> > >> >a single test running and -n 2. That
> > would likely be the simplest scena=
> > >rio=3D
> > >> > to
> > >> >start further debugging from.
> > >> >
> > >> > Mika
> > >> >
> > >> >"Coleburn=2C Randy" writes:
> > >> >>Mika et al:
> > >> >>
> > >> >>Thought I would try something else.
> > >> >>
> > >> >>I took the sources of your thread test
> > program to an older XP machine t=
> > >hat=3D
> > >> > =3D3D
> > >> >>has CM3 circa August 2008. This is
> > the machine and implementation I us=
> > >ed =3D
> > >> >w=3D3D
> > >> >>hen building a major project I did a
> > couple years back.
> > >> >>
> > >> >>The thread test program does indeed build
> > on this old system=2C but whe=
> > >n I r=3D
> > >> >u=3D3D
> > >> >>n it=2C I get different results than with
> > the latest HEAD branch code. =
> > >=3D3D20
> > >> >>
> > >> >>After it prints "running...printing
> > oldest/median age/newest"=2C on the=
> > > next=3D
> > >> > =3D3D
> > >> >>line I get two periods ".." and now the
> > program seems hung. I'll let i=
> > >t "=3D
> > >> >r=3D3D
> > >> >>un" for a few more minutes to see if
> > anything else happens before killi=
> > >ng =3D
> > >> >i=3D3D
> > >> >>t.
> > >> >>
> > >> >>At least we don't get the subscript and
> > assertion failures on this olde=
> > >r C=3D
> > >> >M=3D3D
> > >> >>3 platform.
> > >> >>
> > >> >>Regards=2C
> > >> >>Randy Coleburn
> > >> >>
> > >> >>
> > >> >>-----Original Message-----
> > >> >>From: Coleburn=2C Randy=3D3D20
> > >> >>Sent: Sunday=2C February 27=2C 2011 2:09
> > PM
> > >> >>To: m3devel at elegosoft.com
> > >> >>Subject: Re: [M3devel] results of
> > threadtest program on Windows7
> > >> >>
> > >> >>Mika:
> > >> >>
> > >> >>Ok=2C I've updated to latest HEAD and I've
> > also built Jay's m3sleep pro=
> > >gram.
> > >> >>
> > >> >>Here is what happens now when I run your
> > threadtest program on Windows =
> > >7.
> > >> >>
> > >>
> > >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest
> > -tests ALL=
> > >=2C-fo=3D
> > >> >r=3D3D
> > >> >>k
> > >> >>Writing file...done
> > >> >>Creating read threads...done
> > >> >>Creating nxread threads...done
> > >> >>Creating tryexcept threads...done
> > >> >>Creating forktoomuch threads...done
> > >> >>Creating alloc threads...done
> > >> >>Creating creat threads...done
> > >> >>Creating lock threads...done
> > >> >>running...printing oldest/median
> > age/newest
> > >> >>
> > >> >>
> > >> >>***
> > >> >>*** runtime error:
> > >> >>*** An array subscript was
> > out of range.
> > >> >>*** file
> > "..\src\runtime\common\RTCollector.m3"=2C line 418
> > >> >>***
> > >> >>
> > >> >>
> > >> >>
> > >> >>***
> > >> >>*** runtime error:
> > >> >>*** <*ASSERT*> failed.
> > >> >>*** file
> > "..\src\thread\WIN32\ThreadWin32.m3"=2C line 841
> > >> >>***
> > >> >>
> > >> >>The last error repeats ad infinitum until
> > I press CNTRL-C to abort.
> > >> >>
> > >> >>I'll send more info on the Windows install
> > of Modula3 in a subsequent p=
> > >ost=3D
> > >> >.
> > >> >>
> > >> >>Regards=2C
> > >> >>Randy Coleburn
> > >> >>
> > >> >>-----Original Message-----
> > >> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D3D20
> > >> >>Sent: Saturday=2C February 26=2C 2011
> > 12:55 PM
> > >> >>To: Coleburn=2C Randy
> > >> >>Cc: m3devel at elegosoft.com
> > >> >>Subject: Re: [M3devel] results of
> > threadtest program on Windows7=3D3D20
> > >> >>
> > >> >>Hi Randy=2C
> > >> >>
> > >> >>Hm yes it looks like my Windows
> > programming skills leave something
> > >> >>to be desired.
> > >> >>
> > >> >>You can run the thread tester while
> > skipping a test as follows
> > >> >>
> > >> >> threadtest -tests
> > ALL=2C-fork
> > >> >>
> > >> >>(for instance)
> > >> >>
> > >> >>if you just run=3D3D20
> > >> >>
> > >> >> threadtest -sadfassdaf
> > >> >>
> > >> >>it'll print the tests that are available.
> > >> >>
> > >> >>As it happens=2C I just had to upgrade my
> > windows 2000 system to window=
> > >s 7.
> > >> >>Can you give me a very brief description
> > of what you did to install Mod=
> > >ula=3D
> > >> >-=3D3D
> > >> >>3
> > >> >>on this system?
> > >> >>
> > >> >> Mika
> > >> >>
> > >> >>"Coleburn=2C Randy" writes:
> > >>
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >> >>>Content-Type: text/plain=3B
> > charset=3D3D3D"us-ascii"
> > >> >>>Content-Transfer-Encoding:
> > quoted-printable
> > >> >>>
> > >> >>>Mika:
> > >> >>>
> > >> >>>I've finally managed to get cm3
> > rebuilt on Windows 7 again.
> > >> >>>
> > >> >>>So=2C I ran your threadtest program.
> > >> >>>
> > >> >>>Here are the results. Note the
> > "..." is where I cut out a bunch of th=
> > >e r=3D
> > >> >e=3D3D
> > >> >>p=3D3D3D
> > >> >>>eating "ERROR FApply" messages.
> > >> >>>
> > >>
> > >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > >> >>>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
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>.
> > >> >>>.
> > >> >>>.
> > >> >>>***
> > >> >>>*** runtime error:
> > >> >>>*** An enumeration or
> > subrange value was out of range.
> > >> >>>*** file
> > "..\src\Main.m3"=2C line 340
> > >> >>>***
> > >> >>>
> > >> >>>laziest thread is 0/0/ERROR FApply:
> > OSError.E: ErrorCode=3D3D3D3D2: T=
> > >he sy=3D
> > >> >ste=3D3D
> > >> >>m c=3D3D3D
> > >> >>>annot find the file specified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>.
> > >> >>>.
> > >> >>>.
> > >> >>>laziest thread is 0/0/ERROR FApply:
> > OSError.E: ErrorCode=3D3D3D3D2: T=
> > >he sy=3D
> > >> >ste=3D3D
> > >> >>m c=3D3D3D
> > >> >>>annot find the file specified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>.
> > >> >>>.
> > >> >>>.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>Stack trace:
> > >> >>> FP 
> > PC Procedure
> > >> >>>--------- --------- 
> > -------------------------------
> > >> >>>0x30fbd0 0x127218a 
> > PutStats + 0x1a3 in ..\src\Main.m3
> > >> >>>0x30fcc0 0x1273825 Main_M3
> > + 0x11db(!) in ..\src\Main.m3
> > >> >>>
> > >> >>>Regards=2C
> > >> >>>Randy Coleburn
> > >> >>>
> > >>
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >> >>>Content-Type: text/html=3B
> > charset=3D3D3D"us-ascii"
> > >> >>>Content-Transfer-Encoding:
> > quoted-printable
> > >> >>>
> > > 
> > 
> > 
> > =
> > >
> > >--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_
> > >Content-Type: text/html; charset="iso-8859-1"
> > >Content-Transfer-Encoding: quoted-printable
> > >
> > ><html>
> > ><head>
> > ><style><!--
> > >.hmmessage P
> > >{
> > >margin:0px=3B
> > >padding:0px
> > >}
> > >body.hmmessage
> > >{
> > >font-size: 10pt=3B
> > >font-family:Tahoma
> > >}
> > >--></style>
> > ></head>
> > ><body class=3D'hmmessage'>
> > >I also haven't seen it fail on OpenBSD/x86/4.7. I'm
> > pretty sure using pthre=
> > >ads there.<br>But on Solaris/5.10/sparc it
> > hangs=2C for many hours.<br><br>=
> > >-bash-4.1$ ./threadtest <br>Writing
> > file...done<br>Creating read threads...=
> > >done<br>Creating fork
> > threads...done<br>Creating alloc
> > threads...done<br>Cr=
> > >eating lock threads...done<br>running...printing
> > oldest/median age/newest<b=
> > >r>.<br><br>Are we guranteed forward
> > progress in suspending all threads?<br>=
> > ><br>I do see it fail usually on Darwin.
> > e.g.:<br>........pthread_mutex_dest=
> > >roy:EBUSY<br>pthread_mutex_destroy:EBUSY<br>..laziest
> > thread is 0/0/0 (test=
> > >s: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock
> > 0/0/0)<br>...<br><br>***<br>*** r=
> > >untime
> > error:<br>***&nbsp=3B&nbsp=3B&nbsp=3B An
> > array subscript was out of =
> > >range.<br>***&nbsp=3B&nbsp=3B&nbsp=3B
> > file "../src/runtime/common/RTCollect=
> > >or.m3"=2C line 418<br>***<br><br>I
> > haven't tried Linux yet.<br>Do note that=
> > > we have some variance in the pthreads
> > implementation.<br>The "portable" im=
> > >plementation is used on Linux=2C Solaris=2C
> > NetBSD.<br>And then OpenBSD=2C =
> > >Darwin=2C FreeBSD each have slight
> > differences.<br><br>Mika are your machin=
> > >es all multiprocessors?<br>I do wonder if that
> > helps increase the stress an=
> > >d if I should be sure to use
> > multiprocessors.<br><br>I'm also considering t=
> > >aking the time to try various historical versions=2C
> > either releases or dat=
> > >es in CVS.<br><br>&nbsp=3B-
> > Jay<br><br><hr id=3D"stopSpelling">From:
> > jay.kr=
> > >ell at cornell.edu<br>To:
> > mika at async.caltech.edu=3B
> > rcolebur at scires.com<br>Dat=
> > >e: Tue=2C 1 Mar 2011 10:59:29 +0000<br>CC: m3devel at elegosoft.com<br>Subject=
> > >: Re: [M3devel] results of threadtest program on
> > Windows7<br><br>
> > >
> > ><meta http-equiv=3D"Content-Type"
> > content=3D"text/html=3B charset=3Dunicode=
> > >">
> > ><meta name=3D"Generator" content=3D"Microsoft
> > SafeHTML">
> > ><style>
> > >.ExternalClass .ecxhmmessage P
> > >{padding:0px=3B}
> > >.ExternalClass body.ecxhmmessage
> > >{font-size:10pt=3Bfont-family:Tahoma=3B}
> > >
> > ></style>
> > >
> > >
> > >I haven't seen it fail on NT=2C except for PutCard in
> > the test itself getti=
> > >ng negative numbers.<br>I've run it just a few
> > times now. One single and du=
> > >al processor virtual machines.<br>Randy=2C has it
> > failed many times for you=
> > >?<br><br>&nbsp=3B-
> > Jay<br><br>&gt=3B To: rcolebur at SCIRES.COM<br>&gt=3B
> > Date=
> > >: Sun=2C 27 Feb 2011 15:11:25 -0800<br>&gt=3B
> > From: mika at async.caltech.edu<=
> > >br>&gt=3B CC: m3devel at elegosoft.com<br>&gt=3B
> > Subject: Re: [M3devel] result=
> > >s of threadtest program on Windows7<br>&gt=3B
> > <br>&gt=3B Ah=2C it just does=
> > >n't check command-line arguments that
> > carefully.<br>&gt=3B <br>&gt=3B I thi=
> > >nk what you did is equivalent to "-tests
> > STD".<br>&gt=3B <br>&gt=3B 
> > Mi=
> > >ka<br>&gt=3B <br>&gt=3B
> > "Coleburn=2C Randy" writes:<br>&gt=3B
> > &gt=3BMika:<b=
> > >r>&gt=3B &gt=3B<br>&gt=3B
> > &gt=3BNo change with "-tests POSIX".<br>&gt=3B
> > &g=
> > >t=3B<br>&gt=3B &gt=3BInteresting
> > twist: On Windows 7=2C I thought I'd see =
> > >what the command line o=3D<br>&gt=3B
> > &gt=3Bptions are=2C and I typed "threa=
> > >dtest -help" rather than reading the
> > code.<br>&gt=3B &gt=3B<br>&gt=3B
> > &gt=
> > >=3BFirst time=2C it produced what appears to be a NIL
> > deref crash. Then=2C=
> > > I trie=3D<br>&gt=3B &gt=3Bd it again and
> > it ran to completion. Something =
> > >seems non-deterministic her=3D<br>&gt=3B
> > &gt=3Be. See below.<br>&gt=3B &gt=
> > >=3B<br>&gt=3B
> > &gt=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bt=
> > >hreadtest.exe -help<br>&gt=3B
> > &gt=3BWriting file...done<br>&gt=3B
> > &gt=3BCre=
> > >ating read threads...done<br>&gt=3B
> > &gt=3BCreating fork threads...done<br>&=
> > >gt=3B &gt=3BCreating alloc
> > threads...done<br>&gt=3B &gt=3BCreating lock
> > thr=
> > >eads...done<br>&gt=3B
> > &gt=3Brunning...printing oldest/median
> > age/newest<br>=
> > >&gt=3B &gt=3B.<br>&gt=3B
> > &gt=3B<br>&gt=3B
> > &gt=3B***<br>&gt=3B &gt=3B*** run=
> > >time error:<br>&gt=3B &gt=3B*** 
> > Attempt to reference an illegal memory l=
> > >ocation.<br>&gt=3B &gt=3B*** 
> > pc =3D3D 0x77762262<br>&gt=3B
> > &gt=3B***<br>=
> > >&gt=3B &gt=3B<br>&gt=3B
> > &gt=3BStack trace:<br>&gt=3B
> > &gt=3B FP 
> > PC=
> > > Procedure<br>&gt=3B
> > &gt=3B--------- --------- 
> > ---------------------=
> > >----------<br>&gt=3B &gt=3B
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\s=
> > >rc\runtime\NT386\RTSignal.m=3D<br>&gt=3B
> > &gt=3B3<br>&gt=3B &gt=3B 0xcdf9c0 =
> > > 0x77762262 
> > &lt=3B???&gt=3B<br>&gt=3B &gt=3B
> > 0xcdf9d8 0x12e83b7 LockMute=
> > >x + 0x4f in
> > ..\src\thread\WIN32\ThreadWin32.m=3D<br>&gt=3B
> > &gt=3B3<br>&gt=
> > >=3B &gt=3B 0xcdfa00 0x12c7b08 GetChar +
> > 0x28 in ..\src\rw\Rd.m3<br>&gt=3B=
> > > &gt=3B 0xcdfb38 0x12c12e3 RApply +
> > 0xd3 in ..\src\Main.m3<br>&gt=3B &gt=
> > >=3B 0xcdfb74 0x12e971f ThreadBase + 0x254
> > in ..\src\thread\WIN32\ThreadWi=
> > >n32=3D<br>&gt=3B
> > &gt=3B.m3<br>&gt=3B &gt=3B 0xcdfb80 
> > 0x76543677 &lt=3B???=
> > >&gt=3B<br>&gt=3B &gt=3B
> > 0xcdfbc0 0x77779f02 
> > &lt=3B???&gt=3B<br>&gt=3B &gt=
> > >=3B......... ......... ... more frames
> > ...<br>&gt=3B &gt=3B<br>&gt=3B
> > &gt=
> > >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest.exe
> > -he=
> > >lp<br>&gt=3B &gt=3BWriting
> > file...done<br>&gt=3B &gt=3BCreating read
> > thread=
> > >s...done<br>&gt=3B &gt=3BCreating fork
> > threads...done<br>&gt=3B &gt=3BCreat=
> > >ing alloc threads...done<br>&gt=3B
> > &gt=3BCreating lock threads...done<br>&g=
> > >t=3B &gt=3Brunning...printing oldest/median
> > age/newest<br>&gt=3B &gt=3B....=
> > >......laziest thread is 0/0/0 (tests: read 0/0/0 fork
> > 0/0/0 alloc 0/0/0=3D<=
> > >br>&gt=3B &gt=3B lock
> > 0/0/0)<br>&gt=3B &gt=3B..........laziest
> > thread is 0/=
> > >0/0 (tests: read 0/0/0 fork 0/0/0 alloc
> > 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/=
> > >0)<br>&gt=3B &gt=3B..........laziest
> > thread is 0/0/0 (tests: read 0/0/0 for=
> > >k 0/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B
> > lock 0/0/0)<br>&gt=3B &gt=3B.......=
> > >...laziest thread is 0/0/0 (tests: read 0/0/0 fork
> > 0/0/0 alloc 0/0/0=3D<br>=
> > >&gt=3B &gt=3B lock 0/0/0)<br>&gt=3B
> > &gt=3B..........laziest thread is 0/0/0=
> > > (tests: read 0/0/0 fork 0/0/0 alloc
> > 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/0)<=
> > >br>&gt=3B &gt=3B..........laziest thread is
> > 0/0/0 (tests: read 0/0/0 fork 0=
> > >/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock
> > 0/0/0)<br>&gt=3B &gt=3B..........=
> > >laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0
> > alloc 0/0/0=3D<br>&gt=
> > >=3B &gt=3B lock 0/0/0)<br>&gt=3B
> > &gt=3B..........laziest thread is 0/0/0 (t=
> > ests: read 0/0/0 fork 0/0/0 alloc
> > 0/0/0=3D<br>&gt=3B &gt=3B lock
> > 0/0/0)<br>=
> > >&gt=3B &gt=3B..........laziest thread is 0/0/0
> > (tests: read 0/0/0 fork 0/0/=
> > >0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock
> > 0/0/0)<br>&gt=3B &gt=3B..........laz=
> > >iest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0
> > alloc 0/0/0=3D<br>&gt=3B=
> > > &gt=3B lock 0/0/0)<br>&gt=3B
> > &gt=3BAll tests complete. Congratulations.<b=
> > >r>&gt=3B &gt=3B<br>&gt=3B
> > &gt=3BRegards=2C<br>&gt=3B &gt=3BRandy
> > Coleburn<b=
> > >r>&gt=3B &gt=3B<br>&gt=3B
> > &gt=3B-----Original Message-----<br>&gt=3B
> > &gt=3B=
> > >From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20<br>&gt=3B
> > &gt=3BSen=
> > >t: Sunday=2C February 27=2C 2011 3:30
> > PM<br>&gt=3B &gt=3BTo: Coleburn=2C Ra=
> > >ndy<br>&gt=3B &gt=3BCc: m3devel at elegosoft.com<br>&gt=3B
> > &gt=3BSubject: Re: =
> > >[M3devel] results of threadtest program on
> > Windows7=3D20<br>&gt=3B &gt=3B<b=
> > >r>&gt=3B &gt=3BHi
> > Randy=2C<br>&gt=3B &gt=3B<br>&gt=3B
> > &gt=3BYou can try it =
> > >with -tests POSIX as well.<br>&gt=3B
> > &gt=3B<br>&gt=3B &gt=3BI find on user =
> > >threads it runs very slowly (but it does run) because
> > of how=3D<br>&gt=3B &=
> > >gt=3B unfair<br>&gt=3B &gt=3Bthe thread
> > scheduler is.<br>&gt=3B
> > &gt=3B<br>&=
> > >gt=3B &gt=3BNext step might be to whittle down the
> > tests and see if you can=
> > > get a failu=3D<br>&gt=3B &gt=3Bre
> > with<br>&gt=3B &gt=3Ba single test runni=
> > >ng and -n 2. That would likely be the simplest
> > scenario=3D<br>&gt=3B &gt=
> > >=3B to<br>&gt=3B &gt=3Bstart further
> > debugging from.<br>&gt=3B
> > &gt=3B<br>&g=
> > >t=3B &gt=3B 
> > Mika<br>&gt=3B
> > &gt=3B<br>&gt=3B &gt=3B"Coleburn=2C Randy"
> > w=
> > >rites:<br>&gt=3B &gt=3B&gt=3BMika et
> > al:<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &=
> > >gt=3B&gt=3BThought I would try something
> > else.<br>&gt=3B
> > &gt=3B&gt=3B<br>&g=
> > >t=3B &gt=3B&gt=3BI took the sources of your
> > thread test program to an older=
> > > XP machine that=3D<br>&gt=3B &gt=3B
> > =3D3D<br>&gt=3B &gt=3B&gt=3Bhas CM3 ci=
> > >rca August 2008. This is the machine and
> > implementation I used =3D<br>&gt=
> > >=3B &gt=3Bw=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bhen building a major project I did a=
> > > couple years back.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BThe thread=
> > > test program does indeed build on this old system=2C
> > but when I r=3D<br>&g=
> > >t=3B &gt=3Bu=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bn it=2C I get different results tha=
> > >n with the latest HEAD branch code.
> > =3D3D20<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=
> > >=3B &gt=3B&gt=3BAfter it prints
> > "running...printing oldest/median age/newes=
> > >t"=2C on the next=3D<br>&gt=3B &gt=3B
> > =3D3D<br>&gt=3B &gt=3B&gt=3Bline I ge=
> > >t two periods ".." and now the program seems
> > hung. I'll let it "=3D<br>&gt=
> > >=3B &gt=3Br=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bun" for a few more minutes to see if=
> > > anything else happens before killing
> > =3D<br>&gt=3B &gt=3Bi=3D3D<br>&gt=3B
> > =
> > >&gt=3B&gt=3Bt.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BAt least we don=
> > >'t get the subscript and assertion failures on this
> > older C=3D<br>&gt=3B &g=
> > >t=3BM=3D3D<br>&gt=3B &gt=3B&gt=3B3
> > platform.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=
> > >=3B &gt=3B&gt=3BRegards=2C<br>&gt=3B
> > &gt=3B&gt=3BRandy Coleburn<br>&gt=3B
> > &=
> > >gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B-----Original Mess=
> > >age-----<br>&gt=3B &gt=3B&gt=3BFrom:
> > Coleburn=2C Randy=3D3D20<br>&gt=3B &gt=
> > >=3B&gt=3BSent: Sunday=2C February 27=2C 2011 2:09
> > PM<br>&gt=3B &gt=3B&gt=3B=
> > >To: m3devel at elegosoft.com<br>&gt=3B
> > &gt=3B&gt=3BSubject: Re: [M3devel] resu=
> > >lts of threadtest program on
> > Windows7<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=
> > >=3B&gt=3BMika:<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BOk=2C I've upda=
> > >ted to latest HEAD and I've also built Jay's m3sleep
> > program.<br>&gt=3B &gt=
> > >=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BHere is what happens now when I run your
> > th=
> > >readtest program on Windows 7.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
> > >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest
> > -tests =
> > >ALL=2C-fo=3D<br>&gt=3B
> > &gt=3Br=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bk<br>&gt=3B &gt=
> > >=3B&gt=3BWriting file...done<br>&gt=3B
> > &gt=3B&gt=3BCreating read threads...=
> > >done<br>&gt=3B &gt=3B&gt=3BCreating
> > nxread threads...done<br>&gt=3B &gt=3B&=
> > >gt=3BCreating tryexcept
> > threads...done<br>&gt=3B
> > &gt=3B&gt=3BCreating forkt=
> > >oomuch threads...done<br>&gt=3B
> > &gt=3B&gt=3BCreating alloc threads...done<b=
> > >r>&gt=3B &gt=3B&gt=3BCreating creat
> > threads...done<br>&gt=3B &gt=3B&gt=3BCr=
> > >eating lock threads...done<br>&gt=3B
> > &gt=3B&gt=3Brunning...printing oldest/=
> > >median age/newest<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &=
> > >gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B*** runtime error:<br>&gt=3B
> > &gt=3B&gt=
> > >=3B*** An array subscript was out of
> > range.<br>&gt=3B
> > &gt=3B&gt=3B*** =
> > > file "..\src\runtime\common\RTCollector.m3"=2C line
> > 418<br>&gt=3B &gt=3B&g=
> > >t=3B***<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
> > >=3B<br>&gt=3B
> > &gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B*** runtime error:<br>&=
> > >gt=3B &gt=3B&gt=3B*** 
> > &lt=3B*ASSERT*&gt=3B failed.<br>&gt=3B
> > &gt=3B&gt=
> > >=3B*** file
> > "..\src\thread\WIN32\ThreadWin32.m3"=2C line
> > 841<br>&gt=3B &=
> > >gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BThe last error =
> > >repeats ad infinitum until I press CNTRL-C to
> > abort.<br>&gt=3B &gt=3B&gt=3B=
> > ><br>&gt=3B &gt=3B&gt=3BI'll send more
> > info on the Windows install of Modula=
> > >3 in a subsequent post=3D<br>&gt=3B
> > &gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=
> > >=3B &gt=3B&gt=3BRegards=2C<br>&gt=3B
> > &gt=3B&gt=3BRandy Coleburn<br>&gt=3B
> > &=
> > >gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B-----Original
> > Message-----<br>&gt=3B &gt=
> > >=3B&gt=3BFrom: Mika Nystrom [mailto:mika at async.caltech.edu]=3D3D20<br>&gt=
> > >=3B &gt=3B&gt=3BSent: Saturday=2C February
> > 26=2C 2011 12:55 PM<br>&gt=3B &g=
> > >t=3B&gt=3BTo: Coleburn=2C Randy<br>&gt=3B
> > &gt=3B&gt=3BCc: m3devel at elegosoft=
> > >.com<br>&gt=3B &gt=3B&gt=3BSubject:
> > Re: [M3devel] results of threadtest pro=
> > >gram on Windows7=3D3D20<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BHi Ran=
> > >dy=2C<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BHm yes it looks like my =
> > >Windows programming skills leave
> > something<br>&gt=3B &gt=3B&gt=3Bto be
> > desi=
> > >red.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BYou can run the thread te=
> > >ster while skipping a test as
> > follows<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=
> > >=3B&gt=3B threadtest -tests
> > ALL=2C-fork<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B =
> > >&gt=3B&gt=3B(for instance)<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3Bif =
> > >you just run=3D3D20<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B threadt=
> > >est -sadfassdaf<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3Bit'll print th=
> > >e tests that are available.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BAs=
> > > it happens=2C I just had to upgrade my windows 2000
> > system to windows 7.<b=
> > >r>&gt=3B &gt=3B&gt=3BCan you give me a
> > very brief description of what you d=
> > >id to install Modula=3D<br>&gt=3B
> > &gt=3B-=3D3D<br>&gt=3B
> > &gt=3B&gt=3B3<br>&=
> > >gt=3B &gt=3B&gt=3Bon this
> > system?<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=3B&g=
> > >t=3B Mika<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B"Coleburn=2C Ran=
> > >dy" writes:<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B--_000_D67F02DDC62F7545A6B84C285F88=
> > >F3E6EE25C849atlex02srv_<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BContent-Type: text/plai=
> > >n=3B charset=3D3D3D"us-ascii"<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BContent-Transfer-=
> > >Encoding: quoted-printable<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=
> > >=3B&gt=3BMika:<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BI'v=
> > >e finally managed to get cm3 rebuilt on Windows 7
> > again.<br>&gt=3B &gt=3B&g=
> > >t=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BSo=2C I ran your threadtest
> > program.=
> > ><br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BHere are the resu=
> > >lts. Note the "..." is where I cut out a bunch of
> > the r=3D<br>&gt=3B &gt=
> > >=3Be=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Beating=
> > > "ERROR FApply" messages.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=
> > >=3B&gt=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest.e=
> > >xe<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BWriting
> > file...done<br>&gt=3B &gt=3B&gt=3B&g=
> > >t=3BCreating read threads...done<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BCreating fork =
> > >threads...done<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BCreating alloc
> > threads...done<br=
> > >>&gt=3B &gt=3B&gt=3B&gt=3BCreating
> > lock threads...done<br>&gt=3B &gt=3B&gt=
> > >=3B&gt=3Brunning...printing oldest/median
> > age/newest<br>&gt=3B &gt=3B&gt=3B=
> > >&gt=3BERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find=
> > > the f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=
> > >=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OS=
> > >Error.E: ErrorCode=3D3D3D3D2: The system cannot
> > find the f=3D<br>&gt=3B &g=
> > >t=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Be=
> > >cified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E: 
> > ErrorCode=3D3=
> > >D3D3D2: The system cannot find the
> > f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B =
> > >&gt=3B&gt=3B sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=
> > >=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B=
> > >.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B*** runtime e=
> > >rror:<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B*** An
> > enumeration or subrange value w=
> > >as out of range.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B*** file
> > "..\src\Main.m3"=
> > >=2C line 340<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<b=
> > >r>&gt=3B &gt=3B&gt=3B&gt=3Blaziest
> > thread is 0/0/ERROR FApply: OSError.E: =
> > >ErrorCode=3D3D3D3D2: The sy=3D<br>&gt=3B
> > &gt=3Bste=3D3D<br>&gt=3B &gt=3B&gt=
> > >=3Bm c=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Bannot find the file
> > specified.<br=
> > >>&gt=3B &gt=3B&gt=3B&gt=3BERROR
> > FApply: OSError.E: ErrorCode=3D3D3D3D2: Th=
> > >e system cannot find the f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=
> > >=3B sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&g=
> > >t=3BERROR FApply: OSError.E: ErrorCode=3D3D3D3D2:
> > The system cannot find t=
> > >he f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B=
> > >
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSErr=
> > >or.E: ErrorCode=3D3D3D3D2: The system cannot find
> > the f=3D<br>&gt=3B &gt=
> > >=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Bec=
> > >ified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=
> > >=3B &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Blaziest thread is 0/0/E=
> > >RROR FApply: OSError.E: ErrorCode=3D3D3D3D2: The
> > sy=3D<br>&gt=3B &gt=3Bste=
> > >=3D3D<br>&gt=3B &gt=3B&gt=3Bm
> > c=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Bannot fi=
> > >nd the file specified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E:=
> > > ErrorCode=3D3D3D3D2: The system cannot find the
> > f=3D<br>&gt=3B &gt=3Bile=
> > >=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.=
> > ><br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2:=
> > > The system cannot find the f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&=
> > >gt=3B sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B=
> > >&gt=3BERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find=
> > > the f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=
> > >=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=
> > >=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B=
> > >ERROR FApply: OSError.E: ErrorCode=3D3D3D3D2: The
> > system cannot find the f=
> > >=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B &gt=
> > >=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E=
> > >: ErrorCode=3D3D3D3D2: The system cannot find the
> > f=3D<br>&gt=3B &gt=3Bile=
> > >=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.=
> > ><br>&gt=3B
> > &gt=3B&gt=3B&gt=3BStack
> > trace:<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B FP=
> > > PC 
> > Procedure<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B--------- ---------=
> > > 
> > -------------------------------<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B0x30fbd0 0x1=
> > >27218a PutStats + 0x1a3 in
> > ..\src\Main.m3<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B0x30=
> > >fcc0 0x1273825 Main_M3 + 0x11db(!) in
> > ..\src\Main.m3<br>&gt=3B &gt=3B&gt=
> > >=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BRegards=2C<br>&gt=3B
> > &gt=3B&gt=3B&gt=
> > >=3BRandy Coleburn<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B=
> > >--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_<br>&gt=3B
> > &gt=3B=
> > >&gt=3B&gt=3BContent-Type: text/html=3B
> > charset=3D3D3D"us-ascii"<br>&gt=3B &=
> > >gt=3B&gt=3B&gt=3BContent-Transfer-Encoding:
> > quoted-printable<br>&gt=3B &gt=
> > >=3B&gt=3B&gt=3B<br> 
> > 
> > 
> > </body>
> > ></html>=
> > >
> > >--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_--
> > 
> 
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110302/cc086c5c/attachment-0001.html>

From hendrik at topoi.pooq.com  Wed Mar  2 04:39:45 2011
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Tue, 1 Mar 2011 22:39:45 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <20110301181718.12EFC1A2078@async.async.caltech.edu>
References: <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>
	<COL101-W6172E969583BD60401B836E6C10@phx.gbl>
	<20110301181718.12EFC1A2078@async.async.caltech.edu>
Message-ID: <20110302033945.GC32641@topoi.pooq.com>

On Tue, Mar 01, 2011 at 10:17:18AM -0800, Mika Nystrom wrote:
> 
> Hi Jay,
> 
> 2. Not sure how you could get negative timings.  That would suggest that
> Time.Now() is decreasing---which seems contrary to its specification.
> Although the code is doing some nasty stuff with the timings, mainly
> reading and writing them without locks.  But it's using INTEGER for
> the results so I don't think there can be an atomicity problem there.
> Even if there were coherence problems between processors (is this
> technically possible?) the "now" value has to be coherent since it's
> from the thread that prints the results, and the "then" values could
> only be getting older, not newer...

I've been on a machine before on which the clock occasinally ran 
backwards -- notably a CDC Cyber machine.  I don't doubt that OS and 
hardware designers have found ways to replicate this behaviour on moderm 
machines.  :-(

-- hendrik


From jay.krell at cornell.edu  Wed Mar  2 05:49:16 2011
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Mar 2011 04:49:16 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <20110302033945.GC32641@topoi.pooq.com>
References: <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	<COL101-W6172E969583BD60401B836E6C10@phx.gbl>,
	<20110301181718.12EFC1A2078@async.async.caltech.edu>,
	<20110302033945.GC32641@topoi.pooq.com>
Message-ID: <COL101-W4908705893B5758DC5446EE6C00@phx.gbl>


> I've been on a machine before on which the clock occasinally ran 
> backwards -- notably a CDC Cyber machine. I don't doubt that OS and 
> hardware designers have found ways to replicate this behaviour on moderm 
> machines. :-(
> I've been on a machine before on which the clock occasinally ran 
> backwards -- notably a CDC Cyber machine. I don't doubt that OS and 

Come on! Widely used modern systems must be and are very high quality,
not like older and little used systems. The clock is not going backwards.
 
 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110302/3f0e8a9c/attachment-0001.html>

From hosking at cs.purdue.edu  Wed Mar  2 15:11:55 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 2 Mar 2011 09:11:55 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W3670B74A99994199607C6BE6C00@phx.gbl>
References: <20110301181718.12EFC1A2078@async.async.caltech.edu>,
	<452042.5906.qm@web29706.mail.ird.yahoo.com>
	<COL101-W3670B74A99994199607C6BE6C00@phx.gbl>
Message-ID: <D8168970-37FE-43C9-8127-BE5024AD43E0@cs.purdue.edu>

'Twould be useful to see a stack dump.

On Mar 1, 2011, at 10:11 PM, Jay K wrote:

> Most of the runs error or succeed within 10 minutes. The one Solaris/sparc run I made ran for well over 4 hours and didn't get very far. I'd say it was hung forever.
>  
>  
> I didn't debug it.
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110302/3228a606/attachment-0001.html>

From dabenavidesd at yahoo.es  Wed Mar  2 22:31:41 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 2 Mar 2011 21:31:41 +0000 (GMT)
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W3670B74A99994199607C6BE6C00@phx.gbl>
Message-ID: <571065.83147.qm@web29715.mail.ird.yahoo.com>

Hi all:
yes, but technically you could insert some empty chips slots on the same wafer but in cases of blade systems I'm sure you can, just don't know how much about something like plug-and-play with that.
Thanks in advance

--- El mar, 1/3/11, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: RE: [M3devel] results of threadtest program on Windows7
Para: dabenavidesd at yahoo.es, "Mika Nystrom" <mika at async.caltech.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: martes, 1 de marzo, 2011 22:11




I have still have mostly uniprocessors (though busy selling stuff off...)

? I do have a MacBook Pro and Dell laptop with 2 processors each though.

? It is that MacBook Pro where I can consistently get Darwin to fail, and a?1 and 2 proc Windows virtual machine on the MacBook Pro?that consistently works.

? While Modula-3 user threads never run anything truly concurrently, i.e. on multiple prcoessors, there should still be almost arbitrary preemption.

?

?

I'm skeptical of?any emulation's or virtualization's ability to simulate more processors than underlying physical processors.

?

?

Most of the runs error or succeed within 10 minutes. The one Solaris/sparc run I made ran for well over 4 hours and didn't get very far. I'd say it was hung forever.

?

?

I didn't debug it.

?

?

Yes, OpenBSD pthreads are user threads and therefore probably only ever use one processor.

But that machine only has one. :)


?

I think this will quite difficult to track down.

It might be useful to find an old starting point that succeeds and upgrade forward looking for when things fail.

That is tedious and has its own set of difficulties, granted.

?There are many points in time that don't compile, many are my fault, and there are also many combinations of starting/ending points that don't compile due to some mismatches between start/end.

?

?

I have to try Linux and/or FreeBSD still.

?

?

The errors on Darwin imply to me that memory is being prematurely reclaimed by the garbage collector -- e.g. EBUSY from pthread_mutex_destroy.

But it could also be arbitrary memory corruption (sort of the same thing), same example, but rather than an actually busy mutex, it could be a corrupted mutex or random pointer. Some of that might be easy to track down, e.g. by tracing which addresses are initialized as mutexes, and maybe by putting pad bytes around mutexes and seeing if they get changed.

I'm reluctant to try draw any conclusions yet though, since I have very very little information/knowledge.

?

?

I also forgot to check if I was using any optimization. I'll be sure to not.

?

?

?- Jay


?

> Date: Tue, 1 Mar 2011 22:10:55 +0000
> From: dabenavidesd at yahoo.es
> To: jay.krell at cornell.edu; mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Hi all:
> but you could still run a *nix image with uniprocessor support kernel and try on the vbox, qemu, etc.
> Perhaps you would get enough simulation to detect that the problem is on the hardware layer (either physically or its abstraction) rather than the execution model (the pthreads scheduling policy), if it does no work may be there is a problem in ThreadPthread implementation of pthreads (don't need to switch its default is - smp 1).
> commands i.e in qemu:
> qemu -cdrom /path/to/system.iso -smp 2 
> and run threadtest from there
> 
> Thanks in advance
> 
> 
> 
> 
> 
> 
> --- El mar, 1/3/11, Mika Nystrom <mika at async.caltech.edu> escribi?:
> 
> > De: Mika Nystrom <mika at async.caltech.edu>
> > Asunto: Re: [M3devel] results of threadtest program on Windows7
> > Para: "Jay K" <jay.krell at cornell.edu>
> > CC: m3devel at elegosoft.com
> > Fecha: martes, 1 de marzo, 2011 13:17
> > 
> > Hi Jay,
> > 
> > 1. I think you should get forward progress no matter what,
> > although it
> > might be very slow on some systems.
> > 
> > 2. Not sure how you could get negative timings. That
> > would suggest that
> > Time.Now() is decreasing---which seems contrary to its
> > specification.
> > Although the code is doing some nasty stuff with the
> > timings, mainly
> > reading and writing them without locks. But it's
> > using INTEGER for
> > the results so I don't think there can be an atomicity
> > problem there.
> > Even if there were coherence problems between processors
> > (is this
> > technically possible?) the "now" value has to be coherent
> > since it's
> > from the thread that prints the results, and the "then"
> > values could
> > only be getting older, not newer...
> > 
> > 3. Note that there are systems (FreeBSD 4 is an example)
> > that have a
> > "pthreads" library but where the pthreads library is
> > implemented with
> > user threads. Could that be related to why OpenBSD is
> > working?
> > 
> > 4. Hm. I think I am only using multiprocessor
> > systems, yes. Hard to
> > find single-CPU systems nowadays! I think actually
> > the only one I have
> > is PPC_DARWIN, and I haven't tried the code on that. 
> > So yes this is a
> > possibility as far as explaining differences...
> > 
> > Mika
> > 
> > Jay K writes:
> > >--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_
> > >Content-Type: text/plain; charset="iso-8859-1"
> > >Content-Transfer-Encoding: quoted-printable
> > >
> > >
> > >I also haven't seen it fail on OpenBSD/x86/4.7. I'm
> > pretty sure using pthre=
> > >ads there.
> > >But on Solaris/5.10/sparc it hangs=2C for many hours.
> > >
> > >-bash-4.1$ ./threadtest=20
> > >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
> > >.
> > >
> > >Are we guranteed forward progress in suspending all
> > threads?
> > >
> > >I do see it fail usually on Darwin. e.g.:
> > >........pthread_mutex_destroy:EBUSY
> > >pthread_mutex_destroy:EBUSY
> > >..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:
> > >*** An array subscript was out of range.
> > >*** file
> > "../src/runtime/common/RTCollector.m3"=2C line 418
> > >***
> > >
> > >I haven't tried Linux yet.
> > >Do note that we have some variance in the pthreads
> > implementation.
> > >The "portable" implementation is used on Linux=2C
> > Solaris=2C NetBSD.
> > >And then OpenBSD=2C Darwin=2C FreeBSD each have slight
> > differences.
> > >
> > >Mika are your machines all multiprocessors?
> > >I do wonder if that helps increase the stress and if I
> > should be sure to us=
> > >e multiprocessors.
> > >
> > >I'm also considering taking the time to try various
> > historical versions=2C =
> > >either releases or dates in CVS.
> > >
> > > - Jay
> > >
> > >From: jay.krell at cornell.edu
> > >To: mika at async.caltech.edu=3B
> > rcolebur at scires.com
> > >Date: Tue=2C 1 Mar 2011 10:59:29 +0000
> > >CC: m3devel at elegosoft.com
> > >Subject: Re: [M3devel] results of threadtest program on
> > Windows7
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >I haven't seen it fail on NT=2C except for PutCard in
> > the test itself getti=
> > >ng negative numbers.
> > >I've run it just a few times now. One single and dual
> > processor virtual mac=
> > >hines.
> > >Randy=2C has it failed many times for you?
> > >
> > > - Jay
> > >
> > >> To: rcolebur at SCIRES.COM
> > >> Date: Sun=2C 27 Feb 2011 15:11:25 -0800
> > >> From: mika at async.caltech.edu
> > >> CC: m3devel at elegosoft.com
> > >> Subject: Re: [M3devel] results of threadtest
> > program on Windows7
> > >>=20
> > >> Ah=2C it just doesn't check command-line arguments
> > that carefully.
> > >>=20
> > >> I think what you did is equivalent to "-tests
> > STD".
> > >=20
> > >> Mika
> > >>=20
> > >> "Coleburn=2C Randy" writes:
> > >> >Mika:
> > >> >
> > >> >No change with "-tests POSIX".
> > >> >
> > >> >Interesting twist: On Windows 7=2C I
> > thought I'd see what the command l=
> > >ine o=3D
> > >> >ptions are=2C and I typed "threadtest -help"
> > rather than reading the cod=
> > >e.
> > >> >
> > >> >First time=2C it produced what appears to be a
> > NIL deref crash. Then=2C=
> > > I trie=3D
> > >> >d it again and it ran to completion. 
> > Something seems non-deterministic =
> > >her=3D
> > >> >e. See below.
> > >> >
> > >>
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > -help
> > >> >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
> > >> >.
> > >> >
> > >> >***
> > >> >*** runtime error:
> > >> >*** Attempt to reference an
> > illegal memory location.
> > >> >*** pc =3D3D 0x77762262
> > >> >***
> > >> >
> > >> >Stack trace:
> > >> > FP 
> > PC Procedure
> > >> >--------- --------- 
> > -------------------------------
> > >> > 0xcdf998 0x130351b SystemError +
> > 0x64 in ..\src\runtime\NT386\RTSigna=
> > >l.m=3D
> > >> >3
> > >> > 0xcdf9c0 0x77762262 <???>
> > >> > 0xcdf9d8 0x12e83b7 LockMutex +
> > 0x4f in ..\src\thread\WIN32\ThreadWin3=
> > >2.m=3D
> > >> >3
> > >> > 0xcdfa00 0x12c7b08 GetChar + 0x28
> > in ..\src\rw\Rd.m3
> > >> > 0xcdfb38 0x12c12e3 RApply + 0xd3
> > in ..\src\Main.m3
> > >> > 0xcdfb74 0x12e971f ThreadBase +
> > 0x254 in ..\src\thread\WIN32\ThreadWi=
> > >n32=3D
> > >> >.m3
> > >> > 0xcdfb80 0x76543677 <???>
> > >> > 0xcdfbc0 0x77779f02 <???>
> > >> >......... ......... ... more
> > frames ...
> > >> >
> > >>
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > -help
> > >> >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
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >All tests complete. Congratulations.
> > >> >
> > >> >Regards=2C
> > >> >Randy Coleburn
> > >> >
> > >> >-----Original Message-----
> > >> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> > >> >Sent: Sunday=2C February 27=2C 2011 3:30 PM
> > >> >To: Coleburn=2C Randy
> > >> >Cc: m3devel at elegosoft.com
> > >> >Subject: Re: [M3devel] results of threadtest
> > program on Windows7=3D20
> > >> >
> > >> >Hi Randy=2C
> > >> >
> > >> >You can try it with -tests POSIX as well.
> > >> >
> > >> >I find on user threads it runs very slowly
> > (but it does run) because of =
> > >how=3D
> > >> > unfair
> > >> >the thread scheduler is.
> > >> >
> > >> >Next step might be to whittle down the tests
> > and see if you can get a fa=
> > >ilu=3D
> > >> >re with
> > >> >a single test running and -n 2. That
> > would likely be the simplest scena=
> > >rio=3D
> > >> > to
> > >> >start further debugging from.
> > >> >
> > >> > Mika
> > >> >
> > >> >"Coleburn=2C Randy" writes:
> > >> >>Mika et al:
> > >> >>
> > >> >>Thought I would try something else.
> > >> >>
> > >> >>I took the sources of your thread test
> > program to an older XP machine t=
> > >hat=3D
> > >> > =3D3D
> > >> >>has CM3 circa August 2008. This is
> > the machine and implementation I us=
> > >ed =3D
> > >> >w=3D3D
> > >> >>hen building a major project I did a
> > couple years back.
> > >> >>
> > >> >>The thread test program does indeed build
> > on this old system=2C but whe=
> > >n I r=3D
> > >> >u=3D3D
> > >> >>n it=2C I get different results than with
> > the latest HEAD branch code. =
> > >=3D3D20
> > >> >>
> > >> >>After it prints "running...printing
> > oldest/median age/newest"=2C on the=
> > > next=3D
> > >> > =3D3D
> > >> >>line I get two periods ".." and now the
> > program seems hung. I'll let i=
> > >t "=3D
> > >> >r=3D3D
> > >> >>un" for a few more minutes to see if
> > anything else happens before killi=
> > >ng =3D
> > >> >i=3D3D
> > >> >>t.
> > >> >>
> > >> >>At least we don't get the subscript and
> > assertion failures on this olde=
> > >r C=3D
> > >> >M=3D3D
> > >> >>3 platform.
> > >> >>
> > >> >>Regards=2C
> > >> >>Randy Coleburn
> > >> >>
> > >> >>
> > >> >>-----Original Message-----
> > >> >>From: Coleburn=2C Randy=3D3D20
> > >> >>Sent: Sunday=2C February 27=2C 2011 2:09
> > PM
> > >> >>To: m3devel at elegosoft.com
> > >> >>Subject: Re: [M3devel] results of
> > threadtest program on Windows7
> > >> >>
> > >> >>Mika:
> > >> >>
> > >> >>Ok=2C I've updated to latest HEAD and I've
> > also built Jay's m3sleep pro=
> > >gram.
> > >> >>
> > >> >>Here is what happens now when I run your
> > threadtest program on Windows =
> > >7.
> > >> >>
> > >>
> > >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest
> > -tests ALL=
> > >=2C-fo=3D
> > >> >r=3D3D
> > >> >>k
> > >> >>Writing file...done
> > >> >>Creating read threads...done
> > >> >>Creating nxread threads...done
> > >> >>Creating tryexcept threads...done
> > >> >>Creating forktoomuch threads...done
> > >> >>Creating alloc threads...done
> > >> >>Creating creat threads...done
> > >> >>Creating lock threads...done
> > >> >>running...printing oldest/median
> > age/newest
> > >> >>
> > >> >>
> > >> >>***
> > >> >>*** runtime error:
> > >> >>*** An array subscript was
> > out of range.
> > >> >>*** file
> > "..\src\runtime\common\RTCollector.m3"=2C line 418
> > >> >>***
> > >> >>
> > >> >>
> > >> >>
> > >> >>***
> > >> >>*** runtime error:
> > >> >>*** <*ASSERT*> failed.
> > >> >>*** file
> > "..\src\thread\WIN32\ThreadWin32.m3"=2C line 841
> > >> >>***
> > >> >>
> > >> >>The last error repeats ad infinitum until
> > I press CNTRL-C to abort.
> > >> >>
> > >> >>I'll send more info on the Windows install
> > of Modula3 in a subsequent p=
> > >ost=3D
> > >> >.
> > >> >>
> > >> >>Regards=2C
> > >> >>Randy Coleburn
> > >> >>
> > >> >>-----Original Message-----
> > >> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D3D20
> > >> >>Sent: Saturday=2C February 26=2C 2011
> > 12:55 PM
> > >> >>To: Coleburn=2C Randy
> > >> >>Cc: m3devel at elegosoft.com
> > >> >>Subject: Re: [M3devel] results of
> > threadtest program on Windows7=3D3D20
> > >> >>
> > >> >>Hi Randy=2C
> > >> >>
> > >> >>Hm yes it looks like my Windows
> > programming skills leave something
> > >> >>to be desired.
> > >> >>
> > >> >>You can run the thread tester while
> > skipping a test as follows
> > >> >>
> > >> >> threadtest -tests
> > ALL=2C-fork
> > >> >>
> > >> >>(for instance)
> > >> >>
> > >> >>if you just run=3D3D20
> > >> >>
> > >> >> threadtest -sadfassdaf
> > >> >>
> > >> >>it'll print the tests that are available.
> > >> >>
> > >> >>As it happens=2C I just had to upgrade my
> > windows 2000 system to window=
> > >s 7.
> > >> >>Can you give me a very brief description
> > of what you did to install Mod=
> > >ula=3D
> > >> >-=3D3D
> > >> >>3
> > >> >>on this system?
> > >> >>
> > >> >> Mika
> > >> >>
> > >> >>"Coleburn=2C Randy" writes:
> > >>
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >> >>>Content-Type: text/plain=3B
> > charset=3D3D3D"us-ascii"
> > >> >>>Content-Transfer-Encoding:
> > quoted-printable
> > >> >>>
> > >> >>>Mika:
> > >> >>>
> > >> >>>I've finally managed to get cm3
> > rebuilt on Windows 7 again.
> > >> >>>
> > >> >>>So=2C I ran your threadtest program.
> > >> >>>
> > >> >>>Here are the results. Note the
> > "..." is where I cut out a bunch of th=
> > >e r=3D
> > >> >e=3D3D
> > >> >>p=3D3D3D
> > >> >>>eating "ERROR FApply" messages.
> > >> >>>
> > >>
> > >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > >> >>>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
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>.
> > >> >>>.
> > >> >>>.
> > >> >>>***
> > >> >>>*** runtime error:
> > >> >>>*** An enumeration or
> > subrange value was out of range.
> > >> >>>*** file
> > "..\src\Main.m3"=2C line 340
> > >> >>>***
> > >> >>>
> > >> >>>laziest thread is 0/0/ERROR FApply:
> > OSError.E: ErrorCode=3D3D3D3D2: T=
> > >he sy=3D
> > >> >ste=3D3D
> > >> >>m c=3D3D3D
> > >> >>>annot find the file specified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>.
> > >> >>>.
> > >> >>>.
> > >> >>>laziest thread is 0/0/ERROR FApply:
> > OSError.E: ErrorCode=3D3D3D3D2: T=
> > >he sy=3D
> > >> >ste=3D3D
> > >> >>m c=3D3D3D
> > >> >>>annot find the file specified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>.
> > >> >>>.
> > >> >>>.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>Stack trace:
> > >> >>> FP 
> > PC Procedure
> > >> >>>--------- --------- 
> > -------------------------------
> > >> >>>0x30fbd0 0x127218a 
> > PutStats + 0x1a3 in ..\src\Main.m3
> > >> >>>0x30fcc0 0x1273825 Main_M3
> > + 0x11db(!) in ..\src\Main.m3
> > >> >>>
> > >> >>>Regards=2C
> > >> >>>Randy Coleburn
> > >> >>>
> > >>
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >> >>>Content-Type: text/html=3B
> > charset=3D3D3D"us-ascii"
> > >> >>>Content-Transfer-Encoding:
> > quoted-printable
> > >> >>>
> > > 
> > 
> > 
> > =
> > >
> > >--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_
> > >Content-Type: text/html; charset="iso-8859-1"
> > >Content-Transfer-Encoding: quoted-printable
> > >
> > ><html>
> > ><head>
> > ><style><!--
> > >.hmmessage P
> > >{
> > >margin:0px=3B
> > >padding:0px
> > >}
> > >body.hmmessage
> > >{
> > >font-size: 10pt=3B
> > >font-family:Tahoma
> > >}
> > >--></style>
> > ></head>
> > ><body class=3D'hmmessage'>
> > >I also haven't seen it fail on OpenBSD/x86/4.7. I'm
> > pretty sure using pthre=
> > >ads there.<br>But on Solaris/5.10/sparc it
> > hangs=2C for many hours.<br><br>=
> > >-bash-4.1$ ./threadtest <br>Writing
> > file...done<br>Creating read threads...=
> > >done<br>Creating fork
> > threads...done<br>Creating alloc
> > threads...done<br>Cr=
> > >eating lock threads...done<br>running...printing
> > oldest/median age/newest<b=
> > >r>.<br><br>Are we guranteed forward
> > progress in suspending all threads?<br>=
> > ><br>I do see it fail usually on Darwin.
> > e.g.:<br>........pthread_mutex_dest=
> > >roy:EBUSY<br>pthread_mutex_destroy:EBUSY<br>..laziest
> > thread is 0/0/0 (test=
> > >s: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock
> > 0/0/0)<br>...<br><br>***<br>*** r=
> > >untime
> > error:<br>***&nbsp=3B&nbsp=3B&nbsp=3B An
> > array subscript was out of =
> > >range.<br>***&nbsp=3B&nbsp=3B&nbsp=3B
> > file "../src/runtime/common/RTCollect=
> > >or.m3"=2C line 418<br>***<br><br>I
> > haven't tried Linux yet.<br>Do note that=
> > > we have some variance in the pthreads
> > implementation.<br>The "portable" im=
> > >plementation is used on Linux=2C Solaris=2C
> > NetBSD.<br>And then OpenBSD=2C =
> > >Darwin=2C FreeBSD each have slight
> > differences.<br><br>Mika are your machin=
> > >es all multiprocessors?<br>I do wonder if that
> > helps increase the stress an=
> > >d if I should be sure to use
> > multiprocessors.<br><br>I'm also considering t=
> > >aking the time to try various historical versions=2C
> > either releases or dat=
> > >es in CVS.<br><br>&nbsp=3B-
> > Jay<br><br><hr id=3D"stopSpelling">From:
> > jay.kr=
> > >ell at cornell.edu<br>To:
> > mika at async.caltech.edu=3B
> > rcolebur at scires.com<br>Dat=
> > >e: Tue=2C 1 Mar 2011 10:59:29 +0000<br>CC: m3devel at elegosoft.com<br>Subject=
> > >: Re: [M3devel] results of threadtest program on
> > Windows7<br><br>
> > >
> > ><meta http-equiv=3D"Content-Type"
> > content=3D"text/html=3B charset=3Dunicode=
> > >">
> > ><meta name=3D"Generator" content=3D"Microsoft
> > SafeHTML">
> > ><style>
> > >.ExternalClass .ecxhmmessage P
> > >{padding:0px=3B}
> > >.ExternalClass body.ecxhmmessage
> > >{font-size:10pt=3Bfont-family:Tahoma=3B}
> > >
> > ></style>
> > >
> > >
> > >I haven't seen it fail on NT=2C except for PutCard in
> > the test itself getti=
> > >ng negative numbers.<br>I've run it just a few
> > times now. One single and du=
> > >al processor virtual machines.<br>Randy=2C has it
> > failed many times for you=
> > >?<br><br>&nbsp=3B-
> > Jay<br><br>&gt=3B To: rcolebur at SCIRES.COM<br>&gt=3B
> > Date=
> > >: Sun=2C 27 Feb 2011 15:11:25 -0800<br>&gt=3B
> > From: mika at async.caltech.edu<=
> > >br>&gt=3B CC: m3devel at elegosoft.com<br>&gt=3B
> > Subject: Re: [M3devel] result=
> > >s of threadtest program on Windows7<br>&gt=3B
> > <br>&gt=3B Ah=2C it just does=
> > >n't check command-line arguments that
> > carefully.<br>&gt=3B <br>&gt=3B I thi=
> > >nk what you did is equivalent to "-tests
> > STD".<br>&gt=3B <br>&gt=3B 
> > Mi=
> > >ka<br>&gt=3B <br>&gt=3B
> > "Coleburn=2C Randy" writes:<br>&gt=3B
> > &gt=3BMika:<b=
> > >r>&gt=3B &gt=3B<br>&gt=3B
> > &gt=3BNo change with "-tests POSIX".<br>&gt=3B
> > &g=
> > >t=3B<br>&gt=3B &gt=3BInteresting
> > twist: On Windows 7=2C I thought I'd see =
> > >what the command line o=3D<br>&gt=3B
> > &gt=3Bptions are=2C and I typed "threa=
> > >dtest -help" rather than reading the
> > code.<br>&gt=3B &gt=3B<br>&gt=3B
> > &gt=
> > >=3BFirst time=2C it produced what appears to be a NIL
> > deref crash. Then=2C=
> > > I trie=3D<br>&gt=3B &gt=3Bd it again and
> > it ran to completion. Something =
> > >seems non-deterministic her=3D<br>&gt=3B
> > &gt=3Be. See below.<br>&gt=3B &gt=
> > >=3B<br>&gt=3B
> > &gt=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bt=
> > >hreadtest.exe -help<br>&gt=3B
> > &gt=3BWriting file...done<br>&gt=3B
> > &gt=3BCre=
> > >ating read threads...done<br>&gt=3B
> > &gt=3BCreating fork threads...done<br>&=
> > >gt=3B &gt=3BCreating alloc
> > threads...done<br>&gt=3B &gt=3BCreating lock
> > thr=
> > >eads...done<br>&gt=3B
> > &gt=3Brunning...printing oldest/median
> > age/newest<br>=
> > >&gt=3B &gt=3B.<br>&gt=3B
> > &gt=3B<br>&gt=3B
> > &gt=3B***<br>&gt=3B &gt=3B*** run=
> > >time error:<br>&gt=3B &gt=3B*** 
> > Attempt to reference an illegal memory l=
> > >ocation.<br>&gt=3B &gt=3B*** 
> > pc =3D3D 0x77762262<br>&gt=3B
> > &gt=3B***<br>=
> > >&gt=3B &gt=3B<br>&gt=3B
> > &gt=3BStack trace:<br>&gt=3B
> > &gt=3B FP 
> > PC=
> > > Procedure<br>&gt=3B
> > &gt=3B--------- --------- 
> > ---------------------=
> > >----------<br>&gt=3B &gt=3B
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\s=
> > >rc\runtime\NT386\RTSignal.m=3D<br>&gt=3B
> > &gt=3B3<br>&gt=3B &gt=3B 0xcdf9c0 =
> > > 0x77762262 
> > &lt=3B???&gt=3B<br>&gt=3B &gt=3B
> > 0xcdf9d8 0x12e83b7 LockMute=
> > >x + 0x4f in
> > ..\src\thread\WIN32\ThreadWin32.m=3D<br>&gt=3B
> > &gt=3B3<br>&gt=
> > >=3B &gt=3B 0xcdfa00 0x12c7b08 GetChar +
> > 0x28 in ..\src\rw\Rd.m3<br>&gt=3B=
> > > &gt=3B 0xcdfb38 0x12c12e3 RApply +
> > 0xd3 in ..\src\Main.m3<br>&gt=3B &gt=
> > >=3B 0xcdfb74 0x12e971f ThreadBase + 0x254
> > in ..\src\thread\WIN32\ThreadWi=
> > >n32=3D<br>&gt=3B
> > &gt=3B.m3<br>&gt=3B &gt=3B 0xcdfb80 
> > 0x76543677 &lt=3B???=
> > >&gt=3B<br>&gt=3B &gt=3B
> > 0xcdfbc0 0x77779f02 
> > &lt=3B???&gt=3B<br>&gt=3B &gt=
> > >=3B......... ......... ... more frames
> > ...<br>&gt=3B &gt=3B<br>&gt=3B
> > &gt=
> > >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest.exe
> > -he=
> > >lp<br>&gt=3B &gt=3BWriting
> > file...done<br>&gt=3B &gt=3BCreating read
> > thread=
> > >s...done<br>&gt=3B &gt=3BCreating fork
> > threads...done<br>&gt=3B &gt=3BCreat=
> > >ing alloc threads...done<br>&gt=3B
> > &gt=3BCreating lock threads...done<br>&g=
> > >t=3B &gt=3Brunning...printing oldest/median
> > age/newest<br>&gt=3B &gt=3B....=
> > >......laziest thread is 0/0/0 (tests: read 0/0/0 fork
> > 0/0/0 alloc 0/0/0=3D<=
> > >br>&gt=3B &gt=3B lock
> > 0/0/0)<br>&gt=3B &gt=3B..........laziest
> > thread is 0/=
> > >0/0 (tests: read 0/0/0 fork 0/0/0 alloc
> > 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/=
> > >0)<br>&gt=3B &gt=3B..........laziest
> > thread is 0/0/0 (tests: read 0/0/0 for=
> > >k 0/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B
> > lock 0/0/0)<br>&gt=3B &gt=3B.......=
> > >...laziest thread is 0/0/0 (tests: read 0/0/0 fork
> > 0/0/0 alloc 0/0/0=3D<br>=
> > >&gt=3B &gt=3B lock 0/0/0)<br>&gt=3B
> > &gt=3B..........laziest thread is 0/0/0=
> > > (tests: read 0/0/0 fork 0/0/0 alloc
> > 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/0)<=
> > >br>&gt=3B &gt=3B..........laziest thread is
> > 0/0/0 (tests: read 0/0/0 fork 0=
> > >/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock
> > 0/0/0)<br>&gt=3B &gt=3B..........=
> > >laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0
> > alloc 0/0/0=3D<br>&gt=
> > >=3B &gt=3B lock 0/0/0)<br>&gt=3B
> > &gt=3B..........laziest thread is 0/0/0 (t=
> > ests: read 0/0/0 fork 0/0/0 alloc
> > 0/0/0=3D<br>&gt=3B &gt=3B lock
> > 0/0/0)<br>=
> > >&gt=3B &gt=3B..........laziest thread is 0/0/0
> > (tests: read 0/0/0 fork 0/0/=
> > >0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock
> > 0/0/0)<br>&gt=3B &gt=3B..........laz=
> > >iest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0
> > alloc 0/0/0=3D<br>&gt=3B=
> > > &gt=3B lock 0/0/0)<br>&gt=3B
> > &gt=3BAll tests complete. Congratulations.<b=
> > >r>&gt=3B &gt=3B<br>&gt=3B
> > &gt=3BRegards=2C<br>&gt=3B &gt=3BRandy
> > Coleburn<b=
> > >r>&gt=3B &gt=3B<br>&gt=3B
> > &gt=3B-----Original Message-----<br>&gt=3B
> > &gt=3B=
> > >From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20<br>&gt=3B
> > &gt=3BSen=
> > >t: Sunday=2C February 27=2C 2011 3:30
> > PM<br>&gt=3B &gt=3BTo: Coleburn=2C Ra=
> > >ndy<br>&gt=3B &gt=3BCc: m3devel at elegosoft.com<br>&gt=3B
> > &gt=3BSubject: Re: =
> > >[M3devel] results of threadtest program on
> > Windows7=3D20<br>&gt=3B &gt=3B<b=
> > >r>&gt=3B &gt=3BHi
> > Randy=2C<br>&gt=3B &gt=3B<br>&gt=3B
> > &gt=3BYou can try it =
> > >with -tests POSIX as well.<br>&gt=3B
> > &gt=3B<br>&gt=3B &gt=3BI find on user =
> > >threads it runs very slowly (but it does run) because
> > of how=3D<br>&gt=3B &=
> > >gt=3B unfair<br>&gt=3B &gt=3Bthe thread
> > scheduler is.<br>&gt=3B
> > &gt=3B<br>&=
> > >gt=3B &gt=3BNext step might be to whittle down the
> > tests and see if you can=
> > > get a failu=3D<br>&gt=3B &gt=3Bre
> > with<br>&gt=3B &gt=3Ba single test runni=
> > >ng and -n 2. That would likely be the simplest
> > scenario=3D<br>&gt=3B &gt=
> > >=3B to<br>&gt=3B &gt=3Bstart further
> > debugging from.<br>&gt=3B
> > &gt=3B<br>&g=
> > >t=3B &gt=3B 
> > Mika<br>&gt=3B
> > &gt=3B<br>&gt=3B &gt=3B"Coleburn=2C Randy"
> > w=
> > >rites:<br>&gt=3B &gt=3B&gt=3BMika et
> > al:<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &=
> > >gt=3B&gt=3BThought I would try something
> > else.<br>&gt=3B
> > &gt=3B&gt=3B<br>&g=
> > >t=3B &gt=3B&gt=3BI took the sources of your
> > thread test program to an older=
> > > XP machine that=3D<br>&gt=3B &gt=3B
> > =3D3D<br>&gt=3B &gt=3B&gt=3Bhas CM3 ci=
> > >rca August 2008. This is the machine and
> > implementation I used =3D<br>&gt=
> > >=3B &gt=3Bw=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bhen building a major project I did a=
> > > couple years back.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BThe thread=
> > > test program does indeed build on this old system=2C
> > but when I r=3D<br>&g=
> > >t=3B &gt=3Bu=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bn it=2C I get different results tha=
> > >n with the latest HEAD branch code.
> > =3D3D20<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=
> > >=3B &gt=3B&gt=3BAfter it prints
> > "running...printing oldest/median age/newes=
> > >t"=2C on the next=3D<br>&gt=3B &gt=3B
> > =3D3D<br>&gt=3B &gt=3B&gt=3Bline I ge=
> > >t two periods ".." and now the program seems
> > hung. I'll let it "=3D<br>&gt=
> > >=3B &gt=3Br=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bun" for a few more minutes to see if=
> > > anything else happens before killing
> > =3D<br>&gt=3B &gt=3Bi=3D3D<br>&gt=3B
> > =
> > >&gt=3B&gt=3Bt.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BAt least we don=
> > >'t get the subscript and assertion failures on this
> > older C=3D<br>&gt=3B &g=
> > >t=3BM=3D3D<br>&gt=3B &gt=3B&gt=3B3
> > platform.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=
> > >=3B &gt=3B&gt=3BRegards=2C<br>&gt=3B
> > &gt=3B&gt=3BRandy Coleburn<br>&gt=3B
> > &=
> > >gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B-----Original Mess=
> > >age-----<br>&gt=3B &gt=3B&gt=3BFrom:
> > Coleburn=2C Randy=3D3D20<br>&gt=3B &gt=
> > >=3B&gt=3BSent: Sunday=2C February 27=2C 2011 2:09
> > PM<br>&gt=3B &gt=3B&gt=3B=
> > >To: m3devel at elegosoft.com<br>&gt=3B
> > &gt=3B&gt=3BSubject: Re: [M3devel] resu=
> > >lts of threadtest program on
> > Windows7<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=
> > >=3B&gt=3BMika:<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BOk=2C I've upda=
> > >ted to latest HEAD and I've also built Jay's m3sleep
> > program.<br>&gt=3B &gt=
> > >=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BHere is what happens now when I run your
> > th=
> > >readtest program on Windows 7.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
> > >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest
> > -tests =
> > >ALL=2C-fo=3D<br>&gt=3B
> > &gt=3Br=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bk<br>&gt=3B &gt=
> > >=3B&gt=3BWriting file...done<br>&gt=3B
> > &gt=3B&gt=3BCreating read threads...=
> > >done<br>&gt=3B &gt=3B&gt=3BCreating
> > nxread threads...done<br>&gt=3B &gt=3B&=
> > >gt=3BCreating tryexcept
> > threads...done<br>&gt=3B
> > &gt=3B&gt=3BCreating forkt=
> > >oomuch threads...done<br>&gt=3B
> > &gt=3B&gt=3BCreating alloc threads...done<b=
> > >r>&gt=3B &gt=3B&gt=3BCreating creat
> > threads...done<br>&gt=3B &gt=3B&gt=3BCr=
> > >eating lock threads...done<br>&gt=3B
> > &gt=3B&gt=3Brunning...printing oldest/=
> > >median age/newest<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &=
> > >gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B*** runtime error:<br>&gt=3B
> > &gt=3B&gt=
> > >=3B*** An array subscript was out of
> > range.<br>&gt=3B
> > &gt=3B&gt=3B*** =
> > > file "..\src\runtime\common\RTCollector.m3"=2C line
> > 418<br>&gt=3B &gt=3B&g=
> > >t=3B***<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
> > >=3B<br>&gt=3B
> > &gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B*** runtime error:<br>&=
> > >gt=3B &gt=3B&gt=3B*** 
> > &lt=3B*ASSERT*&gt=3B failed.<br>&gt=3B
> > &gt=3B&gt=
> > >=3B*** file
> > "..\src\thread\WIN32\ThreadWin32.m3"=2C line
> > 841<br>&gt=3B &=
> > >gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BThe last error =
> > >repeats ad infinitum until I press CNTRL-C to
> > abort.<br>&gt=3B &gt=3B&gt=3B=
> > ><br>&gt=3B &gt=3B&gt=3BI'll send more
> > info on the Windows install of Modula=
> > >3 in a subsequent post=3D<br>&gt=3B
> > &gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=
> > >=3B &gt=3B&gt=3BRegards=2C<br>&gt=3B
> > &gt=3B&gt=3BRandy Coleburn<br>&gt=3B
> > &=
> > >gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B-----Original
> > Message-----<br>&gt=3B &gt=
> > >=3B&gt=3BFrom: Mika Nystrom [mailto:mika at async.caltech.edu]=3D3D20<br>&gt=
> > >=3B &gt=3B&gt=3BSent: Saturday=2C February
> > 26=2C 2011 12:55 PM<br>&gt=3B &g=
> > >t=3B&gt=3BTo: Coleburn=2C Randy<br>&gt=3B
> > &gt=3B&gt=3BCc: m3devel at elegosoft=
> > >.com<br>&gt=3B &gt=3B&gt=3BSubject:
> > Re: [M3devel] results of threadtest pro=
> > >gram on Windows7=3D3D20<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BHi Ran=
> > >dy=2C<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BHm yes it looks like my =
> > >Windows programming skills leave
> > something<br>&gt=3B &gt=3B&gt=3Bto be
> > desi=
> > >red.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BYou can run the thread te=
> > >ster while skipping a test as
> > follows<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=
> > >=3B&gt=3B threadtest -tests
> > ALL=2C-fork<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B =
> > >&gt=3B&gt=3B(for instance)<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3Bif =
> > >you just run=3D3D20<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B threadt=
> > >est -sadfassdaf<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3Bit'll print th=
> > >e tests that are available.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BAs=
> > > it happens=2C I just had to upgrade my windows 2000
> > system to windows 7.<b=
> > >r>&gt=3B &gt=3B&gt=3BCan you give me a
> > very brief description of what you d=
> > >id to install Modula=3D<br>&gt=3B
> > &gt=3B-=3D3D<br>&gt=3B
> > &gt=3B&gt=3B3<br>&=
> > >gt=3B &gt=3B&gt=3Bon this
> > system?<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=3B&g=
> > >t=3B Mika<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B"Coleburn=2C Ran=
> > >dy" writes:<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B--_000_D67F02DDC62F7545A6B84C285F88=
> > >F3E6EE25C849atlex02srv_<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BContent-Type: text/plai=
> > >n=3B charset=3D3D3D"us-ascii"<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BContent-Transfer-=
> > >Encoding: quoted-printable<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=
> > >=3B&gt=3BMika:<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BI'v=
> > >e finally managed to get cm3 rebuilt on Windows 7
> > again.<br>&gt=3B &gt=3B&g=
> > >t=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BSo=2C I ran your threadtest
> > program.=
> > ><br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BHere are the resu=
> > >lts. Note the "..." is where I cut out a bunch of
> > the r=3D<br>&gt=3B &gt=
> > >=3Be=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Beating=
> > > "ERROR FApply" messages.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=
> > >=3B&gt=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest.e=
> > >xe<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BWriting
> > file...done<br>&gt=3B &gt=3B&gt=3B&g=
> > >t=3BCreating read threads...done<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BCreating fork =
> > >threads...done<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BCreating alloc
> > threads...done<br=
> > >>&gt=3B &gt=3B&gt=3B&gt=3BCreating
> > lock threads...done<br>&gt=3B &gt=3B&gt=
> > >=3B&gt=3Brunning...printing oldest/median
> > age/newest<br>&gt=3B &gt=3B&gt=3B=
> > >&gt=3BERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find=
> > > the f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=
> > >=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OS=
> > >Error.E: ErrorCode=3D3D3D3D2: The system cannot
> > find the f=3D<br>&gt=3B &g=
> > >t=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Be=
> > >cified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E: 
> > ErrorCode=3D3=
> > >D3D3D2: The system cannot find the
> > f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B =
> > >&gt=3B&gt=3B sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=
> > >=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B=
> > >.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B*** runtime e=
> > >rror:<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B*** An
> > enumeration or subrange value w=
> > >as out of range.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B*** file
> > "..\src\Main.m3"=
> > >=2C line 340<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<b=
> > >r>&gt=3B &gt=3B&gt=3B&gt=3Blaziest
> > thread is 0/0/ERROR FApply: OSError.E: =
> > >ErrorCode=3D3D3D3D2: The sy=3D<br>&gt=3B
> > &gt=3Bste=3D3D<br>&gt=3B &gt=3B&gt=
> > >=3Bm c=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Bannot find the file
> > specified.<br=
> > >>&gt=3B &gt=3B&gt=3B&gt=3BERROR
> > FApply: OSError.E: ErrorCode=3D3D3D3D2: Th=
> > >e system cannot find the f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=
> > >=3B sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&g=
> > >t=3BERROR FApply: OSError.E: ErrorCode=3D3D3D3D2:
> > The system cannot find t=
> > >he f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B=
> > >
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSErr=
> > >or.E: ErrorCode=3D3D3D3D2: The system cannot find
> > the f=3D<br>&gt=3B &gt=
> > >=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Bec=
> > >ified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=
> > >=3B &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Blaziest thread is 0/0/E=
> > >RROR FApply: OSError.E: ErrorCode=3D3D3D3D2: The
> > sy=3D<br>&gt=3B &gt=3Bste=
> > >=3D3D<br>&gt=3B &gt=3B&gt=3Bm
> > c=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Bannot fi=
> > >nd the file specified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E:=
> > > ErrorCode=3D3D3D3D2: The system cannot find the
> > f=3D<br>&gt=3B &gt=3Bile=
> > >=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.=
> > ><br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2:=
> > > The system cannot find the f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&=
> > >gt=3B sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B=
> > >&gt=3BERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find=
> > > the f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=
> > >=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=
> > >=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B=
> > >ERROR FApply: OSError.E: ErrorCode=3D3D3D3D2: The
> > system cannot find the f=
> > >=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B &gt=
> > >=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E=
> > >: ErrorCode=3D3D3D3D2: The system cannot find the
> > f=3D<br>&gt=3B &gt=3Bile=
> > >=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.=
> > ><br>&gt=3B
> > &gt=3B&gt=3B&gt=3BStack
> > trace:<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B FP=
> > > PC 
> > Procedure<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B--------- ---------=
> > > 
> > -------------------------------<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B0x30fbd0 0x1=
> > >27218a PutStats + 0x1a3 in
> > ..\src\Main.m3<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B0x30=
> > >fcc0 0x1273825 Main_M3 + 0x11db(!) in
> > ..\src\Main.m3<br>&gt=3B &gt=3B&gt=
> > >=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BRegards=2C<br>&gt=3B
> > &gt=3B&gt=3B&gt=
> > >=3BRandy Coleburn<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B=
> > >--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_<br>&gt=3B
> > &gt=3B=
> > >&gt=3B&gt=3BContent-Type: text/html=3B
> > charset=3D3D3D"us-ascii"<br>&gt=3B &=
> > >gt=3B&gt=3B&gt=3BContent-Transfer-Encoding:
> > quoted-printable<br>&gt=3B &gt=
> > >=3B&gt=3B&gt=3B<br> 
> > 
> > 
> > </body>
> > ></html>=
> > >
> > >--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_--
> > 
> 
> 
> 
 		 	   		  



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110302/95baa618/attachment-0001.html>

From rcolebur at SCIRES.COM  Thu Mar  3 01:42:47 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>,
	<20110227231125.3DC611A2078@async.async.caltech.edu>
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>

Yes, it fails more often than it runs for me.
Regards,
Randy

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7

I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
>
> Ah, it just doesn't check command-line arguments that carefully.
>
> I think what you did is equivalent to "-tests STD".
>
> Mika
>
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- --------- -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
> >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110302/c3494867/attachment-0001.html>

From jay.krell at cornell.edu  Thu Mar  3 02:17:44 2011
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 3 Mar 2011 01:17:44 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>
Message-ID: <COL101-W4726257303F22627175774E6C30@phx.gbl>


Even with the change I made PutCard to PutInt?
That's the only failure I've seen.
I'll try on a non-virtual dual-proc machine later.
 
Thanks,
 - Jay
 


From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7






Yes, it fails more often than it runs for me.
Regards,
Randy
 


From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7
 
I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Ah, it just doesn't check command-line arguments that carefully.
> 
> I think what you did is equivalent to "-tests STD".
> 
> Mika
> 
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- --------- -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
> >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>> 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110303/cf2fb41d/attachment-0001.html>

From rcolebur at SCIRES.COM  Thu Mar  3 02:36:19 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Wed, 2 Mar 2011 20:36:19 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W4726257303F22627175774E6C30@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>
	<COL101-W4726257303F22627175774E6C30@phx.gbl>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>

Jay:

Ok, I just updated from HEAD and got your latest change to thread test program.

Here are two invocations, back to back, each failing in different ways.

The second one repeats the last error message ad infinitum until you press CNTRL-C to abort.  But note, several different errors reported earlier.

Regards,
Randy

C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cm3
--- building in NT386 ---

ignoring ..\src\m3overrides

new source -> compiling Main.m3
new "Main.mo" -> linking threadtest.exe

C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cd NT386

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
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


***
*** runtime error:
***    <*ASSERT*> failed..
***    file "..\src\runtime\common\RTCollector.m3", line 1086
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0xddfaf0  0x123dffb  CleanBetween + 0x47 in ..\src\runtime\common\RTCollector.m3
0xddfb34  0x1241870  CheckLoadTracedRef + 0xc5 in ..\src\runtime\common\RTCollector.m3
0xddfb74  0x121683c  Init + 0x95 in ..\src\rw\FileRd.m3
0xddfba0  0x121679d  Open + 0x4d in ..\src\rw\FileRd.m3
0xddfcd8  0x1211288  RApply + 0x78 in ..\src\Main.m3
0xddfd14  0x123976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
0xddfd20  0x76d53677  <???>
0xddfd60  0x773c9f02  <???>
.........  .........  ... more frames ...

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
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
.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0x12ec5ad = Move + 0x50 in ..\src\runtime\common\RTCollector.m3
***



***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***



***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Wednesday, March 02, 2011 8:18 PM
To: Coleburn, Randy; m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7

Even with the change I made PutCard to PutInt?
That's the only failure I've seen.
I'll try on a non-virtual dual-proc machine later.

Thanks,
 - Jay

________________________________
From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7
Yes, it fails more often than it runs for me.
Regards,
Randy

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7

I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
>
> Ah, it just doesn't check command-line arguments that carefully.
>
> I think what you did is equivalent to "-tests STD".
>
> Mika
>
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- --------- -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
> >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110302/38ebde7e/attachment-0001.html>

From dabenavidesd at yahoo.es  Thu Mar  3 03:27:58 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 3 Mar 2011 02:27:58 +0000 (GMT)
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W4726257303F22627175774E6C30@phx.gbl>
Message-ID: <974355.12644.qm@web29717.mail.ird.yahoo.com>

Hi all:
I would doubt but there could be some source of problem in smp on the Win32 platform, since there was a SPINE implementation on an intelligent NIC with 2 embedded MIPS CPUs, perhaps this was just a driver RT but it was for real time and in such a case there should be no problem besides that of the scheduling policy, but thinking how about linking MS Win2k R is a kind of crazy not to believe there was some synchronization with CPU board threads and that component threading at some point I believe.

Even more in embedded systems, there was a MPU implementation of it in 80186 a decade ago,? perhaps would be good to have a look of their Thread interface implementation it might be seem interesting if so.

But in any case there should be plenty of ways of implementing the threading tests incrementally of number of threads, besides you may want to check some uniprocessors with hyperThreading technology (sort of thread physical divisions inside the cpu), they are presented to OS as 2 smp processors, it could be interesting, I remember to test? time ago in this machines and anything weird happened, but quite time ago with ThreadPthread LINUXLIBC6 systems with normally distributed programs.
?
What about results in Win2k ?
Thanks in advance

--- El mi?, 2/3/11, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] results of threadtest program on Windows7
Para: rcolebur at scires.com, "m3devel" <m3devel at elegosoft.com>
Fecha: mi?rcoles, 2 de marzo, 2011 20:17




Even with the change?I made?PutCard to PutInt?

That's the only failure I've seen.

I'll try on a non-virtual dual-proc machine later.

?

Thanks,

?- Jay
?



From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7


 

#yiv891226996 .yiv891226996ExternalClass p.yiv891226996ecxMsoNormal, #yiv891226996 .yiv891226996ExternalClass li.yiv891226996ecxMsoNormal, #yiv891226996 .yiv891226996ExternalClass div.yiv891226996ecxMsoNormal
{margin-bottom:.0001pt;font-size:12.0pt;font-family:'serif';}
#yiv891226996 .yiv891226996ExternalClass a:link, #yiv891226996 .yiv891226996ExternalClass span.yiv891226996ecxMsoHyperlink
{color:blue;text-decoration:underline;}
#yiv891226996 .yiv891226996ExternalClass a:visited, #yiv891226996 .yiv891226996ExternalClass span.yiv891226996ecxMsoHyperlinkFollowed
{color:purple;text-decoration:underline;}
#yiv891226996 .yiv891226996ExternalClass p
{margin-right:0in;margin-left:0in;font-size:12.0pt;font-family:'serif';}
#yiv891226996 .yiv891226996ExternalClass span.yiv891226996ecxEmailStyle18
{font-family:'sans-serif';color:#1F497D;}
#yiv891226996 .yiv891226996ExternalClass .yiv891226996ecxMsoChpDefault
{font-size:10.0pt;}
 _filtered #yiv891226996 {}
#yiv891226996 .yiv891226996ExternalClass div.yiv891226996ecxWordSection1
{}




Yes, it fails more often than it runs for me.
Regards,
Randy
?


From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7
?
I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

?- Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Ah, it just doesn't check command-line arguments that carefully.
> 
> I think what you did is equivalent to "-tests STD".
> 
> Mika
> 
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- --------- -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
> >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>> 		 	   		  



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110303/a531d0d6/attachment-0001.html>

From jay.krell at cornell.edu  Thu Mar  3 03:46:39 2011
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 3 Mar 2011 02:46:39 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <974355.12644.qm@web29717.mail.ird.yahoo.com>
References: <COL101-W4726257303F22627175774E6C30@phx.gbl>,
	<974355.12644.qm@web29717.mail.ird.yahoo.com>
Message-ID: <COL101-W2637AB63DA6D9866A00D07E6C30@phx.gbl>


There is probably a bug in RTCollector.m3 or RTAllocator.m3.

 - Jay

Date: Thu, 3 Mar 2011 02:27:58 +0000
From: dabenavidesd at yahoo.es
Subject: Re: [M3devel] results of threadtest program on Windows7
To: rcolebur at scires.com; m3devel at elegosoft.com; jay.krell at cornell.edu

Hi all:
I would doubt but there could be some source of problem in smp on the Win32 platform, since there was a SPINE implementation on an intelligent NIC with 2 embedded MIPS CPUs, perhaps this was just a driver RT but it was for real time and in such a case there should be no problem besides that of the scheduling policy, but thinking how about linking MS Win2k R is a kind of crazy not to believe there was some synchronization with CPU board threads and that component threading at some point I believe.

Even more in embedded systems, there was a MPU implementation of it in 80186 a decade ago,  perhaps would be good to have a look of their Thread interface implementation it might be seem interesting if so.

But in any case there should be plenty of ways of implementing the threading tests incrementally of number of threads, besides you may
 want to check some uniprocessors with hyperThreading technology (sort of thread physical divisions inside the cpu), they are presented to OS as 2 smp processors, it could be interesting, I remember to test  time ago in this machines and anything weird happened, but quite time ago with ThreadPthread LINUXLIBC6 systems with normally distributed programs.
 
What about results in Win2k ?
Thanks in advance

--- El mi?, 2/3/11, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] results of threadtest program on Windows7
Para: rcolebur at scires.com, "m3devel" <m3devel at elegosoft.com>
Fecha: mi?rcoles, 2 de marzo, 2011 20:17




Even with the change I made PutCard to PutInt?

That's the only failure I've seen.

I'll try on a non-virtual dual-proc machine later.

 

Thanks,

 - Jay
 



From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7


 



Yes, it fails more often than it runs for me.
Regards,
Randy
 


From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7
 
I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Ah, it just doesn't check command-line arguments that carefully.
> 
> I think what you did is equivalent to "-tests STD".
> 
> Mika
> 
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the
 command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- ---------
 -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
>
 >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle
 down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints
 "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built
 Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
>
 >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm
 yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type:
 text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR
 FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file
 specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply:
 OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 +
 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>> 		 	   		  

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110303/32472aed/attachment-0001.html>

From jay.krell at cornell.edu  Thu Mar  3 07:32:50 2011
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 3 Mar 2011 06:32:50 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W2637AB63DA6D9866A00D07E6C30@phx.gbl>
References: <COL101-W4726257303F22627175774E6C30@phx.gbl>,
	<974355.12644.qm@web29717.mail.ird.yahoo.com>,
	<COL101-W2637AB63DA6D9866A00D07E6C30@phx.gbl>
Message-ID: <COL101-W1943F7B289FE5FD33E5D1EE6C30@phx.gbl>


Solaris doesn't hang now. I didn't change anything. And it succeeds.
Here are some stacks for a failure on I386_DARWIN.
Notice that it *should* abort right after the EBUSY print, but it still run a while.
Possibly too much information is lost.


(gdb) run
Starting program: /Users/jay/dev2/cm3/m3-libs/m3core/tests/thread/I386_DARWIN/threadtest 
Reading symbols for shared libraries ++. done
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
..........laziest thread is 1/0/0 (tests: read 0/0/0 fork 1/1/1 alloc 0/0/0 lock 0/0/0)
.........pthread_mutex_destroy:EBUSY (0)
.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:
***    An array subscript was out of range.
***    file "../src/runtime/common/RTCollector.m3", line 418
***


Program received signal SIGABRT, Aborted.
0x9385f44e in __semwait_signal ()
(gdb) bt
#0  0x9385f44e in __semwait_signal ()
#1  0x9388a3e6 in _pthread_cond_wait ()
#2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
#3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299133562.375689) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
#4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
#5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
#6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
#7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
#8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
#9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
#10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16


(gdb) thread apply all bt

Thread 13 (process 86311 thread 0x2a03):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#4  0x00003ed8 in Main__LApply (cl=0x9557d8) at ../src/Main.m3:290
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01130) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01130) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 12 (process 86311 thread 0x1f03):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#4  0x00003ed8 in Main__LApply (cl=0x9557a0) at ../src/Main.m3:290
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01080) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01080) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 11 (process 86311 thread 0x1e03):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#4  0x00003ed8 in Main__LApply (cl=0x955768) at ../src/Main.m3:290
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 10 (process 86311 thread 0x1d03):
#0  0x93934136 in __semwait_signal_nocancel ()
#1  0x93933d1b in nanosleep$NOCANCEL$UNIX2003 ()
#2  0x9392d013 in usleep$NOCANCEL$UNIX2003 ()
#3  0x93944685 in abort ()
#4  0x0004b5e6 in Cstdlib__abort () at ../src/C/Common/CstdlibC.c:21
#5  0x000434dd in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20
#6  0x0003d51f in RTProcess__Crash (msg=0x0) at ../src/runtime/common/RTProcess.m3:65
#7  0x0003b9d3 in RTError__EndError (crash=1 '\001') at ../src/runtime/common/RTError.m3:118
#8  0x0003b6e6 in RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:40
#9  0x0003bdc7 in RTException__Crash (a=0xb0490a64, raises=0 '\0', rte=0x7d100) at ../src/runtime/common/RTException.m3:79
#10 0x0003bb21 in RTException__DefaultBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:39
#11 0x0003ba7c in RTException__InvokeBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
#12 0x00043ca5 in RTException__Raise (act=0xb0490a64) at ../src/runtime/ex_frame/RTExFrame.m3:85
#13 0x0003bbb4 in RTException__DefaultBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:47
#14 0x0003ba7c in RTException__InvokeBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
#15 0x00043ca5 in RTException__Raise (act=0xb0490a64) at ../src/runtime/ex_frame/RTExFrame.m3:85
#16 0x0002b102 in RTHooks__ReportFault (module=0x70f80, info=13378) at ../src/runtime/common/RTHooks.m3:111
#17 0x000394c5 in _m3_fault (arg=13378) at ../src/runtime/common/RTCollector.m3:393
#18 0x0002fdd2 in RTCollector__Move (self=0xb3000c, cp=0x9a0014) at ../src/runtime/common/RTCollector.m3:418
#19 0x0002e503 in RTHeapMap__Walk (x=0x9a0014, pc=0x79928, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:202
#20 0x0002dc9c in RTHeapMap__DoWalkRef (t=0x6de54, a=0x9a0014, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:62
#21 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e3f4, a=0x9a000c, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:57
#22 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e508, a=0x9a000c, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:57
#23 0x0002dc2e in RTHeapMap__WalkRef (h=0x9a0008, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:47
#24 0x00032279 in RTCollector__CleanBetween (h=0x9a0008, he=0x9b0000, clean=0 '\0') at ../src/runtime/common/RTCollector.m3:1091
#25 0x00032098 in RTCollector__CleanPage (page=0x9a0000) at ../src/runtime/common/RTCollector.m3:1064
#26 0x00031798 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885
#27 0x00030e75 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720
#28 0x00030a97 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654
#29 0x0002cb85 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00f64) at ../src/runtime/common/RTAllocator.m3:367
#30 0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:296
#31 0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:143
#32 0x00003b5f in Main__AApply (cl=0x9556f8) at ../src/Main.m3:260
#33 0x00046ee2 in ThreadPThread__RunThread (me=0xa00f20) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#34 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00f20) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#35 0x93889155 in _pthread_start ()
#36 0x93889012 in thread_start ()

Thread 9 (process 86311 thread 0x1c03):
#0  0x938582a2 in semaphore_wait_trap ()
#1  0x9385fd92 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00eb4) at ../src/runtime/common/RTAllocator.m3:365
#5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:296
#6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:143
#7  0x00003b5f in Main__AApply (cl=0x9556c0) at ../src/Main.m3:260
#8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00e70) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00e70) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#10 0x93889155 in _pthread_start ()
#11 0x93889012 in thread_start ()

Thread 8 (process 86311 thread 0x1b03):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00e04) at ../src/runtime/common/RTAllocator.m3:365
#5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:296
#6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:143
#7  0x00003b5f in Main__AApply (cl=0x955688) at ../src/Main.m3:260
#8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00dc0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00dc0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#10 0x93889155 in _pthread_start ()
#11 0x93889012 in thread_start ()

Thread 7 (process 86311 thread 0x1a03):
#0  0x9389c856 in __wait4 ()
#1  0x9389c847 in waitpid$UNIX2003 ()
#2  0x0004b222 in Uexec__waitpid (i=86384, j=0xb030ad9c, k=0) at ../src/unix/Common/Uexec.c:67
#3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86384, status=0xb030ad9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
#4  0x0000d66a in Process__Wait (p=0xb00018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
#5  0x00003719 in Main__FApply (cl=0x955618) at ../src/Main.m3:230
#6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00d60) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00d60) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#8  0x93889155 in _pthread_start ()
#9  0x93889012 in thread_start ()

Thread 6 (process 86311 thread 0x1903):
#0  0x9389c856 in __wait4 ()
#1  0x9389c847 in waitpid$UNIX2003 ()
#2  0x0004b222 in Uexec__waitpid (i=86385, j=0xb0288d9c, k=0) at ../src/unix/Common/Uexec.c:67
#3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86385, status=0xb0288d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
#4  0x0000d66a in Process__Wait (p=0xbd000c) at ../src/os/POSIX/ProcessPosixCommon.m3:275
#5  0x00003719 in Main__FApply (cl=0x9555e0) at ../src/Main.m3:230
#6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00b70) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00b70) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#8  0x93889155 in _pthread_start ()
#9  0x93889012 in thread_start ()

Thread 5 (process 86311 thread 0x1803):
#0  0x9389c856 in __wait4 ()
#1  0x9389c847 in waitpid$UNIX2003 ()
#2  0x0004b222 in Uexec__waitpid (i=86386, j=0xb0206d9c, k=0) at ../src/unix/Common/Uexec.c:67
#3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86386, status=0xb0206d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
#4  0x0000d66a in Process__Wait (p=0x9d0018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
#5  0x00003719 in Main__FApply (cl=0x9555a8) at ../src/Main.m3:230
#6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00ac0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00ac0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#8  0x93889155 in _pthread_start ()
#9  0x93889012 in thread_start ()

Thread 4 (process 86311 thread 0x1103):
#0  0x9385fb99 in pthread_mutex_lock ()
#1  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00c20) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#2  0x0004503c in ThreadPThread__LockMutex (m=0xb6000c) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#3  0x0000e060 in Rd__GetChar (rd=0xb6000c) at ../src/rw/Rd.m3:33
#4  0x000030b5 in Main__RApply (cl=0x955538) at ../src/Main.m3:177
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 3 (process 86311 thread 0x117):
#0  0x93859304 in pthread_getspecific ()
#1  0x0004a529 in ThreadPThread__GetActivation () at ../src/thread/PTHREAD/ThreadPThreadC.c:309
#2  0x00049f52 in RTHooks__PushEFrame (frame=0xb0102d20) at ../src/thread/PTHREAD/ThreadPThread.m3:1385
#3  0x0000e07b in Rd__GetChar (rd=0x99000c) at ../src/rw/Rd.m3:33
#4  0x000030b5 in Main__RApply (cl=0x955500) at ../src/Main.m3:177
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 2 (process 86311 thread 0x313):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=12, dataAlignment=4, thread=0xa00834) at ../src/runtime/common/RTAllocator.m3:365
#5  0x0002bf13 in RTAllocator__GetTracedObj (def=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:224
#6  0x0002b98a in RTHooks__AllocateTracedObj (defn=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:122
#7  0x00008eeb in FilePosix__New (fd=5, ds=1) at ../src/os/POSIX/FilePosix.m3:63
#8  0x0000a4eb in FS__OpenFileReadonly (pn=0x775b8) at ../src/os/POSIX/FSPosix.m3:182
#9  0x00014dfa in FileRd__Open (p=0x775b8) at ../src/rw/FileRd.m3:16
#10 0x00003046 in Main__RApply (cl=0x9554c8) at ../src/Main.m3:174
#11 0x00046ee2 in ThreadPThread__RunThread (me=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#12 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#13 0x93889155 in _pthread_start ()
#14 0x93889012 in thread_start ()

Thread 1 (process 86311 local thread 0x2e03):
#0  0x9385f44e in __semwait_signal ()
#1  0x9388a3e6 in _pthread_cond_wait ()
#2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
#3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299133562.375689) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
#4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
#5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
#6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
#7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
#8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
#9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
#10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16







From: jay.krell at cornell.edu
To: dabenavidesd at yahoo.es; rcolebur at scires.com; m3devel at elegosoft.com
Subject: RE: [M3devel] results of threadtest program on Windows7
Date: Thu, 3 Mar 2011 02:46:39 +0000








There is probably a bug in RTCollector.m3 or RTAllocator.m3.

 - Jay

Date: Thu, 3 Mar 2011 02:27:58 +0000
From: dabenavidesd at yahoo.es
Subject: Re: [M3devel] results of threadtest program on Windows7
To: rcolebur at scires.com; m3devel at elegosoft.com; jay.krell at cornell.edu

Hi all:
I would doubt but there could be some source of problem in smp on the Win32 platform, since there was a SPINE implementation on an intelligent NIC with 2 embedded MIPS CPUs, perhaps this was just a driver RT but it was for real time and in such a case there should be no problem besides that of the scheduling policy, but thinking how about linking MS Win2k R is a kind of crazy not to believe there was some synchronization with CPU board threads and that component threading at some point I believe.

Even more in embedded systems, there was a MPU implementation of it in 80186 a decade ago,  perhaps would be good to have a look of their Thread interface implementation it might be seem interesting if so.

But in any case there should be plenty of ways of implementing the threading tests incrementally of number of threads, besides you may
 want to check some uniprocessors with hyperThreading technology (sort of thread physical divisions inside the cpu), they are presented to OS as 2 smp processors, it could be interesting, I remember to test  time ago in this machines and anything weird happened, but quite time ago with ThreadPthread LINUXLIBC6 systems with normally distributed programs.
 
What about results in Win2k ?
Thanks in advance

--- El mi?, 2/3/11, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] results of threadtest program on Windows7
Para: rcolebur at scires.com, "m3devel" <m3devel at elegosoft.com>
Fecha: mi?rcoles, 2 de marzo, 2011 20:17




Even with the change I made PutCard to PutInt?

That's the only failure I've seen.

I'll try on a non-virtual dual-proc machine later.

 

Thanks,

 - Jay
 



From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7


 



Yes, it fails more often than it runs for me.
Regards,
Randy
 


From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7
 
I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Ah, it just doesn't check command-line arguments that carefully.
> 
> I think what you did is equivalent to "-tests STD".
> 
> Mika
> 
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the
 command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- ---------
 -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
>
 >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle
 down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints
 "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built
 Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
>
 >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm
 yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type:
 text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR
 FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file
 specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply:
 OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 +
 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>> 		 	   		  

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110303/60fab6ef/attachment-0001.html>

From jay.krell at cornell.edu  Thu Mar  3 07:37:49 2011
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 3 Mar 2011 06:37:49 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W1943F7B289FE5FD33E5D1EE6C30@phx.gbl>
References: <COL101-W4726257303F22627175774E6C30@phx.gbl>,
	<974355.12644.qm@web29717.mail.ird.yahoo.com>,
	<COL101-W2637AB63DA6D9866A00D07E6C30@phx.gbl>,
	<COL101-W1943F7B289FE5FD33E5D1EE6C30@phx.gbl>
Message-ID: <COL101-W52252742B56CBFEAD0A0DFE6C30@phx.gbl>


Here is another failure also I386_DARWIN.


(gdb) break RTError__MsgS
Breakpoint 2 at 0x3b65f: file ../src/runtime/common/RTError.m3, line 30.
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /Users/jay/dev2/cm3/m3-libs/m3core/tests/thread/I386_DARWIN/threadtest 
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
..[Switching to process 86430 thread 0x1503]

Breakpoint 2, RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:30
30        StartError (msgA, msgB, msgC);
(gdb) bt
#0  RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:30
#1  0x0003bdc7 in RTException__Crash (a=0xb040ea64, raises=0 '\0', rte=0x7d100) at ../src/runtime/common/RTException.m3:79
#2  0x0003bb21 in RTException__DefaultBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:39
#3  0x0003ba7c in RTException__InvokeBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
#4  0x00043ca5 in RTException__Raise (act=0xb040ea64) at ../src/runtime/ex_frame/RTExFrame.m3:85
#5  0x0003bbb4 in RTException__DefaultBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:47
#6  0x0003ba7c in RTException__InvokeBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
#7  0x00043ca5 in RTException__Raise (act=0xb040ea64) at ../src/runtime/ex_frame/RTExFrame.m3:85
#8  0x0002b102 in RTHooks__ReportFault (module=0x70f80, info=13378) at ../src/runtime/common/RTHooks.m3:111
#9  0x000394c5 in _m3_fault (arg=13378) at ../src/runtime/common/RTCollector.m3:393
#10 0x0002fdd2 in RTCollector__Move (self=0xb4000c, cp=0xba0014) at ../src/runtime/common/RTCollector.m3:418
#11 0x0002e503 in RTHeapMap__Walk (x=0xba0014, pc=0x79928, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:202
#12 0x0002dc9c in RTHeapMap__DoWalkRef (t=0x6de54, a=0xba0014, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:62
#13 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e3f4, a=0xba000c, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:57
#14 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e508, a=0xba000c, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:57
#15 0x0002dc2e in RTHeapMap__WalkRef (h=0xba0008, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:47
#16 0x00032279 in RTCollector__CleanBetween (h=0xba0008, he=0xbb0000, clean=0 '\0') at ../src/runtime/common/RTCollector.m3:1091
#17 0x00032098 in RTCollector__CleanPage (page=0xba0000) at ../src/runtime/common/RTCollector.m3:1064
#18 0x00031798 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885
#19 0x00030e75 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720
#20 0x00030a97 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654
#21 0x0002cb85 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00e74) at ../src/runtime/common/RTAllocator.m3:367
#22 0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:296
#23 0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:143
#24 0x00003b5f in Main__AApply (cl=0x9556c0) at ../src/Main.m3:260
#25 0x00046ee2 in ThreadPThread__RunThread (me=0xa00e30) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#26 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00e30) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#27 0x93889155 in _pthread_start ()
#28 0x93889012 in thread_start ()
(gdb) threads apply all bt
Undefined command: "threads".  Try "help".
(gdb) thread apply all bt

Thread 13 (process 86430 thread 0x1903):
#0  0x9388a6f1 in semaphore_wait_signal ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00880) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#4  0x00003ed8 in Main__LApply (cl=0x9557d8) at ../src/Main.m3:290
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa010f0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa010f0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 12 (process 86430 thread 0x1803):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00880) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#4  0x00003ed8 in Main__LApply (cl=0x9557a0) at ../src/Main.m3:290
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01040) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01040) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 11 (process 86430 thread 0x1703):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00880) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#4  0x00003ed8 in Main__LApply (cl=0x955768) at ../src/Main.m3:290
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00f90) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00f90) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 10 (process 86430 thread 0x1603):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00f24) at ../src/runtime/common/RTAllocator.m3:365
#5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:296
#6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:143
#7  0x00003b5f in Main__AApply (cl=0x9556f8) at ../src/Main.m3:260
#8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00ee0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00ee0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#10 0x93889155 in _pthread_start ()
#11 0x93889012 in thread_start ()

Thread 9 (process 86430 thread 0x1503):
#0  RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:30
#1  0x0003bdc7 in RTException__Crash (a=0xb040ea64, raises=0 '\0', rte=0x7d100) at ../src/runtime/common/RTException.m3:79
#2  0x0003bb21 in RTException__DefaultBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:39
#3  0x0003ba7c in RTException__InvokeBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
#4  0x00043ca5 in RTException__Raise (act=0xb040ea64) at ../src/runtime/ex_frame/RTExFrame.m3:85
#5  0x0003bbb4 in RTException__DefaultBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:47
#6  0x0003ba7c in RTException__InvokeBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
#7  0x00043ca5 in RTException__Raise (act=0xb040ea64) at ../src/runtime/ex_frame/RTExFrame.m3:85
#8  0x0002b102 in RTHooks__ReportFault (module=0x70f80, info=13378) at ../src/runtime/common/RTHooks.m3:111
#9  0x000394c5 in _m3_fault (arg=13378) at ../src/runtime/common/RTCollector.m3:393
#10 0x0002fdd2 in RTCollector__Move (self=0xb4000c, cp=0xba0014) at ../src/runtime/common/RTCollector.m3:418
#11 0x0002e503 in RTHeapMap__Walk (x=0xba0014, pc=0x79928, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:202
#12 0x0002dc9c in RTHeapMap__DoWalkRef (t=0x6de54, a=0xba0014, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:62
#13 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e3f4, a=0xba000c, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:57
#14 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e508, a=0xba000c, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:57
#15 0x0002dc2e in RTHeapMap__WalkRef (h=0xba0008, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:47
#16 0x00032279 in RTCollector__CleanBetween (h=0xba0008, he=0xbb0000, clean=0 '\0') at ../src/runtime/common/RTCollector.m3:1091
#17 0x00032098 in RTCollector__CleanPage (page=0xba0000) at ../src/runtime/common/RTCollector.m3:1064
#18 0x00031798 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885
#19 0x00030e75 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720
#20 0x00030a97 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654
#21 0x0002cb85 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00e74) at ../src/runtime/common/RTAllocator.m3:367
#22 0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:296
#23 0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:143
#24 0x00003b5f in Main__AApply (cl=0x9556c0) at ../src/Main.m3:260
#25 0x00046ee2 in ThreadPThread__RunThread (me=0xa00e30) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#26 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00e30) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#27 0x93889155 in _pthread_start ()
#28 0x93889012 in thread_start ()

Thread 8 (process 86430 thread 0x1403):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00dc4) at ../src/runtime/common/RTAllocator.m3:365
#5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:296
#6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:143
#7  0x00003b5f in Main__AApply (cl=0x955688) at ../src/Main.m3:260
#8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00d80) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00d80) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#10 0x93889155 in _pthread_start ()
#11 0x93889012 in thread_start ()

Thread 7 (process 86430 thread 0x1303):
#0  0x9389c856 in __wait4 ()
#1  0x9389c847 in waitpid$UNIX2003 ()
#2  0x0004b222 in Uexec__waitpid (i=86436, j=0xb030ad9c, k=0) at ../src/unix/Common/Uexec.c:67
#3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86436, status=0xb030ad9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
#4  0x0000d66a in Process__Wait (p=0xb00018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
#5  0x00003719 in Main__FApply (cl=0x955618) at ../src/Main.m3:230
#6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00d20) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00d20) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#8  0x93889155 in _pthread_start ()
#9  0x93889012 in thread_start ()

Thread 6 (process 86430 thread 0x1203):
#0  0x9389c856 in __wait4 ()
#1  0x9389c847 in waitpid$UNIX2003 ()
#2  0x0004b222 in Uexec__waitpid (i=86437, j=0xb0288d9c, k=0) at ../src/unix/Common/Uexec.c:67
#3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86437, status=0xb0288d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
#4  0x0000d66a in Process__Wait (p=0xbd0018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
#5  0x00003719 in Main__FApply (cl=0x9555e0) at ../src/Main.m3:230
#6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00b30) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00b30) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#8  0x93889155 in _pthread_start ()
#9  0x93889012 in thread_start ()

Thread 5 (process 86430 thread 0x1103):
#0  0x9389c856 in __wait4 ()
#1  0x9389c847 in waitpid$UNIX2003 ()
#2  0x0004b222 in Uexec__waitpid (i=86435, j=0xb0206d9c, k=0) at ../src/unix/Common/Uexec.c:67
#3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86435, status=0xb0206d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
#4  0x0000d66a in Process__Wait (p=0xc2000c) at ../src/os/POSIX/ProcessPosixCommon.m3:275
#5  0x00003719 in Main__FApply (cl=0x9555a8) at ../src/Main.m3:230
#6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00a80) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00a80) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#8  0x93889155 in _pthread_start ()
#9  0x93889012 in thread_start ()

Thread 4 (process 86430 thread 0x1003):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=12, dataAlignment=4, thread=0xa00a14) at ../src/runtime/common/RTAllocator.m3:365
#5  0x0002bf13 in RTAllocator__GetTracedObj (def=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:224
#6  0x0002b98a in RTHooks__AllocateTracedObj (defn=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:122
#7  0x00008eeb in FilePosix__New (fd=5, ds=1) at ../src/os/POSIX/FilePosix.m3:63
#8  0x0000a4eb in FS__OpenFileReadonly (pn=0x775b8) at ../src/os/POSIX/FSPosix.m3:182
#9  0x00014dfa in FileRd__Open (p=0x775b8) at ../src/rw/FileRd.m3:16
#10 0x00003046 in Main__RApply (cl=0x955538) at ../src/Main.m3:174
#11 0x00046ee2 in ThreadPThread__RunThread (me=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#12 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#13 0x93889155 in _pthread_start ()
#14 0x93889012 in thread_start ()

Thread 3 (process 86430 thread 0x117):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x74220) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00044f3a in ThreadPThread__InitMutex (m=0x960010, root=0x96000c, Clean=0x44dac) at ../src/thread/PTHREAD/ThreadPThread.m3:101
#4  0x0004500b in ThreadPThread__LockMutex (m=0x96000c) at ../src/thread/PTHREAD/ThreadPThread.m3:117
#5  0x0000e060 in Rd__GetChar (rd=0x96000c) at ../src/rw/Rd.m3:33
#6  0x000030b5 in Main__RApply (cl=0x955500) at ../src/Main.m3:177
#7  0x00046ee2 in ThreadPThread__RunThread (me=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#8  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#9  0x93889155 in _pthread_start ()
#10 0x93889012 in thread_start ()

Thread 2 (process 86430 thread 0x313):
#0  0x938582a2 in semaphore_wait_trap ()
#1  0x9385fd92 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x00036509 in RTHeapRep__RegisterFinalCleanup (r=0x9b1050, p=0x44dac) at ../src/runtime/common/RTCollector.m3:2148
#5  0x00044fa2 in ThreadPThread__InitMutex (m=0x9b1054, root=0x9b1050, Clean=0x44dac) at ../src/thread/PTHREAD/ThreadPThread.m3:106
#6  0x0004500b in ThreadPThread__LockMutex (m=0x9b1050) at ../src/thread/PTHREAD/ThreadPThread.m3:117
#7  0x0000e060 in Rd__GetChar (rd=0x9b1050) at ../src/rw/Rd.m3:33
#8  0x000030b5 in Main__RApply (cl=0x9554c8) at ../src/Main.m3:177
#9  0x00046ee2 in ThreadPThread__RunThread (me=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#10 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#11 0x93889155 in _pthread_start ()
#12 0x93889012 in thread_start ()

Thread 1 (process 86430 local thread 0x4507):
#0  0x9385f44e in __semwait_signal ()
#1  0x9388a3e6 in _pthread_cond_wait ()
#2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
#3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299134070.4957981) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
#4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
#5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
#6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
#7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
#8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
#9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
#10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16

 - Jay


From: jay.krell at cornell.edu
To: dabenavidesd at yahoo.es; rcolebur at scires.com; m3devel at elegosoft.com
Subject: RE: [M3devel] results of threadtest program on Windows7
Date: Thu, 3 Mar 2011 06:32:50 +0000








Solaris doesn't hang now. I didn't change anything. And it succeeds.
Here are some stacks for a failure on I386_DARWIN.
Notice that it *should* abort right after the EBUSY print, but it still run a while.
Possibly too much information is lost.


(gdb) run
Starting program: /Users/jay/dev2/cm3/m3-libs/m3core/tests/thread/I386_DARWIN/threadtest 
Reading symbols for shared libraries ++. done
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
..........laziest thread is 1/0/0 (tests: read 0/0/0 fork 1/1/1 alloc 0/0/0 lock 0/0/0)
.........pthread_mutex_destroy:EBUSY (0)
.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:
***    An array subscript was out of range.
***    file "../src/runtime/common/RTCollector.m3", line 418
***


Program received signal SIGABRT, Aborted.
0x9385f44e in __semwait_signal ()
(gdb) bt
#0  0x9385f44e in __semwait_signal ()
#1  0x9388a3e6 in _pthread_cond_wait ()
#2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
#3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299133562.375689) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
#4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
#5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
#6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
#7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
#8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
#9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
#10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16


(gdb) thread apply all bt

Thread 13 (process 86311 thread 0x2a03):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#4  0x00003ed8 in Main__LApply (cl=0x9557d8) at ../src/Main.m3:290
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01130) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01130) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 12 (process 86311 thread 0x1f03):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#4  0x00003ed8 in Main__LApply (cl=0x9557a0) at ../src/Main.m3:290
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01080) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01080) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 11 (process 86311 thread 0x1e03):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#4  0x00003ed8 in Main__LApply (cl=0x955768) at ../src/Main.m3:290
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 10 (process 86311 thread 0x1d03):
#0  0x93934136 in __semwait_signal_nocancel ()
#1  0x93933d1b in nanosleep$NOCANCEL$UNIX2003 ()
#2  0x9392d013 in usleep$NOCANCEL$UNIX2003 ()
#3  0x93944685 in abort ()
#4  0x0004b5e6 in Cstdlib__abort () at ../src/C/Common/CstdlibC.c:21
#5  0x000434dd in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20
#6  0x0003d51f in RTProcess__Crash (msg=0x0) at ../src/runtime/common/RTProcess.m3:65
#7  0x0003b9d3 in RTError__EndError (crash=1 '\001') at ../src/runtime/common/RTError.m3:118
#8  0x0003b6e6 in RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:40
#9  0x0003bdc7 in RTException__Crash (a=0xb0490a64, raises=0 '\0', rte=0x7d100) at ../src/runtime/common/RTException.m3:79
#10 0x0003bb21 in RTException__DefaultBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:39
#11 0x0003ba7c in RTException__InvokeBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
#12 0x00043ca5 in RTException__Raise (act=0xb0490a64) at ../src/runtime/ex_frame/RTExFrame.m3:85
#13 0x0003bbb4 in RTException__DefaultBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:47
#14 0x0003ba7c in RTException__InvokeBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
#15 0x00043ca5 in RTException__Raise (act=0xb0490a64) at ../src/runtime/ex_frame/RTExFrame.m3:85
#16 0x0002b102 in RTHooks__ReportFault (module=0x70f80, info=13378) at ../src/runtime/common/RTHooks.m3:111
#17 0x000394c5 in _m3_fault (arg=13378) at ../src/runtime/common/RTCollector.m3:393
#18 0x0002fdd2 in RTCollector__Move (self=0xb3000c, cp=0x9a0014) at ../src/runtime/common/RTCollector.m3:418
#19 0x0002e503 in RTHeapMap__Walk (x=0x9a0014, pc=0x79928, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:202
#20 0x0002dc9c in RTHeapMap__DoWalkRef (t=0x6de54, a=0x9a0014, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:62
#21 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e3f4, a=0x9a000c, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:57
#22 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e508, a=0x9a000c, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:57
#23 0x0002dc2e in RTHeapMap__WalkRef (h=0x9a0008, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:47
#24 0x00032279 in RTCollector__CleanBetween (h=0x9a0008, he=0x9b0000, clean=0 '\0') at ../src/runtime/common/RTCollector.m3:1091
#25 0x00032098 in RTCollector__CleanPage (page=0x9a0000) at ../src/runtime/common/RTCollector.m3:1064
#26 0x00031798 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885
#27 0x00030e75 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720
#28 0x00030a97 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654
#29 0x0002cb85 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00f64) at ../src/runtime/common/RTAllocator.m3:367
#30 0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:296
#31 0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:143
#32 0x00003b5f in Main__AApply (cl=0x9556f8) at ../src/Main.m3:260
#33 0x00046ee2 in ThreadPThread__RunThread (me=0xa00f20) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#34 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00f20) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#35 0x93889155 in _pthread_start ()
#36 0x93889012 in thread_start ()

Thread 9 (process 86311 thread 0x1c03):
#0  0x938582a2 in semaphore_wait_trap ()
#1  0x9385fd92 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00eb4) at ../src/runtime/common/RTAllocator.m3:365
#5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:296
#6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:143
#7  0x00003b5f in Main__AApply (cl=0x9556c0) at ../src/Main.m3:260
#8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00e70) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00e70) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#10 0x93889155 in _pthread_start ()
#11 0x93889012 in thread_start ()

Thread 8 (process 86311 thread 0x1b03):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00e04) at ../src/runtime/common/RTAllocator.m3:365
#5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:296
#6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:143
#7  0x00003b5f in Main__AApply (cl=0x955688) at ../src/Main.m3:260
#8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00dc0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00dc0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#10 0x93889155 in _pthread_start ()
#11 0x93889012 in thread_start ()

Thread 7 (process 86311 thread 0x1a03):
#0  0x9389c856 in __wait4 ()
#1  0x9389c847 in waitpid$UNIX2003 ()
#2  0x0004b222 in Uexec__waitpid (i=86384, j=0xb030ad9c, k=0) at ../src/unix/Common/Uexec.c:67
#3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86384, status=0xb030ad9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
#4  0x0000d66a in Process__Wait (p=0xb00018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
#5  0x00003719 in Main__FApply (cl=0x955618) at ../src/Main.m3:230
#6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00d60) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00d60) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#8  0x93889155 in _pthread_start ()
#9  0x93889012 in thread_start ()

Thread 6 (process 86311 thread 0x1903):
#0  0x9389c856 in __wait4 ()
#1  0x9389c847 in waitpid$UNIX2003 ()
#2  0x0004b222 in Uexec__waitpid (i=86385, j=0xb0288d9c, k=0) at ../src/unix/Common/Uexec.c:67
#3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86385, status=0xb0288d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
#4  0x0000d66a in Process__Wait (p=0xbd000c) at ../src/os/POSIX/ProcessPosixCommon.m3:275
#5  0x00003719 in Main__FApply (cl=0x9555e0) at ../src/Main.m3:230
#6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00b70) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00b70) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#8  0x93889155 in _pthread_start ()
#9  0x93889012 in thread_start ()

Thread 5 (process 86311 thread 0x1803):
#0  0x9389c856 in __wait4 ()
#1  0x9389c847 in waitpid$UNIX2003 ()
#2  0x0004b222 in Uexec__waitpid (i=86386, j=0xb0206d9c, k=0) at ../src/unix/Common/Uexec.c:67
#3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86386, status=0xb0206d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
#4  0x0000d66a in Process__Wait (p=0x9d0018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
#5  0x00003719 in Main__FApply (cl=0x9555a8) at ../src/Main.m3:230
#6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00ac0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00ac0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#8  0x93889155 in _pthread_start ()
#9  0x93889012 in thread_start ()

Thread 4 (process 86311 thread 0x1103):
#0  0x9385fb99 in pthread_mutex_lock ()
#1  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00c20) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#2  0x0004503c in ThreadPThread__LockMutex (m=0xb6000c) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#3  0x0000e060 in Rd__GetChar (rd=0xb6000c) at ../src/rw/Rd.m3:33
#4  0x000030b5 in Main__RApply (cl=0x955538) at ../src/Main.m3:177
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 3 (process 86311 thread 0x117):
#0  0x93859304 in pthread_getspecific ()
#1  0x0004a529 in ThreadPThread__GetActivation () at ../src/thread/PTHREAD/ThreadPThreadC.c:309
#2  0x00049f52 in RTHooks__PushEFrame (frame=0xb0102d20) at ../src/thread/PTHREAD/ThreadPThread.m3:1385
#3  0x0000e07b in Rd__GetChar (rd=0x99000c) at ../src/rw/Rd.m3:33
#4  0x000030b5 in Main__RApply (cl=0x955500) at ../src/Main.m3:177
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 2 (process 86311 thread 0x313):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=12, dataAlignment=4, thread=0xa00834) at ../src/runtime/common/RTAllocator.m3:365
#5  0x0002bf13 in RTAllocator__GetTracedObj (def=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:224
#6  0x0002b98a in RTHooks__AllocateTracedObj (defn=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:122
#7  0x00008eeb in FilePosix__New (fd=5, ds=1) at ../src/os/POSIX/FilePosix.m3:63
#8  0x0000a4eb in FS__OpenFileReadonly (pn=0x775b8) at ../src/os/POSIX/FSPosix.m3:182
#9  0x00014dfa in FileRd__Open (p=0x775b8) at ../src/rw/FileRd.m3:16
#10 0x00003046 in Main__RApply (cl=0x9554c8) at ../src/Main.m3:174
#11 0x00046ee2 in ThreadPThread__RunThread (me=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#12 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#13 0x93889155 in _pthread_start ()
#14 0x93889012 in thread_start ()

Thread 1 (process 86311 local thread 0x2e03):
#0  0x9385f44e in __semwait_signal ()
#1  0x9388a3e6 in _pthread_cond_wait ()
#2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
#3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299133562.375689) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
#4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
#5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
#6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
#7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
#8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
#9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
#10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16







From: jay.krell at cornell.edu
To: dabenavidesd at yahoo.es; rcolebur at scires.com; m3devel at elegosoft.com
Subject: RE: [M3devel] results of threadtest program on Windows7
Date: Thu, 3 Mar 2011 02:46:39 +0000








There is probably a bug in RTCollector.m3 or RTAllocator.m3.

 - Jay

Date: Thu, 3 Mar 2011 02:27:58 +0000
From: dabenavidesd at yahoo.es
Subject: Re: [M3devel] results of threadtest program on Windows7
To: rcolebur at scires.com; m3devel at elegosoft.com; jay.krell at cornell.edu

Hi all:
I would doubt but there could be some source of problem in smp on the Win32 platform, since there was a SPINE implementation on an intelligent NIC with 2 embedded MIPS CPUs, perhaps this was just a driver RT but it was for real time and in such a case there should be no problem besides that of the scheduling policy, but thinking how about linking MS Win2k R is a kind of crazy not to believe there was some synchronization with CPU board threads and that component threading at some point I believe.

Even more in embedded systems, there was a MPU implementation of it in 80186 a decade ago,  perhaps would be good to have a look of their Thread interface implementation it might be seem interesting if so.

But in any case there should be plenty of ways of implementing the threading tests incrementally of number of threads, besides you may
 want to check some uniprocessors with hyperThreading technology (sort of thread physical divisions inside the cpu), they are presented to OS as 2 smp processors, it could be interesting, I remember to test  time ago in this machines and anything weird happened, but quite time ago with ThreadPthread LINUXLIBC6 systems with normally distributed programs.
 
What about results in Win2k ?
Thanks in advance

--- El mi?, 2/3/11, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] results of threadtest program on Windows7
Para: rcolebur at scires.com, "m3devel" <m3devel at elegosoft.com>
Fecha: mi?rcoles, 2 de marzo, 2011 20:17




Even with the change I made PutCard to PutInt?

That's the only failure I've seen.

I'll try on a non-virtual dual-proc machine later.

 

Thanks,

 - Jay
 



From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7


 



Yes, it fails more often than it runs for me.
Regards,
Randy
 


From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7
 
I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Ah, it just doesn't check command-line arguments that carefully.
> 
> I think what you did is equivalent to "-tests STD".
> 
> Mika
> 
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the
 command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- ---------
 -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
>
 >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle
 down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints
 "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built
 Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
>
 >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm
 yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type:
 text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR
 FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file
 specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply:
 OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 +
 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>> 		 	   		  

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110303/e4e568c3/attachment-0001.html>

From hosking at cs.purdue.edu  Thu Mar  3 16:39:07 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 3 Mar 2011 10:39:07 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>
	<COL101-W4726257303F22627175774E6C30@phx.gbl>
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>
Message-ID: <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>

Both of these errors indicate major breakdown in the garbage collector.
It could be that the damage was done much earlier than the crash.
To check for earlier damage please run with @M3paranoidgc.
Also, you could try running with @M3nogc, or @M3noincremental, or @M3nogenerational, to see if any of them trigger the errors.


On Mar 2, 2011, at 8:36 PM, Coleburn, Randy wrote:

> Jay:
>  
> Ok, I just updated from HEAD and got your latest change to thread test program.
>  
> Here are two invocations, back to back, each failing in different ways. 
>  
> The second one repeats the last error message ad infinitum until you press CNTRL-C to abort.  But note, several different errors reported earlier.
>  
> Regards,
> Randy
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cm3
> --- building in NT386 ---
>  
> ignoring ..\src\m3overrides
>  
> new source -> compiling Main.m3
> new "Main.mo" -> linking threadtest.exe
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cd NT386
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> 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
>  
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed..
> ***    file "..\src\runtime\common\RTCollector.m3", line 1086
> ***
>  
> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0xddfaf0  0x123dffb  CleanBetween + 0x47 in ..\src\runtime\common\RTCollector.m3
> 0xddfb34  0x1241870  CheckLoadTracedRef + 0xc5 in ..\src\runtime\common\RTCollector.m3
> 0xddfb74  0x121683c  Init + 0x95 in ..\src\rw\FileRd.m3
> 0xddfba0  0x121679d  Open + 0x4d in ..\src\rw\FileRd.m3
> 0xddfcd8  0x1211288  RApply + 0x78 in ..\src\Main.m3
> 0xddfd14  0x123976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
> 0xddfd20  0x76d53677  <???>
> 0xddfd60  0x773c9f02  <???>
> .........  .........  ... more frames ...
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> 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
> .
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
> ***    pc = 0x12ec5ad = Move + 0x50 in ..\src\runtime\common\RTCollector.m3
> ***
>  
>  
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
>  
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Wednesday, March 02, 2011 8:18 PM
> To: Coleburn, Randy; m3devel
> Subject: RE: [M3devel] results of threadtest program on Windows7
>  
> Even with the change I made PutCard to PutInt?
> That's the only failure I've seen.
> I'll try on a non-virtual dual-proc machine later.
>  
> Thanks,
>  - Jay
>  
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Wed, 2 Mar 2011 19:42:47 -0500
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Yes, it fails more often than it runs for me.
> Regards,
> Randy
>  
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Tuesday, March 01, 2011 5:59 AM
> To: Mika Nystrom; Coleburn, Randy
> Cc: m3devel
> Subject: RE: [M3devel] results of threadtest program on Windows7
>  
> I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
> I've run it just a few times now. One single and dual processor virtual machines.
> Randy, has it failed many times for you?
> 
>  - Jay
> 
> > To: rcolebur at SCIRES.COM
> > Date: Sun, 27 Feb 2011 15:11:25 -0800
> > From: mika at async.caltech.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] results of threadtest program on Windows7
> > 
> > Ah, it just doesn't check command-line arguments that carefully.
> > 
> > I think what you did is equivalent to "-tests STD".
> > 
> > Mika
> > 
> > "Coleburn, Randy" writes:
> > >Mika:
> > >
> > >No change with "-tests POSIX".
> > >
> > >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> > >ptions are, and I typed "threadtest -help" rather than reading the code.
> > >
> > >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> > >d it again and it ran to completion. Something seems non-deterministic her=
> > >e. See below.
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >.
> > >
> > >***
> > >*** runtime error:
> > >*** Attempt to reference an illegal memory location.
> > >*** pc =3D 0x77762262
> > >***
> > >
> > >Stack trace:
> > > FP PC Procedure
> > >--------- --------- -------------------------------
> > > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> > >3
> > > 0xcdf9c0 0x77762262 <???>
> > > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> > >3
> > > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> > >.m3
> > > 0xcdfb80 0x76543677 <???>
> > > 0xcdfbc0 0x77779f02 <???>
> > >......... ......... ... more frames ...
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >All tests complete. Congratulations.
> > >
> > >Regards,
> > >Randy Coleburn
> > >
> > >-----Original Message-----
> > >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> > >Sent: Sunday, February 27, 2011 3:30 PM
> > >To: Coleburn, Randy
> > >Cc: m3devel at elegosoft.com
> > >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> > >
> > >Hi Randy,
> > >
> > >You can try it with -tests POSIX as well.
> > >
> > >I find on user threads it runs very slowly (but it does run) because of how=
> > > unfair
> > >the thread scheduler is.
> > >
> > >Next step might be to whittle down the tests and see if you can get a failu=
> > >re with
> > >a single test running and -n 2. That would likely be the simplest scenario=
> > > to
> > >start further debugging from.
> > >
> > > Mika
> > >
> > >"Coleburn, Randy" writes:
> > >>Mika et al:
> > >>
> > >>Thought I would try something else.
> > >>
> > >>I took the sources of your thread test program to an older XP machine that=
> > > =3D
> > >>has CM3 circa August 2008. This is the machine and implementation I used =
> > >w=3D
> > >>hen building a major project I did a couple years back.
> > >>
> > >>The thread test program does indeed build on this old system, but when I r=
> > >u=3D
> > >>n it, I get different results than with the latest HEAD branch code. =3D20
> > >>
> > >>After it prints "running...printing oldest/median age/newest", on the next=
> > > =3D
> > >>line I get two periods ".." and now the program seems hung. I'll let it "=
> > >r=3D
> > >>un" for a few more minutes to see if anything else happens before killing =
> > >i=3D
> > >>t.
> > >>
> > >>At least we don't get the subscript and assertion failures on this older C=
> > >M=3D
> > >>3 platform.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>
> > >>-----Original Message-----
> > >>From: Coleburn, Randy=3D20
> > >>Sent: Sunday, February 27, 2011 2:09 PM
> > >>To: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7
> > >>
> > >>Mika:
> > >>
> > >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> > >>
> > >>Here is what happens now when I run your threadtest program on Windows 7.
> > >>
> > >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> > >r=3D
> > >>k
> > >>Writing file...done
> > >>Creating read threads...done
> > >>Creating nxread threads...done
> > >>Creating tryexcept threads...done
> > >>Creating forktoomuch threads...done
> > >>Creating alloc threads...done
> > >>Creating creat threads...done
> > >>Creating lock threads...done
> > >>running...printing oldest/median age/newest
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** An array subscript was out of range.
> > >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> > >>***
> > >>
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** <*ASSERT*> failed.
> > >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> > >>***
> > >>
> > >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> > >>
> > >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> > >.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>-----Original Message-----
> > >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> > >>Sent: Saturday, February 26, 2011 12:55 PM
> > >>To: Coleburn, Randy
> > >>Cc: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> > >>
> > >>Hi Randy,
> > >>
> > >>Hm yes it looks like my Windows programming skills leave something
> > >>to be desired.
> > >>
> > >>You can run the thread tester while skipping a test as follows
> > >>
> > >> threadtest -tests ALL,-fork
> > >>
> > >>(for instance)
> > >>
> > >>if you just run=3D20
> > >>
> > >> threadtest -sadfassdaf
> > >>
> > >>it'll print the tests that are available.
> > >>
> > >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> > >>Can you give me a very brief description of what you did to install Modula=
> > >-=3D
> > >>3
> > >>on this system?
> > >>
> > >> Mika
> > >>
> > >>"Coleburn, Randy" writes:
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>
> > >>>Mika:
> > >>>
> > >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> > >>>
> > >>>So, I ran your threadtest program.
> > >>>
> > >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> > >e=3D
> > >>p=3D3D
> > >>>eating "ERROR FApply" messages.
> > >>>
> > >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > >>>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
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>***
> > >>>*** runtime error:
> > >>>*** An enumeration or subrange value was out of range.
> > >>>*** file "..\src\Main.m3", line 340
> > >>>***
> > >>>
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>Stack trace:
> > >>> FP PC Procedure
> > >>>--------- --------- -------------------------------
> > >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> > >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> > >>>
> > >>>Regards,
> > >>>Randy Coleburn
> > >>>
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/html; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110303/63ad1ce4/attachment-0001.html>

From hosking at cs.purdue.edu  Thu Mar  3 16:40:35 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 3 Mar 2011 10:40:35 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W2637AB63DA6D9866A00D07E6C30@phx.gbl>
References: <COL101-W4726257303F22627175774E6C30@phx.gbl>,
	<974355.12644.qm@web29717.mail.ird.yahoo.com>
	<COL101-W2637AB63DA6D9866A00D07E6C30@phx.gbl>
Message-ID: <12DDA3F3-61D8-47B6-AF76-9362068A061A@cs.purdue.edu>

The bug is not necessarily there.  If the collector is not kept properly informed of the mutator's actions or the pointers it holds in its stacks then the world will break.  What has changed recently that might affect the collector and allocator?

On Mar 2, 2011, at 9:46 PM, Jay K wrote:

> There is probably a bug in RTCollector.m3 or RTAllocator.m3.
> 
>  - Jay
> 
> Date: Thu, 3 Mar 2011 02:27:58 +0000
> From: dabenavidesd at yahoo.es
> Subject: Re: [M3devel] results of threadtest program on Windows7
> To: rcolebur at scires.com; m3devel at elegosoft.com; jay.krell at cornell.edu
> 
> Hi all:
> I would doubt but there could be some source of problem in smp on the Win32 platform, since there was a SPINE implementation on an intelligent NIC with 2 embedded MIPS CPUs, perhaps this was just a driver RT but it was for real time and in such a case there should be no problem besides that of the scheduling policy, but thinking how about linking MS Win2k R is a kind of crazy not to believe there was some synchronization with CPU board threads and that component threading at some point I believe.
> 
> Even more in embedded systems, there was a MPU implementation of it in 80186 a decade ago,  perhaps would be good to have a look of their Thread interface implementation it might be seem interesting if so.
> 
> But in any case there should be plenty of ways of implementing the threading tests incrementally of number of threads, besides you may want to check some uniprocessors with hyperThreading technology (sort of thread physical divisions inside the cpu), they are presented to OS as 2 smp processors, it could be interesting, I remember to test  time ago in this machines and anything weird happened, but quite time ago with ThreadPthread LINUXLIBC6 systems with normally distributed programs.
>  
> What about results in Win2k ?
> Thanks in advance
> 
> --- El mi?, 2/3/11, Jay K <jay.krell at cornell.edu> escribi?:
> 
> De: Jay K <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] results of threadtest program on Windows7
> Para: rcolebur at scires.com, "m3devel" <m3devel at elegosoft.com>
> Fecha: mi?rcoles, 2 de marzo, 2011 20:17
> 
> Even with the change I made PutCard to PutInt?
> That's the only failure I've seen.
> I'll try on a non-virtual dual-proc machine later.
>  
> Thanks,
>  - Jay
>  
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Wed, 2 Mar 2011 19:42:47 -0500
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Yes, it fails more often than it runs for me.
> Regards,
> Randy
>  
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Tuesday, March 01, 2011 5:59 AM
> To: Mika Nystrom; Coleburn, Randy
> Cc: m3devel
> Subject: RE: [M3devel] results of threadtest program on Windows7
>  
> I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
> I've run it just a few times now. One single and dual processor virtual machines.
> Randy, has it failed many times for you?
> 
>  - Jay
> 
> > To: rcolebur at SCIRES.COM
> > Date: Sun, 27 Feb 2011 15:11:25 -0800
> > From: mika at async.caltech.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] results of threadtest program on Windows7
> > 
> > Ah, it just doesn't check command-line arguments that carefully.
> > 
> > I think what you did is equivalent to "-tests STD".
> > 
> > Mika
> > 
> > "Coleburn, Randy" writes:
> > >Mika:
> > >
> > >No change with "-tests POSIX".
> > >
> > >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> > >ptions are, and I typed "threadtest -help" rather than reading the code.
> > >
> > >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> > >d it again and it ran to completion. Something seems non-deterministic her=
> > >e. See below.
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >.
> > >
> > >***
> > >*** runtime error:
> > >*** Attempt to reference an illegal memory location.
> > >*** pc =3D 0x77762262
> > >***
> > >
> > >Stack trace:
> > > FP PC Procedure
> > >--------- --------- -------------------------------
> > > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> > >3
> > > 0xcdf9c0 0x77762262 <???>
> > > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> > >3
> > > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> > >.m3
> > > 0xcdfb80 0x76543677 <???>
> > > 0xcdfbc0 0x77779f02 <???>
> > >......... ......... ... more frames ...
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >All tests complete. Congratulations.
> > >
> > >Regards,
> > >Randy Coleburn
> > >
> > >-----Original Message-----
> > >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> > >Sent: Sunday, February 27, 2011 3:30 PM
> > >To: Coleburn, Randy
> > >Cc: m3devel at elegosoft.com
> > >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> > >
> > >Hi Randy,
> > >
> > >You can try it with -tests POSIX as well.
> > >
> > >I find on user threads it runs very slowly (but it does run) because of how=
> > > unfair
> > >the thread scheduler is.
> > >
> > >Next step might be to whittle down the tests and see if you can get a failu=
> > >re with
> > >a single test running and -n 2. That would likely be the simplest scenario=
> > > to
> > >start further debugging from.
> > >
> > > Mika
> > >
> > >"Coleburn, Randy" writes:
> > >>Mika et al:
> > >>
> > >>Thought I would try something else.
> > >>
> > >>I took the sources of your thread test program to an older XP machine that=
> > > =3D
> > >>has CM3 circa August 2008. This is the machine and implementation I used =
> > >w=3D
> > >>hen building a major project I did a couple years back.
> > >>
> > >>The thread test program does indeed build on this old system, but when I r=
> > >u=3D
> > >>n it, I get different results than with the latest HEAD branch code. =3D20
> > >>
> > >>After it prints "running...printing oldest/median age/newest", on the next=
> > > =3D
> > >>line I get two periods ".." and now the program seems hung. I'll let it "=
> > >r=3D
> > >>un" for a few more minutes to see if anything else happens before killing =
> > >i=3D
> > >>t.
> > >>
> > >>At least we don't get the subscript and assertion failures on this older C=
> > >M=3D
> > >>3 platform.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>
> > >>-----Original Message-----
> > >>From: Coleburn, Randy=3D20
> > >>Sent: Sunday, February 27, 2011 2:09 PM
> > >>To: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7
> > >>
> > >>Mika:
> > >>
> > >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> > >>
> > >>Here is what happens now when I run your threadtest program on Windows 7.
> > >>
> > >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> > >r=3D
> > >>k
> > >>Writing file...done
> > >>Creating read threads...done
> > >>Creating nxread threads...done
> > >>Creating tryexcept threads...done
> > >>Creating forktoomuch threads...done
> > >>Creating alloc threads...done
> > >>Creating creat threads...done
> > >>Creating lock threads...done
> > >>running...printing oldest/median age/newest
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** An array subscript was out of range.
> > >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> > >>***
> > >>
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** <*ASSERT*> failed.
> > >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> > >>***
> > >>
> > >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> > >>
> > >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> > >.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>-----Original Message-----
> > >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> > >>Sent: Saturday, February 26, 2011 12:55 PM
> > >>To: Coleburn, Randy
> > >>Cc: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> > >>
> > >>Hi Randy,
> > >>
> > >>Hm yes it looks like my Windows programming skills leave something
> > >>to be desired.
> > >>
> > >>You can run the thread tester while skipping a test as follows
> > >>
> > >> threadtest -tests ALL,-fork
> > >>
> > >>(for instance)
> > >>
> > >>if you just run=3D20
> > >>
> > >> threadtest -sadfassdaf
> > >>
> > >>it'll print the tests that are available.
> > >>
> > >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> > >>Can you give me a very brief description of what you did to install Modula=
> > >-=3D
> > >>3
> > >>on this system?
> > >>
> > >> Mika
> > >>
> > >>"Coleburn, Randy" writes:
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>
> > >>>Mika:
> > >>>
> > >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> > >>>
> > >>>So, I ran your threadtest program.
> > >>>
> > >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> > >e=3D
> > >>p=3D3D
> > >>>eating "ERROR FApply" messages.
> > >>>
> > >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > >>>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
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>***
> > >>>*** runtime error:
> > >>>*** An enumeration or subrange value was out of range.
> > >>>*** file "..\src\Main.m3", line 340
> > >>>***
> > >>>
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>Stack trace:
> > >>> FP PC Procedure
> > >>>--------- --------- -------------------------------
> > >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> > >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> > >>>
> > >>>Regards,
> > >>>Randy Coleburn
> > >>>
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/html; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110303/fbecdef7/attachment-0001.html>

From hosking at cs.purdue.edu  Thu Mar  3 16:41:48 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 3 Mar 2011 10:41:48 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W52252742B56CBFEAD0A0DFE6C30@phx.gbl>
References: <COL101-W4726257303F22627175774E6C30@phx.gbl>,
	<974355.12644.qm@web29717.mail.ird.yahoo.com>,
	<COL101-W2637AB63DA6D9866A00D07E6C30@phx.gbl>,
	<COL101-W1943F7B289FE5FD33E5D1EE6C30@phx.gbl>
	<COL101-W52252742B56CBFEAD0A0DFE6C30@phx.gbl>
Message-ID: <5572AFA1-4813-4556-B900-B53C1B3F4A00@cs.purdue.edu>

Again, the problem is not necessarily in the collector/allocator.  There has been a lot of churn lately in the threads implementations which could result in confusing the memory manager.


On Mar 3, 2011, at 1:37 AM, Jay K wrote:

> Here is another failure also I386_DARWIN.
> 
> 
> (gdb) break RTError__MsgS
> Breakpoint 2 at 0x3b65f: file ../src/runtime/common/RTError.m3, line 30.
> (gdb) run
> The program being debugged has been started already.
> Start it from the beginning? (y or n) y
> Starting program: /Users/jay/dev2/cm3/m3-libs/m3core/tests/thread/I386_DARWIN/threadtest 
> 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
> ..[Switching to process 86430 thread 0x1503]
> 
> Breakpoint 2, RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:30
> 30        StartError (msgA, msgB, msgC);
> (gdb) bt
> #0  RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:30
> #1  0x0003bdc7 in RTException__Crash (a=0xb040ea64, raises=0 '\0', rte=0x7d100) at ../src/runtime/common/RTException.m3:79
> #2  0x0003bb21 in RTException__DefaultBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:39
> #3  0x0003ba7c in RTException__InvokeBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
> #4  0x00043ca5 in RTException__Raise (act=0xb040ea64) at ../src/runtime/ex_frame/RTExFrame.m3:85
> #5  0x0003bbb4 in RTException__DefaultBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:47
> #6  0x0003ba7c in RTException__InvokeBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
> #7  0x00043ca5 in RTException__Raise (act=0xb040ea64) at ../src/runtime/ex_frame/RTExFrame.m3:85
> #8  0x0002b102 in RTHooks__ReportFault (module=0x70f80, info=13378) at ../src/runtime/common/RTHooks.m3:111
> #9  0x000394c5 in _m3_fault (arg=13378) at ../src/runtime/common/RTCollector.m3:393
> #10 0x0002fdd2 in RTCollector__Move (self=0xb4000c, cp=0xba0014) at ../src/runtime/common/RTCollector.m3:418
> #11 0x0002e503 in RTHeapMap__Walk (x=0xba0014, pc=0x79928, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:202
> #12 0x0002dc9c in RTHeapMap__DoWalkRef (t=0x6de54, a=0xba0014, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:62
> #13 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e3f4, a=0xba000c, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:57
> #14 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e508, a=0xba000c, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:57
> #15 0x0002dc2e in RTHeapMap__WalkRef (h=0xba0008, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:47
> #16 0x00032279 in RTCollector__CleanBetween (h=0xba0008, he=0xbb0000, clean=0 '\0') at ../src/runtime/common/RTCollector.m3:1091
> #17 0x00032098 in RTCollector__CleanPage (page=0xba0000) at ../src/runtime/common/RTCollector.m3:1064
> #18 0x00031798 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885
> #19 0x00030e75 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720
> #20 0x00030a97 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654
> #21 0x0002cb85 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00e74) at ../src/runtime/common/RTAllocator.m3:367
> #22 0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:296
> #23 0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:143
> #24 0x00003b5f in Main__AApply (cl=0x9556c0) at ../src/Main.m3:260
> #25 0x00046ee2 in ThreadPThread__RunThread (me=0xa00e30) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #26 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00e30) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #27 0x93889155 in _pthread_start ()
> #28 0x93889012 in thread_start ()
> (gdb) threads apply all bt
> Undefined command: "threads".  Try "help".
> (gdb) thread apply all bt
> 
> Thread 13 (process 86430 thread 0x1903):
> #0  0x9388a6f1 in semaphore_wait_signal ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00880) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #4  0x00003ed8 in Main__LApply (cl=0x9557d8) at ../src/Main.m3:290
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa010f0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa010f0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 12 (process 86430 thread 0x1803):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00880) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #4  0x00003ed8 in Main__LApply (cl=0x9557a0) at ../src/Main.m3:290
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01040) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01040) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 11 (process 86430 thread 0x1703):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00880) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #4  0x00003ed8 in Main__LApply (cl=0x955768) at ../src/Main.m3:290
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00f90) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00f90) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 10 (process 86430 thread 0x1603):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00f24) at ../src/runtime/common/RTAllocator.m3:365
> #5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:296
> #6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:143
> #7  0x00003b5f in Main__AApply (cl=0x9556f8) at ../src/Main.m3:260
> #8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00ee0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00ee0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #10 0x93889155 in _pthread_start ()
> #11 0x93889012 in thread_start ()
> 
> Thread 9 (process 86430 thread 0x1503):
> #0  RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:30
> #1  0x0003bdc7 in RTException__Crash (a=0xb040ea64, raises=0 '\0', rte=0x7d100) at ../src/runtime/common/RTException.m3:79
> #2  0x0003bb21 in RTException__DefaultBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:39
> #3  0x0003ba7c in RTException__InvokeBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
> #4  0x00043ca5 in RTException__Raise (act=0xb040ea64) at ../src/runtime/ex_frame/RTExFrame.m3:85
> #5  0x0003bbb4 in RTException__DefaultBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:47
> #6  0x0003ba7c in RTException__InvokeBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
> #7  0x00043ca5 in RTException__Raise (act=0xb040ea64) at ../src/runtime/ex_frame/RTExFrame.m3:85
> #8  0x0002b102 in RTHooks__ReportFault (module=0x70f80, info=13378) at ../src/runtime/common/RTHooks.m3:111
> #9  0x000394c5 in _m3_fault (arg=13378) at ../src/runtime/common/RTCollector.m3:393
> #10 0x0002fdd2 in RTCollector__Move (self=0xb4000c, cp=0xba0014) at ../src/runtime/common/RTCollector.m3:418
> #11 0x0002e503 in RTHeapMap__Walk (x=0xba0014, pc=0x79928, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:202
> #12 0x0002dc9c in RTHeapMap__DoWalkRef (t=0x6de54, a=0xba0014, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:62
> #13 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e3f4, a=0xba000c, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:57
> #14 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e508, a=0xba000c, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:57
> #15 0x0002dc2e in RTHeapMap__WalkRef (h=0xba0008, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:47
> #16 0x00032279 in RTCollector__CleanBetween (h=0xba0008, he=0xbb0000, clean=0 '\0') at ../src/runtime/common/RTCollector.m3:1091
> #17 0x00032098 in RTCollector__CleanPage (page=0xba0000) at ../src/runtime/common/RTCollector.m3:1064
> #18 0x00031798 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885
> #19 0x00030e75 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720
> #20 0x00030a97 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654
> #21 0x0002cb85 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00e74) at ../src/runtime/common/RTAllocator.m3:367
> #22 0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:296
> #23 0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:143
> #24 0x00003b5f in Main__AApply (cl=0x9556c0) at ../src/Main.m3:260
> #25 0x00046ee2 in ThreadPThread__RunThread (me=0xa00e30) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #26 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00e30) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #27 0x93889155 in _pthread_start ()
> #28 0x93889012 in thread_start ()
> 
> Thread 8 (process 86430 thread 0x1403):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00dc4) at ../src/runtime/common/RTAllocator.m3:365
> #5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:296
> #6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:143
> #7  0x00003b5f in Main__AApply (cl=0x955688) at ../src/Main.m3:260
> #8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00d80) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00d80) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #10 0x93889155 in _pthread_start ()
> #11 0x93889012 in thread_start ()
> 
> Thread 7 (process 86430 thread 0x1303):
> #0  0x9389c856 in __wait4 ()
> #1  0x9389c847 in waitpid$UNIX2003 ()
> #2  0x0004b222 in Uexec__waitpid (i=86436, j=0xb030ad9c, k=0) at ../src/unix/Common/Uexec.c:67
> #3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86436, status=0xb030ad9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
> #4  0x0000d66a in Process__Wait (p=0xb00018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
> #5  0x00003719 in Main__FApply (cl=0x955618) at ../src/Main.m3:230
> #6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00d20) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00d20) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #8  0x93889155 in _pthread_start ()
> #9  0x93889012 in thread_start ()
> 
> Thread 6 (process 86430 thread 0x1203):
> #0  0x9389c856 in __wait4 ()
> #1  0x9389c847 in waitpid$UNIX2003 ()
> #2  0x0004b222 in Uexec__waitpid (i=86437, j=0xb0288d9c, k=0) at ../src/unix/Common/Uexec.c:67
> #3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86437, status=0xb0288d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
> #4  0x0000d66a in Process__Wait (p=0xbd0018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
> #5  0x00003719 in Main__FApply (cl=0x9555e0) at ../src/Main.m3:230
> #6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00b30) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00b30) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #8  0x93889155 in _pthread_start ()
> #9  0x93889012 in thread_start ()
> 
> Thread 5 (process 86430 thread 0x1103):
> #0  0x9389c856 in __wait4 ()
> #1  0x9389c847 in waitpid$UNIX2003 ()
> #2  0x0004b222 in Uexec__waitpid (i=86435, j=0xb0206d9c, k=0) at ../src/unix/Common/Uexec.c:67
> #3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86435, status=0xb0206d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
> #4  0x0000d66a in Process__Wait (p=0xc2000c) at ../src/os/POSIX/ProcessPosixCommon.m3:275
> #5  0x00003719 in Main__FApply (cl=0x9555a8) at ../src/Main.m3:230
> #6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00a80) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00a80) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #8  0x93889155 in _pthread_start ()
> #9  0x93889012 in thread_start ()
> 
> Thread 4 (process 86430 thread 0x1003):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=12, dataAlignment=4, thread=0xa00a14) at ../src/runtime/common/RTAllocator.m3:365
> #5  0x0002bf13 in RTAllocator__GetTracedObj (def=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:224
> #6  0x0002b98a in RTHooks__AllocateTracedObj (defn=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:122
> #7  0x00008eeb in FilePosix__New (fd=5, ds=1) at ../src/os/POSIX/FilePosix.m3:63
> #8  0x0000a4eb in FS__OpenFileReadonly (pn=0x775b8) at ../src/os/POSIX/FSPosix.m3:182
> #9  0x00014dfa in FileRd__Open (p=0x775b8) at ../src/rw/FileRd.m3:16
> #10 0x00003046 in Main__RApply (cl=0x955538) at ../src/Main.m3:174
> #11 0x00046ee2 in ThreadPThread__RunThread (me=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #12 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #13 0x93889155 in _pthread_start ()
> #14 0x93889012 in thread_start ()
> 
> Thread 3 (process 86430 thread 0x117):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x74220) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00044f3a in ThreadPThread__InitMutex (m=0x960010, root=0x96000c, Clean=0x44dac) at ../src/thread/PTHREAD/ThreadPThread.m3:101
> #4  0x0004500b in ThreadPThread__LockMutex (m=0x96000c) at ../src/thread/PTHREAD/ThreadPThread.m3:117
> #5  0x0000e060 in Rd__GetChar (rd=0x96000c) at ../src/rw/Rd.m3:33
> #6  0x000030b5 in Main__RApply (cl=0x955500) at ../src/Main.m3:177
> #7  0x00046ee2 in ThreadPThread__RunThread (me=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #8  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #9  0x93889155 in _pthread_start ()
> #10 0x93889012 in thread_start ()
> 
> Thread 2 (process 86430 thread 0x313):
> #0  0x938582a2 in semaphore_wait_trap ()
> #1  0x9385fd92 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x00036509 in RTHeapRep__RegisterFinalCleanup (r=0x9b1050, p=0x44dac) at ../src/runtime/common/RTCollector.m3:2148
> #5  0x00044fa2 in ThreadPThread__InitMutex (m=0x9b1054, root=0x9b1050, Clean=0x44dac) at ../src/thread/PTHREAD/ThreadPThread.m3:106
> #6  0x0004500b in ThreadPThread__LockMutex (m=0x9b1050) at ../src/thread/PTHREAD/ThreadPThread.m3:117
> #7  0x0000e060 in Rd__GetChar (rd=0x9b1050) at ../src/rw/Rd.m3:33
> #8  0x000030b5 in Main__RApply (cl=0x9554c8) at ../src/Main.m3:177
> #9  0x00046ee2 in ThreadPThread__RunThread (me=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #10 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #11 0x93889155 in _pthread_start ()
> #12 0x93889012 in thread_start ()
> 
> Thread 1 (process 86430 local thread 0x4507):
> #0  0x9385f44e in __semwait_signal ()
> #1  0x9388a3e6 in _pthread_cond_wait ()
> #2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
> #3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299134070.4957981) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
> #4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
> #5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
> #6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
> #7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
> #8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
> #9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
> #10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16
> 
>  - Jay
> 
> 
> From: jay.krell at cornell.edu
> To: dabenavidesd at yahoo.es; rcolebur at scires.com; m3devel at elegosoft.com
> Subject: RE: [M3devel] results of threadtest program on Windows7
> Date: Thu, 3 Mar 2011 06:32:50 +0000
> 
> Solaris doesn't hang now. I didn't change anything. And it succeeds.
> Here are some stacks for a failure on I386_DARWIN.
> Notice that it *should* abort right after the EBUSY print, but it still run a while.
> Possibly too much information is lost.
> 
> 
> (gdb) run
> Starting program: /Users/jay/dev2/cm3/m3-libs/m3core/tests/thread/I386_DARWIN/threadtest 
> Reading symbols for shared libraries ++. done
> 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
> ..........laziest thread is 1/0/0 (tests: read 0/0/0 fork 1/1/1 alloc 0/0/0 lock 0/0/0)
> .........pthread_mutex_destroy:EBUSY (0)
> .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:
> ***    An array subscript was out of range.
> ***    file "../src/runtime/common/RTCollector.m3", line 418
> ***
> 
> 
> Program received signal SIGABRT, Aborted.
> 0x9385f44e in __semwait_signal ()
> (gdb) bt
> #0  0x9385f44e in __semwait_signal ()
> #1  0x9388a3e6 in _pthread_cond_wait ()
> #2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
> #3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299133562.375689) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
> #4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
> #5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
> #6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
> #7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
> #8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
> #9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
> #10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16
> 
> 
> (gdb) thread apply all bt
> 
> Thread 13 (process 86311 thread 0x2a03):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #4  0x00003ed8 in Main__LApply (cl=0x9557d8) at ../src/Main.m3:290
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01130) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01130) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 12 (process 86311 thread 0x1f03):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #4  0x00003ed8 in Main__LApply (cl=0x9557a0) at ../src/Main.m3:290
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01080) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01080) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 11 (process 86311 thread 0x1e03):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #4  0x00003ed8 in Main__LApply (cl=0x955768) at ../src/Main.m3:290
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 10 (process 86311 thread 0x1d03):
> #0  0x93934136 in __semwait_signal_nocancel ()
> #1  0x93933d1b in nanosleep$NOCANCEL$UNIX2003 ()
> #2  0x9392d013 in usleep$NOCANCEL$UNIX2003 ()
> #3  0x93944685 in abort ()
> #4  0x0004b5e6 in Cstdlib__abort () at ../src/C/Common/CstdlibC.c:21
> #5  0x000434dd in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20
> #6  0x0003d51f in RTProcess__Crash (msg=0x0) at ../src/runtime/common/RTProcess.m3:65
> #7  0x0003b9d3 in RTError__EndError (crash=1 '\001') at ../src/runtime/common/RTError.m3:118
> #8  0x0003b6e6 in RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:40
> #9  0x0003bdc7 in RTException__Crash (a=0xb0490a64, raises=0 '\0', rte=0x7d100) at ../src/runtime/common/RTException.m3:79
> #10 0x0003bb21 in RTException__DefaultBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:39
> #11 0x0003ba7c in RTException__InvokeBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
> #12 0x00043ca5 in RTException__Raise (act=0xb0490a64) at ../src/runtime/ex_frame/RTExFrame.m3:85
> #13 0x0003bbb4 in RTException__DefaultBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:47
> #14 0x0003ba7c in RTException__InvokeBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
> #15 0x00043ca5 in RTException__Raise (act=0xb0490a64) at ../src/runtime/ex_frame/RTExFrame.m3:85
> #16 0x0002b102 in RTHooks__ReportFault (module=0x70f80, info=13378) at ../src/runtime/common/RTHooks.m3:111
> #17 0x000394c5 in _m3_fault (arg=13378) at ../src/runtime/common/RTCollector.m3:393
> #18 0x0002fdd2 in RTCollector__Move (self=0xb3000c, cp=0x9a0014) at ../src/runtime/common/RTCollector.m3:418
> #19 0x0002e503 in RTHeapMap__Walk (x=0x9a0014, pc=0x79928, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:202
> #20 0x0002dc9c in RTHeapMap__DoWalkRef (t=0x6de54, a=0x9a0014, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:62
> #21 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e3f4, a=0x9a000c, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:57
> #22 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e508, a=0x9a000c, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:57
> #23 0x0002dc2e in RTHeapMap__WalkRef (h=0x9a0008, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:47
> #24 0x00032279 in RTCollector__CleanBetween (h=0x9a0008, he=0x9b0000, clean=0 '\0') at ../src/runtime/common/RTCollector.m3:1091
> #25 0x00032098 in RTCollector__CleanPage (page=0x9a0000) at ../src/runtime/common/RTCollector.m3:1064
> #26 0x00031798 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885
> #27 0x00030e75 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720
> #28 0x00030a97 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654
> #29 0x0002cb85 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00f64) at ../src/runtime/common/RTAllocator.m3:367
> #30 0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:296
> #31 0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:143
> #32 0x00003b5f in Main__AApply (cl=0x9556f8) at ../src/Main.m3:260
> #33 0x00046ee2 in ThreadPThread__RunThread (me=0xa00f20) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #34 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00f20) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #35 0x93889155 in _pthread_start ()
> #36 0x93889012 in thread_start ()
> 
> Thread 9 (process 86311 thread 0x1c03):
> #0  0x938582a2 in semaphore_wait_trap ()
> #1  0x9385fd92 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00eb4) at ../src/runtime/common/RTAllocator.m3:365
> #5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:296
> #6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:143
> #7  0x00003b5f in Main__AApply (cl=0x9556c0) at ../src/Main.m3:260
> #8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00e70) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00e70) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #10 0x93889155 in _pthread_start ()
> #11 0x93889012 in thread_start ()
> 
> Thread 8 (process 86311 thread 0x1b03):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00e04) at ../src/runtime/common/RTAllocator.m3:365
> #5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:296
> #6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:143
> #7  0x00003b5f in Main__AApply (cl=0x955688) at ../src/Main.m3:260
> #8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00dc0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00dc0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #10 0x93889155 in _pthread_start ()
> #11 0x93889012 in thread_start ()
> 
> Thread 7 (process 86311 thread 0x1a03):
> #0  0x9389c856 in __wait4 ()
> #1  0x9389c847 in waitpid$UNIX2003 ()
> #2  0x0004b222 in Uexec__waitpid (i=86384, j=0xb030ad9c, k=0) at ../src/unix/Common/Uexec.c:67
> #3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86384, status=0xb030ad9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
> #4  0x0000d66a in Process__Wait (p=0xb00018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
> #5  0x00003719 in Main__FApply (cl=0x955618) at ../src/Main.m3:230
> #6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00d60) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00d60) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #8  0x93889155 in _pthread_start ()
> #9  0x93889012 in thread_start ()
> 
> Thread 6 (process 86311 thread 0x1903):
> #0  0x9389c856 in __wait4 ()
> #1  0x9389c847 in waitpid$UNIX2003 ()
> #2  0x0004b222 in Uexec__waitpid (i=86385, j=0xb0288d9c, k=0) at ../src/unix/Common/Uexec.c:67
> #3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86385, status=0xb0288d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
> #4  0x0000d66a in Process__Wait (p=0xbd000c) at ../src/os/POSIX/ProcessPosixCommon.m3:275
> #5  0x00003719 in Main__FApply (cl=0x9555e0) at ../src/Main.m3:230
> #6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00b70) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00b70) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #8  0x93889155 in _pthread_start ()
> #9  0x93889012 in thread_start ()
> 
> Thread 5 (process 86311 thread 0x1803):
> #0  0x9389c856 in __wait4 ()
> #1  0x9389c847 in waitpid$UNIX2003 ()
> #2  0x0004b222 in Uexec__waitpid (i=86386, j=0xb0206d9c, k=0) at ../src/unix/Common/Uexec.c:67
> #3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86386, status=0xb0206d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
> #4  0x0000d66a in Process__Wait (p=0x9d0018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
> #5  0x00003719 in Main__FApply (cl=0x9555a8) at ../src/Main.m3:230
> #6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00ac0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00ac0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #8  0x93889155 in _pthread_start ()
> #9  0x93889012 in thread_start ()
> 
> Thread 4 (process 86311 thread 0x1103):
> #0  0x9385fb99 in pthread_mutex_lock ()
> #1  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00c20) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #2  0x0004503c in ThreadPThread__LockMutex (m=0xb6000c) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #3  0x0000e060 in Rd__GetChar (rd=0xb6000c) at ../src/rw/Rd.m3:33
> #4  0x000030b5 in Main__RApply (cl=0x955538) at ../src/Main.m3:177
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 3 (process 86311 thread 0x117):
> #0  0x93859304 in pthread_getspecific ()
> #1  0x0004a529 in ThreadPThread__GetActivation () at ../src/thread/PTHREAD/ThreadPThreadC.c:309
> #2  0x00049f52 in RTHooks__PushEFrame (frame=0xb0102d20) at ../src/thread/PTHREAD/ThreadPThread.m3:1385
> #3  0x0000e07b in Rd__GetChar (rd=0x99000c) at ../src/rw/Rd.m3:33
> #4  0x000030b5 in Main__RApply (cl=0x955500) at ../src/Main.m3:177
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 2 (process 86311 thread 0x313):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=12, dataAlignment=4, thread=0xa00834) at ../src/runtime/common/RTAllocator.m3:365
> #5  0x0002bf13 in RTAllocator__GetTracedObj (def=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:224
> #6  0x0002b98a in RTHooks__AllocateTracedObj (defn=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:122
> #7  0x00008eeb in FilePosix__New (fd=5, ds=1) at ../src/os/POSIX/FilePosix.m3:63
> #8  0x0000a4eb in FS__OpenFileReadonly (pn=0x775b8) at ../src/os/POSIX/FSPosix.m3:182
> #9  0x00014dfa in FileRd__Open (p=0x775b8) at ../src/rw/FileRd.m3:16
> #10 0x00003046 in Main__RApply (cl=0x9554c8) at ../src/Main.m3:174
> #11 0x00046ee2 in ThreadPThread__RunThread (me=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #12 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #13 0x93889155 in _pthread_start ()
> #14 0x93889012 in thread_start ()
> 
> Thread 1 (process 86311 local thread 0x2e03):
> #0  0x9385f44e in __semwait_signal ()
> #1  0x9388a3e6 in _pthread_cond_wait ()
> #2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
> #3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299133562.375689) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
> #4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
> #5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
> #6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
> #7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
> #8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
> #9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
> #10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16
> 
> 
> 
> 
> 
> 
> 
> From: jay.krell at cornell.edu
> To: dabenavidesd at yahoo.es; rcolebur at scires.com; m3devel at elegosoft.com
> Subject: RE: [M3devel] results of threadtest program on Windows7
> Date: Thu, 3 Mar 2011 02:46:39 +0000
> 
> There is probably a bug in RTCollector.m3 or RTAllocator.m3.
> 
>  - Jay
> 
> Date: Thu, 3 Mar 2011 02:27:58 +0000
> From: dabenavidesd at yahoo.es
> Subject: Re: [M3devel] results of threadtest program on Windows7
> To: rcolebur at scires.com; m3devel at elegosoft.com; jay.krell at cornell.edu
> 
> Hi all:
> I would doubt but there could be some source of problem in smp on the Win32 platform, since there was a SPINE implementation on an intelligent NIC with 2 embedded MIPS CPUs, perhaps this was just a driver RT but it was for real time and in such a case there should be no problem besides that of the scheduling policy, but thinking how about linking MS Win2k R is a kind of crazy not to believe there was some synchronization with CPU board threads and that component threading at some point I believe.
> 
> Even more in embedded systems, there was a MPU implementation of it in 80186 a decade ago,  perhaps would be good to have a look of their Thread interface implementation it might be seem interesting if so.
> 
> But in any case there should be plenty of ways of implementing the threading tests incrementally of number of threads, besides you may want to check some uniprocessors with hyperThreading technology (sort of thread physical divisions inside the cpu), they are presented to OS as 2 smp processors, it could be interesting, I remember to test  time ago in this machines and anything weird happened, but quite time ago with ThreadPthread LINUXLIBC6 systems with normally distributed programs.
>  
> What about results in Win2k ?
> Thanks in advance
> 
> --- El mi?, 2/3/11, Jay K <jay.krell at cornell.edu> escribi?:
> 
> De: Jay K <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] results of threadtest program on Windows7
> Para: rcolebur at scires.com, "m3devel" <m3devel at elegosoft.com>
> Fecha: mi?rcoles, 2 de marzo, 2011 20:17
> 
> Even with the change I made PutCard to PutInt?
> That's the only failure I've seen.
> I'll try on a non-virtual dual-proc machine later.
>  
> Thanks,
>  - Jay
>  
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Wed, 2 Mar 2011 19:42:47 -0500
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Yes, it fails more often than it runs for me.
> Regards,
> Randy
>  
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Tuesday, March 01, 2011 5:59 AM
> To: Mika Nystrom; Coleburn, Randy
> Cc: m3devel
> Subject: RE: [M3devel] results of threadtest program on Windows7
>  
> I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
> I've run it just a few times now. One single and dual processor virtual machines.
> Randy, has it failed many times for you?
> 
>  - Jay
> 
> > To: rcolebur at SCIRES.COM
> > Date: Sun, 27 Feb 2011 15:11:25 -0800
> > From: mika at async.caltech.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] results of threadtest program on Windows7
> > 
> > Ah, it just doesn't check command-line arguments that carefully.
> > 
> > I think what you did is equivalent to "-tests STD".
> > 
> > Mika
> > 
> > "Coleburn, Randy" writes:
> > >Mika:
> > >
> > >No change with "-tests POSIX".
> > >
> > >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> > >ptions are, and I typed "threadtest -help" rather than reading the code.
> > >
> > >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> > >d it again and it ran to completion. Something seems non-deterministic her=
> > >e. See below.
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >.
> > >
> > >***
> > >*** runtime error:
> > >*** Attempt to reference an illegal memory location.
> > >*** pc =3D 0x77762262
> > >***
> > >
> > >Stack trace:
> > > FP PC Procedure
> > >--------- --------- -------------------------------
> > > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> > >3
> > > 0xcdf9c0 0x77762262 <???>
> > > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> > >3
> > > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> > >.m3
> > > 0xcdfb80 0x76543677 <???>
> > > 0xcdfbc0 0x77779f02 <???>
> > >......... ......... ... more frames ...
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >All tests complete. Congratulations.
> > >
> > >Regards,
> > >Randy Coleburn
> > >
> > >-----Original Message-----
> > >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> > >Sent: Sunday, February 27, 2011 3:30 PM
> > >To: Coleburn, Randy
> > >Cc: m3devel at elegosoft.com
> > >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> > >
> > >Hi Randy,
> > >
> > >You can try it with -tests POSIX as well.
> > >
> > >I find on user threads it runs very slowly (but it does run) because of how=
> > > unfair
> > >the thread scheduler is.
> > >
> > >Next step might be to whittle down the tests and see if you can get a failu=
> > >re with
> > >a single test running and -n 2. That would likely be the simplest scenario=
> > > to
> > >start further debugging from.
> > >
> > > Mika
> > >
> > >"Coleburn, Randy" writes:
> > >>Mika et al:
> > >>
> > >>Thought I would try something else.
> > >>
> > >>I took the sources of your thread test program to an older XP machine that=
> > > =3D
> > >>has CM3 circa August 2008. This is the machine and implementation I used =
> > >w=3D
> > >>hen building a major project I did a couple years back.
> > >>
> > >>The thread test program does indeed build on this old system, but when I r=
> > >u=3D
> > >>n it, I get different results than with the latest HEAD branch code. =3D20
> > >>
> > >>After it prints "running...printing oldest/median age/newest", on the next=
> > > =3D
> > >>line I get two periods ".." and now the program seems hung. I'll let it "=
> > >r=3D
> > >>un" for a few more minutes to see if anything else happens before killing =
> > >i=3D
> > >>t.
> > >>
> > >>At least we don't get the subscript and assertion failures on this older C=
> > >M=3D
> > >>3 platform.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>
> > >>-----Original Message-----
> > >>From: Coleburn, Randy=3D20
> > >>Sent: Sunday, February 27, 2011 2:09 PM
> > >>To: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7
> > >>
> > >>Mika:
> > >>
> > >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> > >>
> > >>Here is what happens now when I run your threadtest program on Windows 7.
> > >>
> > >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> > >r=3D
> > >>k
> > >>Writing file...done
> > >>Creating read threads...done
> > >>Creating nxread threads...done
> > >>Creating tryexcept threads...done
> > >>Creating forktoomuch threads...done
> > >>Creating alloc threads...done
> > >>Creating creat threads...done
> > >>Creating lock threads...done
> > >>running...printing oldest/median age/newest
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** An array subscript was out of range.
> > >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> > >>***
> > >>
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** <*ASSERT*> failed.
> > >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> > >>***
> > >>
> > >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> > >>
> > >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> > >.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>-----Original Message-----
> > >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> > >>Sent: Saturday, February 26, 2011 12:55 PM
> > >>To: Coleburn, Randy
> > >>Cc: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> > >>
> > >>Hi Randy,
> > >>
> > >>Hm yes it looks like my Windows programming skills leave something
> > >>to be desired.
> > >>
> > >>You can run the thread tester while skipping a test as follows
> > >>
> > >> threadtest -tests ALL,-fork
> > >>
> > >>(for instance)
> > >>
> > >>if you just run=3D20
> > >>
> > >> threadtest -sadfassdaf
> > >>
> > >>it'll print the tests that are available.
> > >>
> > >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> > >>Can you give me a very brief description of what you did to install Modula=
> > >-=3D
> > >>3
> > >>on this system?
> > >>
> > >> Mika
> > >>
> > >>"Coleburn, Randy" writes:
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>
> > >>>Mika:
> > >>>
> > >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> > >>>
> > >>>So, I ran your threadtest program.
> > >>>
> > >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> > >e=3D
> > >>p=3D3D
> > >>>eating "ERROR FApply" messages.
> > >>>
> > >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > >>>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
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>***
> > >>>*** runtime error:
> > >>>*** An enumeration or subrange value was out of range.
> > >>>*** file "..\src\Main.m3", line 340
> > >>>***
> > >>>
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>Stack trace:
> > >>> FP PC Procedure
> > >>>--------- --------- -------------------------------
> > >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> > >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> > >>>
> > >>>Regards,
> > >>>Randy Coleburn
> > >>>
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/html; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110303/ad2560e7/attachment-0001.html>

From hosking at cs.purdue.edu  Thu Mar  3 16:42:51 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 3 Mar 2011 10:42:51 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W1943F7B289FE5FD33E5D1EE6C30@phx.gbl>
References: <COL101-W4726257303F22627175774E6C30@phx.gbl>,
	<974355.12644.qm@web29717.mail.ird.yahoo.com>,
	<COL101-W2637AB63DA6D9866A00D07E6C30@phx.gbl>
	<COL101-W1943F7B289FE5FD33E5D1EE6C30@phx.gbl>
Message-ID: <DEFD098A-268B-41EB-B59E-03BF19CAF910@cs.purdue.edu>

Running with @M3paranoidgc should let us know how we end up with a pointer that does not refer to an object.

On Mar 3, 2011, at 1:32 AM, Jay K wrote:

> Solaris doesn't hang now. I didn't change anything. And it succeeds.
> Here are some stacks for a failure on I386_DARWIN.
> Notice that it *should* abort right after the EBUSY print, but it still run a while.
> Possibly too much information is lost.
> 
> 
> (gdb) run
> Starting program: /Users/jay/dev2/cm3/m3-libs/m3core/tests/thread/I386_DARWIN/threadtest 
> Reading symbols for shared libraries ++. done
> 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
> ..........laziest thread is 1/0/0 (tests: read 0/0/0 fork 1/1/1 alloc 0/0/0 lock 0/0/0)
> .........pthread_mutex_destroy:EBUSY (0)
> .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:
> ***    An array subscript was out of range.
> ***    file "../src/runtime/common/RTCollector.m3", line 418
> ***
> 
> 
> Program received signal SIGABRT, Aborted.
> 0x9385f44e in __semwait_signal ()
> (gdb) bt
> #0  0x9385f44e in __semwait_signal ()
> #1  0x9388a3e6 in _pthread_cond_wait ()
> #2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
> #3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299133562.375689) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
> #4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
> #5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
> #6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
> #7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
> #8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
> #9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
> #10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16
> 
> 
> (gdb) thread apply all bt
> 
> Thread 13 (process 86311 thread 0x2a03):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #4  0x00003ed8 in Main__LApply (cl=0x9557d8) at ../src/Main.m3:290
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01130) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01130) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 12 (process 86311 thread 0x1f03):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #4  0x00003ed8 in Main__LApply (cl=0x9557a0) at ../src/Main.m3:290
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01080) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01080) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 11 (process 86311 thread 0x1e03):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #4  0x00003ed8 in Main__LApply (cl=0x955768) at ../src/Main.m3:290
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 10 (process 86311 thread 0x1d03):
> #0  0x93934136 in __semwait_signal_nocancel ()
> #1  0x93933d1b in nanosleep$NOCANCEL$UNIX2003 ()
> #2  0x9392d013 in usleep$NOCANCEL$UNIX2003 ()
> #3  0x93944685 in abort ()
> #4  0x0004b5e6 in Cstdlib__abort () at ../src/C/Common/CstdlibC.c:21
> #5  0x000434dd in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20
> #6  0x0003d51f in RTProcess__Crash (msg=0x0) at ../src/runtime/common/RTProcess.m3:65
> #7  0x0003b9d3 in RTError__EndError (crash=1 '\001') at ../src/runtime/common/RTError.m3:118
> #8  0x0003b6e6 in RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:40
> #9  0x0003bdc7 in RTException__Crash (a=0xb0490a64, raises=0 '\0', rte=0x7d100) at ../src/runtime/common/RTException.m3:79
> #10 0x0003bb21 in RTException__DefaultBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:39
> #11 0x0003ba7c in RTException__InvokeBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
> #12 0x00043ca5 in RTException__Raise (act=0xb0490a64) at ../src/runtime/ex_frame/RTExFrame.m3:85
> #13 0x0003bbb4 in RTException__DefaultBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:47
> #14 0x0003ba7c in RTException__InvokeBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
> #15 0x00043ca5 in RTException__Raise (act=0xb0490a64) at ../src/runtime/ex_frame/RTExFrame.m3:85
> #16 0x0002b102 in RTHooks__ReportFault (module=0x70f80, info=13378) at ../src/runtime/common/RTHooks.m3:111
> #17 0x000394c5 in _m3_fault (arg=13378) at ../src/runtime/common/RTCollector.m3:393
> #18 0x0002fdd2 in RTCollector__Move (self=0xb3000c, cp=0x9a0014) at ../src/runtime/common/RTCollector.m3:418
> #19 0x0002e503 in RTHeapMap__Walk (x=0x9a0014, pc=0x79928, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:202
> #20 0x0002dc9c in RTHeapMap__DoWalkRef (t=0x6de54, a=0x9a0014, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:62
> #21 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e3f4, a=0x9a000c, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:57
> #22 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e508, a=0x9a000c, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:57
> #23 0x0002dc2e in RTHeapMap__WalkRef (h=0x9a0008, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:47
> #24 0x00032279 in RTCollector__CleanBetween (h=0x9a0008, he=0x9b0000, clean=0 '\0') at ../src/runtime/common/RTCollector.m3:1091
> #25 0x00032098 in RTCollector__CleanPage (page=0x9a0000) at ../src/runtime/common/RTCollector.m3:1064
> #26 0x00031798 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885
> #27 0x00030e75 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720
> #28 0x00030a97 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654
> #29 0x0002cb85 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00f64) at ../src/runtime/common/RTAllocator.m3:367
> #30 0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:296
> #31 0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:143
> #32 0x00003b5f in Main__AApply (cl=0x9556f8) at ../src/Main.m3:260
> #33 0x00046ee2 in ThreadPThread__RunThread (me=0xa00f20) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #34 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00f20) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #35 0x93889155 in _pthread_start ()
> #36 0x93889012 in thread_start ()
> 
> Thread 9 (process 86311 thread 0x1c03):
> #0  0x938582a2 in semaphore_wait_trap ()
> #1  0x9385fd92 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00eb4) at ../src/runtime/common/RTAllocator.m3:365
> #5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:296
> #6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:143
> #7  0x00003b5f in Main__AApply (cl=0x9556c0) at ../src/Main.m3:260
> #8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00e70) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00e70) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #10 0x93889155 in _pthread_start ()
> #11 0x93889012 in thread_start ()
> 
> Thread 8 (process 86311 thread 0x1b03):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00e04) at ../src/runtime/common/RTAllocator.m3:365
> #5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:296
> #6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:143
> #7  0x00003b5f in Main__AApply (cl=0x955688) at ../src/Main.m3:260
> #8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00dc0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00dc0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #10 0x93889155 in _pthread_start ()
> #11 0x93889012 in thread_start ()
> 
> Thread 7 (process 86311 thread 0x1a03):
> #0  0x9389c856 in __wait4 ()
> #1  0x9389c847 in waitpid$UNIX2003 ()
> #2  0x0004b222 in Uexec__waitpid (i=86384, j=0xb030ad9c, k=0) at ../src/unix/Common/Uexec.c:67
> #3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86384, status=0xb030ad9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
> #4  0x0000d66a in Process__Wait (p=0xb00018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
> #5  0x00003719 in Main__FApply (cl=0x955618) at ../src/Main.m3:230
> #6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00d60) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00d60) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #8  0x93889155 in _pthread_start ()
> #9  0x93889012 in thread_start ()
> 
> Thread 6 (process 86311 thread 0x1903):
> #0  0x9389c856 in __wait4 ()
> #1  0x9389c847 in waitpid$UNIX2003 ()
> #2  0x0004b222 in Uexec__waitpid (i=86385, j=0xb0288d9c, k=0) at ../src/unix/Common/Uexec.c:67
> #3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86385, status=0xb0288d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
> #4  0x0000d66a in Process__Wait (p=0xbd000c) at ../src/os/POSIX/ProcessPosixCommon.m3:275
> #5  0x00003719 in Main__FApply (cl=0x9555e0) at ../src/Main.m3:230
> #6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00b70) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00b70) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #8  0x93889155 in _pthread_start ()
> #9  0x93889012 in thread_start ()
> 
> Thread 5 (process 86311 thread 0x1803):
> #0  0x9389c856 in __wait4 ()
> #1  0x9389c847 in waitpid$UNIX2003 ()
> #2  0x0004b222 in Uexec__waitpid (i=86386, j=0xb0206d9c, k=0) at ../src/unix/Common/Uexec.c:67
> #3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86386, status=0xb0206d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
> #4  0x0000d66a in Process__Wait (p=0x9d0018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
> #5  0x00003719 in Main__FApply (cl=0x9555a8) at ../src/Main.m3:230
> #6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00ac0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00ac0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #8  0x93889155 in _pthread_start ()
> #9  0x93889012 in thread_start ()
> 
> Thread 4 (process 86311 thread 0x1103):
> #0  0x9385fb99 in pthread_mutex_lock ()
> #1  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00c20) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #2  0x0004503c in ThreadPThread__LockMutex (m=0xb6000c) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #3  0x0000e060 in Rd__GetChar (rd=0xb6000c) at ../src/rw/Rd.m3:33
> #4  0x000030b5 in Main__RApply (cl=0x955538) at ../src/Main.m3:177
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 3 (process 86311 thread 0x117):
> #0  0x93859304 in pthread_getspecific ()
> #1  0x0004a529 in ThreadPThread__GetActivation () at ../src/thread/PTHREAD/ThreadPThreadC.c:309
> #2  0x00049f52 in RTHooks__PushEFrame (frame=0xb0102d20) at ../src/thread/PTHREAD/ThreadPThread.m3:1385
> #3  0x0000e07b in Rd__GetChar (rd=0x99000c) at ../src/rw/Rd.m3:33
> #4  0x000030b5 in Main__RApply (cl=0x955500) at ../src/Main.m3:177
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 2 (process 86311 thread 0x313):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=12, dataAlignment=4, thread=0xa00834) at ../src/runtime/common/RTAllocator.m3:365
> #5  0x0002bf13 in RTAllocator__GetTracedObj (def=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:224
> #6  0x0002b98a in RTHooks__AllocateTracedObj (defn=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:122
> #7  0x00008eeb in FilePosix__New (fd=5, ds=1) at ../src/os/POSIX/FilePosix.m3:63
> #8  0x0000a4eb in FS__OpenFileReadonly (pn=0x775b8) at ../src/os/POSIX/FSPosix.m3:182
> #9  0x00014dfa in FileRd__Open (p=0x775b8) at ../src/rw/FileRd.m3:16
> #10 0x00003046 in Main__RApply (cl=0x9554c8) at ../src/Main.m3:174
> #11 0x00046ee2 in ThreadPThread__RunThread (me=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #12 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #13 0x93889155 in _pthread_start ()
> #14 0x93889012 in thread_start ()
> 
> Thread 1 (process 86311 local thread 0x2e03):
> #0  0x9385f44e in __semwait_signal ()
> #1  0x9388a3e6 in _pthread_cond_wait ()
> #2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
> #3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299133562.375689) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
> #4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
> #5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
> #6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
> #7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
> #8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
> #9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
> #10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16
> 
> 
> 
> 
> 
> 
> 
> From: jay.krell at cornell.edu
> To: dabenavidesd at yahoo.es; rcolebur at scires.com; m3devel at elegosoft.com
> Subject: RE: [M3devel] results of threadtest program on Windows7
> Date: Thu, 3 Mar 2011 02:46:39 +0000
> 
> There is probably a bug in RTCollector.m3 or RTAllocator.m3.
> 
>  - Jay
> 
> Date: Thu, 3 Mar 2011 02:27:58 +0000
> From: dabenavidesd at yahoo.es
> Subject: Re: [M3devel] results of threadtest program on Windows7
> To: rcolebur at scires.com; m3devel at elegosoft.com; jay.krell at cornell.edu
> 
> Hi all:
> I would doubt but there could be some source of problem in smp on the Win32 platform, since there was a SPINE implementation on an intelligent NIC with 2 embedded MIPS CPUs, perhaps this was just a driver RT but it was for real time and in such a case there should be no problem besides that of the scheduling policy, but thinking how about linking MS Win2k R is a kind of crazy not to believe there was some synchronization with CPU board threads and that component threading at some point I believe.
> 
> Even more in embedded systems, there was a MPU implementation of it in 80186 a decade ago,  perhaps would be good to have a look of their Thread interface implementation it might be seem interesting if so.
> 
> But in any case there should be plenty of ways of implementing the threading tests incrementally of number of threads, besides you may want to check some uniprocessors with hyperThreading technology (sort of thread physical divisions inside the cpu), they are presented to OS as 2 smp processors, it could be interesting, I remember to test  time ago in this machines and anything weird happened, but quite time ago with ThreadPthread LINUXLIBC6 systems with normally distributed programs.
>  
> What about results in Win2k ?
> Thanks in advance
> 
> --- El mi?, 2/3/11, Jay K <jay.krell at cornell.edu> escribi?:
> 
> De: Jay K <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] results of threadtest program on Windows7
> Para: rcolebur at scires.com, "m3devel" <m3devel at elegosoft.com>
> Fecha: mi?rcoles, 2 de marzo, 2011 20:17
> 
> Even with the change I made PutCard to PutInt?
> That's the only failure I've seen.
> I'll try on a non-virtual dual-proc machine later.
>  
> Thanks,
>  - Jay
>  
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Wed, 2 Mar 2011 19:42:47 -0500
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Yes, it fails more often than it runs for me.
> Regards,
> Randy
>  
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Tuesday, March 01, 2011 5:59 AM
> To: Mika Nystrom; Coleburn, Randy
> Cc: m3devel
> Subject: RE: [M3devel] results of threadtest program on Windows7
>  
> I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
> I've run it just a few times now. One single and dual processor virtual machines.
> Randy, has it failed many times for you?
> 
>  - Jay
> 
> > To: rcolebur at SCIRES.COM
> > Date: Sun, 27 Feb 2011 15:11:25 -0800
> > From: mika at async.caltech.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] results of threadtest program on Windows7
> > 
> > Ah, it just doesn't check command-line arguments that carefully.
> > 
> > I think what you did is equivalent to "-tests STD".
> > 
> > Mika
> > 
> > "Coleburn, Randy" writes:
> > >Mika:
> > >
> > >No change with "-tests POSIX".
> > >
> > >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> > >ptions are, and I typed "threadtest -help" rather than reading the code.
> > >
> > >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> > >d it again and it ran to completion. Something seems non-deterministic her=
> > >e. See below.
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >.
> > >
> > >***
> > >*** runtime error:
> > >*** Attempt to reference an illegal memory location.
> > >*** pc =3D 0x77762262
> > >***
> > >
> > >Stack trace:
> > > FP PC Procedure
> > >--------- --------- -------------------------------
> > > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> > >3
> > > 0xcdf9c0 0x77762262 <???>
> > > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> > >3
> > > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> > >.m3
> > > 0xcdfb80 0x76543677 <???>
> > > 0xcdfbc0 0x77779f02 <???>
> > >......... ......... ... more frames ...
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >All tests complete. Congratulations.
> > >
> > >Regards,
> > >Randy Coleburn
> > >
> > >-----Original Message-----
> > >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> > >Sent: Sunday, February 27, 2011 3:30 PM
> > >To: Coleburn, Randy
> > >Cc: m3devel at elegosoft.com
> > >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> > >
> > >Hi Randy,
> > >
> > >You can try it with -tests POSIX as well.
> > >
> > >I find on user threads it runs very slowly (but it does run) because of how=
> > > unfair
> > >the thread scheduler is.
> > >
> > >Next step might be to whittle down the tests and see if you can get a failu=
> > >re with
> > >a single test running and -n 2. That would likely be the simplest scenario=
> > > to
> > >start further debugging from.
> > >
> > > Mika
> > >
> > >"Coleburn, Randy" writes:
> > >>Mika et al:
> > >>
> > >>Thought I would try something else.
> > >>
> > >>I took the sources of your thread test program to an older XP machine that=
> > > =3D
> > >>has CM3 circa August 2008. This is the machine and implementation I used =
> > >w=3D
> > >>hen building a major project I did a couple years back.
> > >>
> > >>The thread test program does indeed build on this old system, but when I r=
> > >u=3D
> > >>n it, I get different results than with the latest HEAD branch code. =3D20
> > >>
> > >>After it prints "running...printing oldest/median age/newest", on the next=
> > > =3D
> > >>line I get two periods ".." and now the program seems hung. I'll let it "=
> > >r=3D
> > >>un" for a few more minutes to see if anything else happens before killing =
> > >i=3D
> > >>t.
> > >>
> > >>At least we don't get the subscript and assertion failures on this older C=
> > >M=3D
> > >>3 platform.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>
> > >>-----Original Message-----
> > >>From: Coleburn, Randy=3D20
> > >>Sent: Sunday, February 27, 2011 2:09 PM
> > >>To: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7
> > >>
> > >>Mika:
> > >>
> > >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> > >>
> > >>Here is what happens now when I run your threadtest program on Windows 7.
> > >>
> > >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> > >r=3D
> > >>k
> > >>Writing file...done
> > >>Creating read threads...done
> > >>Creating nxread threads...done
> > >>Creating tryexcept threads...done
> > >>Creating forktoomuch threads...done
> > >>Creating alloc threads...done
> > >>Creating creat threads...done
> > >>Creating lock threads...done
> > >>running...printing oldest/median age/newest
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** An array subscript was out of range.
> > >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> > >>***
> > >>
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** <*ASSERT*> failed.
> > >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> > >>***
> > >>
> > >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> > >>
> > >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> > >.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>-----Original Message-----
> > >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> > >>Sent: Saturday, February 26, 2011 12:55 PM
> > >>To: Coleburn, Randy
> > >>Cc: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> > >>
> > >>Hi Randy,
> > >>
> > >>Hm yes it looks like my Windows programming skills leave something
> > >>to be desired.
> > >>
> > >>You can run the thread tester while skipping a test as follows
> > >>
> > >> threadtest -tests ALL,-fork
> > >>
> > >>(for instance)
> > >>
> > >>if you just run=3D20
> > >>
> > >> threadtest -sadfassdaf
> > >>
> > >>it'll print the tests that are available.
> > >>
> > >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> > >>Can you give me a very brief description of what you did to install Modula=
> > >-=3D
> > >>3
> > >>on this system?
> > >>
> > >> Mika
> > >>
> > >>"Coleburn, Randy" writes:
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>
> > >>>Mika:
> > >>>
> > >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> > >>>
> > >>>So, I ran your threadtest program.
> > >>>
> > >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> > >e=3D
> > >>p=3D3D
> > >>>eating "ERROR FApply" messages.
> > >>>
> > >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > >>>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
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>***
> > >>>*** runtime error:
> > >>>*** An enumeration or subrange value was out of range.
> > >>>*** file "..\src\Main.m3", line 340
> > >>>***
> > >>>
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>Stack trace:
> > >>> FP PC Procedure
> > >>>--------- --------- -------------------------------
> > >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> > >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> > >>>
> > >>>Regards,
> > >>>Randy Coleburn
> > >>>
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/html; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110303/93b23a6e/attachment-0001.html>

From rcolebur at SCIRES.COM  Thu Mar  3 19:47:11 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 3 Mar 2011 13:47:11 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>
	<COL101-W4726257303F22627175774E6C30@phx.gbl>
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>

Tony:

Here are results using the checks you suggested.  These are running on Windows 7.

*         @M3paranoidgc

*         @M3nogc

*         @M3noincremental

*         @M3nogenerational

As you can see below, the only one where the program ran to completion is when using M3nogenerational; However, this doesn't mean it solves the problem, because I ran a second time with this option (see below) and it crashed.

When using M3nogc, looks like we run out of memory.  The computer I am using for these tests is a Dell Latitude 6510 with 4GB RAM and a system-managed pagefile size.

Hope these test runs give some insight into the problem.

Let me know what else I can do to help.

Regards,
Randy

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc
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
.

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0xa8f9bc = RefSanityCheck + 0x2c in ..\src\runtime\common\RTCollector.m3
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogc
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
.....

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.
***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x1faf970   0xaaa7b2  Raise + 0x3f in ..\src\runtime\common\RuntimeError.m3
0x1faf990   0xa86902  AllocateOpenArray + 0x33 in ..\src\runtime\common\RTAllocator.m3
0x1faf9ec   0xa61ab3  AApply + 0x46 in ..\src\Main.m3
0x1fafa28   0xa8976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
0x1fafa34  0x75c43677  <???>
0x1fafa74  0x77b39f02  <???>
.........  .........  ... more frames ...

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3noincremental
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
.

***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\runtime\common\RTCollector.m3", line 418
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogenerational
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
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
All tests complete.  Congratulations.

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogenerational
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
.

***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\runtime\common\RTCollector.m3", line 418
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***


From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Thursday, March 03, 2011 10:39 AM
To: Coleburn, Randy
Cc: m3devel
Subject: Re: [M3devel] results of threadtest program on Windows7

Both of these errors indicate major breakdown in the garbage collector.
It could be that the damage was done much earlier than the crash.
To check for earlier damage please run with @M3paranoidgc.
Also, you could try running with @M3nogc, or @M3noincremental, or @M3nogenerational, to see if any of them trigger the errors.

On Mar 2, 2011, at 8:36 PM, Coleburn, Randy wrote:


Jay:

Ok, I just updated from HEAD and got your latest change to thread test program.

Here are two invocations, back to back, each failing in different ways.

The second one repeats the last error message ad infinitum until you press CNTRL-C to abort.  But note, several different errors reported earlier.

Regards,
Randy

C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cm3
--- building in NT386 ---

ignoring ..\src\m3overrides

new source -> compiling Main.m3
new "Main.mo" -> linking threadtest.exe

C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cd NT386

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
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


***
*** runtime error:
***    <*ASSERT*> failed..
***    file "..\src\runtime\common\RTCollector.m3", line 1086
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0xddfaf0  0x123dffb  CleanBetween + 0x47 in ..\src\runtime\common\RTCollector.m3
0xddfb34  0x1241870  CheckLoadTracedRef + 0xc5 in ..\src\runtime\common\RTCollector.m3
0xddfb74  0x121683c  Init + 0x95 in ..\src\rw\FileRd.m3
0xddfba0  0x121679d  Open + 0x4d in ..\src\rw\FileRd.m3
0xddfcd8  0x1211288  RApply + 0x78 in ..\src\Main.m3
0xddfd14  0x123976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
0xddfd20  0x76d53677  <???>
0xddfd60  0x773c9f02  <???>
.........  .........  ... more frames ...

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
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
.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0x12ec5ad = Move + 0x50 in ..\src\runtime\common\RTCollector.m3
***



***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***



***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

From: jayk123 at hotmail.com<mailto:jayk123 at hotmail.com> [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Wednesday, March 02, 2011 8:18 PM
To: Coleburn, Randy; m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7

Even with the change I made PutCard to PutInt?
That's the only failure I've seen.
I'll try on a non-virtual dual-proc machine later.

Thanks,
 - Jay

________________________________
From: rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>
To: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7
Yes, it fails more often than it runs for me.
Regards,
Randy

From: jayk123 at hotmail.com<mailto:jayk123 at hotmail.com> [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7

I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu<mailto:mika at async.caltech.edu>
> CC: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> Subject: Re: [M3devel] results of threadtest program on Windows7
>
> Ah, it just doesn't check command-line arguments that carefully.
>
> I think what you did is equivalent to "-tests STD".
>
> Mika
>
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- --------- -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
> >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110303/6613e6a9/attachment-0001.html>

From mika at async.caltech.edu  Thu Mar  3 20:11:52 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Thu, 03 Mar 2011 11:11:52 -0800
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv> 
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>
	<COL101-W4726257303F22627175774E6C30@phx.gbl>
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>
Message-ID: <20110303191152.738111A2078@async.async.caltech.edu>

"Coleburn, Randy" writes:
>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE526EBEatlex02srv_
...
>When using M3nogc, looks like we run out of memory.  The computer I am usin=
>g for these tests is a Dell Latitude 6510 with 4GB RAM and a system-managed=
> pagefile size.

Well some (most) of the tests do allocate memory so perhaps that's not so surprising.

You might try it with -alloc , but creat and fork I'm sure also allocate memory on the
heap.

     Mika


From hosking at cs.purdue.edu  Thu Mar  3 20:19:17 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 3 Mar 2011 14:19:17 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>
	<COL101-W4726257303F22627175774E6C30@phx.gbl>
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>
Message-ID: <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>

Can you try with each of the following?

@M3paranoidgc @M3noincremental @M3nogenerational

@M3paranoidgc @M3noincremental

@M3paranoidgc @M3nogenerational

Also, if possible, can you print the stack dump immediately before the assertion error is printed out?  That means setting a breakpoint on the Raise function that reports assertion failures.  I think it is RTHooks__Raise.  Or perhaps RTHooks__ReportFault.  I don't recall exactly.


On Mar 3, 2011, at 1:47 PM, Coleburn, Randy wrote:

> Tony:
>  
> Here are results using the checks you suggested.  These are running on Windows 7.
> ?         @M3paranoidgc
> ?         @M3nogc
> ?         @M3noincremental
> ?         @M3nogenerational
>  
> As you can see below, the only one where the program ran to completion is when using M3nogenerational; However, this doesn?t mean it solves the problem, because I ran a second time with this option (see below) and it crashed.
>  
> When using M3nogc, looks like we run out of memory.  The computer I am using for these tests is a Dell Latitude 6510 with 4GB RAM and a system-managed pagefile size.
>  
> Hope these test runs give some insight into the problem. 
>  
> Let me know what else I can do to help.
>  
> Regards,
> Randy
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc
> 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
> .
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
> ***    pc = 0xa8f9bc = RefSanityCheck + 0x2c in ..\src\runtime\common\RTCollector.m3
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogc
> 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
> .....
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
> ***    file "..\src\runtime\common\RuntimeError.m3", line 63
> ***
>  
> ***    file "..\src\runtime\common\RuntimeError.m3", line 63
> ***
>  
> ***    file "..\src\runtime\common\RuntimeError.m3", line 63
> ***
>  
> ***    file "..\src\runtime\common\RuntimeError.m3", line 63
> ***
>  
> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0x1faf970   0xaaa7b2  Raise + 0x3f in ..\src\runtime\common\RuntimeError.m3
> 0x1faf990   0xa86902  AllocateOpenArray + 0x33 in ..\src\runtime\common\RTAllocator.m3
> 0x1faf9ec   0xa61ab3  AApply + 0x46 in ..\src\Main.m3
> 0x1fafa28   0xa8976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
> 0x1fafa34  0x75c43677  <???>
> 0x1fafa74  0x77b39f02  <???>
> .........  .........  ... more frames ...
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3noincremental
> 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
> .
>  
> ***
> *** runtime error:
> ***    An array subscript was out of range.
> ***    file "..\src\runtime\common\RTCollector.m3", line 418
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogenerational
> 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
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> All tests complete.  Congratulations.
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogenerational
> 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
> .
>  
> ***
> *** runtime error:
> ***    An array subscript was out of range.
> ***    file "..\src\runtime\common\RTCollector.m3", line 418
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Thursday, March 03, 2011 10:39 AM
> To: Coleburn, Randy
> Cc: m3devel
> Subject: Re: [M3devel] results of threadtest program on Windows7
>  
> Both of these errors indicate major breakdown in the garbage collector.
> It could be that the damage was done much earlier than the crash.
> To check for earlier damage please run with @M3paranoidgc.
> Also, you could try running with @M3nogc, or @M3noincremental, or @M3nogenerational, to see if any of them trigger the errors.
>  
> 
> On Mar 2, 2011, at 8:36 PM, Coleburn, Randy wrote:
> 
> 
> Jay:
>  
> Ok, I just updated from HEAD and got your latest change to thread test program.
>  
> Here are two invocations, back to back, each failing in different ways. 
>  
> The second one repeats the last error message ad infinitum until you press CNTRL-C to abort.  But note, several different errors reported earlier.
>  
> Regards,
> Randy
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cm3
> --- building in NT386 ---
>  
> ignoring ..\src\m3overrides
>  
> new source -> compiling Main.m3
> new "Main.mo" -> linking threadtest.exe
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cd NT386
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> 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
>  
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed..
> ***    file "..\src\runtime\common\RTCollector.m3", line 1086
> ***
>  
> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0xddfaf0  0x123dffb  CleanBetween + 0x47 in ..\src\runtime\common\RTCollector.m3
> 0xddfb34  0x1241870  CheckLoadTracedRef + 0xc5 in ..\src\runtime\common\RTCollector.m3
> 0xddfb74  0x121683c  Init + 0x95 in ..\src\rw\FileRd.m3
> 0xddfba0  0x121679d  Open + 0x4d in ..\src\rw\FileRd.m3
> 0xddfcd8  0x1211288  RApply + 0x78 in ..\src\Main.m3
> 0xddfd14  0x123976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
> 0xddfd20  0x76d53677  <???>
> 0xddfd60  0x773c9f02  <???>
> .........  .........  ... more frames ...
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> 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
> .
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
> ***    pc = 0x12ec5ad = Move + 0x50 in ..\src\runtime\common\RTCollector.m3
> ***
>  
>  
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
>  
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Wednesday, March 02, 2011 8:18 PM
> To: Coleburn, Randy; m3devel
> Subject: RE: [M3devel] results of threadtest program on Windows7
>  
> Even with the change I made PutCard to PutInt?
> That's the only failure I've seen.
> I'll try on a non-virtual dual-proc machine later.
>  
> Thanks,
>  - Jay
>  
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Wed, 2 Mar 2011 19:42:47 -0500
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Yes, it fails more often than it runs for me.
> Regards,
> Randy
>  
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Tuesday, March 01, 2011 5:59 AM
> To: Mika Nystrom; Coleburn, Randy
> Cc: m3devel
> Subject: RE: [M3devel] results of threadtest program on Windows7
>  
> I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
> I've run it just a few times now. One single and dual processor virtual machines.
> Randy, has it failed many times for you?
> 
>  - Jay
> 
> > To: rcolebur at SCIRES.COM
> > Date: Sun, 27 Feb 2011 15:11:25 -0800
> > From: mika at async.caltech.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] results of threadtest program on Windows7
> > 
> > Ah, it just doesn't check command-line arguments that carefully.
> > 
> > I think what you did is equivalent to "-tests STD".
> > 
> > Mika
> > 
> > "Coleburn, Randy" writes:
> > >Mika:
> > >
> > >No change with "-tests POSIX".
> > >
> > >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> > >ptions are, and I typed "threadtest -help" rather than reading the code.
> > >
> > >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> > >d it again and it ran to completion. Something seems non-deterministic her=
> > >e. See below.
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >.
> > >
> > >***
> > >*** runtime error:
> > >*** Attempt to reference an illegal memory location.
> > >*** pc =3D 0x77762262
> > >***
> > >
> > >Stack trace:
> > > FP PC Procedure
> > >--------- --------- -------------------------------
> > > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> > >3
> > > 0xcdf9c0 0x77762262 <???>
> > > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> > >3
> > > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> > >.m3
> > > 0xcdfb80 0x76543677 <???>
> > > 0xcdfbc0 0x77779f02 <???>
> > >......... ......... ... more frames ...
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >All tests complete. Congratulations.
> > >
> > >Regards,
> > >Randy Coleburn
> > >
> > >-----Original Message-----
> > >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> > >Sent: Sunday, February 27, 2011 3:30 PM
> > >To: Coleburn, Randy
> > >Cc: m3devel at elegosoft.com
> > >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> > >
> > >Hi Randy,
> > >
> > >You can try it with -tests POSIX as well.
> > >
> > >I find on user threads it runs very slowly (but it does run) because of how=
> > > unfair
> > >the thread scheduler is.
> > >
> > >Next step might be to whittle down the tests and see if you can get a failu=
> > >re with
> > >a single test running and -n 2. That would likely be the simplest scenario=
> > > to
> > >start further debugging from.
> > >
> > > Mika
> > >
> > >"Coleburn, Randy" writes:
> > >>Mika et al:
> > >>
> > >>Thought I would try something else.
> > >>
> > >>I took the sources of your thread test program to an older XP machine that=
> > > =3D
> > >>has CM3 circa August 2008. This is the machine and implementation I used =
> > >w=3D
> > >>hen building a major project I did a couple years back.
> > >>
> > >>The thread test program does indeed build on this old system, but when I r=
> > >u=3D
> > >>n it, I get different results than with the latest HEAD branch code. =3D20
> > >>
> > >>After it prints "running...printing oldest/median age/newest", on the next=
> > > =3D
> > >>line I get two periods ".." and now the program seems hung. I'll let it "=
> > >r=3D
> > >>un" for a few more minutes to see if anything else happens before killing =
> > >i=3D
> > >>t.
> > >>
> > >>At least we don't get the subscript and assertion failures on this older C=
> > >M=3D
> > >>3 platform.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>
> > >>-----Original Message-----
> > >>From: Coleburn, Randy=3D20
> > >>Sent: Sunday, February 27, 2011 2:09 PM
> > >>To: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7
> > >>
> > >>Mika:
> > >>
> > >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> > >>
> > >>Here is what happens now when I run your threadtest program on Windows 7.
> > >>
> > >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> > >r=3D
> > >>k
> > >>Writing file...done
> > >>Creating read threads...done
> > >>Creating nxread threads...done
> > >>Creating tryexcept threads...done
> > >>Creating forktoomuch threads...done
> > >>Creating alloc threads...done
> > >>Creating creat threads...done
> > >>Creating lock threads...done
> > >>running...printing oldest/median age/newest
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** An array subscript was out of range.
> > >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> > >>***
> > >>
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** <*ASSERT*> failed.
> > >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> > >>***
> > >>
> > >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> > >>
> > >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> > >.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>-----Original Message-----
> > >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> > >>Sent: Saturday, February 26, 2011 12:55 PM
> > >>To: Coleburn, Randy
> > >>Cc: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> > >>
> > >>Hi Randy,
> > >>
> > >>Hm yes it looks like my Windows programming skills leave something
> > >>to be desired.
> > >>
> > >>You can run the thread tester while skipping a test as follows
> > >>
> > >> threadtest -tests ALL,-fork
> > >>
> > >>(for instance)
> > >>
> > >>if you just run=3D20
> > >>
> > >> threadtest -sadfassdaf
> > >>
> > >>it'll print the tests that are available.
> > >>
> > >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> > >>Can you give me a very brief description of what you did to install Modula=
> > >-=3D
> > >>3
> > >>on this system?
> > >>
> > >> Mika
> > >>
> > >>"Coleburn, Randy" writes:
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>
> > >>>Mika:
> > >>>
> > >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> > >>>
> > >>>So, I ran your threadtest program.
> > >>>
> > >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> > >e=3D
> > >>p=3D3D
> > >>>eating "ERROR FApply" messages.
> > >>>
> > >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > >>>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
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>***
> > >>>*** runtime error:
> > >>>*** An enumeration or subrange value was out of range.
> > >>>*** file "..\src\Main.m3", line 340
> > >>>***
> > >>>
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>Stack trace:
> > >>> FP PC Procedure
> > >>>--------- --------- -------------------------------
> > >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> > >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> > >>>
> > >>>Regards,
> > >>>Randy Coleburn
> > >>>
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/html; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110303/5d0b2362/attachment-0001.html>

From hendrik at topoi.pooq.com  Fri Mar  4 17:19:14 2011
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Fri, 4 Mar 2011 11:19:14 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <571065.83147.qm@web29715.mail.ird.yahoo.com>
References: <COL101-W3670B74A99994199607C6BE6C00@phx.gbl>
	<571065.83147.qm@web29715.mail.ird.yahoo.com>
Message-ID: <20110304161914.GC8263@topoi.pooq.com>

On Wed, Mar 02, 2011 at 09:31:41PM +0000, Daniel Alejandro Benavides D. wrote:
> Hi all:
> yes, but technically you could insert some empty chips slots on the same wafer but in cases of blade systems I'm sure you can, just don't know how much about something like plug-and-play with that.
> Thanks in advance
> 
> --- El mar, 1/3/11, Jay K <jay.krell at cornell.edu> escribi?:
> 
> De: Jay K <jay.krell at cornell.edu>
> Asunto: RE: [M3devel] results of threadtest program on Windows7
> Para: dabenavidesd at yahoo.es, "Mika Nystrom" <mika at async.caltech.edu>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: martes, 1 de marzo, 2011 22:11
> 
> 
> 
> 
> I have still have mostly uniprocessors (though busy selling stuff off...)
> 
> ? I do have a MacBook Pro and Dell laptop with 2 processors each though.
> 
> ? It is that MacBook Pro where I can consistently get Darwin to fail, and a?1 and 2 proc Windows virtual machine on the MacBook Pro?that consistently works.
> 
> ? While Modula-3 user threads never run anything truly 
>   concurrently, i.e. on multiple prcoessors, there should 
>   still be almost arbitrary preemption.

But you won't get parallel execution of instructions: 
user threads can at most switch threads between instructions.  
With two actual processors, it's possible to get races within 
the execution of a single instruction on each processor.

-- hendrik


From rcolebur at SCIRES.COM  Sat Mar  5 04:07:39 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 4 Mar 2011 22:07:39 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>
	<COL101-W4726257303F22627175774E6C30@phx.gbl>
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>
	<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>

Tony:

I do not have a debugger built for Windows, so I can't do the breakpoint yet.  I'll check into trying to build the debugger, but last time I tried this (a few years ago) it didn't work.  I used m3gdb on HPUX long time ago, but nothing for Windows.

Here are test results you requested (you will see I ran each of them twice, getting different results each time).

The very last test run resulted in another stack dump.

Regards,
Randy

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3noincremental @M3nogenerational
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
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
All tests complete.  Congratulations.

Although it ran to completion the first try, I ran again and it crashes, see below:

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3noincremental @M3nogenerational
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
.

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\runtime\common\RTCollector.m3", line 1709
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3noincremental
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
.

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0x12bf9bc = RefSanityCheck + 0x2c in ..\src\runtime\common\RTCollector.m3
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

Running this one a second time, I get these results:

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3noincremental
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
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
All tests complete.  Congratulations.

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3nogenerational
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
.

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0x12bf9bc = RefSanityCheck + 0x2c in ..\src\runtime\common\RTCollector.m3
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

Running a second time, I get these results:

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3nogenerational
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
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........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:
***    An array subscript was out of range.
***    file "..\src\rw\FileRd.m3", line 83
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0xadf764  0x1296ee8  Seek + 0x454 in ..\src\rw\FileRd.m3
0xadf78c  0x1297d84  DoSeek + 0x80 in ..\src\rw\Rd.m3
0xadf7b0  0x1297bf0  FastGetChar + 0x57 in ..\src\rw\Rd.m3
0xadf7d8  0x1297b58  GetChar + 0x48 in ..\src\rw\Rd.m3
0xadf910  0x12912e3  RApply + 0xd3 in ..\src\Main.m3
0xadf94c  0x12b976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
0xadf958  0x74f03677  <???>
0xadf998  0x77009f02  <???>
.........  .........  ... more frames ...

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Thursday, March 03, 2011 2:19 PM
To: Coleburn, Randy
Cc: m3devel
Subject: Re: [M3devel] results of threadtest program on Windows7

Can you try with each of the following?

@M3paranoidgc @M3noincremental @M3nogenerational

@M3paranoidgc @M3noincremental

@M3paranoidgc @M3nogenerational

Also, if possible, can you print the stack dump immediately before the assertion error is printed out?  That means setting a breakpoint on the Raise function that reports assertion failures.  I think it is RTHooks__Raise.  Or perhaps RTHooks__ReportFault.  I don't recall exactly.


On Mar 3, 2011, at 1:47 PM, Coleburn, Randy wrote:


Tony:

Here are results using the checks you suggested.  These are running on Windows 7.
*         @M3paranoidgc
*         @M3nogc
*         @M3noincremental
*         @M3nogenerational

As you can see below, the only one where the program ran to completion is when using M3nogenerational; However, this doesn't mean it solves the problem, because I ran a second time with this option (see below) and it crashed.

When using M3nogc, looks like we run out of memory.  The computer I am using for these tests is a Dell Latitude 6510 with 4GB RAM and a system-managed pagefile size.

Hope these test runs give some insight into the problem.

Let me know what else I can do to help.

Regards,
Randy

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc
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
.

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0xa8f9bc = RefSanityCheck + 0x2c in ..\src\runtime\common\RTCollector.m3
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogc
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
.....

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.
***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x1faf970   0xaaa7b2  Raise + 0x3f in ..\src\runtime\common\RuntimeError.m3
0x1faf990   0xa86902  AllocateOpenArray + 0x33 in ..\src\runtime\common\RTAllocator.m3
0x1faf9ec   0xa61ab3  AApply + 0x46 in ..\src\Main.m3
0x1fafa28   0xa8976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
0x1fafa34  0x75c43677  <???>
0x1fafa74  0x77b39f02  <???>
.........  .........  ... more frames ...

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3noincremental
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
.

***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\runtime\common\RTCollector.m3", line 418
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogenerational
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
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
All tests complete.  Congratulations.

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogenerational
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
.

***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\runtime\common\RTCollector.m3", line 418
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***


From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Thursday, March 03, 2011 10:39 AM
To: Coleburn, Randy
Cc: m3devel
Subject: Re: [M3devel] results of threadtest program on Windows7

Both of these errors indicate major breakdown in the garbage collector.
It could be that the damage was done much earlier than the crash.
To check for earlier damage please run with @M3paranoidgc.
Also, you could try running with @M3nogc, or @M3noincremental, or @M3nogenerational, to see if any of them trigger the errors.

On Mar 2, 2011, at 8:36 PM, Coleburn, Randy wrote:



Jay:

Ok, I just updated from HEAD and got your latest change to thread test program.

Here are two invocations, back to back, each failing in different ways.

The second one repeats the last error message ad infinitum until you press CNTRL-C to abort.  But note, several different errors reported earlier.

Regards,
Randy

C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cm3
--- building in NT386 ---

ignoring ..\src\m3overrides

new source -> compiling Main.m3
new "Main.mo" -> linking threadtest.exe

C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cd NT386

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
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


***
*** runtime error:
***    <*ASSERT*> failed..
***    file "..\src\runtime\common\RTCollector.m3", line 1086
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0xddfaf0  0x123dffb  CleanBetween + 0x47 in ..\src\runtime\common\RTCollector.m3
0xddfb34  0x1241870  CheckLoadTracedRef + 0xc5 in ..\src\runtime\common\RTCollector.m3
0xddfb74  0x121683c  Init + 0x95 in ..\src\rw\FileRd.m3
0xddfba0  0x121679d  Open + 0x4d in ..\src\rw\FileRd.m3
0xddfcd8  0x1211288  RApply + 0x78 in ..\src\Main.m3
0xddfd14  0x123976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
0xddfd20  0x76d53677  <???>
0xddfd60  0x773c9f02  <???>
.........  .........  ... more frames ...

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
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
.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0x12ec5ad = Move + 0x50 in ..\src\runtime\common\RTCollector.m3
***



***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***



***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

From: jayk123 at hotmail.com<mailto:jayk123 at hotmail.com> [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Wednesday, March 02, 2011 8:18 PM
To: Coleburn, Randy; m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7

Even with the change I made PutCard to PutInt?
That's the only failure I've seen.
I'll try on a non-virtual dual-proc machine later.

Thanks,
 - Jay

________________________________
From: rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>
To: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7
Yes, it fails more often than it runs for me.
Regards,
Randy

From: jayk123 at hotmail.com<mailto:jayk123 at hotmail.com> [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7

I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu<mailto:mika at async.caltech.edu>
> CC: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> Subject: Re: [M3devel] results of threadtest program on Windows7
>
> Ah, it just doesn't check command-line arguments that carefully.
>
> I think what you did is equivalent to "-tests STD".
>
> Mika
>
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- --------- -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
> >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110304/40ce9634/attachment-0001.html>

From jay.krell at cornell.edu  Sat Mar  5 06:37:47 2011
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 5 Mar 2011 05:37:47 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>,
	,,<20110226175511.3F7D21A2078@async.async.caltech.edu>,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>,
	,,<20110227202950.46F3B1A2078@async.async.caltech.edu>,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>,
	, , <20110227231125.3DC611A2078@async.async.caltech.edu>, ,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>,
	<COL101-W4726257303F22627175774E6C30@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>,
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>,
	<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>
Message-ID: <COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>

Microsoft debuggers are freely downloadable. 

 Jay/phone

From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Fri, 4 Mar 2011 22:07:39 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7



Tony: I do not have a debugger built for Windows, so I can?t do the breakpoint yet.  I?ll check into trying to build the debugger, but last time I tried this (a few years ago) it didn?t work.  I used m3gdb on HPUX long time ago, but nothing for Windows. Here are test results you requested (you will see I ran each of them twice, getting different results each time).   The very last test run resulted in another stack dump. Regards,Randy C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3noincremental @M3nogenerationalWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)All tests complete.  Congratulations. Although it ran to completion the first try, I ran again and it crashes, see below: C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3noincremental @M3nogenerationalWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest. ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\runtime\common\RTCollector.m3", line 1709*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3noincrementalWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest. ****** runtime error:***    Attempt to reference an illegal memory location.***    pc = 0x12bf9bc = RefSanityCheck + 0x2c in ..\src\runtime\common\RTCollector.m3*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** Running this one a second time, I get these results: C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3noincrementalWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)All tests complete.  Congratulations. C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3nogenerationalWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest. ****** runtime error:***    Attempt to reference an illegal memory location.***    pc = 0x12bf9bc = RefSanityCheck + 0x2c in ..\src\runtime\common\RTCollector.m3*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** Running a second time, I get these results: C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3nogenerationalWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........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:***    An array subscript was out of range.***    file "..\src\rw\FileRd.m3", line 83*** Stack trace:   FP         PC      Procedure---------  ---------  ------------------------------- 0xadf764  0x1296ee8  Seek + 0x454 in ..\src\rw\FileRd.m3 0xadf78c  0x1297d84  DoSeek + 0x80 in ..\src\rw\Rd.m3 0xadf7b0  0x1297bf0  FastGetChar + 0x57 in ..\src\rw\Rd.m3 0xadf7d8  0x1297b58  GetChar + 0x48 in ..\src\rw\Rd.m3 0xadf910  0x12912e3  RApply + 0xd3 in ..\src\Main.m3 0xadf94c  0x12b976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3 0xadf958  0x74f03677  <???> 0xadf998  0x77009f02  <???>.........  .........  ... more frames ... From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
Sent: Thursday, March 03, 2011 2:19 PM
To: Coleburn, Randy
Cc: m3devel
Subject: Re: [M3devel] results of threadtest program on Windows7 Can you try with each of the following? @M3paranoidgc @M3noincremental @M3nogenerational @M3paranoidgc @M3noincremental @M3paranoidgc @M3nogenerational Also, if possible, can you print the stack dump immediately before the assertion error is printed out?  That means setting a breakpoint on the Raise function that reports assertion failures.  I think it is RTHooks__Raise.  Or perhaps RTHooks__ReportFault.  I don't recall exactly.  On Mar 3, 2011, at 1:47 PM, Coleburn, Randy wrote:

Tony: Here are results using the checks you suggested.  These are running on Windows 7.?         @M3paranoidgc?         @M3nogc?         @M3noincremental?         @M3nogenerational As you can see below, the only one where the program ran to completion is when using M3nogenerational; However, this doesn?t mean it solves the problem, because I ran a second time with this option (see below) and it crashed. When using M3nogc, looks like we run out of memory.  The computer I am using for these tests is a Dell Latitude 6510 with 4GB RAM and a system-managed pagefile size. Hope these test runs give some insight into the problem.  Let me know what else I can do to help. Regards,Randy C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgcWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest. ****** runtime error:***    Attempt to reference an illegal memory location.***    pc = 0xa8f9bc = RefSanityCheck + 0x2c in ..\src\runtime\common\RTCollector.m3*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogcWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest..... ****** runtime error:***    NEW() was unable to allocate more memory. ****** runtime error:***    NEW() was unable to allocate more memory. ****** runtime error:***    NEW() was unable to allocate more memory. ****** runtime error:***    NEW() was unable to allocate more memory. ****** runtime error:***    NEW() was unable to allocate more memory. ****** runtime error:***    NEW() was unable to allocate more memory. ****** runtime error:***    NEW() was unable to allocate more memory. ****** runtime error:***    NEW() was unable to allocate more memory. ****** runtime error:***    NEW() was unable to allocate more memory. ****** runtime error:***    NEW() was unable to allocate more memory.***    file "..\src\runtime\common\RuntimeError.m3", line 63*** ***    file "..\src\runtime\common\RuntimeError.m3", line 63*** ***    file "..\src\runtime\common\RuntimeError.m3", line 63*** ***    file "..\src\runtime\common\RuntimeError.m3", line 63*** Stack trace:   FP         PC      Procedure---------  ---------  -------------------------------0x1faf970   0xaaa7b2  Raise + 0x3f in ..\src\runtime\common\RuntimeError.m30x1faf990   0xa86902  AllocateOpenArray + 0x33 in ..\src\runtime\common\RTAllocator.m30x1faf9ec   0xa61ab3  AApply + 0x46 in ..\src\Main.m30x1fafa28   0xa8976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m30x1fafa34  0x75c43677  <???>0x1fafa74  0x77b39f02  <???>.........  .........  ... more frames ... C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3noincrementalWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest. ****** runtime error:***    An array subscript was out of range.***    file "..\src\runtime\common\RTCollector.m3", line 418*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogenerationalWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)All tests complete.  Congratulations. C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogenerationalWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest. ****** runtime error:***    An array subscript was out of range.***    file "..\src\runtime\common\RTCollector.m3", line 418*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841***  From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
Sent: Thursday, March 03, 2011 10:39 AM
To: Coleburn, Randy
Cc: m3devel
Subject: Re: [M3devel] results of threadtest program on Windows7 Both of these errors indicate major breakdown in the garbage collector.It could be that the damage was done much earlier than the crash.To check for earlier damage please run with @M3paranoidgc.Also, you could try running with @M3nogc, or @M3noincremental, or @M3nogenerational, to see if any of them trigger the errors. On Mar 2, 2011, at 8:36 PM, Coleburn, Randy wrote:


Jay: Ok, I just updated from HEAD and got your latest change to thread test program. Here are two invocations, back to back, each failing in different ways.  The second one repeats the last error message ad infinitum until you press CNTRL-C to abort.  But note, several different errors reported earlier. Regards,Randy C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cm3--- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling Main.m3new "Main.mo" -> linking threadtest.exe C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cd NT386 C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exeWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest  ****** runtime error:***    <*ASSERT*> failed..***    file "..\src\runtime\common\RTCollector.m3", line 1086*** Stack trace:   FP         PC      Procedure---------  ---------  -------------------------------0xddfaf0  0x123dffb  CleanBetween + 0x47 in ..\src\runtime\common\RTCollector.m30xddfb34  0x1241870  CheckLoadTracedRef + 0xc5 in ..\src\runtime\common\RTCollector.m30xddfb74  0x121683c  Init + 0x95 in ..\src\rw\FileRd.m30xddfba0  0x121679d  Open + 0x4d in ..\src\rw\FileRd.m30xddfcd8  0x1211288  RApply + 0x78 in ..\src\Main.m30xddfd14  0x123976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m30xddfd20  0x76d53677  <???>0xddfd60  0x773c9f02  <???>.........  .........  ... more frames ... C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exeWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest. ****** runtime error:***    Attempt to reference an illegal memory location. ****** runtime error:***    Attempt to reference an illegal memory location. ****** runtime error:***    Attempt to reference an illegal memory location.***    pc = 0x12ec5ad = Move + 0x50 in ..\src\runtime\common\RTCollector.m3***   ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841***   ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Wednesday, March 02, 2011 8:18 PM
To: Coleburn, Randy; m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7 Even with the change I made PutCard to PutInt?
That's the only failure I've seen.
I'll try on a non-virtual dual-proc machine later.
 
Thanks,
 - Jay
 From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7Yes, it fails more often than it runs for me.Regards,Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7 I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Ah, it just doesn't check command-line arguments that carefully.
> 
> I think what you did is equivalent to "-tests STD".
> 
> Mika
> 
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- --------- -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
> >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110305/259e7726/attachment-0001.html>

From mika at async.caltech.edu  Sat Mar  5 19:05:58 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Sat, 05 Mar 2011 10:05:58 -0800
Subject: [M3devel] m3gdb broken
Message-ID: <20110305180558.451421A2078@async.async.caltech.edu>

Hi m3devel,

I don't know what's happened here.  m3gdb used to work, and work fairly
well (never perfectly, but...).  Now I'm trying to debug a program and
I get the following:

(m3gdb) break Main.m3:65
Debug info for file "Main.mc" not in stabs format
(m3gdb) 

The system/architecture is AMD64_FREEBSD but I've seen this problem on other
systems too.

Everything is from the CVS head.

Main was compiled as follows, says cm3 -commands:

gcc -gstabs+ -m64 -fPIC -z origin -Wl,--warn-common -Wl,-rpath,\$ORIGIN -Wl,-rpath,\$ORIGIN/../lib  -Wl,--fatal-warnings -z now -Bsymbolic -L/usr/local/lib -o sstubgen  _m3main.o Main.mo /home/mika/t/mscheme/sstubgen/AMD64_FREEBSD/libsstubgen.a /home/mika/t/mscheme/schemereadline/AMD64_FREEBSD/libschemereadline.a /home/mika/t/mscheme/schemesig/AMD64_FREEBSD/libschemesig.a /home/mika/t/calarm/m3readline/AMD64_FREEBSD/libm3readline.a /home/mika/t/calarm/sx/AMD64_FREEBSD/libsx.a /home/mika/t/mscheme/modula3scheme/AMD64_FREEBSD/libmodula3scheme.a /home/mika/t/rdwr/AMD64_FREEBSD/librdwr.a /home/mika/t/mscheme/AMD64_FREEBSD/libmscheme.a /home/mika/t/cit_util/AMD64_FREEBSD/libcit_util.a /usr/local/cm3/pkg/netobj/AMD64_FREEBSD/libm3netobj.a /usr/local/cm3/pkg/tcp/AMD64_FREEBSD/libm3tcp.a /usr/local/cm3/pkg/patternmatching/AMD64_FREEBSD/libpatternmatching.a /home/mika/t/mscheme/scheme-lib/AMD64_FREEBSD/libscheme-lib.a /usr/local/cm3/pkg/libbuf/AMD64_FREEBSD/liblibbuf.a /home/mika/t/ci
 t_common/AMD64_FREEBSD/libcit_common.a /usr/local/cm3/pkg/set/AMD64_FREEBSD/libset.a /home/mika/t/rdwrreset/AMD64_FREEBSD/librdwrreset.a /usr/local/cm3/pkg/m3tk/AMD64_FREEBSD/libm3tk.a /usr/local/cm3/pkg/m3tk-misc/AMD64_FREEBSD/libm3tk-misc.a /usr/local/cm3/pkg/libm3/AMD64_FREEBSD/libm3.a /usr/local/cm3/pkg/m3core/AMD64_FREEBSD/libm3core.a -lm -lcrypt -lssl -L/usr/local/lib -lintl -lreadline

I'm not even sure where to begin looking.  Is it a configuration issue,
something broken in the compiler, or what?

I fear m3gdb is essentially useless at the moment.

     Mika


From mika at async.caltech.edu  Sat Mar  5 21:06:30 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Sat, 05 Mar 2011 12:06:30 -0800
Subject: [M3devel] MODULEs in .M3IMPTAB
Message-ID: <20110305200630.F26711A2078@async.async.caltech.edu>

Hi again m3devel,

Can anyone think of a reason that cm3 should *not* emit information
about MODULEs that it compiles to .M3IMPTAB?  (It doesn't, today,
which means that m3tk-based tools can't find implementations, only
interfaces.)

    Mika


From hosking at cs.purdue.edu  Sat Mar  5 23:43:35 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 5 Mar 2011 17:43:35 -0500
Subject: [M3devel] MODULEs in .M3IMPTAB
In-Reply-To: <20110305200630.F26711A2078@async.async.caltech.edu>
References: <20110305200630.F26711A2078@async.async.caltech.edu>
Message-ID: <F14FF404-B88C-4C46-B433-744E45311209@cs.purdue.edu>

It used to work... :-(

On Mar 5, 2011, at 3:06 PM, Mika Nystrom wrote:

> Hi again m3devel,
> 
> Can anyone think of a reason that cm3 should *not* emit information
> about MODULEs that it compiles to .M3IMPTAB?  (It doesn't, today,
> which means that m3tk-based tools can't find implementations, only
> interfaces.)
> 
>    Mika



From mika at async.caltech.edu  Sat Mar  5 23:53:51 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Sat, 05 Mar 2011 14:53:51 -0800
Subject: [M3devel] MODULEs in .M3IMPTAB
In-Reply-To: <F14FF404-B88C-4C46-B433-744E45311209@cs.purdue.edu> 
References: <20110305200630.F26711A2078@async.async.caltech.edu>
	<F14FF404-B88C-4C46-B433-744E45311209@cs.purdue.edu>
Message-ID: <20110305225351.2A2AD1A2078@async.async.caltech.edu>


Tony, are you sure?  There don't seem to be any tools in CM3 that process
implementations with m3tk, or have I been looking in the wrong places?
stubgen doesn't, I don't think stablegen does, and m3pp and m3tohtml
don't even use m3tk.  Also it doesn't seem to work on PM3-1.13.2.  Hmmmmm....

     Mika

Tony Hosking writes:
>It used to work... :-(
>
>On Mar 5, 2011, at 3:06 PM, Mika Nystrom wrote:
>
>> Hi again m3devel,
>> 
>> Can anyone think of a reason that cm3 should *not* emit information
>> about MODULEs that it compiles to .M3IMPTAB?  (It doesn't, today,
>> which means that m3tk-based tools can't find implementations, only
>> interfaces.)
>> 
>>    Mika


From rcolebur at SCIRES.COM  Sun Mar  6 02:35:41 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Sat, 5 Mar 2011 20:35:41 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>,
	,,<20110226175511.3F7D21A2078@async.async.caltech.edu>,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>,
	,,<20110227202950.46F3B1A2078@async.async.caltech.edu>,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>,
	, , <20110227231125.3DC611A2078@async.async.caltech.edu>, ,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>,
	<COL101-W4726257303F22627175774E6C30@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>,
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>,
	<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>
	<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>

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/20110305/c882dbac/attachment-0001.html>

From rodney_bates at lcwb.coop  Sun Mar  6 03:30:29 2011
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 05 Mar 2011 20:30:29 -0600
Subject: [M3devel] m3gdb broken
In-Reply-To: <20110305180558.451421A2078@async.async.caltech.edu>
References: <20110305180558.451421A2078@async.async.caltech.edu>
Message-ID: <4D72F1C5.2020504@lcwb.coop>



On 03/05/2011 12:05 PM, Mika Nystrom wrote:
> Hi m3devel,
>
> I don't know what's happened here.  m3gdb used to work, and work fairly
> well (never perfectly, but...).  Now I'm trying to debug a program and
> I get the following:
>
> (m3gdb) break Main.m3:65
> Debug info for file "Main.mc" not in stabs format

This message looks vaguely familiar to me, but I'm not recalling just yet.

> (m3gdb)
>
> The system/architecture is AMD64_FREEBSD but I've seen this problem on other
> systems too.
>
> Everything is from the CVS head.
>
> Main was compiled as follows, says cm3 -commands:
>
> gcc -gstabs+ -m64 -fPIC -z origin -Wl,--warn-common -Wl,-rpath,\$ORIGIN -Wl,-rpath,\$ORIGIN/../lib  -Wl,--fatal-warnings -z now -Bsymbolic -L/usr/local/lib -o sstubgen  _m3main.o Main.mo /home/mika/t/mscheme/sstubgen/AMD64_FREEBSD/libsstubgen.a /home/mika/t/mscheme/schemereadline/AMD64_FREEBSD/libschemereadline.a /home/mika/t/mscheme/schemesig/AMD64_FREEBSD/libschemesig.a /home/mika/t/calarm/m3readline/AMD64_FREEBSD/libm3readline.a /home/mika/t/calarm/sx/AMD64_FREEBSD/libsx.a /home/mika/t/mscheme/modula3scheme/AMD64_FREEBSD/libmodula3scheme.a /home/mika/t/rdwr/AMD64_FREEBSD/librdwr.a /home/mika/t/mscheme/AMD64_FREEBSD/libmscheme.a /home/mika/t/cit_util/AMD64_FREEBSD/libcit_util.a /usr/local/cm3/pkg/netobj/AMD64_FREEBSD/libm3netobj.a /usr/local/cm3/pkg/tcp/AMD64_FREEBSD/libm3tcp.a /usr/local/cm3/pkg/patternmatching/AMD64_FREEBSD/libpatternmatching.a /home/mika/t/mscheme/scheme-lib/AMD64_FREEBSD/libscheme-lib.a /usr/local/cm3/pkg/libbuf/AMD64_FREEBSD/liblibbuf.a /home/mika/t/
ci
>   t_common/AMD64_FREEBSD/libcit_common.a /usr/local/cm3/pkg/set/AMD64_FREEBSD/libset.a /home/mika/t/rdwrreset/AMD64_FREEBSD/librdwrreset.a /usr/local/cm3/pkg/m3tk/AMD64_FREEBSD/libm3tk.a /usr/local/cm3/pkg/m3tk-misc/AMD64_FREEBSD/libm3tk-misc.a /usr/local/cm3/pkg/libm3/AMD64_FREEBSD/libm3.a /usr/local/cm3/pkg/m3core/AMD64_FREEBSD/libm3core.a -lm -lcrypt -lssl -L/usr/local/lib -lintl -lreadline
>

This looks like the gcc command for the link step.  Everything it gets is either .o or .a.,
and it invokes gcc, not cm3cg.

I think the problem might lie in the compile step for Main, which would be giving
Main.mc as the input file name.  Its -g option could be the culprit. It should
look something like:

/usr/local/cm3//bin/cm3cg -gstabs+ -m64 -fPIC -mno-align-double -funwind-tables -quiet -fno-reorder-blocks Main.mc -o Main.ms



> I'm not even sure where to begin looking.  Is it a configuration issue,
> something broken in the compiler, or what?
>
> I fear m3gdb is essentially useless at the moment.
>
>       Mika
>

Rodney Bates


From mika at async.caltech.edu  Sun Mar  6 03:37:49 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Sat, 05 Mar 2011 18:37:49 -0800
Subject: [M3devel] m3gdb broken
In-Reply-To: <4D72F1C5.2020504@lcwb.coop> 
References: <20110305180558.451421A2078@async.async.caltech.edu>
	<4D72F1C5.2020504@lcwb.coop>
Message-ID: <20110306023749.88D321A2078@async.async.caltech.edu>

"Rodney M. Bates" writes:
...
>> Debug info for file "Main.mc" not in stabs format
>
>This message looks vaguely familiar to me, but I'm not recalling just yet.
>
>> (m3gdb)
>>
>> The system/architecture is AMD64_FREEBSD but I've seen this problem on other
...
>> Everything is from the CVS head.
>>
>> Main was compiled as follows, says cm3 -commands:
>>
>> gcc -gstabs+ -m64 -fPIC -z origin -Wl,--warn-common -Wl,-rpath,\$ORIGIN -Wl,-rpath,\$ORIGIN/../lib  -Wl,--fatal-warnings -z now -Bsymbolic -
>L/usr/local/lib -o sstubgen  _m3main.o Main.mo /home/mika/t/mscheme/sstubgen/AMD64_FREEBSD/libsstubgen.a /home/mika/t/mscheme/schemereadline/A
>MD64_FREEBSD/libschemereadline.a /home/mika/t/mscheme/schemesig/AMD64_FREEBSD/libschemesig.a /home/mika/t/calarm/m3readline/AMD64_FREEBSD/libm
>3readline.a /home/mika/t/calarm/sx/AMD64_FREEBSD/libsx.a /home/mika/t/mscheme/modula3scheme/AMD64_FREEBSD/libmodula3scheme.a /home/mika/t/rdwr
>/AMD64_FREEBSD/librdwr.a /home/mika/t/mscheme/AMD64_FREEBSD/libmscheme.a /home/mika/t/cit_util/AMD64_FREEBSD/libcit_util.a /usr/local/cm3/pkg/
>netobj/AMD64_FREEBSD/libm3netobj.a /usr/local/cm3/pkg/tcp/AMD64_FREEBSD/libm3tcp.a /usr/local/cm3/pkg/patternmatching/AMD64_FREEBSD/libpattern
>matching.a /home/mika/t/mscheme/scheme-lib/AMD64_FREEBSD/libscheme-lib.a /usr/local/cm3/pkg/libbuf/AMD64_FREEBSD/liblibbuf.a /home/mika/t/
>ci
>>   t_common/AMD64_FREEBSD/libcit_common.a /usr/local/cm3/pkg/set/AMD64_FREEBSD/libset.a /home/mika/t/rdwrreset/AMD64_FREEBSD/librdwrreset.a /
>usr/local/cm3/pkg/m3tk/AMD64_FREEBSD/libm3tk.a /usr/local/cm3/pkg/m3tk-misc/AMD64_FREEBSD/libm3tk-misc.a /usr/local/cm3/pkg/libm3/AMD64_FREEBS
>D/libm3.a /usr/local/cm3/pkg/m3core/AMD64_FREEBSD/libm3core.a -lm -lcrypt -lssl -L/usr/local/lib -lintl -lreadline
>>
>
>This looks like the gcc command for the link step.  Everything it gets is either .o or .a.,
>and it invokes gcc, not cm3cg.
>
>I think the problem might lie in the compile step for Main, which would be giving
>Main.mc as the input file name.  Its -g option could be the culprit. It should
>look something like:
>
>/usr/local/cm3//bin/cm3cg -gstabs+ -m64 -fPIC -mno-align-double -funwind-tables -quiet -fno-reorder-blocks Main.mc -o Main.ms
>

Sorry, I wasn't thinking.  But my cm3cg is also configured right, I think:

(236)ginger:~/t/mscheme/sstubgen/program/src>cm3 -x -commands | & grep Main
new source -> compiling Main.m3
m3front ../src/Main.m3 -w1
/usr/local/cm3//bin/cm3cg -mno-align-double -quiet -fno-reorder-blocks -funwind-tables -fPIC   -m64 -gstabs+ Main.mc -o Main.ms
as -64 Main.ms -o Main.mo
/usr/local/cm3//bin/cm3cg -mno-align-double -quiet -fno-reorder-blocks -funwind-tables -fPIC   -m64 -gstabs+ Main.mc -o Main.ms
as -64 Main.ms -o Main.mo
rm Main.mc
rm Main.ms
gcc -gstabs+ -m64 -fPIC -z origin -Wl,--warn-common -Wl,-rpath,\$ORIGIN -Wl,-rpath,\$ORIGIN/../lib  -Wl,--fatal-warnings -z now -Bsymbolic -L/usr/local/lib -o sstubgen  _m3main.o Main.mo /home/mika/t/mscheme/sstubgen/AMD64_FREEBSD/libsstubgen.a /home/mika/t/mscheme/schemereadline/AMD64_FREEBSD/libschemereadline.a /home/mika/t/mscheme/schemesig/AMD64_FREEBSD/libschemesig.a /home/mika/t/calarm/m3readline/AMD64_FREEBSD/libm3readline.a /home/mika/t/calarm/sx/AMD64_FREEBSD/libsx.a /home/mika/t/mscheme/modula3scheme/AMD64_FREEBSD/libmodula3scheme.a /home/mika/t/rdwr/AMD64_FREEBSD/librdwr.a /home/mika/t/mscheme/AMD64_FREEBSD/libmscheme.a /home/mika/t/cit_util/AMD64_FREEBSD/libcit_util.a /usr/local/cm3/pkg/netobj/AMD64_FREEBSD/libm3netobj.a /usr/local/cm3/pkg/tcp/AMD64_FREEBSD/libm3tcp.a /usr/local/cm3/pkg/patternmatching/AMD64_FREEBSD/libpatternmatching.a /home/mika/t/mscheme/scheme-lib/AMD64_FREEBSD/libscheme-lib.a /usr/local/cm3/pkg/libbuf/AMD64_FREEBSD/liblibbuf.a /home/mika/t/ci
 t_common/AMD64_FREEBSD/libcit_common.a /usr/local/cm3/pkg/set/AMD64_FREEBSD/libset.a /home/mika/t/rdwrreset/AMD64_FREEBSD/librdwrreset.a /usr/local/cm3/pkg/m3tk/AMD64_FREEBSD/libm3tk.a /usr/local/cm3/pkg/m3tk-misc/AMD64_FREEBSD/libm3tk-misc.a /usr/local/cm3/pkg/libm3/AMD64_FREEBSD/libm3.a /usr/local/cm3/pkg/m3core/AMD64_FREEBSD/libm3core.a -lm -lcrypt -lssl -L/usr/local/lib -lintl -lreadline




From mika at async.caltech.edu  Sun Mar  6 05:24:37 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Sat, 05 Mar 2011 20:24:37 -0800
Subject: [M3devel] MODULEs in .M3IMPTAB
In-Reply-To: <12847.73267.qm@web29719.mail.ird.yahoo.com> 
References: <12847.73267.qm@web29719.mail.ird.yahoo.com>
Message-ID: <20110306042437.D48591A2078@async.async.caltech.edu>

Let me be perfectly clear.

m3tk processes interfaces just fine.

m3tk at the moment doesn't know where to find implementations (MODULEs).

One can tell m3tk where to find them with a command-line switch specifying
a list of directories.  But that's not right, because only cm3 (the
compiler driver) knows which source files have been processed to build
which implementation.

I think my argument suggests the .m3s should be emitted to .M3IMPTAB together
with the .i3s (and .igs oh and also .mgs)

    Mika

"Daniel Alejandro Benavides D." writes:
>Hi all:
>yes, I think I did mention it in a past message because about the ESC, it n=
>eedes as it m3tk too, I didn't know it was a requirement of m3tk though. Bu=
>t because is just a module dependency analyzer I thought we could just crea=
>te one in m3tk, sort of a chicken and egg problem it seems now. OK, I with =
>an older cm3 we could use it to build it in a setting and then supply itsel=
>f in m3tk, if that's the way to go, therefore I think this is really needed=
> for ESC release.
>Another thing if you allow me is about again the ESC itself, I think that o=
>ne of the ways we could improve some of the ESC checks is to reuse some sor=
>t automatic program debugger I already mentioned about Juno which language =
>has a subset of Simplify language so we could try to postprocess further er=
>rors to guarantee they are so and the more important it could be possible t=
>o think in analyzing checks for soundness so we may try to put closer Simpl=
>if0y to its (in results terms) goal of finding more errors it can catch. Th=
>at said I would go for double checked proofs so me can arguably guarantee t=
>hey are sound proved theoretically and passing through it Simplify again, a=
>ll of this without modification to ESC per se. This is traditional approach=
> for debuggers, so its not a new idea again, just that we need to be smarte=
>r in certain way to catch with the less computation effort the most bugs we=
> can. Another thing I was thinking was to integrate this proofs in
> regular builds so for example a given all program proofs modified by the d=
>ebugger should be presented as warnings of error and something that must be=
> checked closely (supervised).
>Ok, let mw now your thoughts on this points, thanks in advance
>
>--- El s=E1b, 5/3/11, Mika Nystrom <mika at async.caltech.edu> escribi=F3:
>
>> De: Mika Nystrom <mika at async.caltech.edu>
>> Asunto: Re: [M3devel] MODULEs in .M3IMPTAB
>> Para: "Tony Hosking" <hosking at cs.purdue.edu>
>> CC: m3devel at elegosoft.com
>> Fecha: s=E1bado, 5 de marzo, 2011 17:53
>>=20
>> Tony, are you sure?  There don't seem to be any tools
>> in CM3 that process
>> implementations with m3tk, or have I been looking in the
>> wrong places?
>> stubgen doesn't, I don't think stablegen does, and m3pp and
>> m3tohtml
>> don't even use m3tk.  Also it doesn't seem to work on
>> PM3-1.13.2.  Hmmmmm....
>>=20
>>      Mika
>>=20
>> Tony Hosking writes:
>> >It used to work... :-(
>> >
>> >On Mar 5, 2011, at 3:06 PM, Mika Nystrom wrote:
>> >
>> >> Hi again m3devel,
>> >>=20
>> >> Can anyone think of a reason that cm3 should *not*
>> emit information
>> >> about MODULEs that it compiles to .M3IMPTAB?=20
>> (It doesn't, today,
>> >> which means that m3tk-based tools can't find
>> implementations, only
>> >> interfaces.)
>> >>=20
>> >>    Mika
>> =0A=0A=0A      


From dabenavidesd at yahoo.es  Sun Mar  6 05:20:10 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sun, 6 Mar 2011 04:20:10 +0000 (GMT)
Subject: [M3devel] MODULEs in .M3IMPTAB
In-Reply-To: <20110305225351.2A2AD1A2078@async.async.caltech.edu>
Message-ID: <12847.73267.qm@web29719.mail.ird.yahoo.com>

Hi all:
yes, I think I did mention it in a past message because about the ESC, it needes as it m3tk too, I didn't know it was a requirement of m3tk though. But because is just a module dependency analyzer I thought we could just create one in m3tk, sort of a chicken and egg problem it seems now. OK, I with an older cm3 we could use it to build it in a setting and then supply itself in m3tk, if that's the way to go, therefore I think this is really needed for ESC release.
Another thing if you allow me is about again the ESC itself, I think that one of the ways we could improve some of the ESC checks is to reuse some sort automatic program debugger I already mentioned about Juno which language has a subset of Simplify language so we could try to postprocess further errors to guarantee they are so and the more important it could be possible to think in analyzing checks for soundness so we may try to put closer Simplif0y to its (in results terms) goal of finding more errors it can catch. That said I would go for double checked proofs so me can arguably guarantee they are sound proved theoretically and passing through it Simplify again, all of this without modification to ESC per se. This is traditional approach for debuggers, so its not a new idea again, just that we need to be smarter in certain way to catch with the less computation effort the most bugs we can. Another thing I was thinking was to integrate this proofs in
 regular builds so for example a given all program proofs modified by the debugger should be presented as warnings of error and something that must be checked closely (supervised).
Ok, let mw now your thoughts on this points, thanks in advance

--- El s?b, 5/3/11, Mika Nystrom <mika at async.caltech.edu> escribi?:

> De: Mika Nystrom <mika at async.caltech.edu>
> Asunto: Re: [M3devel] MODULEs in .M3IMPTAB
> Para: "Tony Hosking" <hosking at cs.purdue.edu>
> CC: m3devel at elegosoft.com
> Fecha: s?bado, 5 de marzo, 2011 17:53
> 
> Tony, are you sure?  There don't seem to be any tools
> in CM3 that process
> implementations with m3tk, or have I been looking in the
> wrong places?
> stubgen doesn't, I don't think stablegen does, and m3pp and
> m3tohtml
> don't even use m3tk.  Also it doesn't seem to work on
> PM3-1.13.2.  Hmmmmm....
> 
>      Mika
> 
> Tony Hosking writes:
> >It used to work... :-(
> >
> >On Mar 5, 2011, at 3:06 PM, Mika Nystrom wrote:
> >
> >> Hi again m3devel,
> >> 
> >> Can anyone think of a reason that cm3 should *not*
> emit information
> >> about MODULEs that it compiles to .M3IMPTAB? 
> (It doesn't, today,
> >> which means that m3tk-based tools can't find
> implementations, only
> >> interfaces.)
> >> 
> >>    Mika
> 


      


From hosking at cs.purdue.edu  Sun Mar  6 15:54:14 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 6 Mar 2011 09:54:14 -0500
Subject: [M3devel] MODULEs in .M3IMPTAB
In-Reply-To: <20110305225351.2A2AD1A2078@async.async.caltech.edu>
References: <20110305200630.F26711A2078@async.async.caltech.edu>
	<F14FF404-B88C-4C46-B433-744E45311209@cs.purdue.edu>
	<20110305225351.2A2AD1A2078@async.async.caltech.edu>
Message-ID: <D09FFA7F-549C-41F6-AA59-05A6D4B1B48B@cs.purdue.edu>

m3browser?

Sent from my iPhone

On Mar 5, 2011, at 5:53 PM, Mika Nystrom <mika at async.caltech.edu> wrote:

> 
> Tony, are you sure?  There don't seem to be any tools in CM3 that process
> implementations with m3tk, or have I been looking in the wrong places?
> stubgen doesn't, I don't think stablegen does, and m3pp and m3tohtml
> don't even use m3tk.  Also it doesn't seem to work on PM3-1.13.2.  Hmmmmm....
> 
>     Mika
> 
> Tony Hosking writes:
>> It used to work... :-(
>> 
>> On Mar 5, 2011, at 3:06 PM, Mika Nystrom wrote:
>> 
>>> Hi again m3devel,
>>> 
>>> Can anyone think of a reason that cm3 should *not* emit information
>>> about MODULEs that it compiles to .M3IMPTAB?  (It doesn't, today,
>>> which means that m3tk-based tools can't find implementations, only
>>> interfaces.)
>>> 
>>>   Mika


From mika at async.caltech.edu  Sun Mar  6 17:46:35 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Sun, 06 Mar 2011 08:46:35 -0800
Subject: [M3devel] MODULEs in .M3IMPTAB
In-Reply-To: <D09FFA7F-549C-41F6-AA59-05A6D4B1B48B@cs.purdue.edu> 
References: <20110305200630.F26711A2078@async.async.caltech.edu>
	<F14FF404-B88C-4C46-B433-744E45311209@cs.purdue.edu>
	<20110305225351.2A2AD1A2078@async.async.caltech.edu>
	<D09FFA7F-549C-41F6-AA59-05A6D4B1B48B@cs.purdue.edu>
Message-ID: <20110306164635.A86E61A2078@async.async.caltech.edu>

Nope, m3browser uses something called "m3scan"...

Tony Hosking writes:
>m3browser?
>
>Sent from my iPhone
>
>On Mar 5, 2011, at 5:53 PM, Mika Nystrom <mika at async.caltech.edu> wrote:
>
>>=20
>> Tony, are you sure?  There don't seem to be any tools in CM3 that process
>> implementations with m3tk, or have I been looking in the wrong places?
>> stubgen doesn't, I don't think stablegen does, and m3pp and m3tohtml
>> don't even use m3tk.  Also it doesn't seem to work on PM3-1.13.2.  Hmmmmm.=
>...
>>=20
>>     Mika
>>=20
>> Tony Hosking writes:
>>> It used to work... :-(
>>>=20
>>> On Mar 5, 2011, at 3:06 PM, Mika Nystrom wrote:
>>>=20
>>>> Hi again m3devel,
>>>>=20
>>>> Can anyone think of a reason that cm3 should *not* emit information
>>>> about MODULEs that it compiles to .M3IMPTAB?  (It doesn't, today,
>>>> which means that m3tk-based tools can't find implementations, only
>>>> interfaces.)
>>>>=20
>>>>   Mika


From jay.krell at cornell.edu  Mon Mar  7 02:25:59 2011
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 7 Mar 2011 01:25:59 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , , ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , 
	, <20110227231125.3DC611A2078@async.async.caltech.edu>,
	,,<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, ,
	<COL101-W4726257303F22627175774E6C30@phx.gbl>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, ,
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, ,
	<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>,
	<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>
Message-ID: <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>


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/20110307/05931f46/attachment-0001.html>

From jay.krell at cornell.edu  Mon Mar  7 06:39:53 2011
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 7 Mar 2011 05:39:53 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , ,
	,,<20110226175511.3F7D21A2078@async.async.caltech.edu>, , ,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , ,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , ,
	,,<20110227202950.46F3B1A2078@async.async.caltech.edu>, , ,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , ,,,
	<20110227231125.3DC611A2078@async.async.caltech.edu>, , , ,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , 
	, <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>,
	,,<COL101-W4726257303F22627175774E6C30@phx.gbl>,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>,
	,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>,
	,,<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, ,
	<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>,
	<COL101-W1162A9B603898CC921B557E6C70@phx.gbl>
Message-ID: <COL101-W26D3B03885998122254013E6C70@phx.gbl>


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/20110307/816bd520/attachment-0001.html>

From jay.krell at cornell.edu  Mon Mar  7 06:51:32 2011
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 7 Mar 2011 05:51:32 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W26D3B03885998122254013E6C70@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	,,,,<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	,,,,<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	,,,,<20110227231125.3DC611A2078@async.async.caltech.edu>, , ,
	,,<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , ,,,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , ,
	<COL101-W4726257303F22627175774E6C30@phx.gbl>, , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , ,
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , , ,
	<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, , , 
	, <D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>,
	,,<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, ,
	<COL101-W1162A9B603898CC921B557E6C70@phx.gbl>,
	<COL101-W26D3B03885998122254013E6C70@phx.gbl>
Message-ID: <COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>


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/20110307/b5340413/attachment-0001.html>

From jay.krell at cornell.edu  Mon Mar  7 07:53:06 2011
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 7 Mar 2011 06:53:06 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>,
	,,,,,,<20110226175511.3F7D21A2078@async.async.caltech.edu>,
	,,,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>,
	,,,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>,
	,,,,,,<20110227202950.46F3B1A2078@async.async.caltech.edu>,
	,,,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>,
	,,,,,,<20110227231125.3DC611A2078@async.async.caltech.edu>, ,
	,,,,<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, ,
	,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , ,
	,,<COL101-W4726257303F22627175774E6C30@phx.gbl>, , ,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , ,
	,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , ,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , ,
	,,<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, , ,,,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , ,
	<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , 
	, <D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>,
	, , <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, ,
	<COL101-W26D3B03885998122254013E6C70@phx.gbl>,
	<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>
Message-ID: <COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>


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/20110307/2ad39231/attachment-0001.html>

From jay.krell at cornell.edu  Mon Mar  7 07:58:45 2011
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 7 Mar 2011 06:58:45 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , , , , ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , ,
	, <D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , ,
	, , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , ,
	, , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	, , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , ,
	, , <20110227231125.3DC611A2078@async.async.caltech.edu>, 
	,,,,,,<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	,,,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, ,
	,,,,<COL101-W4726257303F22627175774E6C30@phx.gbl>, ,
	,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, ,
	,,,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, ,
	,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, ,
	,,,,<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, ,
	,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , ,
	,,<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , ,,,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>,,, ,
	<COL101-W1162A9B603898CC921B557E6C70@phx.gbl>,
	, , <COL101-W26D3B03885998122254013E6C70@phx.gbl>, ,
	<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>,
	<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>
Message-ID: <COL101-W510B831AC595A3597FE281E6C70@phx.gbl>


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/20110307/4689d5a0/attachment-0001.html>

From jay.krell at cornell.edu  Wed Mar  9 21:10:37 2011
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 9 Mar 2011 20:10:37 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W510B831AC595A3597FE281E6C70@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , , , , ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , ,
	, <D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , ,
	, , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , ,
	, , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	, , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , ,
	, , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , ,
	, , , <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , , ,
	, <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, 
	,,,,,,<COL101-W4726257303F22627175774E6C30@phx.gbl>,
	,,,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>,
	,,,,,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>,
	,,,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>,
	,,,,,,<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>,
	,,,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, ,
	,,,,<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, ,
	,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>,,,
	, , <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , , ,
	<COL101-W26D3B03885998122254013E6C70@phx.gbl>, ,
	<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>,
	<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>,
	<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>
Message-ID: <COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>


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/20110309/f55d5318/attachment-0001.html>

From jay.krell at cornell.edu  Thu Mar 10 11:09:02 2011
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 10 Mar 2011 10:09:02 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , , , , ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , ,
	, <D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , ,
	, , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , ,
	, , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	, , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , ,
	, , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , ,
	, , , <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , , ,
	, <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , ,
	, , , <COL101-W4726257303F22627175774E6C30@phx.gbl>, , , , , , ,
	, <D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , ,
	, , , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, ,
	, , , , , , <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>,
	, , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, 
	,,,,,,<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>,
	, , , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , ,
	, , <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , , ,
	<COL101-W26D3B03885998122254013E6C70@phx.gbl>, ,
	<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>,
	<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>,
	<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>,
	<COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>
Message-ID: <COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>


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/105955e1/attachment-0001.html>

From jay.krell at cornell.edu  Thu Mar 10 11:40:58 2011
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 10 Mar 2011 10:40:58 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , ,
	, , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , ,
	, , 
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , ,,, , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , ,,, , , , ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,,, , , , ,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , , , ,
	, 
	<20110227231125.3DC611A2078@async.async.caltech.edu>, , , , ,,, , ,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , , ,,,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , ,,, , ,
	<COL101-W4726257303F22627175774E6C30@phx.gbl>, , , , , , ,,,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , ,,, , ,
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , ,,, , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, ,,, , , , , ,
	<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>,,, , , , , ,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , , , ,
	<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , 
	, , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , , ,
	, , <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , ,
	,,<COL101-W26D3B03885998122254013E6C70@phx.gbl>,
	, , <COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>, ,
	<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>, ,
	<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>, ,
	<COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>,
	<COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>
Message-ID: <COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>


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/c8e8b320/attachment-0001.html>

From jay.krell at cornell.edu  Thu Mar 10 12:05:40 2011
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 10 Mar 2011 11:05:40 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , ,
	, , , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , ,
	, 
	, , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , ,
	, , , 
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , ,,, , , ,
	, , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , , , ,
	, , 
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , , ,
	,,,,<20110227231125.3DC611A2078@async.async.caltech.edu>, , , , ,,, ,
	,,<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , , ,
	, , ,,<COL101-W4726257303F22627175774E6C30@phx.gbl>, , , , , ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , , ,
	, , 
	,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , ,,, , ,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, ,,, , , , ,
	, , <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, , , , , , , , ,
	, , 
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , , ,
	,,<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , ,,, , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , , ,,, ,
	<COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, ,
	,,,,<COL101-W26D3B03885998122254013E6C70@phx.gbl>,,, ,
	<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>,
	,,<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>,
	,,<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>,
	, , <COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>, ,
	<COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>,
	<COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>
Message-ID: <COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>


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/01a78fc7/attachment-0001.html>

From jay.krell at cornell.edu  Thu Mar 10 12:11:35 2011
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 10 Mar 2011 11:11:35 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , ,,,
	, , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , ,
	, , , 
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , , ,
	, , 
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , , , , ,
	, , , , , 
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , , , , , ,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , ,
	,,,,,,<20110227231125.3DC611A2078@async.async.caltech.edu>, , , , ,,,
	,,,,<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , ,,, , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , , ,,, ,
	,,<COL101-W4726257303F22627175774E6C30@phx.gbl>, , , , , ,,, , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , , ,,,
	,,,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , ,,, ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , , , , ,
	, , , , , 
	<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, , , , , , , , , , ,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , ,
	,,,,<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , ,,, , , ,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , , ,,,
	,,<COL101-W1162A9B603898CC921B557E6C70@phx.gbl>,
	,,,,,,<COL101-W26D3B03885998122254013E6C70@phx.gbl>,,,
	, , <COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>, , , ,
	<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>, , , ,
	<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>, , , 
	, <COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>,
	, , <COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>, ,
	<COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>,
	<COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>
Message-ID: <COL101-W1593ED3DF56A0900656FCE6C80@phx.gbl>


I forgot to point out: I'll stick to 32bit Windows for now, while looking at Mika's threadtest.

 - Jay

From: jay.krell at cornell.edu
To: rcolebur at scires.com; m3devel at elegosoft.com
Date: Thu, 10 Mar 2011 11:05:40 +0000
Subject: Re: [M3devel] results of threadtest program on Windows7








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/e60c249b/attachment-0001.html>

From rcolebur at SCIRES.COM  Thu Mar 10 17:18:31 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 10 Mar 2011 11:18:31 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , ,
	, , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , ,
	, , 
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , ,,, , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , ,,, , , , ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,,, , , , ,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , , , ,
	, 
	<20110227231125.3DC611A2078@async.async.caltech.edu>, , , , ,,, , ,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , , ,,,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , ,,, , ,
	<COL101-W4726257303F22627175774E6C30@phx.gbl>, , , , , , ,,,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , ,,, , ,
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , ,,, , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, ,,, , , , , ,
	<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>,,, , , , , ,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , , , ,
	<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , 
	, , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , , ,
	, , <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , ,
	,,<COL101-W26D3B03885998122254013E6C70@phx.gbl>,
	, , <COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>, ,
	<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>, ,
	<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>, ,
	<COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>,
	<COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>
	<COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6EE527A91@atlex02-srv>

Jay et al:

CM3's use of native windows threads has worked very well for me in the past, and the majority of all my programs have always been multithreaded.

Surely there must be some collection of changes in last couple of years that is responsible for the runtime errors we are seeing now with the thread test program.  Another possibility is that maybe there is something wrong with the thread test program itself that we haven't spotted yet.

I will try to take some time soon to go back to an earlier cm3 release and run the thread test program there to see how it fares.

Regards,
Randy

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Thursday, March 10, 2011 5:41 AM
To: Coleburn, Randy; m3devel
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/14057194/attachment-0001.html>

From hosking at cs.purdue.edu  Thu Mar 10 17:50:40 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 10 Mar 2011 11:50:40 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , , , ,
	, , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , ,
	, , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , , ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	, , , , , , , ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	, , , , , , , , ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , , ,
	, , , <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , , ,
	, , , <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , ,
	, , , , , , , <COL101-W4726257303F22627175774E6C30@phx.gbl>, , ,
	, , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , , ,
	, , , , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , ,
	, , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , , , , ,
	, , , , <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, !
	, , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , ,
	, , , <COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , , , , ,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , ,
	, , , , <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , , , , ,
	<COL101-W26D3B03885998122254013E6C70@phx.gbl>, , , ,
	<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>, , ,
	<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>, , ,
	<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>, , ,
	<COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>, ,
	<COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>,
	<COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>
	<COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>
Message-ID: <FDAEB2B4-BC12-45DB-8F60-639A9B8E48EF@cs.purdue.edu>

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-0001.html>

From dabenavidesd at yahoo.es  Thu Mar 10 20:19:00 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 10 Mar 2011 19:19:00 +0000 (GMT)
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <FDAEB2B4-BC12-45DB-8F60-639A9B8E48EF@cs.purdue.edu>
Message-ID: <291871.70222.qm@web29714.mail.ird.yahoo.com>

Hi all:
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.
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.
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.
Thanks in advance

--- El jue, 10/3/11, Tony Hosking <hosking at cs.purdue.edu> escribi?:

De: Tony Hosking <hosking at cs.purdue.edu>
Asunto: Re: [M3devel] results of threadtest program on Windows7
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 10 de marzo, 2011 11:50

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/3b78b82d/attachment-0001.html>

From jay.krell at cornell.edu  Thu Mar 10 22:03:58 2011
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 10 Mar 2011 21:03:58 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <FDAEB2B4-BC12-45DB-8F60-639A9B8E48EF@cs.purdue.edu>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , ,
	, , , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , ,
	, , , 
	, , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , ,
	, , , 
	, , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , , , , , ,
	, , 
	, , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , , ,
	, , , 
	, <D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , , , , ,
	, , 
	, , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , , , , ,
	, , 
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , , ,,, , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , , , , , , ,
	, <COL101-W4726257303F22627175774E6C30@phx.gbl>, , ,,, , , , , ,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , , , , ,
	, , , 
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , ,,, , , , , ,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , , , , , , ,
	, , , 
	<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, !, , , , , , , , ,
	, 
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , , , ,
	, , <COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , , , , ,,, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , ,,, , , ,
	<COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , , , ,
	,,<COL101-W26D3B03885998122254013E6C70@phx.gbl>, , ,
	,,<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>, ,
	,,<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>, ,
	,,<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>, ,
	,,<COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>,
	, , <COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>, ,
	<COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>,
	<COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>,
	<FDAEB2B4-BC12-45DB-8F60-639A9B8E48EF@cs.purdue.edu>
Message-ID: <COL101-w573D2FF7546A4BCDD27275E6C80@phx.gbl>


I often forget this. Thank you.

 - Jay

From: hosking at cs.purdue.edu
Date: Thu, 10 Mar 2011 11:50:40 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] results of threadtest program on Windows7



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/35d57c4d/attachment-0001.html>

From jay.krell at cornell.edu  Sat Mar 12 10:57:13 2011
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 12 Mar 2011 09:57:13 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-w573D2FF7546A4BCDD27275E6C80@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , ,
	, , , , , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , ,
	, , , , 
	, , , , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , ,
	, , 
	, , , , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , ,
	, , , , 
	, , , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , ,
	, , , , 
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , ,
	, , , 
	, , , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , ,
	, , , , 
	,,<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , , ,,, ,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , , , , ,
	, , ,,<COL101-W4726257303F22627175774E6C30@phx.gbl>, , ,,, , , , ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , , ,
	, , , , 
	,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , ,,, , , , ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , , , , ,
	, , , , 
	, , <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, !, , , , , , ,
	, , 
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , ,
	, , , 
	,,<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , , , , ,,,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , ,,, , ,
	,,<COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , , ,
	,,,,<COL101-W26D3B03885998122254013E6C70@phx.gbl>, ,
	,,,,<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>,
	,,,,<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>,
	,,,,<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>,
	, , , , <COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>, , , ,
	<COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>, ,
	<COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>,
	<COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>,
	<FDAEB2B4-BC12-45DB-8F60-639A9B8E48EF@cs.purdue.edu>,
	<COL101-w573D2FF7546A4BCDD27275E6C80@phx.gbl>
Message-ID: <COL101-w65CBD25BD3FC0BFF9115BBE6CA0@phx.gbl>


There is a lack of evidence that Java does things in a way at all resembling what Modula-3 does, on Win32.
 There is precious little in the way of calling the Win32 functions SuspendThread and GetThreadContext.
There is evidence that they use cooperative suspend.
It isn't conclusive, to me..just because there is so much there, it is not immediately clear.
That is, pretty clear there is code implementing cooperative suspend, but is that their entire story? I don't know.

 - Jay

From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] results of threadtest program on Windows7
Date: Thu, 10 Mar 2011 21:03:58 +0000








I often forget this. Thank you.

 - Jay

From: hosking at cs.purdue.edu
Date: Thu, 10 Mar 2011 11:50:40 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] results of threadtest program on Windows7



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/20110312/0a47c8d0/attachment-0001.html>

From hosking at cs.purdue.edu  Sat Mar 12 17:23:04 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 12 Mar 2011 11:23:04 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-w65CBD25BD3FC0BFF9115BBE6CA0@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , , , ,
	, , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	, , , , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , , ,
	, , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , , , , ,
	, , , , , , ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , ,
	, , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , ,
	, , , , , , , ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , , ,
	, , , , , <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , ,
	, , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , , ,
	, , , , , , <COL101-W4726257303F22627175774E6C30@phx.gbl>, , , ,
	, , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , , ,
	, , , , , , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>,
	, , , , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , , , , ,
	, , , , , , <44BAC21C-4375-478B-9FDF-27181181D7!
	65@cs.purdue.edu>, !, , , , , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , ,
	, , , , , <COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , , ,
	, , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , , , ,
	, , , , <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , , , , ,
	, , <COL101-W26D3B03885998122254013E6C70@phx.gbl>, , , , , ,
	<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>, , , , ,
	<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>, , , , ,
	<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>, , , , ,
	<COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>, , , ,
	<COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>, ,
	<COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>,
	<COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>,
	<FDAEB2B4-BC12-45DB-8F60-639A9B8E48EF@cs.purdue.edu>,
	<COL101-w573D2FF7546A4BCDD27275E6C80@phx.gbl>
	<COL101-w65CBD25BD3FC0BFF9115BBE6CA0@phx.gbl>
Message-ID: <8972478C-50D2-41D1-8DEB-57323B1D3580@cs.purdue.edu>

I know they use cooperative suspend.
We do in Jikes RVM too.
That's another code base to look at.  Probably easier as it is all in Java.

On Mar 12, 2011, at 4:57 AM, Jay K wrote:

> There is a lack of evidence that Java does things in a way at all resembling what Modula-3 does, on Win32.
>  There is precious little in the way of calling the Win32 functions SuspendThread and GetThreadContext.
> There is evidence that they use cooperative suspend.
> It isn't conclusive, to me..just because there is so much there, it is not immediately clear.
> That is, pretty clear there is code implementing cooperative suspend, but is that their entire story? I don't know.
> 
>  - Jay
> 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] results of threadtest program on Windows7
> Date: Thu, 10 Mar 2011 21:03:58 +0000
> 
> I often forget this. Thank you.
> 
>  - Jay
> 
> From: hosking at cs.purdue.edu
> Date: Thu, 10 Mar 2011 11:50:40 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> 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/20110312/3f9c933e/attachment-0001.html>

From jay.krell at cornell.edu  Sun Mar 13 01:40:36 2011
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 13 Mar 2011 00:40:36 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <8972478C-50D2-41D1-8DEB-57323B1D3580@cs.purdue.edu>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , ,
	, , , , , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , ,
	, , , , 
	, , , , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , ,
	, , 
	, , , , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , ,
	, , , , 
	, , , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , ,
	, , , , 
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , ,
	, , , 
	, , , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , ,
	, , , , 
	,,<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , , ,,, ,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , , , , ,
	, , ,,<COL101-W4726257303F22627175774E6C30@phx.gbl>, , ,,, , , , ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , , ,
	, , , , 
	,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , ,,, , , , ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , , , , ,
	, , , , 
	, , <44BAC21C-4375-478B-9FDF-27181181D7!, 65@cs.purdue.edu>, !, , , , , ,
	, , , 
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , ,
	, , , 
	,,<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , , , , ,,,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , ,,, , ,
	,,<COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , , ,
	,,,,<COL101-W26D3B03885998122254013E6C70@phx.gbl>, ,
	,,,,<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>,
	,,,,<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>,
	,,,,<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>,
	, , , , <COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>, , , ,
	<COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>, ,
	<COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>,
	<COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>,
	<FDAEB2B4-BC12-45DB-8F60-639A9B8E48EF@cs.purdue.edu>,
	<COL101-w573D2FF7546A4BCDD27275E6C80@phx.gbl>
	<COL101-w65CBD25BD3FC0BFF9115BBE6CA0@phx.gbl>,
	<8972478C-50D2-41D1-8DEB-57323B1D3580@cs.purdue.edu>
Message-ID: <COL101-W640F123E3C9A858317508E6CD0@phx.gbl>


I thought maybe they'd show a way for us to get away with "preemptive suspend",
a way to use SuspendThread/GetThreadContext with confidence.

So, you agree we want cooperative suspend then?
And we should maybe get going on implementing it?
Maybe do that before debugging Mika's problem?
  Well, to repeat myself, I'm ok with looking into 32bit-only Windows for Mika's problem.
  Though, clearly, as i've said, I have A LOT less time for Modula-3 now and probably ever.

 - Jay

Subject: Re: [M3devel] results of threadtest program on Windows7
From: hosking at cs.purdue.edu
Date: Sat, 12 Mar 2011 11:23:04 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu



I know they use cooperative suspend.We do in Jikes RVM too.That's another code base to look at.  Probably easier as it is all in Java.

On Mar 12, 2011, at 4:57 AM, Jay K wrote:There is a lack of evidence that Java does things in a way at all resembling what Modula-3 does, on Win32.
 There is precious little in the way of calling the Win32 functions SuspendThread and GetThreadContext.
There is evidence that they use cooperative suspend.
It isn't conclusive, to me..just because there is so much there, it is not immediately clear.
That is, pretty clear there is code implementing cooperative suspend, but is that their entire story? I don't know.

 - Jay

From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] results of threadtest program on Windows7
Date: Thu, 10 Mar 2011 21:03:58 +0000

I often forget this. Thank you.

 - Jay

From: hosking at cs.purdue.edu
Date: Thu, 10 Mar 2011 11:50:40 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] results of threadtest program on Windows7

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/20110313/8d270d25/attachment-0001.html>

From hosking at cs.purdue.edu  Sun Mar 13 19:08:10 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 13 Mar 2011 14:08:10 -0400
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W640F123E3C9A858317508E6CD0@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , , , ,
	, , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	, , , , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , , ,
	, , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , , , , ,
	, , , , , , ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , ,
	, , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , ,
	, , , , , , , ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , , ,
	, , , , , <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , ,
	, , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , , ,
	, , , , , , <COL101-W4726257303F22627175774E6C30@phx.gbl>, , , ,
	, , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , , ,
	, , , , , , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>,
	, , , , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , , , , ,
	, , , , , , <44BAC21C-4375-478B-9FDF-27181181D7!
	!, 65@cs.purdue.edu>, !, , , , , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , ,
	, , , , , <COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , , ,
	, , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , , , ,
	, , , , <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , , , , ,
	, , <COL101-W26D3B03885998122254013E6C70@phx.gbl>, , , , , ,
	<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>, , , , ,
	<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>, , , , ,
	<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>, , , , ,
	<COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>, , , ,
	<COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>, ,
	<COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>,
	<COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>,
	<FDAEB2B4-BC12-45DB-8F60-639A9B8E48EF@cs.purdue.edu>,
	<COL101-w573D2FF7546A4BCDD27275E6C80@phx.gbl>
	<COL101-w65CBD25BD3FC0BFF9115BBE6CA0@phx.gbl>,
	<8972478C-50D2-41D1-8DEB-57323B1D3580@cs.purdue.edu>
	<COL101-W640F123E3C9A858317508E6CD0@phx.gbl>
Message-ID: <685C8B05-23D1-4BE8-93BB-3B11FFD28AFF@cs.purdue.edu>

I'd like to debug the current problem because it does not seem to imply any problem with suspend/resume.  More likely is losing a reference in the stacks somehow.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On Mar 12, 2011, at 7:40 PM, Jay K wrote:

> I thought maybe they'd show a way for us to get away with "preemptive suspend",
> a way to use SuspendThread/GetThreadContext with confidence.
> 
> So, you agree we want cooperative suspend then?
> And we should maybe get going on implementing it?
> Maybe do that before debugging Mika's problem?
>   Well, to repeat myself, I'm ok with looking into 32bit-only Windows for Mika's problem.
>   Though, clearly, as i've said, I have A LOT less time for Modula-3 now and probably ever.
> 
>  - Jay
> 
> Subject: Re: [M3devel] results of threadtest program on Windows7
> From: hosking at cs.purdue.edu
> Date: Sat, 12 Mar 2011 11:23:04 -0500
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> I know they use cooperative suspend.
> We do in Jikes RVM too.
> That's another code base to look at.  Probably easier as it is all in Java.
> 
> On Mar 12, 2011, at 4:57 AM, Jay K wrote:
> 
> There is a lack of evidence that Java does things in a way at all resembling what Modula-3 does, on Win32.
>  There is precious little in the way of calling the Win32 functions SuspendThread and GetThreadContext.
> There is evidence that they use cooperative suspend.
> It isn't conclusive, to me..just because there is so much there, it is not immediately clear.
> That is, pretty clear there is code implementing cooperative suspend, but is that their entire story? I don't know.
> 
>  - Jay
> 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] results of threadtest program on Windows7
> Date: Thu, 10 Mar 2011 21:03:58 +0000
> 
> I often forget this. Thank you.
> 
>  - Jay
> 
> From: hosking at cs.purdue.edu
> Date: Thu, 10 Mar 2011 11:50:40 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> 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/20110313/f58adf71/attachment-0001.html>

From dabenavidesd at yahoo.es  Sun Mar 13 21:34:27 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sun, 13 Mar 2011 20:34:27 +0000 (GMT)
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <685C8B05-23D1-4BE8-93BB-3B11FFD28AFF@cs.purdue.edu>
Message-ID: <895304.26763.qm@web29717.mail.ird.yahoo.com>

Hi all:
I was wondering how it might to produce an environment such of gcc level compatibility, without breaking the runtime in two languages, that is sort of the idea I guess never fully released GNU Modula-3. Perhaps that was the idea of RMS, to make compatible interfaces so anything misbehaved in any platform could be replaced with something more usable for those purposes (and so he was just interested in code generator that accompanied m3tk) see:
http://opensource.apple.com/source/gcc/gcc-5479/boehm-gc/doc/README.macros

So in that case we could use some of the RT requirements more easily and give each platform free compatibility of our RT so more freedom for further developments, say GPL interface against implementations, etc and stabilize more the RT in terms of more up to date requirements, with openjdk, or any other RT, even OS deprecated ones (say we would want that applied in Android OS or any other lightweight system e.g Java I/O subsystem borrow):

http://www.semiramis.org.uk/rrw/software/misc/ksynch.html

Indeed a contracted developer by MIT developed such automating of information recovery from C interfaces (well an OO C dialect) to link with Modula-3 runtime without too much replication and much more smoothly? results? in terms of stability of? Modula-3 RT such e.g apply it too Atoms, etc with full compatiblity if so:
http://www.doc.ic.ac.uk/~pcc03/transfer.pdf
Perhaps this way can we reuse some more time of current developers and historical ones too, which I believe are very important too (especially ESC in Java for any kind of developer even from smartphones and innovative systems like? see:
http://whiley.org/about/overview/
).

Thanks in advance

--- El dom, 13/3/11, Tony Hosking <hosking at cs.purdue.edu> escribi?:

De: Tony Hosking <hosking at cs.purdue.edu>
Asunto: Re: [M3devel] results of threadtest program on Windows7
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: domingo, 13 de marzo, 2011 13:08

I'd like to debug the current problem because it does not seem to imply any problem with suspend/resume. ?More likely is losing a reference in the stacks somehow.

Antony Hosking?|?Associate Professor?| Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice?+1 765 494 6001 |?Mobile?+1 765 427 5484





On Mar 12, 2011, at 7:40 PM, Jay K wrote:
I thought maybe they'd show a way for us to get away with "preemptive suspend",
a way to use SuspendThread/GetThreadContext with confidence.

So, you agree we want cooperative suspend then?
And we should maybe get going on implementing it?
Maybe do that before debugging Mika's problem?
? Well, to repeat myself, I'm ok with looking into 32bit-only Windows for Mika's problem.
? Though, clearly, as i've said, I have A LOT less time for Modula-3 now and probably ever.

?- Jay

Subject: Re: [M3devel] results of threadtest program on Windows7
From:?hosking at cs.purdue.edu
Date: Sat, 12 Mar 2011 11:23:04 -0500
CC:?m3devel at elegosoft.com
To:?jay.krell at cornell.edu

I know they use cooperative suspend.We do in Jikes RVM too.That's another code base to look at. ?Probably easier as it is all in Java.
On Mar 12, 2011, at 4:57 AM, Jay K wrote:
There is a lack of evidence that Java does things in a way at all resembling what Modula-3 does, on Win32.
?There is precious little in the way of calling the Win32 functions SuspendThread and GetThreadContext.
There is evidence that they use cooperative suspend.
It isn't conclusive, to me..just because there is so much there, it is not immediately clear.
That is, pretty clear there is code implementing cooperative suspend, but is that their entire story? I don't know.

?- Jay

From:?jay.krell at cornell.edu
To:?hosking at cs.purdue.edu
CC:?m3devel at elegosoft.com
Subject: RE: [M3devel] results of threadtest program on Windows7
Date: Thu, 10 Mar 2011 21:03:58 +0000

I often forget this. Thank you.

?- Jay

From:?hosking at cs.purdue.edu
Date: Thu, 10 Mar 2011 11:50:40 -0500
To:?jay.krell at cornell.edu
CC:?m3devel at elegosoft.com
Subject: Re: [M3devel] results of threadtest program on Windows7

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/20110313/c6361136/attachment-0001.html>

From dabenavidesd at yahoo.es  Sun Mar 13 21:44:39 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sun, 13 Mar 2011 20:44:39 +0000 (GMT)
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <895304.26763.qm@web29717.mail.ird.yahoo.com>
Message-ID: <234847.43171.qm@web29704.mail.ird.yahoo.com>

Hi all:
instead of before http://www.doc.ic.ac.uk/~pcc03/transfer.pdf
see:
ftp://asg3.andrew.cmu.edu/pub/AUIS/auis-6.3.1/doc/papers/atk/conference/Orgass.paper.ps
at cmu, the first at another too. 
Sorry, thanks in advance

--- El dom, 13/3/11, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] results of threadtest program on Windows7
Para: "Jay K" <jay.krell at cornell.edu>, "Tony Hosking" <hosking at cs.purdue.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: domingo, 13 de marzo, 2011 15:34

Hi all:
I was wondering how it might to produce an environment such of gcc level compatibility, without breaking the runtime in two languages, that is sort of the idea I guess never fully released GNU Modula-3. Perhaps that was the idea of RMS, to make compatible interfaces so anything misbehaved in any platform could be replaced with something more usable for those purposes (and so he was just interested in code generator that accompanied m3tk) see:
http://opensource.apple.com/source/gcc/gcc-5479/boehm-gc/doc/README.macros

So in that case we could use some of the RT requirements more easily and give each platform free compatibility of our RT so more freedom for further developments, say GPL interface against implementations, etc and stabilize more the RT in terms of more up to date requirements, with openjdk, or any other RT, even OS deprecated
 ones (say we would want that applied in Android OS or any other lightweight system e.g Java I/O subsystem borrow):

http://www.semiramis.org.uk/rrw/software/misc/ksynch.html

Indeed a contracted developer by MIT developed such automating of information recovery from C interfaces (well an OO C dialect) to link with Modula-3 runtime without too much replication and much more smoothly? results? in terms of stability of? Modula-3 RT such e.g apply it too Atoms, etc with full compatiblity if so:
http://www.doc.ic.ac.uk/~pcc03/transfer.pdf
Perhaps this way can we reuse some more time of current developers and historical ones too, which I believe are very important too (especially ESC in Java for any kind of developer even from smartphones and innovative systems like? see:
http://whiley.org/about/overview/
).

Thanks in advance

--- El dom, 13/3/11, Tony Hosking <hosking at cs.purdue.edu>
 escribi?:

De: Tony Hosking <hosking at cs.purdue.edu>
Asunto: Re: [M3devel] results of threadtest program on Windows7
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: domingo, 13 de marzo, 2011 13:08

I'd like to debug the current problem because it does not seem to imply any problem with suspend/resume. ?More likely is losing a reference in the stacks somehow.

Antony
 Hosking?|?Associate Professor?| Computer Science | Purdue University305 N. University
 Street | West Lafayette | IN 47907 | USAOffice?+1 765 494 6001 |?Mobile?+1 765 427 5484





On Mar 12, 2011, at 7:40 PM, Jay K wrote:
I thought maybe they'd show a way for us to get away with "preemptive suspend",
a way to use SuspendThread/GetThreadContext with confidence.

So, you agree we want cooperative suspend then?
And we should maybe get going on implementing it?
Maybe do that before debugging Mika's problem?
? Well, to repeat myself, I'm ok with looking into 32bit-only Windows for Mika's problem.
? Though,
 clearly, as i've said, I have A LOT less time for Modula-3 now and probably ever.

?- Jay

Subject: Re: [M3devel] results of threadtest program on Windows7
From:?hosking at cs.purdue.edu
Date: Sat, 12 Mar 2011 11:23:04 -0500
CC:?m3devel at elegosoft.com
To:?jay.krell at cornell.edu

I know they use cooperative suspend.We do in Jikes RVM
 too.That's another code base to look at. ?Probably easier as it is all in Java.
On Mar 12, 2011, at 4:57 AM, Jay K wrote:
There is a lack of evidence that Java does things in a way at all resembling what Modula-3 does, on Win32.
?There is precious little in the way of calling the Win32 functions SuspendThread and GetThreadContext.
There is evidence that they use cooperative suspend.
It isn't conclusive, to me..just because there is so much
 there, it is not immediately clear.
That is, pretty clear there is code implementing cooperative suspend, but is that their entire story? I don't know.

?- Jay

From:?jay.krell at cornell.edu
To:?hosking at cs.purdue.edu
CC:?m3devel at elegosoft.com
Subject: RE: [M3devel] results of threadtest program on Windows7
Date: Thu, 10 Mar 2011 21:03:58
 +0000

I often forget this. Thank you.

?- Jay

From:?hosking at cs.purdue.edu
Date: Thu, 10 Mar 2011 11:50:40 -0500
To:?jay.krell at cornell.edu
CC:?m3devel at elegosoft.com
Subject: Re: [M3devel] results of threadtest program on Windows7

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/20110313/5435f0b3/attachment-0001.html>

From jay.krell at cornell.edu  Sun Mar 13 23:34:06 2011
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 13 Mar 2011 22:34:06 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <685C8B05-23D1-4BE8-93BB-3B11FFD28AFF@cs.purdue.edu>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , ,
	, , , , , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , ,
	, , , , , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , 
	, , , , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, 
	, , , , ,,, , , , , ,
	, , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , , , ,
	, , , 
	, , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , , ,
	, , , 
	, , , , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , ,
	, 
	, , , , , , , <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , , ,
	, , , , 
	, , , <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , , , ,
	, , , 
	, , , <COL101-W4726257303F22627175774E6C30@phx.gbl>, , , , , , , , , , ,
	, , 
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , , , , ,
	, , , 
	, , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , , , , , , ,
	, , 
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , , , , ,
	, , , 
	, , , , <44BAC21C-4375-478B-9FDF-27181181D7!, !, 65@cs.purdue.edu>, !, ,
	, , , , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , 
	, , , , , , , , , , <COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , ,
	, , , , 
	, , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , , ,
	, , , 
	, , , <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , , , , ,,, ,
	<COL101-W26D3B03885998122254013E6C70@phx.gbl>, , , , ,
	,,<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>, , , ,
	,,<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>, , , ,
	,,<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>, , , ,
	,,<COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>, , ,
	,,<COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>,
	, , <COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>, ,
	<COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>, ,
	<FDAEB2B4-BC12-45DB-8F60-639A9B8E48EF@cs.purdue.edu>, ,
	<COL101-w573D2FF7546A4BCDD27275E6C80@phx.gbl>,
	<COL101-w65CBD25BD3FC0BFF9115BBE6CA0@phx.gbl>, ,
	<8972478C-50D2-41D1-8DEB-57323B1D3580@cs.purdue.edu>,
	<COL101-W640F123E3C9A858317508E6CD0@phx.gbl>,
	<685C8B05-23D1-4BE8-93BB-3B11FFD28AFF@cs.purdue.edu>
Message-ID: <COL101-W27E336FE3D9BE3CC4F1320E6CD0@phx.gbl>


Huh? Imagine the stack/registers of a suspended thread cannot be reliably correctly retrieved.
That seems to be the case on wow64.
That would lead to these problems, right?
Anyone seen the tests fail on Win32 on a 32bit OS?
  Even so, I'd want to make sure that 32bit, we don't get the kernel thread context sometimes.
  But that shouldn't be hard to to detect and avoid, i.e. an out of range stack pointer.
I'll see how it goes on a 32bit Windows OS.

 - Jay

From: hosking at cs.purdue.edu
Date: Sun, 13 Mar 2011 14:08:10 -0400
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] results of threadtest program on Windows7



I'd like to debug the current problem because it does not seem to imply any problem with suspend/resume.  More likely is losing a reference in the stacks somehow.

Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484


On Mar 12, 2011, at 7:40 PM, Jay K wrote:I thought maybe they'd show a way for us to get away with "preemptive suspend",
a way to use SuspendThread/GetThreadContext with confidence.

So, you agree we want cooperative suspend then?
And we should maybe get going on implementing it?
Maybe do that before debugging Mika's problem?
  Well, to repeat myself, I'm ok with looking into 32bit-only Windows for Mika's problem.
  Though, clearly, as i've said, I have A LOT less time for Modula-3 now and probably ever.

 - Jay

Subject: Re: [M3devel] results of threadtest program on Windows7
From: hosking at cs.purdue.edu
Date: Sat, 12 Mar 2011 11:23:04 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

I know they use cooperative suspend.We do in Jikes RVM too.That's another code base to look at.  Probably easier as it is all in Java.
On Mar 12, 2011, at 4:57 AM, Jay K wrote:There is a lack of evidence that Java does things in a way at all resembling what Modula-3 does, on Win32.
 There is precious little in the way of calling the Win32 functions SuspendThread and GetThreadContext.
There is evidence that they use cooperative suspend.
It isn't conclusive, to me..just because there is so much there, it is not immediately clear.
That is, pretty clear there is code implementing cooperative suspend, but is that their entire story? I don't know.

 - Jay

From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] results of threadtest program on Windows7
Date: Thu, 10 Mar 2011 21:03:58 +0000

I often forget this. Thank you.

 - Jay

From: hosking at cs.purdue.edu
Date: Thu, 10 Mar 2011 11:50:40 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] results of threadtest program on Windows7

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/20110313/ee993653/attachment-0001.html>

From dabenavidesd at yahoo.es  Mon Mar 14 17:26:54 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 14 Mar 2011 16:26:54 +0000 (GMT)
Subject: [M3devel] About current DCVS and Elego Compact version to don't
	fear the fork
Message-ID: <224092.3263.qm@web29710.mail.ird.yahoo.com>

Hi all:
I just was wondering was the current status of integration if so of both tools, as I have been reading this techguide, see:
http://www.zdnetasia.com/don-t-fear-the-fork-how-dvcs-aids-open-source-development-62207783.htm?scid=nl_z_tgos

about forks and distributed control version systems (maybe that should I call it diversion?).
Ok, I read that some of the Modules are ready for cvsup in Elego-compact but what about dcvs, does it makes sense for it to have it if it's not already integrated, or would you have considered this before current elego compact release, if there is anything specific towards that integration if so what else would be needed or are they loosely coupled?
I appreciate any comments and opinion about doing that, for instance a given php developer which already has cvsup as its control version system mirror of cvs may want to contract someone to make a fork and so to do that.
Thanks in advance



      


From jay.krell at cornell.edu  Mon Mar 14 20:52:22 2011
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 14 Mar 2011 19:52:22 +0000
Subject: [M3devel] About current DCVS and Elego Compact version to don't
 fear the fork
In-Reply-To: <224092.3263.qm@web29710.mail.ird.yahoo.com>
References: <224092.3263.qm@web29710.mail.ird.yahoo.com>
Message-ID: <COL101-W426E1F003C66371CECA627E6CC0@phx.gbl>


Surely the answer is to use GIT or Mercurial or Monotone.
And not anything based on CVS.
 
 - Jay
 
> Date: Mon, 14 Mar 2011 16:26:54 +0000
> From: dabenavidesd at yahoo.es
> To: m3devel at elegosoft.com
> Subject: [M3devel] About current DCVS and Elego Compact version to don't fear the fork
> 
> Hi all:
> I just was wondering was the current status of integration if so of both tools, as I have been reading this techguide, see:
> http://www.zdnetasia.com/don-t-fear-the-fork-how-dvcs-aids-open-source-development-62207783.htm?scid=nl_z_tgos
> 
> about forks and distributed control version systems (maybe that should I call it diversion?).
> Ok, I read that some of the Modules are ready for cvsup in Elego-compact but what about dcvs, does it makes sense for it to have it if it's not already integrated, or would you have considered this before current elego compact release, if there is anything specific towards that integration if so what else would be needed or are they loosely coupled?
> I appreciate any comments and opinion about doing that, for instance a given php developer which already has cvsup as its control version system mirror of cvs may want to contract someone to make a fork and so to do that.
> Thanks in advance 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/9eab90bd/attachment-0001.html>

From wagner at elegosoft.com  Mon Mar 14 21:25:14 2011
From: wagner at elegosoft.com (Olaf Wagner)
Date: Mon, 14 Mar 2011 21:25:14 +0100
Subject: [M3devel] About current DCVS and Elego Compact version to	don't
	fear the fork
In-Reply-To: <COL101-W426E1F003C66371CECA627E6CC0@phx.gbl>
References: <224092.3263.qm@web29710.mail.ird.yahoo.com>
	<COL101-W426E1F003C66371CECA627E6CC0@phx.gbl>
Message-ID: <20110314212514.edcnep7i8wk8gwkc@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

>
> Surely the answer is to use GIT or Mercurial or Monotone.
> And not anything based on CVS.

Yes. There has never been enough interest in DCVS, though it was fully
functional and quite usable for its time. I would have recommended it
six years ago, but not today.

Olaf

>  - Jay
>
>> Date: Mon, 14 Mar 2011 16:26:54 +0000
>> From: dabenavidesd at yahoo.es
>> To: m3devel at elegosoft.com
>> Subject: [M3devel] About current DCVS and Elego Compact version to   
>> don't fear the fork
>>
>> Hi all:
>> I just was wondering was the current status of integration if so of  
>>  both tools, as I have been reading this techguide, see:
>> http://www.zdnetasia.com/don-t-fear-the-fork-how-dvcs-aids-open-source-development-62207783.htm?scid=nl_z_tgos
>>
>> about forks and distributed control version systems (maybe that   
>> should I call it diversion?).
>> Ok, I read that some of the Modules are ready for cvsup in   
>> Elego-compact but what about dcvs, does it makes sense for it to   
>> have it if it's not already integrated, or would you have   
>> considered this before current elego compact release, if there is   
>> anything specific towards that integration if so what else would be  
>>  needed or are they loosely coupled?
>> I appreciate any comments and opinion about doing that, for   
>> instance a given php developer which already has cvsup as its   
>> control version system mirror of cvs may want to contract someone   
>> to make a fork and so to do that.
>> Thanks in advance



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From dabenavidesd at yahoo.es  Mon Mar 14 22:04:04 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 14 Mar 2011 21:04:04 +0000 (GMT)
Subject: [M3devel] About current DCVS and Elego Compact version to don't
	fear the fork
In-Reply-To: <20110314212514.edcnep7i8wk8gwkc@mail.elegosoft.com>
Message-ID: <707155.91060.qm@web29716.mail.ird.yahoo.com>

Hi all:
Ok, in that sense, how easy would be to abstract it the control machinery of Elego ComPact from its version management (does it subversion classify as DVCS?).
Thanks in advance

--- El lun, 14/3/11, Olaf Wagner <wagner at elegosoft.com> escribi?:

> De: Olaf Wagner <wagner at elegosoft.com>
> Asunto: Re: [M3devel] About current DCVS and Elego Compact version to don't fear the fork
> Para: m3devel at elegosoft.com
> Fecha: lunes, 14 de marzo, 2011 15:25
> Quoting Jay K <jay.krell at cornell.edu>:
> 
> > 
> > Surely the answer is to use GIT or Mercurial or
> Monotone.
> > And not anything based on CVS.
> 
> Yes. There has never been enough interest in DCVS, though
> it was fully
> functional and quite usable for its time. I would have
> recommended it
> six years ago, but not today.
> 
> Olaf
> 
> >  - Jay
> > 
> >> Date: Mon, 14 Mar 2011 16:26:54 +0000
> >> From: dabenavidesd at yahoo.es
> >> To: m3devel at elegosoft.com
> >> Subject: [M3devel] About current DCVS and Elego
> Compact version to  don't fear the fork
> >> 
> >> Hi all:
> >> I just was wondering was the current status of
> integration if so of  both tools, as I have been
> reading this techguide, see:
> >> http://www.zdnetasia.com/don-t-fear-the-fork-how-dvcs-aids-open-source-development-62207783.htm?scid=nl_z_tgos
> >> 
> >> about forks and distributed control version
> systems (maybe that  should I call it diversion?).
> >> Ok, I read that some of the Modules are ready for
> cvsup in  Elego-compact but what about dcvs, does it
> makes sense for it to  have it if it's not already
> integrated, or would you have  considered this before
> current elego compact release, if there is  anything
> specific towards that integration if so what else would
> be  needed or are they loosely coupled?
> >> I appreciate any comments and opinion about doing
> that, for  instance a given php developer which already
> has cvsup as its  control version system mirror of cvs
> may want to contract someone  to make a fork and so to
> do that.
> >> Thanks in advance
> 
> 
> 
> --Olaf Wagner -- elego Software Solutions GmbH
>            
>    Gustav-Meyer-Allee 25 / Geb?ude 12, 13355
> Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345
> 869  fax: +49 30 23 45 86 95
>    http://www.elegosoft.com |
> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 |
> USt-IdNr: DE163214194
> 
> 


      


From rcolebur at SCIRES.COM  Mon Mar 14 22:14:20 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Mon, 14 Mar 2011 17:14:20 -0400
Subject: [M3devel] question re LONGINT
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E603418BD67F@atlex02-srv>

I was making some local mods to Mika's threadtest program to help me debug things a bit more on Windows.

I am trying to do:
   INC(counts[i]);
Where counts is REF ARRAY OF LONGINT

The compiler is complaining:
"..\src\Main.m3", line 189: ** INTERNAL CG ERROR *** unable to find integer type?  type=Int.64  s/o/a=64/0/32

I'm not sure what the status of LONGINT is on Windows.  If it is not fully implemented, let me know and I'll switch to REF ARRAY OF INTEGER, but I really need LONGINT.

Regards,
Randy Coleburn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/937a33f2/attachment-0001.html>

From hosking at cs.purdue.edu  Mon Mar 14 22:21:01 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 14 Mar 2011 17:21:01 -0400
Subject: [M3devel] question re LONGINT
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BD67F@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BD67F@atlex02-srv>
Message-ID: <82BC458A-AEC4-4148-B65D-D6B4B0692CDD@cs.purdue.edu>

This is a known problem which I am still to fix.  I know what the issue is...
You can probably make do by reading counts[i] to a variable, incrementing, and assigning.

On Mar 14, 2011, at 5:14 PM, Coleburn, Randy wrote:

> I was making some local mods to Mika?s threadtest program to help me debug things a bit more on Windows.
>  
> I am trying to do:
>    INC(counts[i]);
> Where counts is REF ARRAY OF LONGINT
>  
> The compiler is complaining:
> "..\src\Main.m3", line 189: ** INTERNAL CG ERROR *** unable to find integer type?  type=Int.64  s/o/a=64/0/32
>  
> I?m not sure what the status of LONGINT is on Windows.  If it is not fully implemented, let me know and I?ll switch to REF ARRAY OF INTEGER, but I really need LONGINT.
>  
> Regards,
> Randy Coleburn
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/4b0192d1/attachment-0001.html>

From jay.krell at cornell.edu  Mon Mar 14 23:33:43 2011
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 14 Mar 2011 22:33:43 +0000
Subject: [M3devel] question re LONGINT
In-Reply-To: <82BC458A-AEC4-4148-B65D-D6B4B0692CDD@cs.purdue.edu>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BD67F@atlex02-srv>,
	<82BC458A-AEC4-4148-B65D-D6B4B0692CDD@cs.purdue.edu>
Message-ID: <COL101-W1613B5382CDB4AA0998526E6CC0@phx.gbl>


 - That error is likely from the frontend and will likely occur for any target. Tony's reply implies this as well.
 
 - LONGINT is believed to fully work on NT386. But more testing is welcome.
 
 - (atomics ditto -- believed to work, testing welcome -- and we should probably use them some, e.g. in MUTEX initialization)
 
 - I would be curious to see if threadtest only fails on 64bit Windows. I haven't tried 32bit yet but I will soon.
   - I was thinking more about this WOW64 GetThreadContext problem and ways to mitigate it, other than cooperative suspend.
     I had already suggested and started to implement scanning the entire stack -- i.e. not depending on an ability to get ESP from a suspended thread.
     Like how FreeBSD and OpenBSD work, albeit it is a significant deoptimization.
     Regarding the rest of the context, perhaps it is a reasonable assumption for now to declare that it doesn't matter? e.g. to know/assume
     that m3back never leaves a value only in registers, that anything in a register will also be on the stack? And to disable optimization on the
     hypothetical MINGW platforms. ?
     But still to confirm if there are no problems on 32bit, and to mull over implementing cooperative suspend..in the little time available...
     (Oh, and also, I wonder if SuspendThread can suspend a thread while in the kernel, probably, and if GetThreadContext returns
     the kernel context in that case; should be easy to determine via some experimentation -- which would imply a problem on 32bit Windows also.)
 
 
 - Jay
 


From: hosking at cs.purdue.edu
Date: Mon, 14 Mar 2011 17:21:01 -0400
To: rcolebur at SCIRES.COM
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] question re LONGINT


This is a known problem which I am still to fix.  I know what the issue is...
You can probably make do by reading counts[i] to a variable, incrementing, and assigning.




On Mar 14, 2011, at 5:14 PM, Coleburn, Randy wrote:



I was making some local mods to Mika?s threadtest program to help me debug things a bit more on Windows.
 
I am trying to do:
   INC(counts[i]);
Where counts is REF ARRAY OF LONGINT
 
The compiler is complaining:
"..\src\Main.m3", line 189: ** INTERNAL CG ERROR *** unable to find integer type?  type=Int.64  s/o/a=64/0/32
 
I?m not sure what the status of LONGINT is on Windows.  If it is not fully implemented, let me know and I?ll switch to REF ARRAY OF INTEGER, but I really need LONGINT.
 
Regards,
Randy Coleburn
 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/38fe3b7e/attachment-0001.html>

From rcolebur at SCIRES.COM  Mon Mar 14 23:45:44 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Mon, 14 Mar 2011 18:45:44 -0400
Subject: [M3devel] question on use of Time.Now in thread test program
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E603418BD6A3@atlex02-srv>

I have a question/concern regarding Mika's thread test program.

Each of the threads makes use of the Time.Now() call during each iteration of the thread's main loop.

I haven't fully investigated, but does anyone have concern that so many calls to the system clock from multiple competing threads might have some side effect on the running of multiple threads?

I've also done some limited experimentation with use of counters to see how many times each type of thread is able to go thru its loop between reporting intervals.

I continue to see various types of crashes on Windows 7 (64-bit), but sometimes tests are able to succeed.  I haven't found a repeatable pattern yet to the crashes, so I am still investigating, but just thought it worth asking the above question about use of Time.Now().

I will also try to experiment with Windows XP 32-bit and report back.

Regards,
Randy Coleburn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/4fc9452e/attachment-0001.html>

From jay.krell at cornell.edu  Tue Mar 15 00:07:15 2011
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 14 Mar 2011 23:07:15 +0000
Subject: [M3devel] question on use of Time.Now in thread test program
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BD6A3@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BD6A3@atlex02-srv>
Message-ID: <COL101-W16E61CE9DCE94C7C824631E6CC0@phx.gbl>


Time.Now() is very cheap on Windows and should cause no concern.
It is just GetSystemTimeAsFileTime, which just reads some globals, followed by a simple unit and integer to double conversion.
I would avoid 64bit Windows for now, very unfortunate, but I don't trust GetThreadContext.
 
 
PROCEDURE Now(): T=
  VAR
    fileTime: WinBase.FILETIME;
  BEGIN
    WinBase.GetSystemTimeAsFileTime(fileTime);
    RETURN TimeWin32.FromFileTime(fileTime);
  END Now;


double
__cdecl
TimeWin32__FromFileTime(FILETIME ft)
{
    LARGE_INTEGER li;

    li.LowPart = ft.dwLowDateTime;
    li.HighPart = ft.dwHighDateTime;
    return ((double)li.QuadPart) / 1.0e7;
}


Hm -- I don't like passing structs by value, too hard to be sure how it works -- I'd like to change this to be "READONLY" -- passed by pointer.
Maybe code the entire thing in Modula-3 -- or more likely, the entire thing in C.
 
Time.Now() might be more expensive on other platform, I don't know.
 
I also see some failures, some success, no pattern.
I think the success is just luck and the code is by its nature very non-deterministic.
 
 - Jay
 


From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Mon, 14 Mar 2011 18:45:44 -0400
Subject: [M3devel] question on use of Time.Now in thread test program






I have a question/concern regarding Mika?s thread test program.
 
Each of the threads makes use of the Time.Now() call during each iteration of the thread?s main loop.  
 
I haven?t fully investigated, but does anyone have concern that so many calls to the system clock from multiple competing threads might have some side effect on the running of multiple threads?
 
I?ve also done some limited experimentation with use of counters to see how many times each type of thread is able to go thru its loop between reporting intervals.
 
I continue to see various types of crashes on Windows 7 (64-bit), but sometimes tests are able to succeed.  I haven?t found a repeatable pattern yet to the crashes, so I am still investigating, but just thought it worth asking the above question about use of Time.Now().
 
I will also try to experiment with Windows XP 32-bit and report back.
 
Regards,
Randy Coleburn 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/b0dca15e/attachment-0001.html>

From dabenavidesd at yahoo.es  Tue Mar 15 00:21:49 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 14 Mar 2011 23:21:49 +0000 (GMT)
Subject: [M3devel] question on use of Time.Now in thread test program
In-Reply-To: <COL101-W16E61CE9DCE94C7C824631E6CC0@phx.gbl>
Message-ID: <569254.84801.qm@web29712.mail.ird.yahoo.com>

Hi all:
see at:
http://www.ic.unicamp.br/~stolfi/EXPORT/software/m3/Misc.html 

CPUTime module.
Thanks in advance

--- El lun, 14/3/11, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] question on use of Time.Now in thread test program
Para: rcolebur at scires.com, "m3devel" <m3devel at elegosoft.com>
Fecha: lunes, 14 de marzo, 2011 18:07




Time.Now() is very cheap on Windows and should cause no concern.

It is just GetSystemTimeAsFileTime, which just reads some globals, followed by a simple unit and integer to double conversion.

I would avoid 64bit Windows for now, very unfortunate, but I don't trust GetThreadContext.

?

?

PROCEDURE Now(): T=
? VAR
??? fileTime: WinBase.FILETIME;
? BEGIN
??? WinBase.GetSystemTimeAsFileTime(fileTime);
??? RETURN TimeWin32.FromFileTime(fileTime);
? END Now;



double
__cdecl
TimeWin32__FromFileTime(FILETIME ft)
{
??? LARGE_INTEGER li;

??? li.LowPart = ft.dwLowDateTime;
??? li.HighPart = ft.dwHighDateTime;
??? return ((double)li.QuadPart) / 1.0e7;
}



Hm -- I don't like passing structs by value, too hard to be sure how it works -- I'd like to change this to be "READONLY" -- passed by pointer.

Maybe code the entire thing in Modula-3 -- or more likely, the entire thing in C.

?

Time.Now() might be more expensive on other platform, I don't know.

?

I also see some failures, some success, no pattern.

I think the success is just luck and the code is by its nature very non-deterministic.

?

?- Jay
?



From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Mon, 14 Mar 2011 18:45:44 -0400
Subject: [M3devel] question on use of Time.Now in thread test program


 

#yiv1082952660 .yiv1082952660ExternalClass p.yiv1082952660ecxMsoNormal, #yiv1082952660 .yiv1082952660ExternalClass li.yiv1082952660ecxMsoNormal, #yiv1082952660 .yiv1082952660ExternalClass div.yiv1082952660ecxMsoNormal
{margin-bottom:.0001pt;font-size:11.0pt;font-family:'sans-serif';}
#yiv1082952660 .yiv1082952660ExternalClass a:link, #yiv1082952660 .yiv1082952660ExternalClass span.yiv1082952660ecxMsoHyperlink
{color:blue;text-decoration:underline;}
#yiv1082952660 .yiv1082952660ExternalClass a:visited, #yiv1082952660 .yiv1082952660ExternalClass span.yiv1082952660ecxMsoHyperlinkFollowed
{color:purple;text-decoration:underline;}
#yiv1082952660 .yiv1082952660ExternalClass span.yiv1082952660ecxEmailStyle17
{font-family:'sans-serif';color:windowtext;}
#yiv1082952660 .yiv1082952660ExternalClass .yiv1082952660ecxMsoChpDefault
{}
 _filtered #yiv1082952660 {}
#yiv1082952660 .yiv1082952660ExternalClass div.yiv1082952660ecxWordSection1
{}




I have a question/concern regarding Mika?s thread test program.
?
Each of the threads makes use of the Time.Now() call during each iteration of the thread?s main loop.? 
?
I haven?t fully investigated, but does anyone have concern that so many calls to the system clock from multiple competing threads might have some side effect on the running of multiple threads?
?
I?ve also done some limited experimentation with use of counters to see how many times each type of thread is able to go thru its loop between reporting intervals.
?
I continue to see various types of crashes on Windows 7 (64-bit), but sometimes tests are able to succeed.? I haven?t found a repeatable pattern yet to the crashes, so I am still investigating, but just thought it worth asking the above question about use of Time.Now().
?
I will also try to experiment with Windows XP 32-bit and report back.
?
Regards,
Randy Coleburn 		 	   		  



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/5b36d1fd/attachment-0001.html>

From jay.krell at cornell.edu  Tue Mar 15 00:48:23 2011
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 14 Mar 2011 23:48:23 +0000
Subject: [M3devel] question on use of Time.Now in thread test program
In-Reply-To: <569254.84801.qm@web29712.mail.ird.yahoo.com>
References: <COL101-W16E61CE9DCE94C7C824631E6CC0@phx.gbl>,
	<569254.84801.qm@web29712.mail.ird.yahoo.com>
Message-ID: <COL101-W2A6D6D82DFF94AD42BA35E6CC0@phx.gbl>


Please don't use Uresource.struct_rusage in Modula-3.
I removed it. It is a portabilty/maintenance problem.
 
 - Jay

 


Date: Mon, 14 Mar 2011 23:21:49 +0000
From: dabenavidesd at yahoo.es
To: rcolebur at scires.com; m3devel at elegosoft.com; jay.krell at cornell.edu
Subject: Re: [M3devel] question on use of Time.Now in thread test program





Hi all:
see at:
http://www.ic.unicamp.br/~stolfi/EXPORT/software/m3/Misc.html 

CPUTime module.
Thanks in advance

--- El lun, 14/3/11, Jay K <jay.krell at cornell.edu> escribi?:


De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] question on use of Time.Now in thread test program
Para: rcolebur at scires.com, "m3devel" <m3devel at elegosoft.com>
Fecha: lunes, 14 de marzo, 2011 18:07




Time.Now() is very cheap on Windows and should cause no concern.
It is just GetSystemTimeAsFileTime, which just reads some globals, followed by a simple unit and integer to double conversion.
I would avoid 64bit Windows for now, very unfortunate, but I don't trust GetThreadContext.
 
 
PROCEDURE Now(): T=
  VAR
    fileTime: WinBase.FILETIME;
  BEGIN
    WinBase.GetSystemTimeAsFileTime(fileTime);
    RETURN TimeWin32.FromFileTime(fileTime);
  END Now;


double
__cdecl
TimeWin32__FromFileTime(FILETIME ft)
{
    LARGE_INTEGER li;

    li.LowPart = ft.dwLowDateTime;
    li.HighPart = ft.dwHighDateTime;
    return ((double)li.QuadPart) / 1.0e7;
}


Hm -- I don't like passing structs by value, too hard to be sure how it works -- I'd like to change this to be "READONLY" -- passed by pointer.
Maybe code the entire thing in Modula-3 -- or more likely, the entire thing in C.
 
Time.Now() might be more expensive on other platform, I don't know.
 
I also see some failures, some success, no pattern.
I think the success is just luck and the code is by its nature very non-deterministic.
 
 - Jay
 


From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Mon, 14 Mar 2011 18:45:44 -0400
Subject: [M3devel] question on use of Time.Now in thread test program





I have a question/concern regarding Mika?s thread test program.
 
Each of the threads makes use of the Time.Now() call during each iteration of the thread?s main loop.  
 
I haven?t fully investigated, but does anyone have concern that so many calls to the system clock from multiple competing threads might have some side effect on the running of multiple threads?
 
I?ve also done some limited experimentation with use of counters to see how many times each type of thread is able to go thru its loop between reporting intervals.
 
I continue to see various types of crashes on Windows 7 (64-bit), but sometimes tests are able to succeed.  I haven?t found a repeatable pattern yet to the crashes, so I am still investigating, but just thought it worth asking the above question about use of Time.Now().
 
I will also try to experiment with Windows XP 32-bit and report back.
 
Regards,
Randy Coleburn
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/7153deb4/attachment-0001.html>

From hosking at cs.purdue.edu  Tue Mar 15 00:50:24 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 14 Mar 2011 19:50:24 -0400
Subject: [M3devel] question re LONGINT
In-Reply-To: <COL101-W1613B5382CDB4AA0998526E6CC0@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BD67F@atlex02-srv>,
	<82BC458A-AEC4-4148-B65D-D6B4B0692CDD@cs.purdue.edu>
	<COL101-W1613B5382CDB4AA0998526E6CC0@phx.gbl>
Message-ID: <C1309C40-1D9F-4C67-80A7-E04C9FDF3554@cs.purdue.edu>

On Mar 14, 2011, at 6:33 PM, Jay K wrote:

>  - That error is likely from the frontend and will likely occur for any target. Tony's reply implies this as well.
>  
>  - LONGINT is believed to fully work on NT386. But more testing is welcome.
>  
>  - (atomics ditto -- believed to work, testing welcome -- and we should probably use them some, e.g. in MUTEX initialization)

They are still slightly broken.  I have some fixes still to check in.  If only I could find some time to test everything...
But, they will be essential if we ever do cooperative thread suspension.

>   - I would be curious to see if threadtest only fails on 64bit Windows. I haven't tried 32bit yet but I will soon.
>    - I was thinking more about this WOW64 GetThreadContext problem and ways to mitigate it, other than cooperative suspend.
>      I had already suggested and started to implement scanning the entire stack -- i.e. not depending on an ability to get ESP from a suspended thread.
>      Like how FreeBSD and OpenBSD work, albeit it is a significant deoptimization.
>      Regarding the rest of the context, perhaps it is a reasonable assumption for now to declare that it doesn't matter? e.g. to know/assume
>      that m3back never leaves a value only in registers, that anything in a register will also be on the stack? And to disable optimization on the
>      hypothetical MINGW platforms. ?
>      But still to confirm if there are no problems on 32bit, and to mull over implementing cooperative suspend..in the little time available...
>      (Oh, and also, I wonder if SuspendThread can suspend a thread while in the kernel, probably, and if GetThreadContext returns
>      the kernel context in that case; should be easy to determine via some experimentation -- which would imply a problem on 32bit Windows also.)
>  
>  
>  - Jay
>  
> From: hosking at cs.purdue.edu
> Date: Mon, 14 Mar 2011 17:21:01 -0400
> To: rcolebur at SCIRES.COM
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] question re LONGINT
> 
> This is a known problem which I am still to fix.  I know what the issue is...
> You can probably make do by reading counts[i] to a variable, incrementing, and assigning.
> 
> On Mar 14, 2011, at 5:14 PM, Coleburn, Randy wrote:
> 
> I was making some local mods to Mika?s threadtest program to help me debug things a bit more on Windows.
>  
> I am trying to do:
>    INC(counts[i]);
> Where counts is REF ARRAY OF LONGINT
>  
> The compiler is complaining:
> "..\src\Main.m3", line 189: ** INTERNAL CG ERROR *** unable to find integer type?  type=Int.64  s/o/a=64/0/32
>  
> I?m not sure what the status of LONGINT is on Windows.  If it is not fully implemented, let me know and I?ll switch to REF ARRAY OF INTEGER, but I really need LONGINT.
>  
> Regards,
> Randy Coleburn
>  
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/552f4ee8/attachment-0001.html>

From hosking at cs.purdue.edu  Tue Mar 15 02:06:53 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 14 Mar 2011 21:06:53 -0400
Subject: [M3devel] question re LONGINT
In-Reply-To: <COL101-W1613B5382CDB4AA0998526E6CC0@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BD67F@atlex02-srv>,
	<82BC458A-AEC4-4148-B65D-D6B4B0692CDD@cs.purdue.edu>
	<COL101-W1613B5382CDB4AA0998526E6CC0@phx.gbl>
Message-ID: <5B02FDDE-41EA-42FD-A57B-ECED6C626AC8@cs.purdue.edu>

On Mar 14, 2011, at 6:33 PM, Jay K wrote:

>  - That error is likely from the frontend and will likely occur for any target. Tony's reply implies this as well.
>  
>  - LONGINT is believed to fully work on NT386. But more testing is welcome.
>  
>  - (atomics ditto -- believed to work, testing welcome -- and we should probably use them some, e.g. in MUTEX initialization)

They are still slightly broken.  I have some fixes still to check in.  If only I could find some time to test everything...
But, they will be essential if we ever do cooperative thread suspension.

>   - I would be curious to see if threadtest only fails on 64bit Windows. I haven't tried 32bit yet but I will soon.
>    - I was thinking more about this WOW64 GetThreadContext problem and ways to mitigate it, other than cooperative suspend.
>      I had already suggested and started to implement scanning the entire stack -- i.e. not depending on an ability to get ESP from a suspended thread.
>      Like how FreeBSD and OpenBSD work, albeit it is a significant deoptimization.
>      Regarding the rest of the context, perhaps it is a reasonable assumption for now to declare that it doesn't matter? e.g. to know/assume
>      that m3back never leaves a value only in registers, that anything in a register will also be on the stack? And to disable optimization on the
>      hypothetical MINGW platforms. ?
>      But still to confirm if there are no problems on 32bit, and to mull over implementing cooperative suspend..in the little time available...
>      (Oh, and also, I wonder if SuspendThread can suspend a thread while in the kernel, probably, and if GetThreadContext returns
>      the kernel context in that case; should be easy to determine via some experimentation -- which would imply a problem on 32bit Windows also.)
>  
>  
>  - Jay
>  
> From: hosking at cs.purdue.edu
> Date: Mon, 14 Mar 2011 17:21:01 -0400
> To: rcolebur at SCIRES.COM
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] question re LONGINT
> 
> This is a known problem which I am still to fix.  I know what the issue is...
> You can probably make do by reading counts[i] to a variable, incrementing, and assigning.
> 
> On Mar 14, 2011, at 5:14 PM, Coleburn, Randy wrote:
> 
> I was making some local mods to Mika?s threadtest program to help me debug things a bit more on Windows.
>  
> I am trying to do:
>    INC(counts[i]);
> Where counts is REF ARRAY OF LONGINT
>  
> The compiler is complaining:
> "..\src\Main.m3", line 189: ** INTERNAL CG ERROR *** unable to find integer type?  type=Int.64  s/o/a=64/0/32
>  
> I?m not sure what the status of LONGINT is on Windows.  If it is not fully implemented, let me know and I?ll switch to REF ARRAY OF INTEGER, but I really need LONGINT.
>  
> Regards,
> Randy Coleburn
>  
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/7a5b1085/attachment-0001.html>

From rcolebur at SCIRES.COM  Tue Mar 15 02:40:12 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Mon, 14 Mar 2011 21:40:12 -0400
Subject: [M3devel] draft new edition of thread test program
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E603418BD6AD@atlex02-srv>

Mika et al:

I didn't want to check in a modified version of your program without everyone agreeing my modifications are desired.

Attached is my modified source code.  See if you think the modifications are worthy of adding to the program, or feel free to adjust further, or just tell me you don't want to add them.  If you want me to check in the modified source, let me know.

Basically, I've done 2 things:


1.       Added pp.finish() in command line parsing so that if you put extra arguments on command line that aren't parsed, you will get an error message.  For example, I keep finding I sometimes separate the test names with space instead of comma, only to realize after program starts that the extra arguments were ignored.  (We could also change the specs to allow for comma to be used as a test name separator.)


2.       Added "-verbose" command line option.  If you choose this option, extra information is printed, namely:  as threads are created, their "id" is printed and then for each iteration, the number of times each thread executed its main loop is printed.  Also, if a thread doesn't make any progress on an iteration, a notice that the thread may be starved or deadlocked is printed.

Unless you use -verbose, the program output is the same as your version, except that if you give extra command line arguments, the program will abort and notify you.  For example,
C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -tests read lock
ParseParams: parameter 4 = "lock" extraneous or misplaced.

*** Couldnt parse cmd-line args.

Now, running on Windows 7 (64-bit), I still get non-deterministic behavior and some crashes.  For example:
C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,lock
Writing file...done
Creating read threads...
   read=0
   read=1
   read=2
done
Creating lock threads...
   lock=21
   lock=22
   lock=23
done
running...printing oldest/median age/newest
..........laziest thread is 0/0/0 (tests: read 0/0/0 lock 0/0/0)
   read Thread 0 completed 1670 loops.
   read Thread 1 completed 1692 loops.
   read Thread 2 completed 1849 loops.
   lock Thread 21 completed 11788253 loops.
   lock Thread 22 completed 9448889 loops.
   lock Thread 23 completed 9480853 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 lock 0/0/0)
   read Thread 0 completed 2148 loops.
   read Thread 1 completed 2113 loops.
   read Thread 2 completed 2343 loops.
   lock Thread 21 completed 13326765 loops.
   lock Thread 22 completed 11327588 loops.
   lock Thread 23 completed 12743882 loops.
.......

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0x126e37d = Move + 0x50 in ..\src\runtime\common\RTCollector.m3
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

I'll try on 32-bit XP soon and report.

Regards,
Randy Coleburn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/448a0612/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Main.m3
Type: application/octet-stream
Size: 18584 bytes
Desc: Main.m3
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/448a0612/attachment-0001.obj>

From hosking at cs.purdue.edu  Tue Mar 15 03:44:10 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 14 Mar 2011 22:44:10 -0400
Subject: [M3devel] draft new edition of thread test program
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BD6AD@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BD6AD@atlex02-srv>
Message-ID: <A347E6AC-DAD7-4792-AD0D-C45712E46299@cs.purdue.edu>

In the face of these crashes it would be best to run all tests with the @M3paranoidgc flag at all times.

On Mar 14, 2011, at 9:40 PM, Coleburn, Randy wrote:

> Mika et al:
>  
> I didn?t want to check in a modified version of your program without everyone agreeing my modifications are desired.
>  
> Attached is my modified source code.  See if you think the modifications are worthy of adding to the program, or feel free to adjust further, or just tell me you don?t want to add them.  If you want me to check in the modified source, let me know.
>  
> Basically, I?ve done 2 things:
> 
> 1.       Added pp.finish() in command line parsing so that if you put extra arguments on command line that aren?t parsed, you will get an error message.  For example, I keep finding I sometimes separate the test names with space instead of comma, only to realize after program starts that the extra arguments were ignored.  (We could also change the specs to allow for comma to be used as a test name separator.)
> 
> 2.       Added ??verbose? command line option.  If you choose this option, extra information is printed, namely:  as threads are created, their ?id? is printed and then for each iteration, the number of times each thread executed its main loop is printed.  Also, if a thread doesn?t make any progress on an iteration, a notice that the thread may be starved or deadlocked is printed.
>  
> Unless you use ?verbose, the program output is the same as your version, except that if you give extra command line arguments, the program will abort and notify you.  For example,
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -tests read lock
> ParseParams: parameter 4 = "lock" extraneous or misplaced.
>  
> *** Couldnt parse cmd-line args.
>  
> Now, running on Windows 7 (64-bit), I still get non-deterministic behavior and some crashes.  For example:
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,lock
> Writing file...done
> Creating read threads...
>    read=0
>    read=1
>    read=2
> done
> Creating lock threads...
>    lock=21
>    lock=22
>    lock=23
> done
> running...printing oldest/median age/newest
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 lock 0/0/0)
>    read Thread 0 completed 1670 loops.
>    read Thread 1 completed 1692 loops.
>    read Thread 2 completed 1849 loops.
>    lock Thread 21 completed 11788253 loops.
>    lock Thread 22 completed 9448889 loops.
>    lock Thread 23 completed 9480853 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 lock 0/0/0)
>    read Thread 0 completed 2148 loops.
>    read Thread 1 completed 2113 loops.
>    read Thread 2 completed 2343 loops.
>    lock Thread 21 completed 13326765 loops.
>    lock Thread 22 completed 11327588 loops.
>    lock Thread 23 completed 12743882 loops.
> .......
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
> ***    pc = 0x126e37d = Move + 0x50 in ..\src\runtime\common\RTCollector.m3
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> I?ll try on 32-bit XP soon and report.
>  
> Regards,
> Randy Coleburn
>  
> <Main.m3>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/13a33906/attachment-0001.html>

From mika at async.caltech.edu  Wed Mar 16 16:40:27 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Wed, 16 Mar 2011 08:40:27 -0700
Subject: [M3devel] draft new edition of thread test program
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BD6AD@atlex02-srv> 
References: <D67F02DDC62F7545A6B84C285F88F3E603418BD6AD@atlex02-srv>
Message-ID: <20110316154027.14DAF1A2078@async.async.caltech.edu>

Hi Randy,

No objections from me!

     Mika

"Coleburn, Randy" writes:
>--_004_D67F02DDC62F7545A6B84C285F88F3E603418BD6ADatlex02srv_
>Content-Type: multipart/alternative;
>	boundary="_000_D67F02DDC62F7545A6B84C285F88F3E603418BD6ADatlex02srv_"
>
>--_000_D67F02DDC62F7545A6B84C285F88F3E603418BD6ADatlex02srv_
>Content-Type: text/plain; charset="us-ascii"
>Content-Transfer-Encoding: quoted-printable
>
>Mika et al:
>
>I didn't want to check in a modified version of your program without everyo=
>ne agreeing my modifications are desired.
>
>Attached is my modified source code.  See if you think the modifications ar=
>e worthy of adding to the program, or feel free to adjust further, or just =
>tell me you don't want to add them.  If you want me to check in the modifie=
>d source, let me know.
>
>Basically, I've done 2 things:
>
>
>1.       Added pp.finish() in command line parsing so that if you put extra=
> arguments on command line that aren't parsed, you will get an error messag=
>e.  For example, I keep finding I sometimes separate the test names with sp=
>ace instead of comma, only to realize after program starts that the extra a=
>rguments were ignored.  (We could also change the specs to allow for comma =
>to be used as a test name separator.)
>
>
>2.       Added "-verbose" command line option.  If you choose this option, =
>extra information is printed, namely:  as threads are created, their "id" i=
>s printed and then for each iteration, the number of times each thread exec=
>uted its main loop is printed.  Also, if a thread doesn't make any progress=
> on an iteration, a notice that the thread may be starved or deadlocked is =
>printed.
>
>Unless you use -verbose, the program output is the same as your version, ex=
>cept that if you give extra command line arguments, the program will abort =
>and notify you.  For example,
>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -tests read=
> lock
>ParseParams: parameter 4 =3D "lock" extraneous or misplaced.
>
>*** Couldnt parse cmd-line args.
>
>Now, running on Windows 7 (64-bit), I still get non-deterministic behavior =
>and some crashes.  For example:
>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -t=
>ests read,lock
>Writing file...done
>Creating read threads...
>   read=3D0
>   read=3D1
>   read=3D2
>done
>Creating lock threads...
>   lock=3D21
>   lock=3D22
>   lock=3D23
>done
>running...printing oldest/median age/newest
>..........laziest thread is 0/0/0 (tests: read 0/0/0 lock 0/0/0)
>   read Thread 0 completed 1670 loops.
>   read Thread 1 completed 1692 loops.
>   read Thread 2 completed 1849 loops.
>   lock Thread 21 completed 11788253 loops.
>   lock Thread 22 completed 9448889 loops.
>   lock Thread 23 completed 9480853 loops.
>..........laziest thread is 0/0/0 (tests: read 0/0/0 lock 0/0/0)
>   read Thread 0 completed 2148 loops.
>   read Thread 1 completed 2113 loops.
>   read Thread 2 completed 2343 loops.
>   lock Thread 21 completed 13326765 loops.
>   lock Thread 22 completed 11327588 loops.
>   lock Thread 23 completed 12743882 loops.
>.......
>
>***
>*** runtime error:
>***    Attempt to reference an illegal memory location.
>
>***
>*** runtime error:
>***    Attempt to reference an illegal memory location.
>
>***
>*** runtime error:
>***    Attempt to reference an illegal memory location.
>***    pc =3D 0x126e37d =3D Move + 0x50 in ..\src\runtime\common\RTCollecto=
>r.m3
>***
>
>***
>*** runtime error:
>***    <*ASSERT*> failed.
>***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
>***
>
>***
>*** runtime error:
>***    <*ASSERT*> failed.
>***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
>***
>
>***
>*** runtime error:
>***    <*ASSERT*> failed.
>***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
>***
>
>I'll try on 32-bit XP soon and report.
>
>Regards,
>Randy Coleburn
>
>
>--_000_D67F02DDC62F7545A6B84C285F88F3E603418BD6ADatlex02srv_
>Content-Type: text/html; charset="us-ascii"
>Content-Transfer-Encoding: quoted-printable
>
><html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
>osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
>xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
>icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
>:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
>uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
>t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
>m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
>t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
>:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
>soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
>xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
>icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
>schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
>point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
>/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
>=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
>schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
>.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
>/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
>://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
>repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
> xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
>schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
>/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
>ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
>p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
>/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
>mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
>crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
>s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
>ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
>om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
>ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
>partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
>06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
>6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
>deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
>Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
>st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta http-equi=
>v=3DContent-Type content=3D"text/html; charset=3Dus-ascii"><meta name=3DGen=
>erator content=3D"Microsoft Word 12 (filtered medium)"><style><!--
>/* Font Definitions */
>@font-face
>	{font-family:"Cambria Math";
>	panose-1:2 4 5 3 5 4 6 3 2 4;}
>@font-face
>	{font-family:Calibri;
>	panose-1:2 15 5 2 2 2 4 3 2 4;}
>/* Style Definitions */
>p.MsoNormal, li.MsoNormal, div.MsoNormal
>	{margin:0in;
>	margin-bottom:.0001pt;
>	font-size:11.0pt;
>	font-family:"Calibri","sans-serif";}
>a:link, span.MsoHyperlink
>	{mso-style-priority:99;
>	color:blue;
>	text-decoration:underline;}
>a:visited, span.MsoHyperlinkFollowed
>	{mso-style-priority:99;
>	color:purple;
>	text-decoration:underline;}
>p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
>	{mso-style-priority:34;
>	margin-top:0in;
>	margin-right:0in;
>	margin-bottom:0in;
>	margin-left:.5in;
>	margin-bottom:.0001pt;
>	font-size:11.0pt;
>	font-family:"Calibri","sans-serif";}
>span.EmailStyle17
>	{mso-style-type:personal-compose;
>	font-family:"Calibri","sans-serif";
>	color:windowtext;}
>.MsoChpDefault
>	{mso-style-type:export-only;}
>@page WordSection1
>	{size:8.5in 11.0in;
>	margin:1.0in 1.0in 1.0in 1.0in;}
>div.WordSection1
>	{page:WordSection1;}
>/* List Definitions */
>@list l0
>	{mso-list-id:384720956;
>	mso-list-type:hybrid;
>	mso-list-template-ids:982285054 67698703 67698713 67698715 67698703 676987=
>13 67698715 67698703 67698713 67698715;}
>@list l0:level1
>	{mso-level-tab-stop:none;
>	mso-level-number-position:left;
>	text-indent:-.25in;}
>ol
>	{margin-bottom:0in;}
>ul
>	{margin-bottom:0in;}
>--></style><!--[if gte mso 9]><xml>
><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
></xml><![endif]--><!--[if gte mso 9]><xml>
><o:shapelayout v:ext=3D"edit">
><o:idmap v:ext=3D"edit" data=3D"1" />
></o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
>nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>Mika et al:<o:p>=
></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>I =
>didn&#8217;t want to check in a modified version of your program without ev=
>eryone agreeing my modifications are desired.<o:p></o:p></p><p class=3DMsoN=
>ormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>Attached is my modified sou=
>rce code.&nbsp; See if you think the modifications are worthy of adding to =
>the program, or feel free to adjust further, or just tell me you don&#8217;=
>t want to add them.&nbsp; If you want me to check in the modified source, l=
>et me know.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p clas=
>s=3DMsoNormal>Basically, I&#8217;ve done 2 things:<br><br><o:p></o:p></p><p=
> class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 lf=
>o1'><![if !supportLists]><span style=3D'mso-list:Ignore'>1.<span style=3D'f=
>ont:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></=
>span><![endif]>Added <b>pp.finish()</b> in command line parsing so that if =
>you put extra arguments on command line that aren&#8217;t parsed, you will =
>get an error message.&nbsp; For example, I keep finding I sometimes separat=
>e the test names with space instead of comma, only to realize after program=
> starts that the extra arguments were ignored.&nbsp; (We could also change =
>the specs to allow for comma to be used as a test name separator.)<br><br><=
>o:p></o:p></p><p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-l=
>ist:l0 level1 lfo1'><![if !supportLists]><span style=3D'mso-list:Ignore'>2.=
><span style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
>&nbsp; </span></span><![endif]>Added &#8220;<b>&#8211;verbose</b>&#8221; co=
>mmand line option.&nbsp; If you choose this option, extra information is pr=
>inted, namely: &nbsp;as threads are created, their &#8220;id&#8221; is prin=
>ted and then for each iteration, the number of times each thread executed i=
>ts main loop is printed.&nbsp; Also, if a thread doesn&#8217;t make any pro=
>gress on an iteration, a notice that the thread may be starved or deadlocke=
>d is printed.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p cl=
>ass=3DMsoNormal>Unless you use &#8211;verbose, the program output is the sa=
>me as your version, except that if you give extra command line arguments, t=
>he program will abort and notify you.&nbsp; For example,<o:p></o:p></p><p c=
>lass=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Cou=
>rier New"'>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt;threadtest.e=
>xe -tests read lock<o:p></o:p></span></p><p class=3DMsoNormal style=3D'marg=
>in-left:.5in'><span style=3D'font-family:"Courier New"'>ParseParams: parame=
>ter 4 =3D &quot;lock&quot; extraneous or misplaced.<o:p></o:p></span></p><p=
> class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"C=
>ourier New"'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal style=3D'marg=
>in-left:.5in'><span style=3D'font-family:"Courier New"'>*** Couldnt parse c=
>md-line args.<o:p></o:p></span></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></=
>p><p class=3DMsoNormal>Now, running on Windows 7 (64-bit), I still get non-=
>deterministic behavior and some crashes.&nbsp; For example:<o:p></o:p></p><=
>p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"=
>Courier New"'>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt;threadtes=
>t.exe -verbose -tests read,lock<o:p></o:p></span></p><p class=3DMsoNormal s=
>tyle=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'>Writing=
> file...done<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left=
>:.5in'><span style=3D'font-family:"Courier New"'>Creating read threads...<o=
>:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span s=
>tyle=3D'font-family:"Courier New"'>&nbsp;&nbsp; read=3D0<o:p></o:p></span><=
>/p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-fami=
>ly:"Courier New"'>&nbsp;&nbsp; read=3D1<o:p></o:p></span></p><p class=3DMso=
>Normal style=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'=
>>&nbsp;&nbsp; read=3D2<o:p></o:p></span></p><p class=3DMsoNormal style=3D'm=
>argin-left:.5in'><span style=3D'font-family:"Courier New"'>done<o:p></o:p><=
>/span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'fo=
>nt-family:"Courier New"'>Creating lock threads...<o:p></o:p></span></p><p c=
>lass=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Cou=
>rier New"'>&nbsp;&nbsp; lock=3D21<o:p></o:p></span></p><p class=3DMsoNormal=
> style=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'>&nbsp=
>;&nbsp; lock=3D22<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin=
>-left:.5in'><span style=3D'font-family:"Courier New"'>&nbsp;&nbsp; lock=3D2=
>3<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><spa=
>n style=3D'font-family:"Courier New"'>done<o:p></o:p></span></p><p class=3D=
>MsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Courier Ne=
>w"'>running...printing oldest/median age/newest<o:p></o:p></span></p><p cla=
>ss=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Couri=
>er New"'>..........laziest thread is 0/0/0 (tests: read 0/0/0 lock 0/0/0)<o=
>:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span s=
>tyle=3D'font-family:"Courier New"'>&nbsp;&nbsp; read Thread 0 completed 167=
>0 loops.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5i=
>n'><span style=3D'font-family:"Courier New"'>&nbsp;&nbsp; read Thread 1 com=
>pleted 1692 loops.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margi=
>n-left:.5in'><span style=3D'font-family:"Courier New"'>&nbsp;&nbsp; read Th=
>read 2 completed 1849 loops.<o:p></o:p></span></p><p class=3DMsoNormal styl=
>e=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'>&nbsp;&nbs=
>p; lock Thread 21 completed 11788253 loops.<o:p></o:p></span></p><p class=
>=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Courier=
> New"'>&nbsp;&nbsp; lock Thread 22 completed 9448889 loops.<o:p></o:p></spa=
>n></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-f=
>amily:"Courier New"'>&nbsp;&nbsp; lock Thread 23 completed 9480853 loops.<o=
>:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span s=
>tyle=3D'font-family:"Courier New"'>..........laziest thread is 0/0/0 (tests=
>: read 0/0/0 lock 0/0/0)<o:p></o:p></span></p><p class=3DMsoNormal style=3D=
>'margin-left:.5in'><span style=3D'font-family:"Courier New"'>&nbsp;&nbsp; r=
>ead Thread 0 completed 2148 loops.<o:p></o:p></span></p><p class=3DMsoNorma=
>l style=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'>&nbs=
>p;&nbsp; read Thread 1 completed 2113 loops.<o:p></o:p></span></p><p class=
>=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Courier=
> New"'>&nbsp;&nbsp; read Thread 2 completed 2343 loops.<o:p></o:p></span></=
>p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-famil=
>y:"Courier New"'>&nbsp;&nbsp; lock Thread 21 completed 13326765 loops.<o:p>=
></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span styl=
>e=3D'font-family:"Courier New"'>&nbsp;&nbsp; lock Thread 22 completed 11327=
>588 loops.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.=
>5in'><span style=3D'font-family:"Courier New"'>&nbsp;&nbsp; lock Thread 23 =
>completed 12743882 loops.<o:p></o:p></span></p><p class=3DMsoNormal style=
>=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'>.......<o:p=
>></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span sty=
>le=3D'font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=3DMso=
>Normal style=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'=
>>***<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><=
>span style=3D'font-family:"Courier New"'>*** runtime error:<o:p></o:p></spa=
>n></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-f=
>amily:"Courier New"'>***&nbsp;&nbsp;&nbsp; Attempt to reference an illegal =
>memory location.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-=
>left:.5in'><span style=3D'font-family:"Courier New"'><o:p>&nbsp;</o:p></spa=
>n></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-f=
>amily:"Courier New"'>***<o:p></o:p></span></p><p class=3DMsoNormal style=3D=
>'margin-left:.5in'><span style=3D'font-family:"Courier New"'>*** runtime er=
>ror:<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><=
>span style=3D'font-family:"Courier New"'>***&nbsp;&nbsp;&nbsp; Attempt to r=
>eference an illegal memory location.<o:p></o:p></span></p><p class=3DMsoNor=
>mal style=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'><o=
>:p>&nbsp;</o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><=
>span style=3D'font-family:"Courier New"'>***<o:p></o:p></span></p><p class=
>=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Courier=
> New"'>*** runtime error:<o:p></o:p></span></p><p class=3DMsoNormal style=
>=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'>***&nbsp;&n=
>bsp;&nbsp; Attempt to reference an illegal memory location.<o:p></o:p></spa=
>n></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-f=
>amily:"Courier New"'>***&nbsp;&nbsp;&nbsp; pc =3D 0x126e37d =3D Move + 0x50=
> in ..\src\runtime\common\RTCollector.m3<o:p></o:p></span></p><p class=3DMs=
>oNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"=
>'>***<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'>=
><span style=3D'font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p cl=
>ass=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Cour=
>ier New"'>***<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-lef=
>t:.5in'><span style=3D'font-family:"Courier New"'>*** runtime error:<o:p></=
>o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=
>=3D'font-family:"Courier New"'>***&nbsp;&nbsp;&nbsp; &lt;*ASSERT*&gt; faile=
>d.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><sp=
>an style=3D'font-family:"Courier New"'>***&nbsp;&nbsp;&nbsp; file &quot;..\=
>src\thread\WIN32\ThreadWin32.m3&quot;, line 841<o:p></o:p></span></p><p cla=
>ss=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Couri=
>er New"'>***<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left=
>:.5in'><span style=3D'font-family:"Courier New"'><o:p>&nbsp;</o:p></span></=
>p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-famil=
>y:"Courier New"'>***<o:p></o:p></span></p><p class=3DMsoNormal style=3D'mar=
>gin-left:.5in'><span style=3D'font-family:"Courier New"'>*** runtime error:=
><o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span=
> style=3D'font-family:"Courier New"'>***&nbsp;&nbsp;&nbsp; &lt;*ASSERT*&gt;=
> failed.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5i=
>n'><span style=3D'font-family:"Courier New"'>***&nbsp;&nbsp;&nbsp; file &qu=
>ot;..\src\thread\WIN32\ThreadWin32.m3&quot;, line 841<o:p></o:p></span></p>=
><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:=
>"Courier New"'>***<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margi=
>n-left:.5in'><span style=3D'font-family:"Courier New"'><o:p>&nbsp;</o:p></s=
>pan></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font=
>-family:"Courier New"'>***<o:p></o:p></span></p><p class=3DMsoNormal style=
>=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'>*** runtime=
> error:<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in=
>'><span style=3D'font-family:"Courier New"'>***&nbsp;&nbsp;&nbsp; &lt;*ASSE=
>RT*&gt; failed.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-l=
>eft:.5in'><span style=3D'font-family:"Courier New"'>***&nbsp;&nbsp;&nbsp; f=
>ile &quot;..\src\thread\WIN32\ThreadWin32.m3&quot;, line 841<o:p></o:p></sp=
>an></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-=
>family:"Courier New"'>***<o:p></o:p></span></p><p class=3DMsoNormal><o:p>&n=
>bsp;</o:p></p><p class=3DMsoNormal>I&#8217;ll try on 32-bit XP soon and rep=
>ort.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMso=
>Normal>Regards,<o:p></o:p></p><p class=3DMsoNormal>Randy Coleburn<o:p></o:p=
>></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></body></html>=
>
>--_000_D67F02DDC62F7545A6B84C285F88F3E603418BD6ADatlex02srv_--
>
>--_004_D67F02DDC62F7545A6B84C285F88F3E603418BD6ADatlex02srv_
>Content-Type: application/octet-stream; name="Main.m3"
>Content-Description: Main.m3
>Content-Disposition: attachment; filename="Main.m3"; size=18584;
>	creation-date="Thu, 03 Mar 2011 01:28:22 GMT";
>	modification-date="Tue, 15 Mar 2011 01:30:19 GMT"
>Content-Transfer-Encoding: base64
>
>TU9EVUxFIE1haW47DQoNCigqIFRocmVhZGluZyBzdHJlc3MtdGVzdC4NCg0KICAgQ3JlYXRlIGEg
>bnVtYmVyIG9mIHRocmVhZHMuICBuIGlzIHNwZWNpZmllZCB2aWEgblBlciwgSXQgaXMNCiAgIHJl
>YXNvbmFibGUgZm9yIG5QZXIgdG8gYmUgZnJvbSAxIHRvIGEgZmV3IGh1bmRyZWQuICBuUGVyIGRl
>ZmF1bHRzDQogICB0byAzIGJ1dCBjYW4gYmUgc2V0IGJ5IHRoZSAtbiBjb21tYW5kLWxpbmUgc3dp
>dGNoLg0KDQogICBPdGhlciBjb21tYW5kLWxpbmUgc3dpdGNoZXM6DQoNCiAgIC13YWl0IDxzdGVw
>cz4NCiAgICAgIGhvdyBtYW55IG9uZS1zZWNvbmQgd2FpdHMgdG8gZXhlY3V0ZSBiZXR3ZWVuIHBy
>aW50cyAoZGVmYXVsdCAxMCkNCg0KICAgLWl0ZXJzIDxpdGVycz4NCiAgICAgIGhvdyBtYW55IGl0
>ZXJhdGlvbnMgdG8gcnVuIGZvciAoZGVmYXVsdCAxMCkNCg0KICAgLXRlc3RzIDx0ZXN0MT4sPHRl
>c3QyPiwuLi4NCiAgICAgIGNvbW1hLXNlcGFyYXRlZCBsaXN0IG9mIHRlc3RzIChkZWZhdWx0IHN0
>ZCB0eXBlcykNCiAgICAgIGNhbiBzcGVjaWZ5IGFsbCB3aXRoICJBTEwiIG9yIHN0YW5kYXJkIHRl
>c3RzIHdpdGggIlNURCINCiAgICAgIGFuZCBjYW4gc3VidHJhY3QgdGVzdHMgd2l0aCAtPG5hbWUg
>b2YgdGVzdD4NCiAgICAgIGV4YW1wbGVzLg0KICAgICAgICAgLXRlc3RzIHJlYWQsYWxsb2MsY3Jl
>YXQNCg0KICAgICAgICAgLXRlc3RzIEFMTCwtcmVhZA0KDQogICBUaGUgdGhyZWFkcyBjcmVhdGVk
>IGFyZSBvZiBmaXZlIHR5cGVzLiAgRWFjaCB0eXBlIG9mIHRocmVhZCBzdGFydHMNCiAgIGJ5IHNs
>ZWVwaW5nIGZvciBhIHdoaWxlLCB0byBnaXZlIHRoZSBvdGhlciB0aHJlYWRzIGEgY2hhbmNlIHRv
>IGJlDQogICBjcmVhdGVkLg0KDQogICBUaGUgdGhyZWFkcyBhcmUgb2YgdGhlIGZvbGxvd2luZyB0
>eXBlczoNCg0KICAgMS4gUmVhZGVyIC0tIGNvbnRpbnVvdXNseSByZWFkIHRoZSBjb250ZW50cyBv
>ZiB0aGUgZmlsZSAiaG9odW0iLA0KICAgICAgY3JlYXRlZCBkdXJpbmcgc3RhcnR1cCBpbiBDV0Qg
>YnkgdGhlIG1haW4gdGhyZWFkLg0KDQogICAyLiBGb3JrZXIgLS0gcmVwZWF0ZWRseSBmb3JrIGEg
>c3VicHJvY2VzcyB0aGF0IHNsZWVwcyBmb3Igb25lIHNlY29uZA0KICAgICAgdXNpbmcgUHJvY2Vz
>cy5DcmVhdGUuDQoNCiAgIDJiLiBGb3JrVG9vTXVjaCAtLSBmb3JrICJzbGVlcCAxMCIgYW5kIGRv
>IE5PVCBjYWxsIFByb2Nlc3MuV2FpdC4NCiAgICAgIE1heSBnZW5lcmF0ZSBsb3RzIG9mIHpvbWJp
>ZXMuDQoNCiAgIDMuIEFsbG9jYXRvciAtLSByZXBlYXRlZGx5IGFsbG9jYXRlIGhlYXAgbWVtb3J5
>IGFuZCBwZXJmb3JtDQogICAgICBtZWFuaW5nbGVzcyBvcGVyYXRpb25zIG9uIGl0Lg0KDQogICA0
>LiBDcmVhdG9yIC0tIHJlcGVhdGVkbHkgZm9yayBhIHNpbXBsZSBUaHJlYWQuVCB0aGF0IGRvZXMg
>bm90aGluZw0KICAgICAgYW5kIGV4aXRzLiAgV2FpdCBmb3IgaXQgdG8gZXhpdCBiZWZvcmUgZm9y
>a2luZyBhbm90aGVyLg0KDQogICA1LiBMb2NrZXIgLS0gcmVwZWF0ZWRseSBpbmNyZW1lbnQgb3Ig
>ZGVjcmVtZW50IGEgc2luZ2xlIGludGVnZXINCiAgICAgIHZhcmlhYmxlIGZyb20gd2l0aGluIGEg
>TVVURVgtcHJvdGVjdGVkIGNyaXRpY2FsIHNlY3Rpb24uDQoNCiAgIDYuIFJlYWRlck5vRXhjZXB0
>IC0tIGxpa2UgUmVhZGVyIGJ1dCB3aXRob3V0IFRSWS1FWENFUFQNCg0KICAgNy4gVHJ5RXhjZXB0
>IC0tIGEgbG9vcCB0aGF0IGNhdGNoZXMgYW4gZXhjZXB0aW9uIHRoYXQgbmV2ZXIgaGFwcGVucw0K
>DQogICBFYWNoIHRocmVhZCB3cml0ZXMgdGhlIHRoZSBpdCBwZXJmb3JtcyBhbiBvcGVyYXRpb24g
>dG8gdGhlIHRpbWVzMQ0KICAgYXJyYXkuICBUaGUgdGltZXMxIGFycmF5IGlzIGNvcGllZCBieSB0
>aGUgbWFpbiB0aHJlYWQsIGV2ZXJ5IDEwKw0KICAgc2Vjb25kcywgaW50byB0aGUgdGltZXMyIGFy
>cmF5LiAgTm8gbG9ja3MgYXJlIHVzZWQgdG8gc3luY2hyb25pemUNCiAgIHRoaXMgY29weWluZyBh
>Y3Rpdml0eSBhcyB3ZSBkb24ndCB3YW50IHRvIGludHJvZHVjZSB0b28gbWFueSBwb3NzaWJsZQ0K
>ICAgcGxhY2VzIHRoaW5ncyBjb3VsZCBkZWFkbG9jay4NCg0KICAgVGhlIG1haW4gdGhyZWFkIHRo
>ZW4gcHJpbnRzIG91dCBob3cgbG9uZyBhZ28gdGhlIHRocmVhZCB0aGF0IGhhcyBub3QNCiAgIHdy
>aXR0ZW4gdGltZXMxIGxhc3Qgd3JvdGUgdGhhdCBhcnJheS4NCg0KICAgTm90ZSB0aGF0IGFjdGlv
>bnMgaW4gdGhlIG1haW4gdGhyZWFkIG1heSBhbGxvY2F0ZSBtZW1vcnkgYW5kIHRoZXJlZm9yZQ0K
>ICAgYWNxdWlyZXMgbG9ja3MgaW4gVGhyZWFkUFRocmVhZC5tMywgdGhlIGZpbGUgd2hpY2ggdGhl
>IHByb2dyYW0gaXMNCiAgIG1haW5seSBpbnRlbmRlZCB0byB0ZXN0LiAgVGhlIGRlc2lnbiBpcyBi
>YXNlZCBvbiBhIGtub3dsZWRnZSBvZiB0aGUNCiAgIGludGVybmFsIGJlaGF2aW9yIG9mIFRocmVh
>ZFBUaHJlYWQubTMgYW5kIGFsc28gb24gYSBrbm93bGVkZ2Ugb2YgdGhlDQogICBtaXNiZWhhdmlv
>ciBvZiBleGlzdGluZywgaGlnaGx5IG11bHRpdGhyZWFkZWQgYXBwbGljYXRpb25zLg0KDQoNCiAg
>IEZBSVJORVNTIElTU1VFUw0KDQogICBFc3BlY2lhbGx5IHdpdGggdXNlciB0aHJlYWRzLCB0aGVy
>ZSBtYXkgYmUgZmFpcm5lc3MgcHJvYmxlbXMuICBUaGUNCiAgIHBvaW50IG9mIHRoZSBwcm9ncmFt
>IGlzIHRvIHRlc3QgdGhyZWFkaW5nIHNvIHRoZXJlIGlzIG9idmlvdXNseSBubw0KICAgYXR0ZW1w
>dCBhdCBlbmZvcmNpbmcgZmFpcm5lc3MuICBXaXRoIHVzZXIgdGhyZWFkcywgdGhpcyBtYXkgY2F1
>c2UNCiAgIGNlcnRhaW4gdHlwZXMgb2YgdGhyZWFkcyB0byBtb25vcG9saXplIHRoZSBjcHUuICAi
>U1RELC1sb2NrIiBtaWdodA0KICAgYmUgYWR2aXNlZCBmb3IgdGhlIGxpc3Qgb2YgdGVzdHMgZm9y
>IHVzZXIgdGhyZWFkcy4NCg0KICAgQXV0aG9yOiBNaWthIE55c3Ryb20gPG1pa2FAYWx1bS5taXQu
>ZWR1Pg0KDQogICBDb3B5cmlnaHQgKGMpIDIwMTEgR2VuZXJhdGlvbiBDYXBpdGFsIEx0ZC4gIEFs
>bCByaWdodHMgcmVzZXJ2ZWQuDQoNCiAgIFBlcm1pc3Npb24gdG8gdXNlLCBjb3B5LCBtb2RpZnks
>IGFuZCBkaXN0cmlidXRlIHRoaXMgc29mdHdhcmUNCiAgIGFuZCBpdHMgZG9jdW1lbnRhdGlvbiBm
>b3IgYW55IHB1cnBvc2UgYW5kIHdpdGhvdXQgZmVlIGlzIGhlcmVieQ0KICAgZ3JhbnRlZCwgcHJv
>dmlkZWQgdGhhdCB0aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhcHBlYXIgaW4gYWxsDQogICBj
>b3BpZXMuIEdlbmVyYXRpb24gQ2FwaXRhbCBMdGQuIG1ha2VzIG5vIHJlcHJlc2VudGF0aW9ucw0K
>ICAgYWJvdXQgdGhlIHN1aXRhYmlsaXR5IG9mIHRoaXMgc29mdHdhcmUgZm9yIGFueSBwdXJwb3Nl
>LiBJdCBpcw0KICAgcHJvdmlkZWQgImFzIGlzIiB3aXRob3V0IGV4cHJlc3Mgb3IgaW1wbGllZCB3
>YXJyYW50eS4NCg0KICopDQogKCogTWFyY2ggMTQsIDIwMTEsIFIuQy5Db2xlYnVybjoNCiAgICAg
>ICBBZGRlZCAtdmVyYm9zZSBvcHRpb24gYW5kIHRocmVhZCBsb29wIGl0ZXJhdGlvbiBjb3VudGlu
>ZyB3aXRoIGV4cGxpY2l0IG5vdGlmaWNhdGlvbiBvZiBzdGFydmVkL2RlYWRsb2NrZWQgdGhyZWFk
>cy4NCiAgICAgICBBZGRlZCBwcC5maW5pc2goKSB0byB0ZWxsIGlmIGFsbCBjb21tYW5kIGxpbmUg
>cGFyYW1ldGVycyB3ZXJlIHByb2Nlc3NlZC4NCiAqKQ0KDQoNCklNUE9SVCBUaHJlYWQsIFJkLCBG
>aWxlUmQsIFdyLCBGaWxlV3IsIFByb2Nlc3M7DQpJTVBPUlQgVGltZTsNCklNUE9SVCBJbnRBcnJh
>eVNvcnQ7DQpJTVBPUlQgQXRvbSwgQXRvbUxpc3Q7DQpJTVBPUlQgT1NFcnJvcjsNCklNUE9SVCBQ
>YXJzZVBhcmFtcywgUGFyYW1zOw0KSU1QT1JUIFN0ZGlvOw0KSU1QT1JUIFRleHQ7DQpJTVBPUlQg
>Rm10Ow0KDQo8KiBGQVRBTCBUaHJlYWQuQWxlcnRlZCwgV3IuRmFpbHVyZSAqPg0KDQpDT05TVCBJ
>bml0UGF1c2UgPSAxLjBkMDsNCg0KVFlQRSBDbG9zdXJlID0gVGhyZWFkLkNsb3N1cmUgT0JKRUNU
>IGlkIDogQ0FSRElOQUwgRU5EOw0KDQpQUk9DRURVUkUgTWFrZVJlYWRlclRocmVhZChpIDogQ0FS
>RElOQUwpID0NCiAgQkVHSU4NCiAgICBFVkFMIFRocmVhZC5Gb3JrKE5FVyhDbG9zdXJlLCBpZCA6
>PSBpLCBhcHBseSA6PSBSQXBwbHkpKQ0KICBFTkQgTWFrZVJlYWRlclRocmVhZDsNCg0KUFJPQ0VE
>VVJFIE1ha2VSZWFkZXJOb0V4Y2VwdFRocmVhZChpIDogQ0FSRElOQUwpID0NCiAgQkVHSU4NCiAg
>ICBFVkFMIFRocmVhZC5Gb3JrKE5FVyhDbG9zdXJlLCBpZCA6PSBpLCBhcHBseSA6PSBOQXBwbHkp
>KQ0KICBFTkQgTWFrZVJlYWRlck5vRXhjZXB0VGhyZWFkOw0KDQpQUk9DRURVUkUgTWFrZVRyeUV4
>Y2VwdFRocmVhZChpIDogQ0FSRElOQUwpID0NCiAgQkVHSU4NCiAgICBFVkFMIFRocmVhZC5Gb3Jr
>KE5FVyhDbG9zdXJlLCBpZCA6PSBpLCBhcHBseSA6PSBUQXBwbHkpKQ0KICBFTkQgTWFrZVRyeUV4
>Y2VwdFRocmVhZDsNCg0KUFJPQ0VEVVJFIE1ha2VGb3JrZXJUaHJlYWQoaSA6IENBUkRJTkFMKSA9
>DQogIEJFR0lODQogICAgRVZBTCBUaHJlYWQuRm9yayhORVcoQ2xvc3VyZSwgaWQgOj0gaSwgYXBw
>bHkgOj0gRkFwcGx5KSkNCiAgRU5EIE1ha2VGb3JrZXJUaHJlYWQ7DQoNClBST0NFRFVSRSBNYWtl
>Rm9ya1Rvb011Y2hUaHJlYWQoaSA6IENBUkRJTkFMKSA9DQogIEJFR0lODQogICAgRVZBTCBUaHJl
>YWQuRm9yayhORVcoQ2xvc3VyZSwgaWQgOj0gaSwgYXBwbHkgOj0gTUFwcGx5KSkNCiAgRU5EIE1h
>a2VGb3JrVG9vTXVjaFRocmVhZDsNCg0KUFJPQ0VEVVJFIE1ha2VBbGxvY2F0b3JUaHJlYWQoaSA6
>IENBUkRJTkFMKSA9DQogIEJFR0lODQogICAgRVZBTCBUaHJlYWQuRm9yayhORVcoQ2xvc3VyZSwg
>aWQgOj0gaSwgYXBwbHkgOj0gQUFwcGx5KSkNCiAgRU5EIE1ha2VBbGxvY2F0b3JUaHJlYWQ7DQoN
>ClBST0NFRFVSRSBNYWtlQ3JlYXRvclRocmVhZChpIDogQ0FSRElOQUwpID0NCiAgQkVHSU4NCiAg
>ICBFVkFMIFRocmVhZC5Gb3JrKE5FVyhDbG9zdXJlLCBpZCA6PSBpLCBhcHBseSA6PSBDQXBwbHkp
>KQ0KICBFTkQgTWFrZUNyZWF0b3JUaHJlYWQ7DQoNClBST0NFRFVSRSBNYWtlTG9ja2VyVGhyZWFk
>KGkgOiBDQVJESU5BTCkgPQ0KICBCRUdJTg0KICAgIEVWQUwgVGhyZWFkLkZvcmsoTkVXKENsb3N1
>cmUsIGlkIDo9IGksIGFwcGx5IDo9IExBcHBseSkpDQogIEVORCBNYWtlTG9ja2VyVGhyZWFkOw0K
>DQpUWVBFDQogIFRocmVhZE1ha2VyID0gUFJPQ0VEVVJFKGkgOiBDQVJESU5BTCk7DQogIE5hbWVk
>ID0gUkVDT1JEIG1ha2VyIDogVGhyZWFkTWFrZXI7IG5hbWVkIDogVEVYVCBFTkQ7DQoNCkNPTlNU
>DQogIE1ha2VycyA9IEFSUkFZIE9GIE5hbWVkIHsNCiAgICBOYW1lZCB7IE1ha2VSZWFkZXJUaHJl
>YWQsICAgICAgICAgInJlYWQiICB9LA0KICAgIE5hbWVkIHsgTWFrZVJlYWRlck5vRXhjZXB0VGhy
>ZWFkLCAibnhyZWFkIiAgfSwNCiAgICBOYW1lZCB7IE1ha2VUcnlFeGNlcHRUaHJlYWQsICAgICAg
>InRyeWV4Y2VwdCIgIH0sDQogICAgTmFtZWQgeyBNYWtlRm9ya2VyVGhyZWFkLCAgICAgICAgICJm
>b3JrIiAgfSwNCiAgICBOYW1lZCB7IE1ha2VGb3JrVG9vTXVjaFRocmVhZCwgICAgImZvcmt0b29t
>dWNoIiAgfSwNCiAgICBOYW1lZCB7IE1ha2VBbGxvY2F0b3JUaHJlYWQsICAgICAgImFsbG9jIiB9
>LA0KICAgIE5hbWVkIHsgTWFrZUNyZWF0b3JUaHJlYWQsICAgICAgICAiY3JlYXQiIH0sDQogICAg
>TmFtZWQgeyBNYWtlTG9ja2VyVGhyZWFkLCAgICAgICAgICJsb2NrIiAgfQ0KICB9Ow0KDQpDT05T
>VCBTdGRUZXN0QXJyID0gQVJSQVkgT0YgVEVYVCB7ICJyZWFkIiwgImZvcmsiLCAiYWxsb2MiLCAi
>Y3JlYXRlIiwgImxvY2siIH07DQooKiBkZXNpZ25hdGVkICJzdGFuZGFyZCIgdGVzdHMgKikNCg0K
>VFlQRSBNID0gWyBGSVJTVChNYWtlcnMpLi5MQVNUKE1ha2VycykgXTsNCg0KKCoqKioqKioqKioq
>KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
>KiopDQoNClBST0NFRFVSRSBSQXBwbHkoY2wgOiBDbG9zdXJlKSA6IFJFRkFOWSA9DQogIEJFR0lO
>DQogICAgY291bnRzMVtjbC5pZF0gOj0gMEw7DQogICAgY291bnRzM1tjbC5pZF0gOj0gMEw7DQog
>ICAgVGhyZWFkLlBhdXNlKEluaXRQYXVzZSk7DQogICAgTE9PUA0KICAgICAgVFJZDQogICAgICAg
>IFdJVEggcmQgPSBGaWxlUmQuT3BlbihGaWxlbmFtZSkgRE8NCiAgICAgICAgICBUUlkNCiAgICAg
>ICAgICAgIExPT1ANCiAgICAgICAgICAgICAgPCpVTlVTRUQqPlZBUiBjIDo9IFJkLkdldENoYXIo
>cmQpOyBCRUdJTiAgRU5EDQogICAgICAgICAgICBFTkQNCiAgICAgICAgICBFWENFUFQNCiAgICAg
>ICAgICAgIFJkLkVuZE9mRmlsZSA9PiBSZC5DbG9zZShyZCkNCiAgICAgICAgICBFTkQ7DQogICAg
>ICAgICAgdGltZXMxW2NsLmlkXTo9IEZMT09SKFRpbWUuTm93KCkpDQogICAgICAgIEVORA0KICAg
>ICAgRVhDRVBUDQogICAgICAgIE9TRXJyb3IuRSh4KSA9PiBFcnJvcigiUkFwcGx5OiBPU0Vycm9y
>LkU6ICIgJiBGbXRBdG9tTGlzdCh4KSkNCiAgICAgIHwNCiAgICAgICAgUmQuRmFpbHVyZSh4KSA9
>PiBFcnJvcigiUkFwcGx5OiBSZC5GYWlsdXJlOiAiICYgRm10QXRvbUxpc3QoeCkpDQogICAgICBF
>TkQ7DQogICAgICBjb3VudHMxW2NsLmlkXSA6PSBjb3VudHMxW2NsLmlkXSArIDFMOyAoKiB3b3Vs
>ZCBiZSBuaWNlIHRvIHVzZSBJTkMgaGVyZSwgYnV0IHRoZXJlIGlzIGEgQ0cgYnVnIG9uIE5UMzg2
>IHdpdGggSU5DIG9mIExPTkdJTlQgKikNCiAgICBFTkQNCiAgRU5EIFJBcHBseTsNCg0KUFJPQ0VE
>VVJFIE5BcHBseShjbCA6IENsb3N1cmUpIDogUkVGQU5ZID0NCiAgPCpGQVRBTCBPU0Vycm9yLkUs
>IFJkLkZhaWx1cmUsIFJkLkVuZE9mRmlsZSo+DQogIEJFR0lODQogICAgY291bnRzMVtjbC5pZF0g
>Oj0gMEw7DQogICAgY291bnRzM1tjbC5pZF0gOj0gMEw7DQogICAgVGhyZWFkLlBhdXNlKEluaXRQ
>YXVzZSk7DQogICAgTE9PUA0KICAgICAgV0lUSCByZCA9IEZpbGVSZC5PcGVuKEZpbGVuYW1lKSBE
>Tw0KICAgICAgICBXSElMRSBOT1QgUmQuRU9GKHJkKSBETw0KICAgICAgICAgIDwqVU5VU0VEKj5W
>QVIgYyA6PSBSZC5HZXRDaGFyKHJkKTsgQkVHSU4gIEVORA0KICAgICAgICBFTkQ7DQogICAgICAg
>IFJkLkNsb3NlKHJkKTsNCiAgICAgICAgdGltZXMxW2NsLmlkXTo9IEZMT09SKFRpbWUuTm93KCkp
>DQogICAgICBFTkQ7DQogICAgICBjb3VudHMxW2NsLmlkXSA6PSBjb3VudHMxW2NsLmlkXSArIDFM
>OyAoKiB3b3VsZCBiZSBuaWNlIHRvIHVzZSBJTkMgaGVyZSwgYnV0IHRoZXJlIGlzIGEgQ0cgYnVn
>IG9uIE5UMzg2IHdpdGggSU5DIG9mIExPTkdJTlQgKikNCiAgICBFTkQNCiAgRU5EIE5BcHBseTsN
>Cg0KRVhDRVBUSU9OIFg7DQoNClBST0NFRFVSRSBUQXBwbHkoY2wgOiBDbG9zdXJlKSA6IFJFRkFO
>WSA9DQogIEJFR0lODQogICAgY291bnRzMVtjbC5pZF0gOj0gMEw7DQogICAgY291bnRzM1tjbC5p
>ZF0gOj0gMEw7DQogICAgVGhyZWFkLlBhdXNlKEluaXRQYXVzZSk7DQogICAgTE9PUA0KICAgICAg
>VFJZDQogICAgICAgIFdJVEggbm93ID0gVGltZS5Ob3coKSBETw0KICAgICAgICAgIHRpbWVzMVtj
>bC5pZF06PSBGTE9PUihub3cpOw0KICAgICAgICAgIElGIG5vdyA8IDAuMGQwIFRIRU4gUkFJU0Ug
>WCBFTkQNCiAgICAgICAgRU5EDQogICAgICBFWENFUFQgWCA9PiA8KkFTU0VSVCBGQUxTRSo+DQog
>ICAgICBFTkQ7DQogICAgICBjb3VudHMxW2NsLmlkXSA6PSBjb3VudHMxW2NsLmlkXSArIDFMOyAo
>KiB3b3VsZCBiZSBuaWNlIHRvIHVzZSBJTkMgaGVyZSwgYnV0IHRoZXJlIGlzIGEgQ0cgYnVnIG9u
>IE5UMzg2IHdpdGggSU5DIG9mIExPTkdJTlQgKikNCiAgICBFTkQNCiAgRU5EIFRBcHBseTsNCg0K
>UFJPQ0VEVVJFIEZBcHBseShjbCA6IENsb3N1cmUpIDogUkVGQU5ZID0NCiAgQkVHSU4NCiAgICBj
>b3VudHMxW2NsLmlkXSA6PSAwTDsNCiAgICBjb3VudHMzW2NsLmlkXSA6PSAwTDsNCiAgICBUaHJl
>YWQuUGF1c2UoSW5pdFBhdXNlKTsNCiAgICBMT09QDQogICAgICBUUlkNCiAgICAgICAgV0lUSCBw
>cm9jID0gUHJvY2Vzcy5DcmVhdGUoUGFyYW1zLkdldCgwKSwNCiAgICAgICAgICAgICAgICAgICAg
>ICAgICAgICAgICAgICAgQVJSQVkgT0YgVEVYVCB7ICItc2xlZXAiIH0pIERPDQogICAgICAgICAg
>RVZBTCBQcm9jZXNzLldhaXQocHJvYyk7IHRpbWVzMVtjbC5pZF0gOj0gRkxPT1IoVGltZS5Ob3co
>KSkNCiAgICAgICAgRU5EDQogICAgICBFWENFUFQNCiAgICAgICAgT1NFcnJvci5FKHgpID0+IEVy
>cm9yKCJGQXBwbHk6IE9TRXJyb3IuRTogIiAmIEZtdEF0b21MaXN0KHgpKQ0KICAgICAgRU5EOw0K
>ICAgICAgY291bnRzMVtjbC5pZF0gOj0gY291bnRzMVtjbC5pZF0gKyAxTDsgKCogd291bGQgYmUg
>bmljZSB0byB1c2UgSU5DIGhlcmUsIGJ1dCB0aGVyZSBpcyBhIENHIGJ1ZyBvbiBOVDM4NiB3aXRo
>IElOQyBvZiBMT05HSU5UICopDQogICAgRU5EDQogIEVORCBGQXBwbHk7DQoNClBST0NFRFVSRSBN
>QXBwbHkoY2wgOiBDbG9zdXJlKSA6IFJFRkFOWSA9DQogIEJFR0lODQogICAgY291bnRzMVtjbC5p
>ZF0gOj0gMEw7DQogICAgY291bnRzM1tjbC5pZF0gOj0gMEw7DQogICAgVGhyZWFkLlBhdXNlKElu
>aXRQYXVzZSk7DQogICAgTE9PUA0KICAgICAgVFJZDQogICAgICAgIDwqTk9XQVJOKj5XSVRIIHBy
>b2MgPSBQcm9jZXNzLkNyZWF0ZShQYXJhbXMuR2V0KDApLA0KICAgICAgICAgICAgICAgICAgICAg
>ICAgICAgICAgICAgICBBUlJBWSBPRiBURVhUIHsgIi1zbGVlcDEwIiB9KSBETw0KICAgICAgICAg
>ICgqIG5vIFByb2Nlc3MuV2FpdCAqKQ0KICAgICAgICAgIHRpbWVzMVtjbC5pZF0gOj0gRkxPT1Io
>VGltZS5Ob3coKSk7DQogICAgICAgICAgVGhyZWFkLlBhdXNlKDEuMGQwKQ0KICAgICAgICBFTkQN
>CiAgICAgIEVYQ0VQVA0KICAgICAgICBPU0Vycm9yLkUoeCkgPT4gRXJyb3IoIkZBcHBseTogT1NF
>cnJvci5FOiAiICYgRm10QXRvbUxpc3QoeCkpDQogICAgICBFTkQ7DQogICAgICBjb3VudHMxW2Ns
>LmlkXSA6PSBjb3VudHMxW2NsLmlkXSArIDFMOyAoKiB3b3VsZCBiZSBuaWNlIHRvIHVzZSBJTkMg
>aGVyZSwgYnV0IHRoZXJlIGlzIGEgQ0cgYnVnIG9uIE5UMzg2IHdpdGggSU5DIG9mIExPTkdJTlQg
>KikNCiAgICBFTkQNCiAgRU5EIE1BcHBseTsNCg0KUFJPQ0VEVVJFIEFBcHBseShjbCA6IENsb3N1
>cmUpIDogUkVGQU5ZID0NCiAgQkVHSU4NCiAgICBjb3VudHMxW2NsLmlkXSA6PSAwTDsNCiAgICBj
>b3VudHMzW2NsLmlkXSA6PSAwTDsNCiAgICBUaHJlYWQuUGF1c2UoSW5pdFBhdXNlKTsNCiAgICBM
>T09QDQogICAgICBWQVINCiAgICAgICAgYXJyIDo9IE5FVyhSRUYgQVJSQVkgT0YgSU5URUdFUiwg
>MTAyNSk7DQogICAgICBCRUdJTg0KICAgICAgICBGT1IgaSA6PSBGSVJTVChhcnJeKSsxIFRPIExB
>U1QoYXJyXikgRE8NCiAgICAgICAgICBhcnJbaV0gOj0gYXJyW2ldIC0gYXJyW2ktMV0NCiAgICAg
>ICAgRU5EOyB0aW1lczFbY2wuaWRdIDo9IEZMT09SKFRpbWUuTm93KCkpDQogICAgICBFTkQ7DQog
>ICAgICBjb3VudHMxW2NsLmlkXSA6PSBjb3VudHMxW2NsLmlkXSArIDFMOyAoKiB3b3VsZCBiZSBu
>aWNlIHRvIHVzZSBJTkMgaGVyZSwgYnV0IHRoZXJlIGlzIGEgQ0cgYnVnIG9uIE5UMzg2IHdpdGgg
>SU5DIG9mIExPTkdJTlQgKikNCiAgICBFTkQNCiAgRU5EIEFBcHBseTsNCg0KUFJPQ0VEVVJFIENB
>cHBseShjbCA6IENsb3N1cmUpIDogUkVGQU5ZID0NCiAgQkVHSU4NCiAgICBjb3VudHMxW2NsLmlk
>XSA6PSAwTDsNCiAgICBjb3VudHMzW2NsLmlkXSA6PSAwTDsNCiAgICBUaHJlYWQuUGF1c2UoSW5p
>dFBhdXNlKTsNCiAgICBMT09QDQogICAgICBWQVINCiAgICAgICAgdCA6PSBUaHJlYWQuRm9yayhO
>RVcoVGhyZWFkLkNsb3N1cmUsIGFwcGx5IDo9IFRocmVhZE5PUCkpOw0KICAgICAgQkVHSU4NCiAg
>ICAgICAgRVZBTCBUaHJlYWQuSm9pbih0KTsgdGltZXMxW2NsLmlkXSA6PSBGTE9PUihUaW1lLk5v
>dygpKQ0KICAgICAgRU5EOw0KICAgICAgY291bnRzMVtjbC5pZF0gOj0gY291bnRzMVtjbC5pZF0g
>KyAxTDsgKCogd291bGQgYmUgbmljZSB0byB1c2UgSU5DIGhlcmUsIGJ1dCB0aGVyZSBpcyBhIENH
>IGJ1ZyBvbiBOVDM4NiB3aXRoIElOQyBvZiBMT05HSU5UICopDQogICAgRU5EDQogIEVORCBDQXBw
>bHk7DQoNClBST0NFRFVSRSBUaHJlYWROT1AoPCpVTlVTRUQqPmNsIDogVGhyZWFkLkNsb3N1cmUp
>IDogUkVGQU5ZID0gQkVHSU4gUkVUVVJOIE5JTCBFTkQgVGhyZWFkTk9QOw0KDQpWQVIgbXUgICAg
>IDo9IE5FVyhNVVRFWCk7DQpWQVIgc2hhcmVkIDo9IDA7DQoNClBST0NFRFVSRSBMQXBwbHkoY2wg
>OiBDbG9zdXJlKSA6IFJFRkFOWSA9DQogIEJFR0lODQogICAgY291bnRzMVtjbC5pZF0gOj0gMEw7
>DQogICAgY291bnRzM1tjbC5pZF0gOj0gMEw7DQogICAgVGhyZWFkLlBhdXNlKEluaXRQYXVzZSk7
>DQogICAgTE9PUA0KICAgICAgTE9DSyBtdSBETw0KICAgICAgICBDQVNFIGNsLmlkIE1PRCAyIE9G
>DQogICAgICAgICAgMSA9PiBJTkMoc2hhcmVkKQ0KICAgICAgICB8DQogICAgICAgICAgMCA9PiBE
>RUMoc2hhcmVkKQ0KICAgICAgICBFTFNFDQogICAgICAgICAgPCpBU1NFUlQgRkFMU0UqPg0KICAg
>ICAgICBFTkQNCiAgICAgIEVORDsgdGltZXMxW2NsLmlkXSA6PSBGTE9PUihUaW1lLk5vdygpKTsN
>CiAgICAgIGNvdW50czFbY2wuaWRdIDo9IGNvdW50czFbY2wuaWRdICsgMUw7ICgqIHdvdWxkIGJl
>IG5pY2UgdG8gdXNlIElOQyBoZXJlLCBidXQgdGhlcmUgaXMgYSBDRyBidWcgb24gTlQzODYgd2l0
>aCBJTkMgb2YgTE9OR0lOVCAqKQ0KICAgIEVORA0KICBFTkQgTEFwcGx5Ow0KDQoNCkNPTlNUIEZp
>bGVuYW1lID0gImhvaHVtIjsNCg0KUFJPQ0VEVVJFIFdyaXRlQUZpbGUoKSA9DQogIDwqRkFUQUwg
>V3IuRmFpbHVyZSwgT1NFcnJvci5FKj4gICgqIGVycm9ycyBkdXJpbmcgc2V0dXAgYXJlIGp1c3Qg
>ZmF0YWwgKikNCiAgQkVHSU4NCiAgICBXSVRIIHdyID0gRmlsZVdyLk9wZW4oRmlsZW5hbWUpIERP
>DQogICAgICBGT1IgaSA6PSAxIFRPIDI1NiBETw0KICAgICAgICBGT1IgaiA6PSAxIFRPIGkgRE8N
>CiAgICAgICAgICBXci5QdXRDaGFyKHdyLCBWQUwoT1JEKCdBJykgKyBpIE1PRCAyNSwgQ0hBUikp
>DQogICAgICAgIEVORDsNCiAgICAgICAgV3IuUHV0VGV4dCh3ciwgV3IuRU9MKQ0KICAgICAgRU5E
>Ow0KICAgICAgV3IuQ2xvc2Uod3IpDQogICAgRU5EDQogIEVORCBXcml0ZUFGaWxlOw0KDQpQUk9D
>RURVUkUgUHV0SW50KGMgOiBJTlRFR0VSKSA9DQogIEJFR0lODQogICAgSUYgYyA8IDAgVEhFTg0K
>ICAgICAgV3IuUHV0Q2hhcihTdGRpby5zdGRvdXQsJy0nKTsNCiAgICAgIGMgOj0gLWM7DQogICAg
>RU5EOw0KICAgIElGIGMgPiAxMCBUSEVODQogICAgICBQdXRJbnQoYyBESVYgMTApDQogICAgRU5E
>Ow0KICAgIFdyLlB1dENoYXIoU3RkaW8uc3Rkb3V0LFZBTChjIE1PRCAxMCArIE9SRCgnMCcpLENI
>QVIpKQ0KICBFTkQgUHV0SW50Ow0KDQpQUk9DRURVUkUgUHV0U3RhdHMoVkFSIGEgOiBBUlJBWSBP
>RiBJTlRFR0VSKSA9DQogICgqIG5vdyBpcyBnbG9iYWwgaW4gTWFpbi5tMyAqKQ0KICBCRUdJTg0K
>ICAgIEludEFycmF5U29ydC5Tb3J0KGEpOw0KDQogICAgKCogdGhlIHJlc3VsdCBpc24ndCBxdWl0
>ZSByaWdodCBpZiBOVU1CRVIoYSkgaXMgZXZlbiAqKQ0KICAgIFdJVEggbWluID0gYVtGSVJTVChh
>KV0sDQogICAgICAgICBtYXggPSBhW0xBU1QoYSldLA0KICAgICAgICAgbWVkID0gYVtMQVNUKGEp
>IERJViAyXSBETw0KICAgICAgUHV0SW50KG5vdy1taW4pOw0KICAgICAgV3IuUHV0Q2hhcihTdGRp
>by5zdGRvdXQsJy8nKTsNCiAgICAgIFB1dEludChub3ctbWVkKTsNCiAgICAgIFdyLlB1dENoYXIo
>U3RkaW8uc3Rkb3V0LCcvJyk7DQogICAgICBQdXRJbnQobm93LW1heCkNCiAgICBFTkQNCiAgRU5E
>IFB1dFN0YXRzOw0KDQpQUk9DRURVUkUgRm10QXRvbUxpc3QoZXJyIDogQXRvbUxpc3QuVCkgOiBU
>RVhUID0NCiAgVkFSDQogICAgbXNnIDo9ICIiOw0KICAgIHAgOj0gZXJyOw0KICBCRUdJTg0KICAg
>IFdISUxFIHAgIyBOSUwgRE8NCiAgICAgIG1zZyA6PSBtc2cgJiAiICIgJiBBdG9tLlRvVGV4dChw
>LmhlYWQpOyBwIDo9IHAudGFpbA0KICAgIEVORDsNCiAgICBSRVRVUk4gbXNnDQogIEVORCBGbXRB
>dG9tTGlzdDsNCg0KUFJPQ0VEVVJFIEVycm9yKG1zZyA6IFRFWFQpID0NCiAgQkVHSU4NCiAgICBX
>ci5QdXRUZXh0KFN0ZGlvLnN0ZG91dCwiRVJST1IgIiAmIG1zZyAmIFdyLkVPTCkNCiAgRU5EIEVy
>cm9yOw0KDQpQUk9DRURVUkUgQWRkVGVzdCh0ZXN0IDogVEVYVCkgPQ0KICBCRUdJTg0KICAgIElG
>ICAgIFRleHQuRXF1YWwoIkFMTCIsdGVzdCkgVEhFTg0KICAgICAgc2V0cyA6PSBTRVQgT0YgTSB7
>IEZJUlNUKE0pIC4uIExBU1QoTSkgfTsNCiAgICAgIFJFVFVSTg0KICAgIEVMU0lGIFRleHQuRXF1
>YWwoIlNURCIsdGVzdCkgVEhFTg0KICAgICAgc2V0cyA6PSBTdGRUZXN0czsNCiAgICAgIFJFVFVS
>Tg0KICAgIEVMU0lGIFRleHQuRXF1YWwoIlBPU0lYIix0ZXN0KSBUSEVODQogICAgICAoKiBlcXVh
>bCB0byBTVEQsLWxvY2sgKikNCiAgICAgIHNldHMgOj0gU3RkVGVzdHM7DQogICAgICB0ZXN0IDo9
>ICItbG9jayINCiAgICBFTkQ7DQoNCiAgICBGT1IgaSA6PSBGSVJTVChNYWtlcnMpIFRPIExBU1Qo
>TWFrZXJzKSBETw0KICAgICAgSUYgICAgVGV4dC5FcXVhbChNYWtlcnNbaV0ubmFtZWQsdGVzdCkg
>VEhFTg0KICAgICAgICBzZXRzIDo9IHNldHMgKyBTRVQgT0YgTSB7IGkgfTsgUkVUVVJODQogICAg
>ICBFTFNJRiBUZXh0LkVxdWFsKCItIiAmIE1ha2Vyc1tpXS5uYW1lZCx0ZXN0KSBUSEVODQogICAg
>ICAgIHNldHMgOj0gc2V0cyAtIFNFVCBPRiBNIHsgaSB9OyBSRVRVUk4NCiAgICAgIEVORA0KICAg
>IEVORDsNCg0KICAgICgqIG5vIG1hdGNoICopDQoNCiAgICBWQVINCiAgICAgIG1zZyA6PSAiTm8g
>dGVzdCBuYW1lZCBcIiIgJiB0ZXN0ICYgIlwiLCBrbm93biB0ZXN0czoiOw0KICAgIEJFR0lODQog
>ICAgICBGT1IgaSA6PSBGSVJTVChNYWtlcnMpIFRPIExBU1QoTWFrZXJzKSBETw0KICAgICAgICBt
>c2cgOj0gbXNnICYgIiAiICYgTWFrZXJzW2ldLm5hbWVkDQogICAgICBFTkQ7DQogICAgICBQcm9j
>ZXNzLkNyYXNoKG1zZykNCiAgICBFTkQNCiAgRU5EIEFkZFRlc3Q7DQoNCkNPTlNUDQogIERlZmF1
>bHROUGVyID0gMzsNClZBUg0KICBuUGVyIDo9IERlZmF1bHROUGVyOyAoKiBtdXN0IGJlIG9kZCAq
>KQ0KDQogIG4gOiBDQVJESU5BTDsNCg0KICB0aW1lczEsIHRpbWVzMiwgdGltZXMzIDogUkVGIEFS
>UkFZIE9GIElOVEVHRVI7DQogICgqIHRpbWVzMSA6IGlucHV0IGFycmF5DQogICAgIHRpbWVzMiA6
>IGEgc3RhYmxlIGNvcHkgb2YgdGltZXMxDQoNCiAgICAgdGltZXMzIDogYSBjb3B5IG9mIHRob3Nl
>IGJpdHMgb2YgdGltZXMxIHRoYXQgYXJlIGFjdGl2ZQ0KICAqKQ0KICBjb3VudHMxLCBjb3VudHMy
>LCBjb3VudHMzIDogUkVGIEFSUkFZIE9GIExPTkdJTlQ7DQogICgqIGNvdW50czEgOiBpbnB1dA0K
>ICAgICBjb3VudHMyIDogc3RhYmxlIGNvcHkgb2YgY291bnRzMQ0KICAgICBjb3VudHMzIDogY29w
>eSBvZiBwcmlvciBjb3VudHMyIHZhbHVlcyB1c2VkIGZvciBjb21wYXJpc29uDQogICopDQogIGFj
>dGl2ZTogUkVGIEFSUkFZIE9GIEJPT0xFQU47ICgqIHRlbGxzIGlmIGEgcGFydGljdWxhciB0aHJl
>YWQgaWQgaXMgYW4gYWN0aXZlIHRocmVhZCAqKQ0KICB0aHJlYWRNOiBSRUYgQVJSQVkgT0YgTTsg
>KCogZm9yIGFjdGl2ZSB0aHJlYWRzLCB0ZWxscyB0aGUgdHlwZSBvZiB0aHJlYWQsIGkuZS4sIGl0
>cyBNICopDQogIG5vdyA6IElOVEVHRVI7DQogIHNldHMgOiBTRVQgT0YgTTsNCg0KICBwcCA6PSBO
>RVcoUGFyc2VQYXJhbXMuVCkuaW5pdChTdGRpby5zdGRlcnIpOw0KDQogIGl0ZXJzIDo9IDEwOw0K
>ICB3YWl0ICA6PSAxMDsNCiAgU3RkVGVzdHMgOj0gU0VUIE9GIE0geyB9Ow0KICB2ZXJib3NlOiBC
>T09MRUFOIDo9IEZBTFNFOw0KDQpCRUdJTg0KICBGT1IgaSA6PSBGSVJTVChTdGRUZXN0QXJyKSBU
>TyBMQVNUKFN0ZFRlc3RBcnIpIERPDQogICAgRk9SIGogOj0gRklSU1QoTSkgVE8gTEFTVChNKSBE
>Tw0KICAgICAgSUYgVGV4dC5FcXVhbChTdGRUZXN0QXJyW2ldLE1ha2Vyc1tqXS5uYW1lZCkgVEhF
>Tg0KICAgICAgICBTdGRUZXN0cyA6PSBTdGRUZXN0cyArIFNFVCBPRiBNIHsgaiB9DQogICAgICBF
>TkQNCiAgICBFTkQNCiAgRU5EOw0KDQogIHNldHMgOj0gU3RkVGVzdHM7DQoNCiAgVFJZDQogICAg
>SUYgcHAua2V5d29yZFByZXNlbnQoIi1zbGVlcDEwIikgVEhFTg0KICAgICAgKCogc2xlZXAgYW5k
>IGV4aXQgKikNCiAgICAgIFRocmVhZC5QYXVzZSgxMC4wZDApOw0KICAgICAgUHJvY2Vzcy5FeGl0
>KDApDQogICAgRU5EOw0KICAgIElGIHBwLmtleXdvcmRQcmVzZW50KCItc2xlZXAiKSBUSEVODQog
>ICAgICAoKiBzbGVlcCBhbmQgZXhpdCAqKQ0KICAgICAgVGhyZWFkLlBhdXNlKDEuMGQwKTsNCiAg
>ICAgIFByb2Nlc3MuRXhpdCgwKQ0KICAgIEVORDsNCg0KICAgIElGIHBwLmtleXdvcmRQcmVzZW50
>KCItbiIpICAgICBUSEVOIG5QZXIgOj0gcHAuZ2V0TmV4dEludCgpIEVORDsNCiAgICBJRiBwcC5r
>ZXl3b3JkUHJlc2VudCgiLXdhaXQiKSAgVEhFTiB3YWl0IDo9IHBwLmdldE5leHRJbnQoKSBFTkQ7
>DQogICAgSUYgcHAua2V5d29yZFByZXNlbnQoIi1pdGVycyIpIFRIRU4gaXRlcnMgOj0gcHAuZ2V0
>TmV4dEludCgpIEVORDsNCiAgICBJRiBwcC5rZXl3b3JkUHJlc2VudCgiLXZlcmJvc2UiKSBUSEVO
>IHZlcmJvc2UgOj0gVFJVRTsgRU5EOw0KDQogICAgSUYgcHAua2V5d29yZFByZXNlbnQoIi10ZXN0
>cyIpIFRIRU4NCiAgICAgIFZBUg0KICAgICAgICBzIDo9IDA7DQogICAgICBCRUdJTg0KICAgICAg
>ICBzZXRzIDo9IFNFVCBPRiBNIHt9IDsNCg0KICAgICAgICBXSVRIIHRlc3RzID0gcHAuZ2V0TmV4
>dCgpLA0KICAgICAgICAgICAgIGwgICAgID0gVGV4dC5MZW5ndGgodGVzdHMpIERPDQogICAgICAg
>ICAgRk9SIGkgOj0gMCBUTyBsLTEgRE8NCiAgICAgICAgICAgIElGIGkgPSBsLTEgVEhFTg0KICAg
>ICAgICAgICAgICBBZGRUZXN0KFRleHQuU3ViKHRlc3RzLHMsbC1zKSkNCiAgICAgICAgICAgIEVM
>U0lGIFRleHQuR2V0Q2hhcih0ZXN0cyxpKSA9ICcsJyBUSEVODQogICAgICAgICAgICAgIEFkZFRl
>c3QoVGV4dC5TdWIodGVzdHMscyxpLXMpKTsNCiAgICAgICAgICAgICAgcyA6PSBpKzENCiAgICAg
>ICAgICAgIEVORA0KICAgICAgICAgIEVORA0KICAgICAgICBFTkQNCiAgICAgIEVORDsNCiAgICAg
>IHBwLmZpbmlzaCgpOw0KICAgIEVORA0KDQogIEVYQ0VQVA0KICAgIFBhcnNlUGFyYW1zLkVycm9y
>ID0+IFByb2Nlc3MuQ3Jhc2goIkNvdWxkbnQgcGFyc2UgY21kLWxpbmUgYXJncy4iKQ0KICBFTkQ7
>DQoNCiAgbiA6PSBOVU1CRVIoTWFrZXJzKSAqIG5QZXI7DQogIHRpbWVzMSA6PSBORVcoUkVGIEFS
>UkFZIE9GIElOVEVHRVIsIG4pOw0KICB0aW1lczIgOj0gTkVXKFJFRiBBUlJBWSBPRiBJTlRFR0VS
>LCBuKTsNCiAgdGltZXMzIDo9IE5FVyhSRUYgQVJSQVkgT0YgSU5URUdFUiwgbik7DQogIGNvdW50
>czEgOj0gTkVXKFJFRiBBUlJBWSBPRiBMT05HSU5ULCBuKTsNCiAgY291bnRzMiA6PSBORVcoUkVG
>IEFSUkFZIE9GIExPTkdJTlQsIG4pOw0KICBjb3VudHMzIDo9IE5FVyhSRUYgQVJSQVkgT0YgTE9O
>R0lOVCwgbik7DQogIGFjdGl2ZSA6PSBORVcoUkVGIEFSUkFZIE9GIEJPT0xFQU4sIG4pOw0KICB0
>aHJlYWRNIDo9IE5FVyhSRUYgQVJSQVkgT0YgTSwgbik7DQoNCiAgRk9SIGkgOj0gMCBUTyBuLTEN
>CiAgRE8NCiAgICAgYWN0aXZlW2ldIDo9IEZBTFNFOw0KICBFTkQ7ICgqIGZvciAqKQ0KDQogIFdy
>LlB1dFRleHQoU3RkaW8uc3Rkb3V0LCJXcml0aW5nIGZpbGUuLi4iKTsgV3IuRmx1c2goU3RkaW8u
>c3Rkb3V0KTsNCiAgV3JpdGVBRmlsZSgpOw0KICBXci5QdXRUZXh0KFN0ZGlvLnN0ZG91dCwiZG9u
>ZSIgJiBXci5FT0wpOyBXci5GbHVzaChTdGRpby5zdGRvdXQpOw0KDQogIEZPUiBpIDo9IEZJUlNU
>KE0pIFRPIExBU1QoTSkgRE8NCiAgICBJRiBpIElOIHNldHMgVEhFTg0KICAgICAgV3IuUHV0VGV4
>dChTdGRpby5zdGRvdXQsIkNyZWF0aW5nICIgJiBNYWtlcnNbaV0ubmFtZWQgJiAiIHRocmVhZHMu
>Li4iKTsNCiAgICAgIFdyLkZsdXNoKFN0ZGlvLnN0ZG91dCk7DQogICAgICBGT1IgaiA6PSAwIFRP
>IG5QZXIgLSAxIERPDQogICAgICAgIFdJVEggaWQgPSBpICogblBlciArIGoNCiAgICAgICAgRE8N
>CiAgICAgICAgICAgTWFrZXJzW2ldLm1ha2VyKGlkKTsNCiAgICAgICAgICAgYWN0aXZlW2lkXSA6
>PSBUUlVFOw0KICAgICAgICAgICB0aHJlYWRNW2lkXSA6PSBpOw0KICAgICAgICAgICBJRiB2ZXJi
>b3NlDQogICAgICAgICAgIFRIRU4NCiAgICAgICAgICAgICAgV3IuUHV0VGV4dChTdGRpby5zdGRv
>dXQsIFdyLkVPTCk7IFdyLlB1dFRleHQoU3RkaW8uc3Rkb3V0LCAiICAgIiAmIE1ha2Vyc1tpXS5u
>YW1lZCAmICI9Iik7IFB1dEludChpZCk7DQogICAgICAgICAgIEVORDsgKCogaWYgKikNCiAgICAg
>ICAgRU5EOyAoKiB3aXRoICopDQogICAgICBFTkQ7DQogICAgICBJRiB2ZXJib3NlDQogICAgICBU
>SEVODQogICAgICAgICBXci5QdXRUZXh0KFN0ZGlvLnN0ZG91dCwgV3IuRU9MKTsNCiAgICAgIEVO
>RDsgKCogaWYgKikNCiAgICAgIFdyLlB1dFRleHQoU3RkaW8uc3Rkb3V0LCAiZG9uZSIgJiBXci5F
>T0wpOyAgV3IuRmx1c2goU3RkaW8uc3Rkb3V0KQ0KICAgIEVORA0KICBFTkQ7DQoNCiAgV3IuUHV0
>VGV4dChTdGRpby5zdGRvdXQsInJ1bm5pbmcuLi5wcmludGluZyBvbGRlc3QvbWVkaWFuIGFnZS9u
>ZXdlc3QiICYgV3IuRU9MKTsNCiAgV3IuRmx1c2goU3RkaW8uc3Rkb3V0KTsNCiAgRk9SIGkgOj0g
>MSBUTyBpdGVycyBETw0KICAgIEZPUiBqIDo9IDEgVE8gd2FpdCBETw0KICAgICAgVGhyZWFkLlBh
>dXNlKDEuMGQwKTsNCiAgICAgIFdyLlB1dFRleHQoU3RkaW8uc3Rkb3V0LCIuIik7DQogICAgICBX
>ci5GbHVzaChTdGRpby5zdGRvdXQpDQogICAgRU5EOw0KICAgIHRpbWVzMl4gOj0gdGltZXMxXjsN
>CiAgICBub3cgIDo9IEZMT09SKFRpbWUuTm93KCkpOw0KICAgIGNvdW50czJeIDo9IGNvdW50czFe
>Ow0KICAgIFZBUg0KICAgICAgcCA6PSAwOw0KICAgIEJFR0lODQogICAgICBGT1IgaSA6PSBGSVJT
>VChNKSBUTyBMQVNUKE0pIERPDQogICAgICAgIElGIGkgSU4gc2V0cyBUSEVODQogICAgICAgICAg
>U1VCQVJSQVkodGltZXMzXixwLG5QZXIpIDo9IFNVQkFSUkFZKHRpbWVzMl4saSpuUGVyLG5QZXIp
>Ow0KICAgICAgICAgIElOQyhwLG5QZXIpDQogICAgICAgIEVORA0KICAgICAgRU5EOw0KICAgICAg
>V3IuUHV0VGV4dChTdGRpby5zdGRvdXQsImxhemllc3QgdGhyZWFkIGlzICIpOw0KICAgICAgUHV0
>U3RhdHMoU1VCQVJSQVkodGltZXMzXiwwLHApKTsNCiAgICAgIFdyLlB1dFRleHQoU3RkaW8uc3Rk
>b3V0LCIgKHRlc3RzOiIpOw0KDQogICAgICBGT1IgaSA6PSBGSVJTVChNKSBUTyBMQVNUKE0pIERP
>DQogICAgICAgIElGIGkgSU4gc2V0cyBUSEVODQogICAgICAgICAgV3IuUHV0VGV4dChTdGRpby5z
>dGRvdXQsIiAiKTsNCiAgICAgICAgICBXci5QdXRUZXh0KFN0ZGlvLnN0ZG91dCxNYWtlcnNbaV0u
>bmFtZWQpOw0KICAgICAgICAgIFdyLlB1dFRleHQoU3RkaW8uc3Rkb3V0LCIgIik7DQogICAgICAg
>ICAgUHV0U3RhdHMoU1VCQVJSQVkodGltZXMyXixpKm5QZXIsblBlcikpDQogICAgICAgIEVORA0K
>ICAgICAgRU5EOw0KICAgICAgV3IuUHV0VGV4dChTdGRpby5zdGRvdXQsIikiKTtXci5QdXRUZXh0
>KFN0ZGlvLnN0ZG91dCxXci5FT0wpOw0KICAgICAgV3IuRmx1c2goU3RkaW8uc3Rkb3V0KTsNCg0K
>ICAgICAgRk9SIGkgOj0gMCBUTyBuLTENCiAgICAgIERPDQogICAgICAgICBJRiBhY3RpdmVbaV0g
>QU5EIChjb3VudHMyW2ldID0gY291bnRzM1tpXSkNCiAgICAgICAgIFRIRU4NCiAgICAgICAgICAg
>IFdyLlB1dFRleHQoU3RkaW8uc3Rkb3V0LCBNYWtlcnNbdGhyZWFkTVtpXV0ubmFtZWQgJiAiIFRo
>cmVhZCAiICYgRm10LkludChpKSAmICIgYXBwZWFycyBzdGFydmVkIG9yIGRlYWRsb2NrZWQgISEh
>IiAmIFdyLkVPTCk7DQogICAgICAgICBFTFNJRiB2ZXJib3NlIEFORCBhY3RpdmVbaV0gQU5EIChj
>b3VudHMyW2ldID4gY291bnRzM1tpXSkNCiAgICAgICAgIFRIRU4NCiAgICAgICAgICAgIFdyLlB1
>dFRleHQoU3RkaW8uc3Rkb3V0LCAiICAgIiAmIE1ha2Vyc1t0aHJlYWRNW2ldXS5uYW1lZCAmICIg
>VGhyZWFkICIgJiBGbXQuSW50KGkpICYgIiBjb21wbGV0ZWQgIiAmIEZtdC5Mb25nSW50KGNvdW50
>czJbaV0gLSBjb3VudHMzW2ldKSAmICIgbG9vcHMuIiAmIFdyLkVPTCk7DQogICAgICAgICBFTkQ7
>ICgqIGlmICopDQogICAgICBFTkQ7ICgqIGZvciAqKQ0KICAgICAgY291bnRzM14gOj0gY291bnRz
>Ml47DQogICAgICBXci5GbHVzaChTdGRpby5zdGRvdXQpOw0KICAgIEVORA0KICBFTkQ7DQogIFdy
>LlB1dFRleHQoU3RkaW8uc3Rkb3V0LCAiQWxsIHRlc3RzIGNvbXBsZXRlLiAgQ29uZ3JhdHVsYXRp
>b25zLiIpOw0KICBXci5QdXRUZXh0KFN0ZGlvLnN0ZG91dCwgV3IuRU9MKTsNCkVORCBNYWluLg0K
>DQo=
>
>--_004_D67F02DDC62F7545A6B84C285F88F3E603418BD6ADatlex02srv_--


From rcolebur at SCIRES.COM  Wed Mar 16 19:42:10 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Wed, 16 Mar 2011 14:42:10 -0400
Subject: [M3devel] thread tests on NT386 32-bit circa 2008, not good so far
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E603418BDAF8@atlex02-srv>

I've gone back to a CM3 built on June 21, 2008.
Platform is IBM ThinkPad T60, Windows XP Professional, 32-bit.

If I try to put the "@M3paranoidgc" option on the command line, the thread test program always crashes, even before it reports anything about creating the threads.

"read", "nxread", "tryexcept", "fork", "forktoomuch", and "lock" tests seem to succeed.

"creat" and "alloc" seem to hang the program on the first iteration.  I see one "." printed and nothing else.  Have to CTRL-C abort.
BUT, if you run them with "@M3nogc" they will run until we run out of memory.  Tony, does this give any hint as to what may be wrong?

Output of the various runs is shown below:


C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read @M3paranoidgc

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0x42fb8c = AllocTraced + 0x3e in ..\src\runtime\common\RTCollector.m3
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 845
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 845
***


C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests alloc
Writing file...done
Creating alloc threads...
   alloc=15
   alloc=16
   alloc=17
done
running...printing oldest/median age/newest
.^C

C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests creat
Writing file...done
Creating creat threads...
   creat=18
   creat=19
   creat=20
done
running...printing oldest/median age/newest
.^C


C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests creat,alloc @M3nogc
Writing file...done
Creating alloc threads...
   alloc=15
   alloc=16
   alloc=17
done
Creating creat threads...
   creat=18
   creat=19
   creat=20
done
running...printing oldest/median age/newest
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 29204 loops.
   alloc Thread 16 completed 38868 loops.
   alloc Thread 17 completed 29118 loops.
   creat Thread 18 completed 111114 loops.
   creat Thread 19 completed 114913 loops.
   creat Thread 20 completed 108555 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 6968 loops.
   alloc Thread 16 completed 6747 loops.
   alloc Thread 17 completed 6331 loops.
   creat Thread 18 completed 40626 loops.
   creat Thread 19 completed 46526 loops.
   creat Thread 20 completed 43511 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 4857 loops.
   alloc Thread 16 completed 5409 loops.
   alloc Thread 17 completed 4601 loops.
   creat Thread 18 completed 50836 loops.
   creat Thread 19 completed 50108 loops.
   creat Thread 20 completed 53645 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 6249 loops.
   alloc Thread 16 completed 7252 loops.
   alloc Thread 17 completed 6770 loops.
   creat Thread 18 completed 62606 loops.
   creat Thread 19 completed 66036 loops.
   creat Thread 20 completed 62561 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 7000 loops.
   alloc Thread 16 completed 7559 loops.
   alloc Thread 17 completed 7389 loops.
   creat Thread 18 completed 66873 loops.
   creat Thread 19 completed 81612 loops.
   creat Thread 20 completed 62607 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 6666 loops.
   alloc Thread 16 completed 7579 loops.
   alloc Thread 17 completed 6964 loops.
   creat Thread 18 completed 89667 loops.
   creat Thread 19 completed 90794 loops.
   creat Thread 20 completed 90528 loops.
.....

***
*** runtime error:
***    NEW() was unable to allocate more memory.
***    file "..\src\runtime\common\RTCollector.m3", line 1545
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x4e7fe34   0x430197  LongAlloc + 0x89 in ..\src\runtime\common\RTCollector.m3
0x4e7fe90   0x42fd06  AllocTraced + 0x1b8 in ..\src\runtime\common\RTCollector.m3
0x4e7fed4   0x427ea9  GetOpenArray + 0x80 in ..\src\runtime\common\RTAllocator.m3
0x4e7fef8   0x427738  AllocateOpenArray + 0x19 in ..\src\runtime\common\RTAllocator.m3
0x4e7ff50   0x402293  AApply + 0x109 in ..\src\Main.m3
0x4e7ff88   0x42a34a  RunThread + 0x1f6 in ..\src\thread\WIN32\ThreadWin32.m3
0x4e7ffb4   0x42a0e3  ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3
.........  .........  ... more frames ...


C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lock
Writing file...done
Creating read threads...
   read=0
   read=1
   read=2
done
Creating nxread threads...
   nxread=3
   nxread=4
   nxread=5
done
Creating tryexcept threads...
   tryexcept=6
   tryexcept=7
   tryexcept=8
done
Creating fork threads...
   fork=9
   fork=0
   fork=11
done
Creating forktoomuch threads...
   forktoomuch=12
   forktoomuch=13
   forktoomuch=14
done
Creating lock threads...
   lock=21
   lock=22
   lock=23
done
running...printing oldest/median age/newest
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 2 loops.
   read Thread 1 completed 6 loops.
   read Thread 2 completed 4 loops.
   nxread Thread 3 completed 3 loops.
   nxread Thread 4 completed 1 loops.
   nxread Thread 5 completed 3 loops.
   tryexcept Thread 6 completed 14293296 loops.
   tryexcept Thread 7 completed 23332343 loops.
   tryexcept Thread 8 completed 14563267 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 5 loops.
   forktoomuch Thread 12 completed 6 loops.
   forktoomuch Thread 13 completed 7 loops.
   forktoomuch Thread 14 completed 6 loops.
   lock Thread 21 completed 1395 loops.
   lock Thread 22 completed 1613 loops.
   lock Thread 23 completed 2354 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 6 loops.
   read Thread 1 completed 13 loops.
   read Thread 2 completed 5 loops.
   nxread Thread 3 completed 8 loops.
   nxread Thread 4 completed 7 loops.
   nxread Thread 5 completed 10 loops.
   tryexcept Thread 6 completed 15350367 loops.
   tryexcept Thread 7 completed 22864059 loops.
   tryexcept Thread 8 completed 14516795 loops.
   fork Thread 9 completed 6 loops.
   fork Thread 10 completed 7 loops.
   fork Thread 11 completed 6 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 9 loops.
   forktoomuch Thread 14 completed 8 loops.
   lock Thread 21 completed 3742 loops.
   lock Thread 22 completed 2342 loops.
   lock Thread 23 completed 3827 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 5 loops.
   read Thread 1 completed 10 loops.
   read Thread 2 completed 4 loops.
   nxread Thread 3 completed 5 loops.
   nxread Thread 4 completed 3 loops.
   nxread Thread 5 completed 4 loops.
   tryexcept Thread 6 completed 14205335 loops.
   tryexcept Thread 7 completed 23955466 loops.
   tryexcept Thread 8 completed 14597334 loops.
   fork Thread 9 completed 7 loops.
   fork Thread 10 completed 6 loops.
   fork Thread 11 completed 7 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 9 loops.
   forktoomuch Thread 14 completed 8 loops.
   lock Thread 21 completed 1384 loops.
   lock Thread 22 completed 3801 loops.
   lock Thread 23 completed 4735 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 5 loops.
   read Thread 1 completed 9 loops.
   read Thread 2 completed 6 loops.
   nxread Thread 3 completed 5 loops.
   nxread Thread 4 completed 4 loops.
   nxread Thread 5 completed 9 loops.
   tryexcept Thread 6 completed 13962901 loops.
   tryexcept Thread 7 completed 22999610 loops.
   tryexcept Thread 8 completed 14123517 loops.
   fork Thread 9 completed 6 loops.
   fork Thread 10 completed 6 loops.
   fork Thread 11 completed 5 loops.
   forktoomuch Thread 12 completed 7 loops.
   forktoomuch Thread 13 completed 8 loops.
   forktoomuch Thread 14 completed 8 loops.
   lock Thread 21 completed 1744 loops.
   lock Thread 22 completed 2095 loops.
   lock Thread 23 completed 1503 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 2 loops.
   read Thread 1 completed 6 loops.
   read Thread 2 completed 2 loops.
   nxread Thread 3 completed 3 loops.
   nxread Thread 4 completed 3 loops.
   nxread Thread 5 completed 3 loops.
   tryexcept Thread 6 completed 15715885 loops.
   tryexcept Thread 7 completed 24769727 loops.
   tryexcept Thread 8 completed 15414675 loops.
   fork Thread 9 completed 7 loops.
   fork Thread 10 completed 6 loops.
   fork Thread 11 completed 7 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 8 loops.
   forktoomuch Thread 14 completed 9 loops.
   lock Thread 21 completed 1523 loops.
   lock Thread 22 completed 1922 loops.
   lock Thread 23 completed 1204 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 5 loops.
   read Thread 1 completed 9 loops.
   read Thread 2 completed 6 loops.
   nxread Thread 3 completed 4 loops.
   nxread Thread 4 completed 2 loops.
   nxread Thread 5 completed 8 loops.
   tryexcept Thread 6 completed 14688224 loops.
   tryexcept Thread 7 completed 23710577 loops.
   tryexcept Thread 8 completed 15355622 loops.
   fork Thread 9 completed 6 loops.
   fork Thread 10 completed 7 loops.
   fork Thread 11 completed 6 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 9 loops.
   forktoomuch Thread 14 completed 7 loops.
   lock Thread 21 completed 9427 loops.
   lock Thread 22 completed 3941 loops.
   lock Thread 23 completed 4421 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 9 loops.
   read Thread 1 completed 11 loops.
   read Thread 2 completed 6 loops.
   nxread Thread 3 completed 7 loops.
   nxread Thread 4 completed 5 loops.
   nxread Thread 5 completed 9 loops.
   tryexcept Thread 6 completed 16315690 loops.
   tryexcept Thread 7 completed 25110147 loops.
   tryexcept Thread 8 completed 17291322 loops.
   fork Thread 9 completed 5 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 5 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 9 loops.
   forktoomuch Thread 14 completed 8 loops.
   lock Thread 21 completed 1648 loops.
   lock Thread 22 completed 1274 loops.
   lock Thread 23 completed 975 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 2 loops.
   read Thread 1 completed 6 loops.
   read Thread 2 completed 3 loops.
   nxread Thread 3 completed 7 loops.
   nxread Thread 4 completed 4 loops.
   nxread Thread 5 completed 7 loops.
   tryexcept Thread 6 completed 16955552 loops.
   tryexcept Thread 7 completed 27781696 loops.
   tryexcept Thread 8 completed 16151561 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 3 loops.
   fork Thread 11 completed 2 loops.
   forktoomuch Thread 12 completed 7 loops.
   forktoomuch Thread 13 completed 7 loops.
   forktoomuch Thread 14 completed 7 loops.
   lock Thread 21 completed 2148 loops.
   lock Thread 22 completed 2179 loops.
   lock Thread 23 completed 1804 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 7 loops.
   read Thread 1 completed 5 loops.
   read Thread 2 completed 4 loops.
   nxread Thread 3 completed 9 loops.
   nxread Thread 4 completed 6 loops.
   nxread Thread 5 completed 5 loops.
   tryexcept Thread 6 completed 14537433 loops.
   tryexcept Thread 7 completed 24043303 loops.
   tryexcept Thread 8 completed 14258976 loops.
   fork Thread 9 completed 6 loops.
   fork Thread 10 completed 7 loops.
   fork Thread 11 completed 6 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 8 loops.
   forktoomuch Thread 14 completed 8 loops.
   lock Thread 21 completed 6504 loops.
   lock Thread 22 completed 2290 loops.
   lock Thread 23 completed 7696 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 5 loops.
   read Thread 1 completed 6 loops.
   read Thread 2 completed 2 loops.
   nxread Thread 3 completed 4 loops.
   nxread Thread 4 completed 1 loops.
   nxread Thread 5 completed 3 loops.
   tryexcept Thread 6 completed 17349384 loops.
   tryexcept Thread 7 completed 29845941 loops.
   tryexcept Thread 8 completed 17792587 loops.
   fork Thread 9 completed 5 loops.
   fork Thread 10 completed 5 loops.
   fork Thread 11 completed 6 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 9 loops.
   forktoomuch Thread 14 completed 9 loops.
   lock Thread 21 completed 2692 loops.
   lock Thread 22 completed 4498 loops.
   lock Thread 23 completed 3600 loops.
All tests complete.  Congratulations.

C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>

Regards,
Randy Coleburn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110316/5aece318/attachment-0001.html>

From rcolebur at SCIRES.COM  Wed Mar 16 19:54:37 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Wed, 16 Mar 2011 14:54:37 -0400
Subject: [M3devel] another thread test run on NT386 32-bit using HEAD branch
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E603418BDB06@atlex02-srv>

Here are results from the following platform:
IBM G40, Windows XP Professional, 32-bit
Using current HEAD branch of CM3

Both of the runs below use @M3paranoidgc

Note on the second run using alloc and creat tests that I get an error about a thread trying to join twice.

C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lock @M3paranoidgc
Writing file...done
Creating read threads...
   read=0
   read=1
   read=2
done
Creating nxread threads...
   nxread=3
   nxread=4
   nxread=5
done
Creating tryexcept threads...
   tryexcept=6
   tryexcept=7
   tryexcept=8
done
Creating fork threads...
   fork=9
   fork=0
   fork=11
done
Creating forktoomuch threads...
   forktoomuch=12
   forktoomuch=13
   forktoomuch=14
done
Creating lock threads...
   lock=21
   lock=22
   lock=23
done
running...printing oldest/median age/newest
....

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0x4086a0 = Init + 0x79 in ..\src\rw\FileRd.m3
***

.Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x107feb8   0x44536b  SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m3
0x107ff00   0x4086a0  Init + 0x79 in ..\src\rw\FileRd.m3
0x107ff2c   0x40861d  Open + 0x4d in ..\src\rw\FileRd.m3
0x107ff78   0x40173e  NApply + 0x124 in ..\src\Main.m3
0x107ffb4   0x42b56f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
.........  .........  ... more frames ...



C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests alloc,creat @M3paranoidgc
Writing file...done
Creating alloc threads...
   alloc=15
   alloc=16
   alloc=17
done
Creating creat threads...
   creat=18
   creat=19
   creat=20
done
running...printing oldest/median age/newest
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 11125 loops.
   alloc Thread 16 completed 10472 loops.
   alloc Thread 17 completed 9722 loops.
   creat Thread 18 completed 84 loops.
   creat Thread 19 completed 98 loops.
   creat Thread 20 completed 96 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 14258 loops.
   alloc Thread 16 completed 10791 loops.
   alloc Thread 17 completed 11403 loops.
   creat Thread 18 completed 111 loops.
   creat Thread 19 completed 115 loops.
   creat Thread 20 completed 121 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 13954 loops.
   alloc Thread 16 completed 9547 loops.
   alloc Thread 17 completed 10561 loops.
   creat Thread 18 completed 115 loops.
   creat Thread 19 completed 121 loops.
   creat Thread 20 completed 125 loops.
.

***
*** runtime error:
***    Thread client error: attempt to join with thread twice
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 688
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x127fedc   0x42c3ee  Die + 0x2a in ..\src\thread\WIN32\ThreadWin32.m3
0x127ff10   0x42b882  XJoin + 0x3c in ..\src\thread\WIN32\ThreadWin32.m3
0x127ff38   0x42ba06  Join + 0x46 in ..\src\thread\WIN32\ThreadWin32.m3
0x127ff78   0x402777  CApply + 0x12d in ..\src\Main.m3
0x127ffb4   0x42b56f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
.........  .........  ... more frames ...


Regards,
Randy Coleburn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110316/9a242093/attachment-0001.html>

From dabenavidesd at yahoo.es  Wed Mar 16 22:11:06 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 16 Mar 2011 21:11:06 +0000 (GMT)
Subject: [M3devel] thread tests on NT386 32-bit circa 2008,
	not good so far
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BDAF8@atlex02-srv>
Message-ID: <654158.70885.qm@web29702.mail.ird.yahoo.com>

Hi all:
I would be not surprised if its results were wrong crashes but because of the system threading.
Certainly we? would need to discard why the user threads are working so far and system threads are not working, i.e why CVsup is not working there are several idiomatic differences between system threads, each system indeed has its own behavior different from user threads, it certainly makes things portable in that sense to me.
But when ever we have access to one SPIN installation, I guess the program would be no trouble in running, as I think you could even debug it with a dynamic race condition detector, as I read somewhere, they did a catch somewhere in C client libraries linked against RT or better than that to use SPIN m3gdb specially modified for that purpose of remote debugging.
Even with the user threads implementation is not difficult but because of those libraries get into that debugging I believe.
Also we can annotate sources to debug later with ESC, at least its syntax, later more.
The other thing is that we then must need LL pragma which I still don't how to use, so any documentation on that is most welcome.
Yet another option would be catch the system threads in a stack trace able platform like there were before, perhaps this is the most feasible 
Thanks in advance

?

--- El mi?, 16/3/11, Coleburn, Randy <rcolebur at SCIRES.COM> escribi?:

De: Coleburn, Randy <rcolebur at SCIRES.COM>
Asunto: [M3devel] thread tests on NT386 32-bit circa 2008, not good so far
Para: "m3devel" <m3devel at elegosoft.com>
Fecha: mi?rcoles, 16 de marzo, 2011 13:42

I?ve gone back to a CM3 built on June 21, 2008.Platform is IBM ThinkPad T60, Windows XP Professional, 32-bit. ?If I try to put the ?@M3paranoidgc? option on the command line, the thread test program always crashes, even before it reports anything about creating the threads. ??read?, ?nxread?, ?tryexcept?, ?fork?, ?forktoomuch?, and ?lock? tests seem to succeed. ??creat? and ?alloc? seem to hang the program on the first iteration.? I see one ?.? printed and nothing else.? Have to CTRL-C abort.BUT, if you run them with ?@M3nogc? they will run until we run out of memory.? Tony, does this give any hint as to what may be wrong? ?Output of the various runs is shown below: ? ?C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read @M3paranoidgc ?****** runtime error:***??? Attempt to reference an illegal memory location.***??? pc = 0x42fb8c = AllocTraced + 0x3e in
 ..\src\runtime\common\RTCollector.m3*** ?****** runtime error:***??? <*ASSERT*> failed.***??? file "..\src\thread\WIN32\ThreadWin32.m3", line 845*** ?****** runtime error:***??? <*ASSERT*> failed.***??? file "..\src\thread\WIN32\ThreadWin32.m3", line 845*** ? ?C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests allocWriting file...doneCreating alloc threads...?? alloc=15?? alloc=16?? alloc=17donerunning...printing oldest/median age/newest.^C ?C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests creatWriting file...doneCreating creat threads...?? creat=18?? creat=19?? creat=20donerunning...printing oldest/median age/newest.^C ? ?C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests creat,alloc @M3nogcWriting file...doneCreating alloc threads...?? alloc=15?? alloc=16?? alloc=17doneCreating creat threads...?? creat=18??
 creat=19?? creat=20donerunning...printing oldest/median age/newest..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)?? alloc Thread 15 completed 29204 loops.?? alloc Thread 16 completed 38868 loops.?? alloc Thread 17 completed 29118 loops.?? creat Thread 18 completed 111114 loops.?? creat Thread 19 completed 114913 loops.?? creat Thread 20 completed 108555 loops...........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)?? alloc Thread 15 completed 6968 loops.?? alloc Thread 16 completed 6747 loops.?? alloc Thread 17 completed 6331 loops.?? creat Thread 18 completed 40626 loops.?? creat Thread 19 completed 46526 loops.?? creat Thread 20 completed 43511 loops...........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)?? alloc Thread 15 completed 4857 loops.?? alloc Thread 16 completed 5409 loops.?? alloc Thread 17 completed 4601 loops.?? creat Thread 18 completed 50836 loops.?? creat
 Thread 19 completed 50108 loops.?? creat Thread 20 completed 53645 loops...........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)?? alloc Thread 15 completed 6249 loops.?? alloc Thread 16 completed 7252 loops.?? alloc Thread 17 completed 6770 loops.?? creat Thread 18 completed 62606 loops.?? creat Thread 19 completed 66036 loops.?? creat Thread 20 completed 62561 loops...........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)?? alloc Thread 15 completed 7000 loops.?? alloc Thread 16 completed 7559 loops.?? alloc Thread 17 completed 7389 loops.?? creat Thread 18 completed 66873 loops.?? creat Thread 19 completed 81612 loops.?? creat Thread 20 completed 62607 loops...........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)?? alloc Thread 15 completed 6666 loops.?? alloc Thread 16 completed 7579 loops.?? alloc Thread 17 completed 6964 loops.?? creat Thread 18 completed 89667 loops.?? creat
 Thread 19 completed 90794 loops.?? creat Thread 20 completed 90528 loops...... ?****** runtime error:***??? NEW() was unable to allocate more memory.***??? file "..\src\runtime\common\RTCollector.m3", line 1545*** ?Stack trace:?? FP???????? PC????? Procedure---------? ---------? -------------------------------0x4e7fe34?? 0x430197? LongAlloc + 0x89 in ..\src\runtime\common\RTCollector.m30x4e7fe90?? 0x42fd06? AllocTraced + 0x1b8 in ..\src\runtime\common\RTCollector.m30x4e7fed4?? 0x427ea9? GetOpenArray + 0x80 in ..\src\runtime\common\RTAllocator.m30x4e7fef8?? 0x427738? AllocateOpenArray + 0x19 in ..\src\runtime\common\RTAllocator.m30x4e7ff50?? 0x402293? AApply + 0x109 in ..\src\Main.m30x4e7ff88?? 0x42a34a? RunThread + 0x1f6 in ..\src\thread\WIN32\ThreadWin32.m30x4e7ffb4?? 0x42a0e3? ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3.........? .........? ... more frames ... ?
 ?C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lockWriting file...doneCreating read threads...?? read=0?? read=1?? read=2doneCreating nxread threads...?? nxread=3?? nxread=4?? nxread=5doneCreating tryexcept threads...?? tryexcept=6?? tryexcept=7?? tryexcept=8doneCreating fork threads...?? fork=9?? fork=0?? fork=11doneCreating forktoomuch threads...?? forktoomuch=12?? forktoomuch=13?? forktoomuch=14doneCreating lock threads...?? lock=21?? lock=22?? lock=23donerunning...printing oldest/median age/newest..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 2 loops.?? read Thread 1 completed 6 loops.?? read Thread 2 completed 4 loops.?? nxread Thread 3 completed 3 loops.?? nxread Thread 4 completed 1 loops.?? nxread Thread 5 completed 3
 loops.?? tryexcept Thread 6 completed 14293296 loops.?? tryexcept Thread 7 completed 23332343 loops.?? tryexcept Thread 8 completed 14563267 loops.?? fork Thread 9 completed 4 loops.?? fork Thread 10 completed 4 loops.?? fork Thread 11 completed 5 loops.?? forktoomuch Thread 12 completed 6 loops.?? forktoomuch Thread 13 completed 7 loops.?? forktoomuch Thread 14 completed 6 loops.?? lock Thread 21 completed 1395 loops.?? lock Thread 22 completed 1613 loops.?? lock Thread 23 completed 2354 loops...........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 6 loops.?? read Thread 1 completed 13 loops.?? read Thread 2 completed 5 loops.?? nxread Thread 3 completed 8 loops.?? nxread Thread 4 completed 7 loops.?? nxread Thread 5 completed 10 loops.?? tryexcept Thread 6 completed 15350367 loops.?? tryexcept Thread 7 completed 22864059
 loops.?? tryexcept Thread 8 completed 14516795 loops.?? fork Thread 9 completed 6 loops.?? fork Thread 10 completed 7 loops.?? fork Thread 11 completed 6 loops.?? forktoomuch Thread 12 completed 8 loops.?? forktoomuch Thread 13 completed 9 loops.?? forktoomuch Thread 14 completed 8 loops.?? lock Thread 21 completed 3742 loops.?? lock Thread 22 completed 2342 loops.?? lock Thread 23 completed 3827 loops...........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 5 loops.?? read Thread 1 completed 10 loops.?? read Thread 2 completed 4 loops.?? nxread Thread 3 completed 5 loops.?? nxread Thread 4 completed 3 loops.?? nxread Thread 5 completed 4 loops.?? tryexcept Thread 6 completed 14205335 loops.?? tryexcept Thread 7 completed 23955466 loops.?? tryexcept Thread 8 completed 14597334 loops.?? fork Thread 9 completed 7 loops.??
 fork Thread 10 completed 6 loops.?? fork Thread 11 completed 7 loops.?? forktoomuch Thread 12 completed 8 loops.?? forktoomuch Thread 13 completed 9 loops.?? forktoomuch Thread 14 completed 8 loops.?? lock Thread 21 completed 1384 loops.?? lock Thread 22 completed 3801 loops.?? lock Thread 23 completed 4735 loops...........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 5 loops.?? read Thread 1 completed 9 loops.?? read Thread 2 completed 6 loops.?? nxread Thread 3 completed 5 loops.?? nxread Thread 4 completed 4 loops.?? nxread Thread 5 completed 9 loops.?? tryexcept Thread 6 completed 13962901 loops.?? tryexcept Thread 7 completed 22999610 loops.?? tryexcept Thread 8 completed 14123517 loops.?? fork Thread 9 completed 6 loops.?? fork Thread 10 completed 6 loops.?? fork Thread 11 completed 5 loops.?? forktoomuch Thread 12
 completed 7 loops.?? forktoomuch Thread 13 completed 8 loops.?? forktoomuch Thread 14 completed 8 loops.?? lock Thread 21 completed 1744 loops.?? lock Thread 22 completed 2095 loops.?? lock Thread 23 completed 1503 loops...........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 2 loops.?? read Thread 1 completed 6 loops.?? read Thread 2 completed 2 loops.?? nxread Thread 3 completed 3 loops.?? nxread Thread 4 completed 3 loops.? ?nxread Thread 5 completed 3 loops.?? tryexcept Thread 6 completed 15715885 loops.?? tryexcept Thread 7 completed 24769727 loops.?? tryexcept Thread 8 completed 15414675 loops.?? fork Thread 9 completed 7 loops.?? fork Thread 10 completed 6 loops.?? fork Thread 11 completed 7 loops.?? forktoomuch Thread 12 completed 8 loops.?? forktoomuch Thread 13 completed 8 loops.?? forktoomuch Thread 14 completed
 9 loops.?? lock Thread 21 completed 1523 loops.?? lock Thread 22 completed 1922 loops.?? lock Thread 23 completed 1204 loops...........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 5 loops.?? read Thread 1 completed 9 loops.?? read Thread 2 completed 6 loops.?? nxread Thread 3 completed 4 loops.?? nxread Thread 4 completed 2 loops.?? nxread Thread 5 completed 8 loops.?? tryexcept Thread 6 completed 14688224 loops.?? tryexcept Thread 7 completed 23710577 loops.?? tryexcept Thread 8 completed 15355622 loops.?? fork Thread 9 completed 6 loops.?? fork Thread 10 completed 7 loops.?? fork Thread 11 completed 6 loops.?? forktoomuch Thread 12 completed 8 loops.?? forktoomuch Thread 13 completed 9 loops.?? forktoomuch Thread 14 completed 7 loops.?? lock Thread 21 completed 9427 loops.?? lock Thread 22 completed 3941 loops.?? lock
 Thread 23 completed 4421 loops...........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 9 loops.?? read Thread 1 completed 11 loops.?? read Thread 2 completed 6 loops.?? nxread Thread 3 completed 7 loops.?? nxread Thread 4 completed 5 loops.?? nxread Thread 5 completed 9 loops.?? tryexcept Thread 6 completed 16315690 loops.?? tryexcept Thread 7 completed 25110147 loops.?? tryexcept Thread 8 completed 17291322 loops.?? fork Thread 9 completed 5 loops.?? fork Thread 10 completed 4 loops.?? fork Thread 11 completed 5 loops.? ?forktoomuch Thread 12 completed 8 loops.?? forktoomuch Thread 13 completed 9 loops.?? forktoomuch Thread 14 completed 8 loops.?? lock Thread 21 completed 1648 loops.?? lock Thread 22 completed 1274 loops.?? lock Thread 23 completed 975 loops...........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0
 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 2 loops.?? read Thread 1 completed 6 loops.?? read Thread 2 completed 3 loops.?? nxread Thread 3 completed 7 loops.?? nxread Thread 4 completed 4 loops.?? nxread Thread 5 completed 7 loops.?? tryexcept Thread 6 completed 16955552 loops.?? tryexcept Thread 7 completed 27781696 loops.?? tryexcept Thread 8 completed 16151561 loops.?? fork Thread 9 completed 4 loops.?? fork Thread 10 completed 3 loops.?? fork Thread 11 completed 2 loops.?? forktoomuch Thread 12 completed 7 loops.?? forktoomuch Thread 13 completed 7 loops.?? forktoomuch Thread 14 completed 7 loops.?? lock Thread 21 completed 2148 loops.?? lock Thread 22 completed 2179 loops.?? lock Thread 23 completed 1804 loops...........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 7 loops.??
 read Thread 1 completed 5 loops.?? read Thread 2 completed 4 loops.?? nxread Thread 3 completed 9 loops.?? nxread Thread 4 completed 6 loops.?? nxread Thread 5 completed 5 loops.?? tryexcept Thread 6 completed 14537433 loops.?? tryexcept Thread 7 completed 24043303 loops.?? tryexcept Thread 8 completed 14258976 loops.?? fork Thread 9 completed 6 loops.?? fork Thread 10 completed 7 loops.?? fork Thread 11 completed 6 loops.?? forktoomuch Thread 12 completed 8 loops.?? forktoomuch Thread 13 completed 8 loops.?? forktoomuch Thread 14 completed 8 loops.?? lock Thread 21 completed 6504 loops.?? lock Thread 22 completed 2290 loops.?? lock Thread 23 completed 7696 loops...........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 5 loops.?? read Thread 1 completed 6 loops.?? read Thread 2 completed 2 loops.?? nxread Thread 3 completed
 4 loops.?? nxread Thread 4 completed 1 loops.?? nxread Thread 5 completed 3 loops.?? tryexcept Thread 6 completed 17349384 loops.?? tryexcept Thread 7 completed 29845941 loops.?? tryexcept Thread 8 completed 17792587 loops.?? fork Thread 9 completed 5 loops.?? fork Thread 10 completed 5 loops.?? fork Thread 11 completed 6 loops.? ?forktoomuch Thread 12 completed 8 loops.?? forktoomuch Thread 13 completed 9 loops.?? forktoomuch Thread 14 completed 9 loops.?? lock Thread 21 completed 2692 loops.?? lock Thread 22 completed 4498 loops.?? lock Thread 23 completed 3600 loops.All tests complete.? Congratulations. ?C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386> ?Regards,Randy Coleburn ?


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110316/e17b3645/attachment-0001.html>

From hosking at cs.purdue.edu  Wed Mar 16 22:22:38 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 16 Mar 2011 17:22:38 -0400
Subject: [M3devel] another thread test run on NT386 32-bit using HEAD
	branch
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BDB06@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BDB06@atlex02-srv>
Message-ID: <0BEFC896-66CC-4441-8271-360FD0E3F59B@cs.purdue.edu>

Badness both places.  Not sure I see anything obvious from these dumps.

On Mar 16, 2011, at 2:54 PM, Coleburn, Randy wrote:

> Here are results from the following platform:
> IBM G40, Windows XP Professional, 32-bit
> Using current HEAD branch of CM3
>  
> Both of the runs below use @M3paranoidgc
>  
> Note on the second run using alloc and creat tests that I get an error about a thread trying to join twice.
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lock @M3paranoidgc
> Writing file...done
> Creating read threads...
>    read=0
>    read=1
>    read=2
> done
> Creating nxread threads...
>    nxread=3
>    nxread=4
>    nxread=5
> done
> Creating tryexcept threads...
>    tryexcept=6
>    tryexcept=7
>    tryexcept=8
> done
> Creating fork threads...
>    fork=9
>    fork=0
>    fork=11
> done
> Creating forktoomuch threads...
>    forktoomuch=12
>    forktoomuch=13
>    forktoomuch=14
> done
> Creating lock threads...
>    lock=21
>    lock=22
>    lock=23
> done
> running...printing oldest/median age/newest
> ....
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
> ***    pc = 0x4086a0 = Init + 0x79 in ..\src\rw\FileRd.m3
> ***
>  
> .Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0x107feb8   0x44536b  SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m3
> 0x107ff00   0x4086a0  Init + 0x79 in ..\src\rw\FileRd.m3
> 0x107ff2c   0x40861d  Open + 0x4d in ..\src\rw\FileRd.m3
> 0x107ff78   0x40173e  NApply + 0x124 in ..\src\Main.m3
> 0x107ffb4   0x42b56f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
> .........  .........  ... more frames ...
>  
>  
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests alloc,creat @M3paranoidgc
> Writing file...done
> Creating alloc threads...
>    alloc=15
>    alloc=16
>    alloc=17
> done
> Creating creat threads...
>    creat=18
>    creat=19
>    creat=20
> done
> running...printing oldest/median age/newest
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 11125 loops.
>    alloc Thread 16 completed 10472 loops.
>    alloc Thread 17 completed 9722 loops.
>    creat Thread 18 completed 84 loops.
>    creat Thread 19 completed 98 loops.
>    creat Thread 20 completed 96 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 14258 loops.
>    alloc Thread 16 completed 10791 loops.
>    alloc Thread 17 completed 11403 loops.
>    creat Thread 18 completed 111 loops.
>    creat Thread 19 completed 115 loops.
>    creat Thread 20 completed 121 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 13954 loops.
>    alloc Thread 16 completed 9547 loops.
>    alloc Thread 17 completed 10561 loops.
>    creat Thread 18 completed 115 loops.
>    creat Thread 19 completed 121 loops.
>    creat Thread 20 completed 125 loops.
> .
>  
> ***
> *** runtime error:
> ***    Thread client error: attempt to join with thread twice
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 688
> ***
>  
> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0x127fedc   0x42c3ee  Die + 0x2a in ..\src\thread\WIN32\ThreadWin32.m3
> 0x127ff10   0x42b882  XJoin + 0x3c in ..\src\thread\WIN32\ThreadWin32.m3
> 0x127ff38   0x42ba06  Join + 0x46 in ..\src\thread\WIN32\ThreadWin32.m3
> 0x127ff78   0x402777  CApply + 0x12d in ..\src\Main.m3
> 0x127ffb4   0x42b56f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
> .........  .........  ... more frames ...
>  
>  
> Regards,
> Randy Coleburn
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110316/56759756/attachment-0001.html>

From hosking at cs.purdue.edu  Wed Mar 16 22:25:25 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 16 Mar 2011 17:25:25 -0400
Subject: [M3devel] thread tests on NT386 32-bit circa 2008,
	not good so far
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BDAF8@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BDAF8@atlex02-srv>
Message-ID: <B579D06A-BA7D-4739-9954-3B8A4E358AAD@cs.purdue.edu>

I don't remember how stable the collector was at that point.  Running them with @M3nogc indicates there were problems with it.
Now, what happens with the current trunk head when run with @M3nogc?

On Mar 16, 2011, at 2:42 PM, Coleburn, Randy wrote:

> I?ve gone back to a CM3 built on June 21, 2008.
> Platform is IBM ThinkPad T60, Windows XP Professional, 32-bit.
>  
> If I try to put the ?@M3paranoidgc? option on the command line, the thread test program always crashes, even before it reports anything about creating the threads.
>  
> ?read?, ?nxread?, ?tryexcept?, ?fork?, ?forktoomuch?, and ?lock? tests seem to succeed.
>  
> ?creat? and ?alloc? seem to hang the program on the first iteration.  I see one ?.? printed and nothing else.  Have to CTRL-C abort.
> BUT, if you run them with ?@M3nogc? they will run until we run out of memory.  Tony, does this give any hint as to what may be wrong?
>  
> Output of the various runs is shown below:
>  
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read @M3paranoidgc
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
> ***    pc = 0x42fb8c = AllocTraced + 0x3e in ..\src\runtime\common\RTCollector.m3
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 845
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 845
> ***
>  
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests alloc
> Writing file...done
> Creating alloc threads...
>    alloc=15
>    alloc=16
>    alloc=17
> done
> running...printing oldest/median age/newest
> .^C
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests creat
> Writing file...done
> Creating creat threads...
>    creat=18
>    creat=19
>    creat=20
> done
> running...printing oldest/median age/newest
> .^C
>  
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests creat,alloc @M3nogc
> Writing file...done
> Creating alloc threads...
>    alloc=15
>    alloc=16
>    alloc=17
> done
> Creating creat threads...
>    creat=18
>    creat=19
>    creat=20
> done
> running...printing oldest/median age/newest
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 29204 loops.
>    alloc Thread 16 completed 38868 loops.
>    alloc Thread 17 completed 29118 loops.
>    creat Thread 18 completed 111114 loops.
>    creat Thread 19 completed 114913 loops.
>    creat Thread 20 completed 108555 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 6968 loops.
>    alloc Thread 16 completed 6747 loops.
>    alloc Thread 17 completed 6331 loops.
>    creat Thread 18 completed 40626 loops.
>    creat Thread 19 completed 46526 loops.
>    creat Thread 20 completed 43511 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 4857 loops.
>    alloc Thread 16 completed 5409 loops.
>    alloc Thread 17 completed 4601 loops.
>    creat Thread 18 completed 50836 loops.
>    creat Thread 19 completed 50108 loops.
>    creat Thread 20 completed 53645 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 6249 loops.
>    alloc Thread 16 completed 7252 loops.
>    alloc Thread 17 completed 6770 loops.
>    creat Thread 18 completed 62606 loops.
>    creat Thread 19 completed 66036 loops.
>    creat Thread 20 completed 62561 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 7000 loops.
>    alloc Thread 16 completed 7559 loops.
>    alloc Thread 17 completed 7389 loops.
>    creat Thread 18 completed 66873 loops.
>    creat Thread 19 completed 81612 loops.
>    creat Thread 20 completed 62607 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 6666 loops.
>    alloc Thread 16 completed 7579 loops.
>    alloc Thread 17 completed 6964 loops.
>    creat Thread 18 completed 89667 loops.
>    creat Thread 19 completed 90794 loops.
>    creat Thread 20 completed 90528 loops.
> .....
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
> ***    file "..\src\runtime\common\RTCollector.m3", line 1545
> ***
>  
> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0x4e7fe34   0x430197  LongAlloc + 0x89 in ..\src\runtime\common\RTCollector.m3
> 0x4e7fe90   0x42fd06  AllocTraced + 0x1b8 in ..\src\runtime\common\RTCollector.m3
> 0x4e7fed4   0x427ea9  GetOpenArray + 0x80 in ..\src\runtime\common\RTAllocator.m3
> 0x4e7fef8   0x427738  AllocateOpenArray + 0x19 in ..\src\runtime\common\RTAllocator.m3
> 0x4e7ff50   0x402293  AApply + 0x109 in ..\src\Main.m3
> 0x4e7ff88   0x42a34a  RunThread + 0x1f6 in ..\src\thread\WIN32\ThreadWin32.m3
> 0x4e7ffb4   0x42a0e3  ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3
> .........  .........  ... more frames ...
>  
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lock
> Writing file...done
> Creating read threads...
>    read=0
>    read=1
>    read=2
> done
> Creating nxread threads...
>    nxread=3
>    nxread=4
>    nxread=5
> done
> Creating tryexcept threads...
>    tryexcept=6
>    tryexcept=7
>    tryexcept=8
> done
> Creating fork threads...
>    fork=9
>    fork=0
>    fork=11
> done
> Creating forktoomuch threads...
>    forktoomuch=12
>    forktoomuch=13
>    forktoomuch=14
> done
> Creating lock threads...
>    lock=21
>    lock=22
>    lock=23
> done
> running...printing oldest/median age/newest
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 2 loops.
>    read Thread 1 completed 6 loops.
>    read Thread 2 completed 4 loops.
>    nxread Thread 3 completed 3 loops.
>    nxread Thread 4 completed 1 loops.
>    nxread Thread 5 completed 3 loops.
>    tryexcept Thread 6 completed 14293296 loops.
>    tryexcept Thread 7 completed 23332343 loops.
>    tryexcept Thread 8 completed 14563267 loops.
>    fork Thread 9 completed 4 loops.
>    fork Thread 10 completed 4 loops.
>    fork Thread 11 completed 5 loops.
>    forktoomuch Thread 12 completed 6 loops.
>    forktoomuch Thread 13 completed 7 loops.
>    forktoomuch Thread 14 completed 6 loops.
>    lock Thread 21 completed 1395 loops.
>    lock Thread 22 completed 1613 loops.
>    lock Thread 23 completed 2354 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 6 loops.
>    read Thread 1 completed 13 loops.
>    read Thread 2 completed 5 loops.
>    nxread Thread 3 completed 8 loops.
>    nxread Thread 4 completed 7 loops.
>    nxread Thread 5 completed 10 loops.
>    tryexcept Thread 6 completed 15350367 loops.
>    tryexcept Thread 7 completed 22864059 loops.
>    tryexcept Thread 8 completed 14516795 loops.
>    fork Thread 9 completed 6 loops.
>    fork Thread 10 completed 7 loops.
>    fork Thread 11 completed 6 loops.
>    forktoomuch Thread 12 completed 8 loops.
>    forktoomuch Thread 13 completed 9 loops.
>    forktoomuch Thread 14 completed 8 loops.
>    lock Thread 21 completed 3742 loops.
>    lock Thread 22 completed 2342 loops.
>    lock Thread 23 completed 3827 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 5 loops.
>    read Thread 1 completed 10 loops.
>    read Thread 2 completed 4 loops.
>    nxread Thread 3 completed 5 loops.
>    nxread Thread 4 completed 3 loops.
>    nxread Thread 5 completed 4 loops.
>    tryexcept Thread 6 completed 14205335 loops.
>    tryexcept Thread 7 completed 23955466 loops.
>    tryexcept Thread 8 completed 14597334 loops.
>    fork Thread 9 completed 7 loops.
>    fork Thread 10 completed 6 loops.
>    fork Thread 11 completed 7 loops.
>    forktoomuch Thread 12 completed 8 loops.
>    forktoomuch Thread 13 completed 9 loops.
>    forktoomuch Thread 14 completed 8 loops.
>    lock Thread 21 completed 1384 loops.
>    lock Thread 22 completed 3801 loops.
>    lock Thread 23 completed 4735 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 5 loops.
>    read Thread 1 completed 9 loops.
>    read Thread 2 completed 6 loops.
>    nxread Thread 3 completed 5 loops.
>    nxread Thread 4 completed 4 loops.
>    nxread Thread 5 completed 9 loops.
>    tryexcept Thread 6 completed 13962901 loops.
>    tryexcept Thread 7 completed 22999610 loops.
>    tryexcept Thread 8 completed 14123517 loops.
>    fork Thread 9 completed 6 loops.
>    fork Thread 10 completed 6 loops.
>    fork Thread 11 completed 5 loops.
>    forktoomuch Thread 12 completed 7 loops.
>    forktoomuch Thread 13 completed 8 loops.
>    forktoomuch Thread 14 completed 8 loops.
>    lock Thread 21 completed 1744 loops.
>    lock Thread 22 completed 2095 loops.
>    lock Thread 23 completed 1503 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 2 loops.
>    read Thread 1 completed 6 loops.
>    read Thread 2 completed 2 loops.
>    nxread Thread 3 completed 3 loops.
>    nxread Thread 4 completed 3 loops.
>    nxread Thread 5 completed 3 loops.
>    tryexcept Thread 6 completed 15715885 loops.
>    tryexcept Thread 7 completed 24769727 loops.
>    tryexcept Thread 8 completed 15414675 loops.
>    fork Thread 9 completed 7 loops.
>    fork Thread 10 completed 6 loops.
>    fork Thread 11 completed 7 loops.
>    forktoomuch Thread 12 completed 8 loops.
>    forktoomuch Thread 13 completed 8 loops.
>    forktoomuch Thread 14 completed 9 loops.
>    lock Thread 21 completed 1523 loops.
>    lock Thread 22 completed 1922 loops.
>    lock Thread 23 completed 1204 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 5 loops.
>    read Thread 1 completed 9 loops.
>    read Thread 2 completed 6 loops.
>    nxread Thread 3 completed 4 loops.
>    nxread Thread 4 completed 2 loops.
>    nxread Thread 5 completed 8 loops.
>    tryexcept Thread 6 completed 14688224 loops.
>    tryexcept Thread 7 completed 23710577 loops.
>    tryexcept Thread 8 completed 15355622 loops.
>    fork Thread 9 completed 6 loops.
>    fork Thread 10 completed 7 loops.
>    fork Thread 11 completed 6 loops.
>    forktoomuch Thread 12 completed 8 loops.
>    forktoomuch Thread 13 completed 9 loops.
>    forktoomuch Thread 14 completed 7 loops.
>    lock Thread 21 completed 9427 loops.
>    lock Thread 22 completed 3941 loops.
>    lock Thread 23 completed 4421 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 9 loops.
>    read Thread 1 completed 11 loops.
>    read Thread 2 completed 6 loops.
>    nxread Thread 3 completed 7 loops.
>    nxread Thread 4 completed 5 loops.
>    nxread Thread 5 completed 9 loops.
>    tryexcept Thread 6 completed 16315690 loops.
>    tryexcept Thread 7 completed 25110147 loops.
>    tryexcept Thread 8 completed 17291322 loops.
>    fork Thread 9 completed 5 loops.
>    fork Thread 10 completed 4 loops.
>    fork Thread 11 completed 5 loops.
>    forktoomuch Thread 12 completed 8 loops.
>    forktoomuch Thread 13 completed 9 loops.
>    forktoomuch Thread 14 completed 8 loops.
>    lock Thread 21 completed 1648 loops.
>    lock Thread 22 completed 1274 loops.
>    lock Thread 23 completed 975 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 2 loops.
>    read Thread 1 completed 6 loops.
>    read Thread 2 completed 3 loops.
>    nxread Thread 3 completed 7 loops.
>    nxread Thread 4 completed 4 loops.
>    nxread Thread 5 completed 7 loops.
>    tryexcept Thread 6 completed 16955552 loops.
>    tryexcept Thread 7 completed 27781696 loops.
>    tryexcept Thread 8 completed 16151561 loops.
>    fork Thread 9 completed 4 loops.
>    fork Thread 10 completed 3 loops.
>    fork Thread 11 completed 2 loops.
>    forktoomuch Thread 12 completed 7 loops.
>    forktoomuch Thread 13 completed 7 loops.
>    forktoomuch Thread 14 completed 7 loops.
>    lock Thread 21 completed 2148 loops.
>    lock Thread 22 completed 2179 loops.
>    lock Thread 23 completed 1804 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 7 loops.
>    read Thread 1 completed 5 loops.
>    read Thread 2 completed 4 loops.
>    nxread Thread 3 completed 9 loops.
>    nxread Thread 4 completed 6 loops.
>    nxread Thread 5 completed 5 loops.
>    tryexcept Thread 6 completed 14537433 loops.
>    tryexcept Thread 7 completed 24043303 loops.
>    tryexcept Thread 8 completed 14258976 loops.
>    fork Thread 9 completed 6 loops.
>    fork Thread 10 completed 7 loops.
>    fork Thread 11 completed 6 loops.
>    forktoomuch Thread 12 completed 8 loops.
>    forktoomuch Thread 13 completed 8 loops.
>    forktoomuch Thread 14 completed 8 loops.
>    lock Thread 21 completed 6504 loops.
>    lock Thread 22 completed 2290 loops.
>    lock Thread 23 completed 7696 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 5 loops.
>    read Thread 1 completed 6 loops.
>    read Thread 2 completed 2 loops.
>    nxread Thread 3 completed 4 loops.
>    nxread Thread 4 completed 1 loops.
>    nxread Thread 5 completed 3 loops.
>    tryexcept Thread 6 completed 17349384 loops.
>    tryexcept Thread 7 completed 29845941 loops.
>    tryexcept Thread 8 completed 17792587 loops.
>    fork Thread 9 completed 5 loops.
>    fork Thread 10 completed 5 loops.
>    fork Thread 11 completed 6 loops.
>    forktoomuch Thread 12 completed 8 loops.
>    forktoomuch Thread 13 completed 9 loops.
>    forktoomuch Thread 14 completed 9 loops.
>    lock Thread 21 completed 2692 loops.
>    lock Thread 22 completed 4498 loops.
>    lock Thread 23 completed 3600 loops.
> All tests complete.  Congratulations.
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>
>  
> Regards,
> Randy Coleburn
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110316/6a0a5098/attachment-0001.html>

From rcolebur at SCIRES.COM  Wed Mar 16 23:34:53 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Wed, 16 Mar 2011 18:34:53 -0400
Subject: [M3devel] thread tests on NT386 32-bt
In-Reply-To: <B579D06A-BA7D-4739-9954-3B8A4E358AAD@cs.purdue.edu>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BDAF8@atlex02-srv>
	<B579D06A-BA7D-4739-9954-3B8A4E358AAD@cs.purdue.edu>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E603418BDB96@atlex02-srv>

Tony asked:
I don't remember how stable the collector was at that point.  Running them with @M3nogc indicates there were problems with it.
Now, what happens with the current trunk head when run with @M3nogc?
Here you go:

The alloc & create tests ran 9 iterations before running out of memory.

The other tests ran to completion.

See below (these tests run on IBM G40, XP Pro, 32-bit, against current HEAD branch):

C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests alloc,creat @M3nogc
Writing file...done
Creating alloc threads...
   alloc=15
   alloc=16
   alloc=17
done
Creating creat threads...
   creat=18
   creat=19
   creat=20
done
running...printing oldest/median age/newest
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 32400 loops.
   alloc Thread 16 completed 48840 loops.
   alloc Thread 17 completed 36525 loops.
   creat Thread 18 completed 25 loops.
   creat Thread 19 completed 28 loops.
   creat Thread 20 completed 27 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 5850 loops.
   alloc Thread 16 completed 8310 loops.
   alloc Thread 17 completed 8910 loops.
   creat Thread 18 completed 19 loops.
   creat Thread 19 completed 20 loops.
   creat Thread 20 completed 21 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 8505 loops.
   alloc Thread 16 completed 11805 loops.
   alloc Thread 17 completed 13170 loops.
   creat Thread 18 completed 27 loops.
   creat Thread 19 completed 26 loops.
   creat Thread 20 completed 27 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 7035 loops.
   alloc Thread 16 completed 13080 loops.
   alloc Thread 17 completed 5010 loops.
   creat Thread 18 completed 19 loops.
   creat Thread 19 completed 21 loops.
   creat Thread 20 completed 19 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 10260 loops.
   alloc Thread 16 completed 5445 loops.
  alloc Thread 17 completed 6390 loops.
   creat Thread 18 completed 21 loops.
   creat Thread 19 completed 23 loops.
   creat Thread 20 completed 23 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 3240 loops.
   alloc Thread 16 completed 12405 loops.
   alloc Thread 17 completed 6975 loops.
   creat Thread 18 completed 24 loops.
   creat Thread 19 completed 25 loops.
   creat Thread 20 completed 23 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 7410 loops.
   alloc Thread 16 completed 6090 loops.
   alloc Thread 17 completed 8670 loops.
   creat Thread 18 completed 17 loops.
   creat Thread 19 completed 17 loops.
   creat Thread 20 completed 17 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 6105 loops.
   alloc Thread 16 completed 7425 loops.
   alloc Thread 17 completed 10155 loops.
   creat Thread 18 completed 14 loops.
   creat Thread 19 completed 17 loops.
   creat Thread 20 completed 17 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 17160 loops.
   alloc Thread 16 completed 13365 loops.
   alloc Thread 17 completed 13785 loops.
   creat Thread 18 completed 17 loops.
   creat Thread 19 completed 16 loops.
   creat Thread 20 completed 17 loops.
......

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.
***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***
.
***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0xf7fefc   0x44c572  Raise + 0x3f in ..\src\runtime\common\RuntimeError.m3
0xf7ff1c   0x428712  AllocateOpenArray + 0x33 in ..\src\runtime\common\RTAllocator.m3
0xf7ff78   0x402430  AApply + 0x128 in ..\src\Main.m3
0xf7ffb4   0x42b56f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
.........  .........  ... more frames ...



C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lock @M3nogc
Writing file...done
Creating read threads...
   read=0
   read=1
   read=2
done
Creating nxread threads...
   nxread=3
   nxread=4
   nxread=5
done
Creating tryexcept threads...
   tryexcept=6
   tryexcept=7
   tryexcept=8
done
Creating fork threads...
   fork=9
   fork=0
   fork=11
done
Creating forktoomuch threads...
   forktoomuch=12
   forktoomuch=13
   forktoomuch=14
done
Creating lock threads...
   lock=21
   lock=22
   lock=23
done
running...printing oldest/median age/newest
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 98 loops.
   read Thread 1 completed 101 loops.
   read Thread 2 completed 98 loops.
   nxread Thread 3 completed 63 loops.
   nxread Thread 4 completed 64 loops.
   nxread Thread 5 completed 64 loops.
   tryexcept Thread 6 completed 1106827 loops.
   tryexcept Thread 7 completed 1056963 loops.
   tryexcept Thread 8 completed 1124363 loops.
   fork Thread 9 completed 3 loops.
   fork Thread 10 completed 3 loops.
   fork Thread 11 completed 3 loops.
   forktoomuch Thread 12 completed 5 loops.
   forktoomuch Thread 13 completed 5 loops.
   forktoomuch Thread 14 completed 4 loops.
   lock Thread 21 completed 902314 loops.
   lock Thread 22 completed 873503 loops.
   lock Thread 23 completed 946840 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 108 loops.
   read Thread 1 completed 105 loops.
   read Thread 2 completed 108 loops.
   nxread Thread 3 completed 68 loops.
   nxread Thread 4 completed 70 loops.
   nxread Thread 5 completed 67 loops.
   tryexcept Thread 6 completed 1197135 loops.
   tryexcept Thread 7 completed 1248635 loops.
   tryexcept Thread 8 completed 1263743 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 4 loops.
   forktoomuch Thread 12 completed 6 loops.
   forktoomuch Thread 13 completed 7 loops.
   forktoomuch Thread 14 completed 7 loops.
   lock Thread 21 completed 1156474 loops.
   lock Thread 22 completed 1007509 loops.
   lock Thread 23 completed 1072164 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 91 loops.
   read Thread 1 completed 101 loops.
   read Thread 2 completed 99 loops.
   nxread Thread 3 completed 67 loops.
   nxread Thread 4 completed 63 loops.
   nxread Thread 5 completed 64 loops.
   tryexcept Thread 6 completed 1212286 loops.
   tryexcept Thread 7 completed 1115613 loops.
   tryexcept Thread 8 completed 1124737 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 5 loops.
   fork Thread 11 completed 4 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 8 loops.
   forktoomuch Thread 14 completed 7 loops.
   lock Thread 21 completed 1058176 loops.
   lock Thread 22 completed 979426 loops.
   lock Thread 23 completed 1068972 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 103 loops.
   read Thread 1 completed 105 loops.
   read Thread 2 completed 105 loops.
   nxread Thread 3 completed 63 loops.
   nxread Thread 4 completed 63 loops.
   nxread Thread 5 completed 61 loops.
   tryexcept Thread 6 completed 1132672 loops.
   tryexcept Thread 7 completed 1186707 loops.
   tryexcept Thread 8 completed 1136861 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 4 loops.
   forktoomuch Thread 12 completed 6 loops.
   forktoomuch Thread 13 completed 6 loops.
   forktoomuch Thread 14 completed 7 loops.
   lock Thread 21 completed 794204 loops.
   lock Thread 22 completed 1171670 loops.
   lock Thread 23 completed 992164 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 88 loops.
   read Thread 1 completed 93 loops.
   read Thread 2 completed 105 loops.
   nxread Thread 3 completed 60 loops.
   nxread Thread 4 completed 63 loops.
   nxread Thread 5 completed 64 loops.
   tryexcept Thread 6 completed 1213622 loops.
   tryexcept Thread 7 completed 1169506 loops.
   tryexcept Thread 8 completed 1220576 loops.
   fork Thread 9 completed 3 loops.
   fork Thread 10 completed 3 loops.
   fork Thread 11 completed 3 loops.
   forktoomuch Thread 12 completed 5 loops.
   forktoomuch Thread 13 completed 6 loops.
   forktoomuch Thread 14 completed 6 loops.
   lock Thread 21 completed 947532 loops.
   lock Thread 22 completed 1046220 loops.
   lock Thread 23 completed 886815 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 104 loops.
   read Thread 1 completed 104 loops.
   read Thread 2 completed 104 loops.
   nxread Thread 3 completed 69 loops.
   nxread Thread 4 completed 68 loops.
   nxread Thread 5 completed 68 loops.
   tryexcept Thread 6 completed 1225537 loops.
   tryexcept Thread 7 completed 1158824 loops.
   tryexcept Thread 8 completed 1185900 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 5 loops.
   fork Thread 11 completed 4 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 7 loops.
   forktoomuch Thread 14 completed 6 loops.
   lock Thread 21 completed 1116802 loops.
   lock Thread 22 completed 1028306 loops.
   lock Thread 23 completed 1130454 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 107 loops.
   read Thread 1 completed 110 loops.
   read Thread 2 completed 112 loops.
   nxread Thread 3 completed 63 loops.
   nxread Thread 4 completed 63 loops.
   nxread Thread 5 completed 63 loops.
   tryexcept Thread 6 completed 1156252 loops.
   tryexcept Thread 7 completed 1094847 loops.
   tryexcept Thread 8 completed 1199661 loops.
   fork Thread 9 completed 3 loops.
   fork Thread 10 completed 3 loops.
   fork Thread 11 completed 4 loops.
   forktoomuch Thread 12 completed 7 loops.
   forktoomuch Thread 13 completed 7 loops.
   forktoomuch Thread 14 completed 7 loops.
   lock Thread 21 completed 746279 loops.
   lock Thread 22 completed 1069667 loops.
   lock Thread 23 completed 1045028 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 98 loops.
   read Thread 1 completed 99 loops.
   read Thread 2 completed 96 loops.
   nxread Thread 3 completed 64 loops.
   nxread Thread 4 completed 60 loops.
   nxread Thread 5 completed 63 loops.
   tryexcept Thread 6 completed 1185205 loops.
   tryexcept Thread 7 completed 1175381 loops.
   tryexcept Thread 8 completed 1114031 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 5 loops.
   fork Thread 11 completed 4 loops.
   forktoomuch Thread 12 completed 6 loops.
   forktoomuch Thread 13 completed 7 loops.
   forktoomuch Thread 14 completed 6 loops.
   lock Thread 21 completed 1053691 loops.
   lock Thread 22 completed 1009143 loops.
   lock Thread 23 completed 966082 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 111 loops.
   read Thread 1 completed 110 loops.
   read Thread 2 completed 101 loops.
   nxread Thread 3 completed 64 loops.
   nxread Thread 4 completed 65 loops.
   nxread Thread 5 completed 64 loops.
   tryexcept Thread 6 completed 1130609 loops.
   tryexcept Thread 7 completed 1160042 loops.
   tryexcept Thread 8 completed 1110365 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 5 loops.
   forktoomuch Thread 12 completed 7 loops.
   forktoomuch Thread 13 completed 7 loops.
   forktoomuch Thread 14 completed 7 loops.
   lock Thread 21 completed 682298 loops.
   lock Thread 22 completed 1124977 loops.
   lock Thread 23 completed 960154 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 62 loops.
   read Thread 1 completed 65 loops.
   read Thread 2 completed 62 loops.
   nxread Thread 3 completed 45 loops.
   nxread Thread 4 completed 42 loops.
   nxread Thread 5 completed 42 loops.
   tryexcept Thread 6 completed 1569234 loops.
   tryexcept Thread 7 completed 1553679 loops.
   tryexcept Thread 8 completed 1511503 loops.
   fork Thread 9 completed 1 loops.
   fork Thread 10 completed 2 loops.
   fork Thread 11 completed 2 loops.
   forktoomuch Thread 12 completed 4 loops.
   forktoomuch Thread 13 completed 4 loops.
   forktoomuch Thread 14 completed 4 loops.
   lock Thread 21 completed 1311441 loops.
   lock Thread 22 completed 1309196 loops.
   lock Thread 23 completed 1418347 loops.
All tests complete.  Congratulations.

C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>

Regards,
Randy Coleburn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110316/7fb37fc9/attachment-0001.html>

From rcolebur at SCIRES.COM  Wed Mar 16 23:50:55 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Wed, 16 Mar 2011 18:50:55 -0400
Subject: [M3devel] thread test results on Win7 64-bit
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E603418BDB9C@atlex02-srv>

Here are thread test results for Dell Latitude E6510, Windows 7, 64-bit, against current HEAD branch.
I ran each set 3 times:  no @M3 directive, @M3paranoidgc, and @M3nogc
Note 3rd run where the fork thread shows being starved during first iteration, but test did run to completion using @M3nogc.


C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lock
Writing file...done
Creating read threads...
   read=0
   read=1
   read=2
done
Creating nxread threads...
   nxread=3
   nxread=4
   nxread=5
done
Creating tryexcept threads...
   tryexcept=6
   tryexcept=7
   tryexcept=8
done
Creating fork threads...
   fork=9
   fork=0
   fork=11
done
Creating forktoomuch threads...
   forktoomuch=12
   forktoomuch=13
   forktoomuch=14
done
Creating lock threads...
   lock=21
   lock=22
   lock=23
done
running...printing oldest/median age/newest
.

***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\rw\FileRd.m3", line 83
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0xaafa68  0x1198d68  Seek + 0x454 in ..\src\rw\FileRd.m3
0xaafa94  0x119a836  FastEOF + 0xc9 in ..\src\rw\Rd.m3
0xaafabc  0x119a72c  EOF + 0x48 in ..\src\rw\Rd.m3
0xaafb08  0x119176e  NApply + 0x154 in ..\src\Main.m3
0xaafb44  0x11bb56f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
0xaafb50  0x75c53677  <???>
0xaafb90  0x77e39f02  <???>
.........  .........  ... more frames ...


C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lock @M3paranoidgc
Writing file...done
Creating read threads...
   read=0
   read=1
   read=2
done
Creating nxread threads...
   nxread=3
   nxread=4
   nxread=5
done
Creating tryexcept threads...
   tryexcept=6
   tryexcept=7
   tryexcept=8
done
Creating fork threads...
   fork=9
   fork=0
   fork=11
done
Creating forktoomuch threads...
   forktoomuch=12
   forktoomuch=13
   forktoomuch=14
done
Creating lock threads...
   lock=21
   lock=22
   lock=23
done
running...printing oldest/median age/newest
.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0x11986a0 = Init + 0x79 in ..\src\rw\FileRd.m3
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x84fb48  0x11d537b  SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m3
0x84fb90  0x11986a0  Init + 0x79 in ..\src\rw\FileRd.m3
0x84fbbc  0x119861d  Open + 0x4d in ..\src\rw\FileRd.m3
0x84fcf4  0x1191360  RApply + 0x160 in ..\src\Main.m3
0x84fd30  0x11bb56f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
0x84fd3c  0x75c53677  <???>
0x84fd7c  0x77e39f02  <???>
.........  .........  ... more frames ...


C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lock @M3nogc
Writing file...done
Creating read threads...
   read=0
   read=1
   read=2
done
Creating nxread threads...
   nxread=3
   nxread=4
   nxread=5
done
Creating tryexcept threads...
   tryexcept=6
   tryexcept=7
   tryexcept=8
done
Creating fork threads...
   fork=9
   fork=0
   fork=11
done
Creating forktoomuch threads...
   forktoomuch=12
   forktoomuch=13
   forktoomuch=14
done
Creating lock threads...
   lock=21
   lock=22
   lock=23
done
running...printing oldest/median age/newest
..........laziest thread is 0/0/-2 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork -2/-2/-2 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 113 loops.
   read Thread 1 completed 45 loops.
   read Thread 2 completed 56 loops.
   nxread Thread 3 completed 48 loops.
   nxread Thread 4 completed 50 loops.
   nxread Thread 5 completed 41 loops.
   tryexcept Thread 6 completed 19499179 loops.
   tryexcept Thread 7 completed 15275763 loops.
   tryexcept Thread 8 completed 22671986 loops.
fork Thread 9 appears starved or deadlocked !!!
fork Thread 10 appears starved or deadlocked !!!
fork Thread 11 appears starved or deadlocked !!!
   forktoomuch Thread 12 completed 5 loops.
   forktoomuch Thread 13 completed 5 loops.
   forktoomuch Thread 14 completed 5 loops.
   lock Thread 21 completed 9512206 loops.
   lock Thread 22 completed 6619988 loops.
   lock Thread 23 completed 7547029 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 81 loops.
   read Thread 1 completed 71 loops.
   read Thread 2 completed 89 loops.
   nxread Thread 3 completed 66 loops.
   nxread Thread 4 completed 40 loops.
   nxread Thread 5 completed 36 loops.
   tryexcept Thread 6 completed 19628784 loops.
   tryexcept Thread 7 completed 22393679 loops.
   tryexcept Thread 8 completed 19328247 loops.
   fork Thread 9 completed 3 loops.
   fork Thread 10 completed 2 loops.
   fork Thread 11 completed 1 loops.
   forktoomuch Thread 12 completed 5 loops.
   forktoomuch Thread 13 completed 6 loops.
   forktoomuch Thread 14 completed 5 loops.
   lock Thread 21 completed 10152547 loops.
   lock Thread 22 completed 7780818 loops.
   lock Thread 23 completed 8156000 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 151 loops.
   read Thread 1 completed 114 loops.
   read Thread 2 completed 198 loops.
   nxread Thread 3 completed 81 loops.
   nxread Thread 4 completed 102 loops.
   nxread Thread 5 completed 65 loops.
   tryexcept Thread 6 completed 16242018 loops.
   tryexcept Thread 7 completed 18541779 loops.
   tryexcept Thread 8 completed 23687938 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 5 loops.
   fork Thread 11 completed 4 loops.
   forktoomuch Thread 12 completed 7 loops.
   forktoomuch Thread 13 completed 8 loops.
   forktoomuch Thread 14 completed 7 loops.
   lock Thread 21 completed 6189375 loops.
   lock Thread 22 completed 12637746 loops.
   lock Thread 23 completed 6191441 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 158 loops.
   read Thread 1 completed 111 loops.
   read Thread 2 completed 210 loops.
   nxread Thread 3 completed 80 loops.
   nxread Thread 4 completed 107 loops.
   nxread Thread 5 completed 77 loops.
   tryexcept Thread 6 completed 27811791 loops.
   tryexcept Thread 7 completed 14614651 loops.
   tryexcept Thread 8 completed 14962432 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 5 loops.
   forktoomuch Thread 12 completed 9 loops.
   forktoomuch Thread 13 completed 8 loops.
   forktoomuch Thread 14 completed 9 loops.
   lock Thread 21 completed 6021783 loops.
   lock Thread 22 completed 11487180 loops.
   lock Thread 23 completed 6730226 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 85 loops.
   read Thread 1 completed 75 loops.
   read Thread 2 completed 85 loops.
   nxread Thread 3 completed 50 loops.
   nxread Thread 4 completed 58 loops.
   nxread Thread 5 completed 67 loops.
   tryexcept Thread 6 completed 28345540 loops.
   tryexcept Thread 7 completed 14693468 loops.
   tryexcept Thread 8 completed 17065423 loops.
   fork Thread 9 completed 5 loops.
   fork Thread 10 completed 6 loops.
   fork Thread 11 completed 5 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 9 loops.
   forktoomuch Thread 14 completed 8 loops.
   lock Thread 21 completed 6621257 loops.
   lock Thread 22 completed 10815327 loops.
   lock Thread 23 completed 8437962 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 174 loops.
   read Thread 1 completed 133 loops.
   read Thread 2 completed 202 loops.
   nxread Thread 3 completed 85 loops.
   nxread Thread 4 completed 110 loops.
   nxread Thread 5 completed 72 loops.
   tryexcept Thread 6 completed 23348157 loops.
   tryexcept Thread 7 completed 14374032 loops.
   tryexcept Thread 8 completed 19940269 loops.
   fork Thread 9 completed 5 loops.
   fork Thread 10 completed 5 loops.
   fork Thread 11 completed 5 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 8 loops.
   forktoomuch Thread 14 completed 8 loops.
   lock Thread 21 completed 7341139 loops.
   lock Thread 22 completed 10330530 loops.
   lock Thread 23 completed 6812041 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 26 loops.
   read Thread 1 completed 32 loops.
   read Thread 2 completed 36 loops.
   nxread Thread 3 completed 38 loops.
   nxread Thread 4 completed 24 loops.
   nxread Thread 5 completed 27 loops.
   tryexcept Thread 6 completed 17115144 loops.
   tryexcept Thread 7 completed 19179208 loops.
   tryexcept Thread 8 completed 25222246 loops.
   fork Thread 9 completed 5 loops.
   fork Thread 10 completed 6 loops.
   fork Thread 11 completed 5 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 9 loops.
   forktoomuch Thread 14 completed 9 loops.
   lock Thread 21 completed 10391588 loops.
   lock Thread 22 completed 7466890 loops.
   lock Thread 23 completed 8045330 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 68 loops.
   read Thread 1 completed 78 loops.
   read Thread 2 completed 87 loops.
   nxread Thread 3 completed 55 loops.
   nxread Thread 4 completed 49 loops.
   nxread Thread 5 completed 49 loops.
   tryexcept Thread 6 completed 23843674 loops.
   tryexcept Thread 7 completed 23476782 loops.
   tryexcept Thread 8 completed 15668116 loops.
   fork Thread 9 completed 5 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 5 loops.
   forktoomuch Thread 12 completed 9 loops.
   forktoomuch Thread 13 completed 8 loops.
   forktoomuch Thread 14 completed 9 loops.
   lock Thread 21 completed 7504169 loops.
   lock Thread 22 completed 9868443 loops.
  lock Thread 23 completed 8893786 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 191 loops.
   read Thread 1 completed 181 loops.
   read Thread 2 completed 256 loops.
   nxread Thread 3 completed 100 loops.
   nxread Thread 4 completed 116 loops.
   nxread Thread 5 completed 110 loops.
   tryexcept Thread 6 completed 25424753 loops.
   tryexcept Thread 7 completed 16145782 loops.
   tryexcept Thread 8 completed 18178878 loops.
   fork Thread 9 completed 5 loops.
   fork Thread 10 completed 5 loops.
   fork Thread 11 completed 4 loops.
   forktoomuch Thread 12 completed 9 loops.
   forktoomuch Thread 13 completed 9 loops.
   forktoomuch Thread 14 completed 8 loops.
   lock Thread 21 completed 8276088 loops.
   lock Thread 22 completed 8386980 loops.
   lock Thread 23 completed 9006728 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 100 loops.
   read Thread 1 completed 126 loops.
   read Thread 2 completed 180 loops.
   nxread Thread 3 completed 80 loops.
   nxread Thread 4 completed 63 loops.
   nxread Thread 5 completed 96 loops.
   tryexcept Thread 6 completed 24009428 loops.
   tryexcept Thread 7 completed 18997565 loops.
   tryexcept Thread 8 completed 17752747 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 4 loops.
   forktoomuch Thread 12 completed 7 loops.
   forktoomuch Thread 13 completed 8 loops.
   forktoomuch Thread 14 completed 9 loops.
   lock Thread 21 completed 8760970 loops.
   lock Thread 22 completed 6987943 loops.
   lock Thread 23 completed 10012968 loops.
All tests complete.  Congratulations.


C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests alloc,creat
Writing file...done
Creating alloc threads...
   alloc=15
   alloc=16
   alloc=17
done
Creating creat threads...
   creat=18
   creat=19
   creat=20
done
running...printing oldest/median age/newest
.....

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0xdee37d = Move + 0x50 in ..\src\runtime\common\RTCollector.m3
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

^C


C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests alloc,creat @M3paranoidgc
Writing file...done
Creating alloc threads...
   alloc=15
   alloc=16
   alloc=17
done
Creating creat threads...
   creat=18
   creat=19
   creat=20
done
running...printing oldest/median age/newest
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 15465 loops.
   alloc Thread 16 completed 26927 loops.
   alloc Thread 17 completed 32052 loops.
   creat Thread 18 completed 248 loops.
   creat Thread 19 completed 432 loops.
   creat Thread 20 completed 260 loops.
..

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

^C


C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests alloc,creat @M3nogc
Writing file...done
Creating alloc threads...
   alloc=15
   alloc=16
   alloc=17
done
Creating creat threads...
   creat=18
   creat=19
   creat=20
done
running...printing oldest/median age/newest
...

NEW() was unable to al***ate more memory. was unable to allocate more memory.

NEW() was unable to al***ate more memory.

NEW() was unable to al***ate more memory. was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.
***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0xa5fa48   0xeac5a2  Raise + 0x3f in ..\src\runtime\common\RuntimeError.m3
0xa5fa68   0xe88712  AllocateOpenArray + 0x33 in ..\src\runtime\common\RTAllocator.m3
0xa5fac4   0xe62430  AApply + 0x128 in ..\src\Main.m3
0xa5fb00   0xe8b56f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
0xa5fb0c  0x75c53677  <???>
0xa5fb4c  0x77e39f02  <???>
.........  .........  ... more frames ...

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>

Regards,
Randy Coleburn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110316/2a7332c1/attachment-0001.html>

From hosking at cs.purdue.edu  Thu Mar 17 01:13:34 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 16 Mar 2011 20:13:34 -0400
Subject: [M3devel] thread test results on Win7 64-bit
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BDB9C@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BDB9C@atlex02-srv>
Message-ID: <8A030252-DB8E-4505-BA29-70B28329577F@cs.purdue.edu>

This is the offending line:

On Mar 16, 2011, at 6:50 PM, Coleburn, Randy wrote:

> ***
> *** runtime error:
> ***    An array subscript was out of range.
> ***    file "..\src\rw\FileRd.m3", line 83
> ***

      n := rd.sourceH.read(
             SUBARRAY(LOOPHOLE(ADR(rd.buff[0]), ByteArrayPtr)^, 0,
                      MIN (NUMBER(rd.buff^), BIG)), mayBlock := NOT dontBlock)

I am very suspicious about this...  anyone have any insights?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110316/fedb208a/attachment-0001.html>

From hosking at cs.purdue.edu  Thu Mar 17 01:13:47 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 16 Mar 2011 20:13:47 -0400
Subject: [M3devel] thread tests on NT386 32-bt
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BDB96@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BDAF8@atlex02-srv>
	<B579D06A-BA7D-4739-9954-3B8A4E358AAD@cs.purdue.edu>
	<D67F02DDC62F7545A6B84C285F88F3E603418BDB96@atlex02-srv>
Message-ID: <1D3141BB-DB5F-46C9-ACB1-A3B9A95B74AE@cs.purdue.edu>

OK, good.  So I think this is definitely a threads/GC interaction.  Should be diagnosable from here out.

On Mar 16, 2011, at 6:34 PM, Coleburn, Randy wrote:

> Tony asked:
> I don't remember how stable the collector was at that point.  Running them with @M3nogc indicates there were problems with it.
> Now, what happens with the current trunk head when run with @M3nogc?
> 
> Here you go:
>  
> The alloc & create tests ran 9 iterations before running out of memory.
>  
> The other tests ran to completion.
>  
> See below (these tests run on IBM G40, XP Pro, 32-bit, against current HEAD branch):
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests alloc,creat @M3nogc
> Writing file...done
> Creating alloc threads...
>    alloc=15
>    alloc=16
>    alloc=17
> done
> Creating creat threads...
>    creat=18
>    creat=19
>    creat=20
> done
> running...printing oldest/median age/newest
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 32400 loops.
>    alloc Thread 16 completed 48840 loops.
>    alloc Thread 17 completed 36525 loops.
>    creat Thread 18 completed 25 loops.
>    creat Thread 19 completed 28 loops.
>    creat Thread 20 completed 27 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 5850 loops.
>    alloc Thread 16 completed 8310 loops.
>    alloc Thread 17 completed 8910 loops.
>    creat Thread 18 completed 19 loops.
>    creat Thread 19 completed 20 loops.
>    creat Thread 20 completed 21 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 8505 loops.
>    alloc Thread 16 completed 11805 loops.
>    alloc Thread 17 completed 13170 loops.
>    creat Thread 18 completed 27 loops.
>    creat Thread 19 completed 26 loops.
>    creat Thread 20 completed 27 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 7035 loops.
>    alloc Thread 16 completed 13080 loops.
>    alloc Thread 17 completed 5010 loops.
>    creat Thread 18 completed 19 loops.
>    creat Thread 19 completed 21 loops.
>    creat Thread 20 completed 19 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 10260 loops.
>    alloc Thread 16 completed 5445 loops.
>   alloc Thread 17 completed 6390 loops.
>    creat Thread 18 completed 21 loops.
>    creat Thread 19 completed 23 loops.
>    creat Thread 20 completed 23 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 3240 loops.
>    alloc Thread 16 completed 12405 loops.
>    alloc Thread 17 completed 6975 loops.
>    creat Thread 18 completed 24 loops.
>    creat Thread 19 completed 25 loops.
>    creat Thread 20 completed 23 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 7410 loops.
>    alloc Thread 16 completed 6090 loops.
>    alloc Thread 17 completed 8670 loops.
>    creat Thread 18 completed 17 loops.
>    creat Thread 19 completed 17 loops.
>    creat Thread 20 completed 17 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 6105 loops.
>    alloc Thread 16 completed 7425 loops.
>    alloc Thread 17 completed 10155 loops.
>    creat Thread 18 completed 14 loops.
>    creat Thread 19 completed 17 loops.
>    creat Thread 20 completed 17 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 17160 loops.
>    alloc Thread 16 completed 13365 loops.
>    alloc Thread 17 completed 13785 loops.
>    creat Thread 18 completed 17 loops.
>    creat Thread 19 completed 16 loops.
>    creat Thread 20 completed 17 loops.
> ......
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
> ***    file "..\src\runtime\common\RuntimeError.m3", line 63
> ***
>  
> ***    file "..\src\runtime\common\RuntimeError.m3", line 63
> ***
> .
> ***    file "..\src\runtime\common\RuntimeError.m3", line 63
> ***
>  
> ***    file "..\src\runtime\common\RuntimeError.m3", line 63
> ***
>  
> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0xf7fefc   0x44c572  Raise + 0x3f in ..\src\runtime\common\RuntimeError.m3
> 0xf7ff1c   0x428712  AllocateOpenArray + 0x33 in ..\src\runtime\common\RTAllocator.m3
> 0xf7ff78   0x402430  AApply + 0x128 in ..\src\Main.m3
> 0xf7ffb4   0x42b56f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
> .........  .........  ... more frames ...
>  
>  
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lock @M3nogc
> Writing file...done
> Creating read threads...
>    read=0
>    read=1
>    read=2
> done
> Creating nxread threads...
>    nxread=3
>    nxread=4
>    nxread=5
> done
> Creating tryexcept threads...
>    tryexcept=6
>    tryexcept=7
>    tryexcept=8
> done
> Creating fork threads...
>    fork=9
>    fork=0
>    fork=11
> done
> Creating forktoomuch threads...
>    forktoomuch=12
>    forktoomuch=13
>    forktoomuch=14
> done
> Creating lock threads...
>    lock=21
>    lock=22
>    lock=23
> done
> running...printing oldest/median age/newest
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 98 loops.
>    read Thread 1 completed 101 loops.
>    read Thread 2 completed 98 loops.
>    nxread Thread 3 completed 63 loops.
>    nxread Thread 4 completed 64 loops.
>    nxread Thread 5 completed 64 loops.
>    tryexcept Thread 6 completed 1106827 loops.
>    tryexcept Thread 7 completed 1056963 loops.
>    tryexcept Thread 8 completed 1124363 loops.
>    fork Thread 9 completed 3 loops.
>    fork Thread 10 completed 3 loops.
>    fork Thread 11 completed 3 loops.
>    forktoomuch Thread 12 completed 5 loops.
>    forktoomuch Thread 13 completed 5 loops.
>    forktoomuch Thread 14 completed 4 loops.
>    lock Thread 21 completed 902314 loops.
>    lock Thread 22 completed 873503 loops.
>    lock Thread 23 completed 946840 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 108 loops.
>    read Thread 1 completed 105 loops.
>    read Thread 2 completed 108 loops.
>    nxread Thread 3 completed 68 loops.
>    nxread Thread 4 completed 70 loops.
>    nxread Thread 5 completed 67 loops.
>    tryexcept Thread 6 completed 1197135 loops.
>    tryexcept Thread 7 completed 1248635 loops.
>    tryexcept Thread 8 completed 1263743 loops.
>    fork Thread 9 completed 4 loops.
>    fork Thread 10 completed 4 loops.
>    fork Thread 11 completed 4 loops.
>    forktoomuch Thread 12 completed 6 loops.
>    forktoomuch Thread 13 completed 7 loops.
>    forktoomuch Thread 14 completed 7 loops.
>    lock Thread 21 completed 1156474 loops.
>    lock Thread 22 completed 1007509 loops.
>    lock Thread 23 completed 1072164 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 91 loops.
>    read Thread 1 completed 101 loops.
>    read Thread 2 completed 99 loops.
>    nxread Thread 3 completed 67 loops.
>    nxread Thread 4 completed 63 loops.
>    nxread Thread 5 completed 64 loops.
>    tryexcept Thread 6 completed 1212286 loops.
>    tryexcept Thread 7 completed 1115613 loops.
>    tryexcept Thread 8 completed 1124737 loops.
>    fork Thread 9 completed 4 loops.
>    fork Thread 10 completed 5 loops.
>    fork Thread 11 completed 4 loops.
>    forktoomuch Thread 12 completed 8 loops.
>    forktoomuch Thread 13 completed 8 loops.
>    forktoomuch Thread 14 completed 7 loops.
>    lock Thread 21 completed 1058176 loops.
>    lock Thread 22 completed 979426 loops.
>    lock Thread 23 completed 1068972 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 103 loops.
>    read Thread 1 completed 105 loops.
>    read Thread 2 completed 105 loops.
>    nxread Thread 3 completed 63 loops.
>    nxread Thread 4 completed 63 loops.
>    nxread Thread 5 completed 61 loops.
>    tryexcept Thread 6 completed 1132672 loops.
>    tryexcept Thread 7 completed 1186707 loops.
>    tryexcept Thread 8 completed 1136861 loops.
>    fork Thread 9 completed 4 loops.
>    fork Thread 10 completed 4 loops.
>    fork Thread 11 completed 4 loops.
>    forktoomuch Thread 12 completed 6 loops.
>    forktoomuch Thread 13 completed 6 loops.
>    forktoomuch Thread 14 completed 7 loops.
>    lock Thread 21 completed 794204 loops.
>    lock Thread 22 completed 1171670 loops.
>    lock Thread 23 completed 992164 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 88 loops.
>    read Thread 1 completed 93 loops.
>    read Thread 2 completed 105 loops.
>    nxread Thread 3 completed 60 loops.
>    nxread Thread 4 completed 63 loops.
>    nxread Thread 5 completed 64 loops.
>    tryexcept Thread 6 completed 1213622 loops.
>    tryexcept Thread 7 completed 1169506 loops.
>    tryexcept Thread 8 completed 1220576 loops.
>    fork Thread 9 completed 3 loops.
>    fork Thread 10 completed 3 loops.
>    fork Thread 11 completed 3 loops.
>    forktoomuch Thread 12 completed 5 loops.
>    forktoomuch Thread 13 completed 6 loops.
>    forktoomuch Thread 14 completed 6 loops.
>    lock Thread 21 completed 947532 loops.
>    lock Thread 22 completed 1046220 loops.
>    lock Thread 23 completed 886815 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 104 loops.
>    read Thread 1 completed 104 loops.
>    read Thread 2 completed 104 loops.
>    nxread Thread 3 completed 69 loops.
>    nxread Thread 4 completed 68 loops.
>    nxread Thread 5 completed 68 loops.
>    tryexcept Thread 6 completed 1225537 loops.
>    tryexcept Thread 7 completed 1158824 loops.
>    tryexcept Thread 8 completed 1185900 loops.
>    fork Thread 9 completed 4 loops.
>    fork Thread 10 completed 5 loops.
>    fork Thread 11 completed 4 loops.
>    forktoomuch Thread 12 completed 8 loops.
>    forktoomuch Thread 13 completed 7 loops.
>    forktoomuch Thread 14 completed 6 loops.
>    lock Thread 21 completed 1116802 loops.
>    lock Thread 22 completed 1028306 loops.
>    lock Thread 23 completed 1130454 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 107 loops.
>    read Thread 1 completed 110 loops.
>    read Thread 2 completed 112 loops.
>    nxread Thread 3 completed 63 loops.
>    nxread Thread 4 completed 63 loops.
>    nxread Thread 5 completed 63 loops.
>    tryexcept Thread 6 completed 1156252 loops.
>    tryexcept Thread 7 completed 1094847 loops.
>    tryexcept Thread 8 completed 1199661 loops.
>    fork Thread 9 completed 3 loops.
>    fork Thread 10 completed 3 loops.
>    fork Thread 11 completed 4 loops.
>    forktoomuch Thread 12 completed 7 loops.
>    forktoomuch Thread 13 completed 7 loops.
>    forktoomuch Thread 14 completed 7 loops.
>    lock Thread 21 completed 746279 loops.
>    lock Thread 22 completed 1069667 loops.
>    lock Thread 23 completed 1045028 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 98 loops.
>    read Thread 1 completed 99 loops.
>    read Thread 2 completed 96 loops.
>    nxread Thread 3 completed 64 loops.
>    nxread Thread 4 completed 60 loops.
>    nxread Thread 5 completed 63 loops.
>    tryexcept Thread 6 completed 1185205 loops.
>    tryexcept Thread 7 completed 1175381 loops.
>    tryexcept Thread 8 completed 1114031 loops.
>    fork Thread 9 completed 4 loops.
>    fork Thread 10 completed 5 loops.
>    fork Thread 11 completed 4 loops.
>    forktoomuch Thread 12 completed 6 loops.
>    forktoomuch Thread 13 completed 7 loops.
>    forktoomuch Thread 14 completed 6 loops.
>    lock Thread 21 completed 1053691 loops.
>    lock Thread 22 completed 1009143 loops.
>    lock Thread 23 completed 966082 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 111 loops.
>    read Thread 1 completed 110 loops.
>    read Thread 2 completed 101 loops.
>    nxread Thread 3 completed 64 loops.
>    nxread Thread 4 completed 65 loops.
>    nxread Thread 5 completed 64 loops.
>    tryexcept Thread 6 completed 1130609 loops.
>    tryexcept Thread 7 completed 1160042 loops.
>    tryexcept Thread 8 completed 1110365 loops.
>    fork Thread 9 completed 4 loops.
>    fork Thread 10 completed 4 loops.
>    fork Thread 11 completed 5 loops.
>    forktoomuch Thread 12 completed 7 loops.
>    forktoomuch Thread 13 completed 7 loops.
>    forktoomuch Thread 14 completed 7 loops.
>    lock Thread 21 completed 682298 loops.
>    lock Thread 22 completed 1124977 loops.
>    lock Thread 23 completed 960154 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 62 loops.
>    read Thread 1 completed 65 loops.
>    read Thread 2 completed 62 loops.
>    nxread Thread 3 completed 45 loops.
>    nxread Thread 4 completed 42 loops.
>    nxread Thread 5 completed 42 loops.
>    tryexcept Thread 6 completed 1569234 loops.
>    tryexcept Thread 7 completed 1553679 loops.
>    tryexcept Thread 8 completed 1511503 loops.
>    fork Thread 9 completed 1 loops.
>    fork Thread 10 completed 2 loops.
>    fork Thread 11 completed 2 loops.
>    forktoomuch Thread 12 completed 4 loops.
>    forktoomuch Thread 13 completed 4 loops.
>    forktoomuch Thread 14 completed 4 loops.
>    lock Thread 21 completed 1311441 loops.
>    lock Thread 22 completed 1309196 loops.
>    lock Thread 23 completed 1418347 loops.
> All tests complete.  Congratulations.
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>
>  
> Regards,
> Randy Coleburn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110316/40c031b5/attachment-0001.html>

From rcolebur at SCIRES.COM  Thu Mar 17 20:46:00 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 17 Mar 2011 15:46:00 -0400
Subject: [M3devel] thread test results on Win7 64-bit
In-Reply-To: <8A030252-DB8E-4505-BA29-70B28329577F@cs.purdue.edu>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BDB9C@atlex02-srv>
	<8A030252-DB8E-4505-BA29-70B28329577F@cs.purdue.edu>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E603418BDDEC@atlex02-srv>

Tony et al:

On the surface, it would seem this convoluted code is doing the following:

1.       Making rd.buff appear as an "ARRAY OF Byte", vice an "ARRAY OF CHAR, so as to meet the requirements of the File.T.read interface.

2.       Limiting the buffer to be the smaller of "BIG", or the actual number of elements in rd.buff

Now, re #2, the code in FileRd seems to allocate buffers in 4096-char arrays, and BIG is 16M, so I don't quite see why the need to ensure the buffer is limited to no more than BIG, as it should never be more than 4096.

All that aside, are you concerned that the GC could be relocating rd.buff after its address is obtained and fed to the File.T.read (rd.sourceH.read) procedure?

If indeed this movement can occur, this code definitely needs to change.

How can we force the GC not to move rd.buff, or is there another "safe" way to make rd.buff appear as an "ARRAY OF Byte" to satisfy the File.T.read interface?

Buffers are allocated in line #45 as a traced reference to an ARRAY OF CHAR via:
      rd.buff := NEW(CharBuffer, BufferSize);
Yet, the ByteArrayPtr in FileRd.m3 (line 25) is an untraced reference (to an array of Byte).

Should we be allocating buffers (rd.buff) as untraced refs instead, and then explicitly freeing?  Or, is there a way to keep them as traced refs, but avoid collection/movement while being used in an unsafe manner?

Finally, there are multiple statements in the FileRd.m3 module similar to line #83 that must be dealt with (e.g., 114, 119).

Regards,
Randy Coleburn

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Wednesday, March 16, 2011 8:14 PM
To: Coleburn, Randy
Cc: m3devel
Subject: Re: [M3devel] thread test results on Win7 64-bit

This is the offending line:
On Mar 16, 2011, at 6:50 PM, Coleburn, Randy wrote:

***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\rw\FileRd.m3", line 83
***

      n := rd.sourceH.read(
             SUBARRAY(LOOPHOLE(ADR(rd.buff[0]), ByteArrayPtr)^, 0,
                      MIN (NUMBER(rd.buff^), BIG)), mayBlock := NOT dontBlock)

I am very suspicious about this...  anyone have any insights?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110317/006cbf1a/attachment-0001.html>

From dabenavidesd at yahoo.es  Fri Mar 18 01:31:35 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 18 Mar 2011 00:31:35 +0000 (GMT)
Subject: [M3devel] thread test results on Win7 64-bit
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BDDEC@atlex02-srv>
Message-ID: <46694.52575.qm@web29710.mail.ird.yahoo.com>

Hi all:
reading through the green book chapter on IO streams, p160, it seems, there should not be such a range violation cause its actually allowed to be NIL (see? ftp://gatekeeper.research.compaq.com/pub/DEC/SRC/research-reports/abstracts/src-rr-053.html
p 30 and above) so this must be related to the fact there is some missing a conditional if so as it is unsafely checked by the compiler, but it might not be necessarily that, I mean unsafe perse, but in that case just for that may get a RT error unneeded to argue for that (i.e it might not), indeed most of the crashes might come by this classes, but as I read TextWr seek method style was to raise an unlisted exception which is by itself a RT error as a policy, however subclasses of Rd.T must be aware of their obligations that is, they have invariants so we could? check for those I believe they are there in safe MODULES (as I think is checked already) and manner that is even as one could argue in UNSAFE modules they hold (if they don't hold just the first case), we could if this is really broken get it in safe modules to check for them in an ESC, actually first RW lib was absolutely according to their comments unsafe for speed performance but after
 crashed many times decided to made safe interfaces to look for those kind of errors. So it might be need a middle layer not UNSAFE module of FileRd INTERFACE to look for those errors closely, e.g implement that method failing (FileRd.seek) and related safely and check them by ESC.
Specifically from the three invariants the most feasible mentioned in RdClass interface which might be not be satisfied and should be checked in a debugger is the first of the three (because would cause same RT error shown there):
rd is valid if =>
[rd.lo .. rd.hi-i] 
where i can be 0 and so buff=NIL, 
so its possible though would need confirmation a breakpoint there in line FileRd.m3:83 to see rd.buff
the others that come after this, 
cur(rd) = MIN(rd.cur,? len(rd))
from what
rd.cur>len(rd) or rd.cur = len(rd)
and third:
NOT (rd.intermittent AND rd.seekable)
That said I would recommend the latter method a mechanic debugger meanwhile, tough if positive we would follow the guideline of Greg and the gang to specify it in a safe module, at least the method. Then in an automatic debugger might help to proof that for us too if so.
Indeed there are more classes of invariants there for declare clean and also private invariants too. Will check for that too.  
Thanks in advance

--- El jue, 17/3/11, Coleburn, Randy <rcolebur at SCIRES.COM> escribi?:

De: Coleburn, Randy <rcolebur at SCIRES.COM>
Asunto: Re: [M3devel] thread test results on Win7 64-bit
Para: "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 17 de marzo, 2011 14:46

Tony et al: ?On the surface, it would seem this convoluted code is doing the following:1.?????? Making rd.buff appear as an ?ARRAY OF Byte?, vice an ?ARRAY OF CHAR, so as to meet the requirements of the File.T.read interface.2.?????? Limiting the buffer to be the smaller of ?BIG?, or the actual number of elements in rd.buff ?Now, re #2, the code in FileRd seems to allocate buffers in 4096-char arrays, and BIG is 16M, so I don?t quite see why the need to ensure the buffer is limited to no more than BIG, as it should never be more than 4096. ?All that aside, are you concerned that the GC could be relocating rd.buff after its address is obtained and fed to the File.T.read (rd.sourceH.read) procedure? ?If indeed this movement can occur, this code definitely needs to change. ?How can we force the GC not to move rd.buff, or is there another ?safe? way to make rd.buff appear as an ?ARRAY OF Byte? to satisfy the File.T.read
 interface? ?Buffers are allocated in line #45 as a traced reference to an ARRAY OF CHAR via:????? rd.buff := NEW(CharBuffer, BufferSize);Yet, the ByteArrayPtr in FileRd.m3 (line 25) is an untraced reference (to an array of Byte). ?Should we be allocating buffers (rd.buff) as untraced refs instead, and then explicitly freeing?? Or, is there a way to keep them as traced refs, but avoid collection/movement while being used in an unsafe manner? ?Finally, there are multiple statements in the FileRd.m3 module similar to line #83 that must be dealt with (e.g., 114, 119). ?Regards,Randy Coleburn ?From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
Sent: Wednesday, March 16, 2011 8:14 PM
To: Coleburn, Randy
Cc: m3devel
Subject: Re: [M3devel] thread test results on Win7 64-bit ?This is the offending line:On Mar 16, 2011, at 6:50 PM, Coleburn, Randy wrote: ?****** runtime error:***??? An array subscript was out of range.***??? file "..\src\rw\FileRd.m3", line 83*** ??? ? ?n := rd.sourceH.read(?? ? ? ? ? ? SUBARRAY(LOOPHOLE(ADR(rd.buff[0]), ByteArrayPtr)^, 0,?? ? ? ? ? ? ? ? ? ? ?MIN (NUMBER(rd.buff^), BIG)), mayBlock := NOT dontBlock) ?I am very suspicious about this... ?anyone have any insights? ?


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110318/0138ec00/attachment-0001.html>

From jay.krell at cornell.edu  Sun Mar 20 22:08:46 2011
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 20 Mar 2011 21:08:46 +0000
Subject: [M3devel] runaway hudson/pgm
Message-ID: <COL101-W63D86DE03E6E0EF01D5ABEE6B20@phx.gbl>


Some "pgm" (a common name for test cases) running as Hudson was eating CPU and laptop was noticably hot/slow, so I killed it.

 - Jay




 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110320/71efb57d/attachment-0001.html>

From rodney_bates at lcwb.coop  Tue Mar 22 19:45:28 2011
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Tue, 22 Mar 2011 13:45:28 -0500
Subject: [M3devel] thread test results on Win7 64-bit
Message-ID: <4D88EE48.70608@lcwb.coop>



The only subscript operation in this line is rd.buff[0].
 From the declaration of buff in RdClass.i3:32, buff has
type REF ARRAY OF CHAR.  If buff were NIL, it should give
a different runtime error (probably segfault).  With the
subscript being statically zero, the only way this could
happen is if buff was allocated with a zero NUMBER.  I
didn't go looking for that, but it seems unlikely.

Otherwise, it would have to be a corrupted heap object or
maybe miscompiled code.  Or the runtime error message is
wrong.  From this shallow reasoning, I would put my bet on
the corrupted object.

On 03/16/2011 07:13 PM, Tony Hosking wrote:
> This is the offending line:
>
> On Mar 16, 2011, at 6:50 PM, Coleburn, Randy wrote:
>
>> ***
>> *** runtime error:
>> *** An array subscript was out of range.
>> *** file "..\src\rw\FileRd.m3", line 83
>> ***
>
> n := rd.sourceH.read(
> SUBARRAY(LOOPHOLE(ADR(rd.buff[0]), ByteArrayPtr)^, 0,
> MIN (NUMBER(rd.buff^), BIG)), mayBlock := NOT dontBlock)
>
> I am very suspicious about this... anyone have any insights?
>



From dabenavidesd at yahoo.es  Thu Mar 24 00:41:35 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 23 Mar 2011 23:41:35 +0000 (GMT)
Subject: [M3devel] thread test results on Win7 64-bit
Message-ID: <634095.3089.qm@web29701.mail.ird.yahoo.com>

Hi all:
that is correct, it could be not NIL and still be wrong if V1 doesn't hold the characters of src are not those of buff mentione cin green book, page 160 or p 37 of:
ftp://apotheca.hpl.hp.com/pub/dec/SRC/research-reports/SRC-053.pdf

rd.buff[rd.st + i - rd.lo] = src(rd)[i]

The other thing is that as WrRep module section 6.8 in green book, page 151 says is needed or in SRC-RR-053, p 21 sec 8, collector is not relocating, does it hold this?


Aside, does a procedure type hold ADDRESS and its values are valid, as we could trace untraced objects, records, procedures in an unmovable heap and change them absolutely but in terms of an unsafe RT, that is to communicate better its abstraction low level in the RT, or high level like with traced ones.

Thanks in advance


--- El mar, 22/3/11, Rodney M. Bates <rodney_bates at lcwb.coop> escribi?:

> De: Rodney M. Bates <rodney_bates at lcwb.coop>
> Asunto: Re: [M3devel] thread test results on Win7 64-bit
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: martes, 22 de marzo, 2011 13:45
> 
> 
> The only subscript operation in this line is rd.buff[0].
>  From the declaration of buff in RdClass.i3:32, buff has
> type REF ARRAY OF CHAR.  If buff were NIL, it should
> give
> a different runtime error (probably segfault).  With
> the
> subscript being statically zero, the only way this could
> happen is if buff was allocated with a zero NUMBER. 
> I
> didn't go looking for that, but it seems unlikely.
> 
> Otherwise, it would have to be a corrupted heap object or
> maybe miscompiled code.  Or the runtime error message
> is
> wrong.  From this shallow reasoning, I would put my
> bet on
> the corrupted object.
> 
> On 03/16/2011 07:13 PM, Tony Hosking wrote:
> > This is the offending line:
> >
> > On Mar 16, 2011, at 6:50 PM, Coleburn, Randy wrote:
> >
> >> ***
> >> *** runtime error:
> >> *** An array subscript was out of range.
> >> *** file "..\src\rw\FileRd.m3", line 83
> >> ***
> >
> > n := rd.sourceH.read(
> > SUBARRAY(LOOPHOLE(ADR(rd.buff[0]), ByteArrayPtr)^, 0,
> > MIN (NUMBER(rd.buff^), BIG)), mayBlock := NOT
> dontBlock)
> >
> > I am very suspicious about this... anyone have any
> insights?
> >
> 
>



      


From rodney_bates at lcwb.coop  Mon Mar 28 18:16:23 2011
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Mon, 28 Mar 2011 11:16:23 -0500
Subject: [M3devel] How to install cm3 at a nonstandard location
Message-ID: <4D90B457.90305@lcwb.coop>

I tried to build cm3 head and install at /usr/local/cm3-head.
 From the installation notes, I set environment variable
CM3_INSTALL to this path.  After fixing several failures
involving merges by cvs, I discovered it had been putting
things into /usr/local/cm3, where I have the latest cm3
release, giving me a mixture of stuff from the head and
the release, which I certainly don't trust.

I was building instead of using cminstall, like the the install
notes were referring to.  However, before I started, I found
code in scripts/sysinfo.sh setting up CM3_INSTALL to the default,
unless already set, which I took to mean this was the way to
do it when building too.

I did double and triple check my spelling and value of
CM3_INSTALL, before and after the failed builds.

So how do I get this to work?

This was on LINUXLIBC6.

Rodney Bates




From mika at async.caltech.edu  Mon Mar 28 18:51:33 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Mon, 28 Mar 2011 09:51:33 -0700
Subject: [M3devel] How to install cm3 at a nonstandard location
In-Reply-To: <4D90B457.90305@lcwb.coop> 
References: <4D90B457.90305@lcwb.coop>
Message-ID: <20110328165133.7504B1A2078@async.async.caltech.edu>

I think I pass the target directory to cminstall on the cmd. line, something like:

./cminstall /path/to/installation/root

"Rodney M. Bates" writes:
>I tried to build cm3 head and install at /usr/local/cm3-head.
> From the installation notes, I set environment variable
>CM3_INSTALL to this path.  After fixing several failures
>involving merges by cvs, I discovered it had been putting
>things into /usr/local/cm3, where I have the latest cm3
>release, giving me a mixture of stuff from the head and
>the release, which I certainly don't trust.
>
>I was building instead of using cminstall, like the the install
>notes were referring to.  However, before I started, I found
>code in scripts/sysinfo.sh setting up CM3_INSTALL to the default,
>unless already set, which I took to mean this was the way to
>do it when building too.
>
>I did double and triple check my spelling and value of
>CM3_INSTALL, before and after the failed builds.
>
>So how do I get this to work?
>
>This was on LINUXLIBC6.
>
>Rodney Bates
>


From dabenavidesd at yahoo.es  Mon Mar 28 21:24:52 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 28 Mar 2011 20:24:52 +0100 (BST)
Subject: [M3devel] About Simplify build script platforms and cm3ide service
Message-ID: <402597.44437.qm@web29712.mail.ird.yahoo.com>

Hi all:
I was wondering as I remember Simplify has a component to show IO (not sure for input) web page to show results or the theorems being proved and their proof and some test suites contain test compliant test suites, it seems we surely will have to display that for other clients than us, so it might be useful to put this tests or runs in the cm3ide server, as it allows to show a centralized approach rather than running simplify from old binary versions. It is also an opportunity to show an application of it, Modula-3 and of an application itself and by the way make cm3 improved performance for long runs of it since this is really an used tool, thus we can show how the compiler can take and how much can be optimized for every platform (perhaps to rethink a build script for it and perhaps to add optimization backend support port of  DS3100 burs based? or full 64 bit support in Win2k, xp, 2003, Server, Vista, 7, etc platforms, perhaps better to make an
 improvement over current Win*nix Platforms?
There are some tools which might use that, I know from two sources test suites mentioned coming from ESC in Modula-3, Java and later versions
Originally from the ESC/Modula-3 VCG:
http://portal.acm.org/citation.cfm?id=1066102&dl=guide&coll=GUIDE

(In section Source Materials, the second tab, inside simplify_benchmarks hyperlink and see simplify_benchmarks/format.txt for thge big and small suites or download directly from:
http://delivery.acm.org/10.1145/1070000/1066102/supp/simplify_benchmarks.tar.gz?key1=1066102&key2=3798331031&coll=DL&dl=ACM&CFID=15503308&CFTOKEN=88865083 

)

later modification of ESC/Java VCG relevant originally in:
http://replay.waybackmachine.org/20090422004503/http://nemerle.org/~malekith/smt/benchmarks/
Even other systems like JVM based Whiley, and or so any ESC/JVM itself, etc.
  
Thanks in advance


From jay.krell at cornell.edu  Tue Mar 29 02:03:03 2011
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 29 Mar 2011 00:03:03 +0000
Subject: [M3devel] How to install cm3 at a nonstandard location
In-Reply-To: <20110328165133.7504B1A2078@async.async.caltech.edu>
References: <4D90B457.90305@lcwb.coop>,
	<20110328165133.7504B1A2078@async.async.caltech.edu>
Message-ID: <COL101-W63008765882635E26EA9B1E6BD0@phx.gbl>


Another approach is to copy a few things to the new location, e.g. config files, cm3, cm3cg, and then use those to build/ship.
That is how make-dist.py works, for example.
And be sure the config files use path() to find themselves, instead of hardcoding their location.

 - Jay

> To: rodney_bates at lcwb.coop
> Date: Mon, 28 Mar 2011 09:51:33 -0700
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] How to install cm3 at a nonstandard location
> 
> I think I pass the target directory to cminstall on the cmd. line, something like:
> 
> ./cminstall /path/to/installation/root
> 
> "Rodney M. Bates" writes:
> >I tried to build cm3 head and install at /usr/local/cm3-head.
> > From the installation notes, I set environment variable
> >CM3_INSTALL to this path.  After fixing several failures
> >involving merges by cvs, I discovered it had been putting
> >things into /usr/local/cm3, where I have the latest cm3
> >release, giving me a mixture of stuff from the head and
> >the release, which I certainly don't trust.
> >
> >I was building instead of using cminstall, like the the install
> >notes were referring to.  However, before I started, I found
> >code in scripts/sysinfo.sh setting up CM3_INSTALL to the default,
> >unless already set, which I took to mean this was the way to
> >do it when building too.
> >
> >I did double and triple check my spelling and value of
> >CM3_INSTALL, before and after the failed builds.
> >
> >So how do I get this to work?
> >
> >This was on LINUXLIBC6.
> >
> >Rodney Bates
> >
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110329/c26447fc/attachment-0001.html>

From dabenavidesd at yahoo.es  Tue Mar 29 01:57:23 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 29 Mar 2011 00:57:23 +0100 (BST)
Subject: [M3devel] About CM3_IDE_UsersGuide format if so
Message-ID: <667386.49334.qm@web29719.mail.ird.yahoo.com>

Hi all:
I wanted to know whether you agree on reformat the CM3_IDE_UserGuide doc file into a standard linear one, like of the doc tools used in cm3 and pm3 repository are based on either tex, html (and back and forth see belo ) or even gnuinfo files, although there some small ones of mtex that I don't know much about and also the noweb files (literate programming like native burs backend is coded or ldb, where still is to be seeing whether generic files are post processed as expected by cm3) that are also plain text files.
I was thinking in make some docs more widely available specifically some improvement over Net Object collector information, since there are two formal proofs of that I believe one is current there (Birrell's collection scheme) and "new" one distributed cyclic garbage collection.
This would allows us to alter proof them by formal and automatic mechanical checking and such gain some more interest in the platform and its collection algorithms:
http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-116.pdf

And subsequent work:
http://kar.kent.ac.uk/21327/

http://www.cs.kent.ac.uk/pubs/1998/926/index.html

and last but not least:
http://www.cs.kent.ac.uk/pubs/2003/1650/

With mechanism such as of the pm3 sgml-obliq it could be shown to convert from ps (with see doi:10.1109/ICDAR.1997.619868 [1]) to html to tex and so on keep improving the situation with respect of lack of annotation information with the current papers, as of anybody who wants to write informally knowledge about it let him do it freely.

Well, just in case you don't mind I will try to add extra converted this docs to lyx, from where it could be later compiled to tex or displayed directly in any other format if so.

Thanks in advance

[1] B. Poirier and M. Dagenais, ?An interactive system to extract structured text from a geometrical representation,? in Document Analysis and Recognition, 1997., Proceedings of the Fourth International Conference on, 1997, vol. 1, pp. 342-346 vol.1.


From jay.krell at cornell.edu  Tue Mar 29 02:04:00 2011
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 29 Mar 2011 00:04:00 +0000
Subject: [M3devel] FW: GCC 4.6.0 Released
In-Reply-To: <20110328072557.GG11563@sunsite.ms.mff.cuni.cz>
References: <20110328072557.GG11563@sunsite.ms.mff.cuni.cz>
Message-ID: <COL101-W2D287BFCAEBA44A26313CE6BD0@phx.gbl>


for us to consider..


> Date: Mon, 28 Mar 2011 09:25:57 +0200
> From: jakub at redhat.com
> To: gcc-announce at gcc.gnu.org
> CC: gcc at gcc.gnu.org
> Subject: GCC 4.6.0 Released
> 
> The GNU Compiler Collection version 4.6.0 has been released.
> 
> GCC 4.6.0 is a major release, containing substantial new functionality
> not available in GCC 4.5.x or previous GCC releases.
> 
> The "link-time optimization" framework introduced in GCC 4.5.0 has been
> significantly improved in this release, it is now possible to compile
> very large applications like Mozilla or GCC itself with LTO.
> GCC can now partially inline functions, inlining just hot short path
> to exit and keeping the rest of the function out of line.
> Support for the upcoming C++0x standard has been notably improved,
> Fortran 2003 and 2008 has been greatly extended and many other frontends
> undergone substantial changes as well.
> Many other improvements have been added and more than thousand of bugs
> have been fixed in various parts of the compiler collection.
> 
> See:
> 
>   http://gcc.gnu.org/gcc-4.6/changes.html
> 
> for more information about changes in GCC 4.6.0.
> 
> This release is available from the FTP servers listed here:
> 
>   http://www.gnu.org/order/ftp.html
> 
> The release is in gcc/gcc-4.6.0/ subdirectory.
> 
> If you encounter difficulties using GCC 4.6, please do not contact me
> directly.  Instead, please visit http://gcc.gnu.org for information
> about getting help.
> 
> As always, a vast number of people contributed to this GCC releases --
> far too many to thank individually!
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110329/eb0cebe0/attachment-0001.html>

From hosking at cs.purdue.edu  Tue Mar 29 04:38:00 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 28 Mar 2011 22:38:00 -0400
Subject: [M3devel] FW: GCC 4.6.0 Released
In-Reply-To: <COL101-W2D287BFCAEBA44A26313CE6BD0@phx.gbl>
References: <20110328072557.GG11563@sunsite.ms.mff.cuni.cz>
	<COL101-W2D287BFCAEBA44A26313CE6BD0@phx.gbl>
Message-ID: <4D4B822F-1820-4E91-8543-AA35097A3766@cs.purdue.edu>

Are you volunteering?  ;-)


On Mar 28, 2011, at 8:04 PM, Jay K wrote:

> for us to consider..
> 
> 
> > Date: Mon, 28 Mar 2011 09:25:57 +0200
> > From: jakub at redhat.com
> > To: gcc-announce at gcc.gnu.org
> > CC: gcc at gcc.gnu.org
> > Subject: GCC 4.6.0 Released
> > 
> > The GNU Compiler Collection version 4.6.0 has been released.
> > 
> > GCC 4.6.0 is a major release, containing substantial new functionality
> > not available in GCC 4.5.x or previous GCC releases.
> > 
> > The "link-time optimization" framework introduced in GCC 4.5.0 has been
> > significantly improved in this release, it is now possible to compile
> > very large applications like Mozilla or GCC itself with LTO.
> > GCC can now partially inline functions, inlining just hot short path
> > to exit and keeping the rest of the function out of line.
> > Support for the upcoming C++0x standard has been notably improved,
> > Fortran 2003 and 2008 has been greatly extended and many other frontends
> > undergone substantial changes as well.
> > Many other improvements have been added and more than thousand of bugs
> > have been fixed in various parts of the compiler collection.
> > 
> > See:
> > 
> > http://gcc.gnu.org/gcc-4.6/changes.html
> > 
> > for more information about changes in GCC 4.6.0.
> > 
> > This release is available from the FTP servers listed here:
> > 
> > http://www.gnu.org/order/ftp.html
> > 
> > The release is in gcc/gcc-4.6.0/ subdirectory.
> > 
> > If you encounter difficulties using GCC 4.6, please do not contact me
> > directly. Instead, please visit http://gcc.gnu.org for information
> > about getting help.
> > 
> > As always, a vast number of people contributed to this GCC releases --
> > far too many to thank individually!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110328/bc44c277/attachment-0001.html>

From dabenavidesd at yahoo.es  Tue Mar 29 05:07:56 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 29 Mar 2011 04:07:56 +0100 (BST)
Subject: [M3devel] About Simplify build script platforms and cm3ide
	service
In-Reply-To: <402597.44437.qm@web29712.mail.ird.yahoo.com>
Message-ID: <428050.39604.qm@web29720.mail.ird.yahoo.com>

Hi all:
some refs I didn't mention where it came from, here:
http://www.cs.nyu.edu/pipermail/smt-lib/2007/000149.html

And further for same knowledge and software theories improvement [1] in:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.22.4306

[2] in:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.28.6492

and realized retrospectively on [3], and a newer one [4]

[1] U. Nestmann, H. H?ttel, J. Kleist, and M. Merro, ?Aliasing Models for Mobile Objects,? Information and Computation, vol. 175, no. 1, pp. 3-33, May. 2002.

[2] M. Merro, J. Kleist, and U. Nestmann, ?Mobile Objects as Mobile Processes,? Information and Computation, vol. 177, no. 2, pp. 195-241, Sep. 2002.

[3] D. Caromel and L. Henrio, A Theory of Distributed Objects, 1st ed. Springer, 2005.

[4] M. Hennessy, A Distributed Pi-Calculus, 1st ed. Cambridge University Press, 2007.

Again, this would useful for such an application extension of DCVS like mercurial, perforce and git rewrite from scratch but in something rely fast and reliable for really distributed computations, don't you think? :)
 
Thanks in advance

--- El lun, 28/3/11, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

> De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
> Asunto: [M3devel] About Simplify build script platforms and cm3ide service
> Para: m3devel at elegosoft.com
> Fecha: lunes, 28 de marzo, 2011 14:24
> Hi all:
> I was wondering as I remember Simplify has a component to
> show IO (not sure for input) web page to show results or the
> theorems being proved and their proof and some test suites
> contain test compliant test suites, it seems we surely will
> have to display that for other clients than us, so it might
> be useful to put this tests or runs in the cm3ide server, as
> it allows to show a centralized approach rather than running
> simplify from old binary versions. It is also an opportunity
> to show an application of it, Modula-3 and of an application
> itself and by the way make cm3 improved performance for long
> runs of it since this is really an used tool, thus we can
> show how the compiler can take and how much can be optimized
> for every platform (perhaps to rethink a build script for it
> and perhaps to add optimization backend support port
> of  DS3100 burs based? or full 64 bit support in Win2k,
> xp, 2003, Server, Vista, 7, etc platforms, perhaps better to
> make an
>  improvement over current Win*nix Platforms?
> There are some tools which might use that, I know from two
> sources test suites mentioned coming from ESC in Modula-3,
> Java and later versions
> Originally from the ESC/Modula-3 VCG:
> http://portal.acm.org/citation.cfm?id=1066102&dl=guide&coll=GUIDE
> 
> (In section Source Materials, the second tab, inside
> simplify_benchmarks hyperlink and see
> simplify_benchmarks/format.txt for thge big and small suites
> or download directly from:
> http://delivery.acm.org/10.1145/1070000/1066102/supp/simplify_benchmarks.tar.gz?key1=1066102&key2=3798331031&coll=DL&dl=ACM&CFID=15503308&CFTOKEN=88865083
> 
> 
> )
> 
> later modification of ESC/Java VCG relevant originally in:
> http://replay.waybackmachine.org/20090422004503/http://nemerle.org/~malekith/smt/benchmarks/
> Even other systems like JVM based Whiley, and or so any
> ESC/JVM itself, etc.
>   
> Thanks in advance
> 


From wagner at elegosoft.com  Tue Mar 29 09:18:52 2011
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 29 Mar 2011 09:18:52 +0200
Subject: [M3devel] How to install cm3 at a nonstandard location
In-Reply-To: <4D90B457.90305@lcwb.coop>
References: <4D90B457.90305@lcwb.coop>
Message-ID: <20110329091852.sdnxriui04s880go@mail.elegosoft.com>

Quoting "Rodney M. Bates" <rodney_bates at lcwb.coop>:

> I tried to build cm3 head and install at /usr/local/cm3-head.
> From the installation notes, I set environment variable
> CM3_INSTALL to this path.  After fixing several failures
> involving merges by cvs, I discovered it had been putting
> things into /usr/local/cm3, where I have the latest cm3
> release, giving me a mixture of stuff from the head and
> the release, which I certainly don't trust.
>
> I was building instead of using cminstall, like the the install
> notes were referring to.  However, before I started, I found
> code in scripts/sysinfo.sh setting up CM3_INSTALL to the default,
> unless already set, which I took to mean this was the way to
> do it when building too.
>
> I did double and triple check my spelling and value of
> CM3_INSTALL, before and after the failed builds.
>
> So how do I get this to work?
>
> This was on LINUXLIBC6.

It certainly used to work, but scripts have changed much in recent
years, and some people rather use python or Windows' cmd scripts etc.

I always need to make sure myself when I try something like that again.
The main thing to look for is the central configuration file or
the set of configuration files that the builder reads. These are
quake scripts of course, and I think there's INSTALL_ROOT.

The current cm3.cfg seems to use a combination of CM3_INSTALL and
INSATLL_ROOT:

1.1       jkrell     14: proc CM3SetInstallRoot() is
                      15:     if defined("INSTALL_ROOT")
                      16:         return
                      17:     end
                      18:     if not equal ($CM3_INSTALL, "")
                      19:         INSTALL_ROOT = $CM3_INSTALL
                      20:         return
                      21:     end
                      22:     INSTALL_ROOT = (path() & SL & "..")
                      23: end

Of course this file may look completely different if you've got an
older installed version of cm3...

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Tue Mar 29 10:07:08 2011
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 29 Mar 2011 08:07:08 +0000
Subject: [M3devel] FW: GCC 4.6.0 Released
In-Reply-To: <4D4B822F-1820-4E91-8543-AA35097A3766@cs.purdue.edu>
References: <20110328072557.GG11563@sunsite.ms.mff.cuni.cz>,
	<COL101-W2D287BFCAEBA44A26313CE6BD0@phx.gbl>,
	<4D4B822F-1820-4E91-8543-AA35097A3766@cs.purdue.edu>
Message-ID: <COL101-W26BEC4765D7A10521AAA4FE6BD0@phx.gbl>


I assume we want it and yeah I might get to it.
I'd like to continue to avoid the gmp/mpfr/mpc dependencies, as well as not bothering with LTO for the forseable future.

 - Jay

From: hosking at cs.purdue.edu
Date: Mon, 28 Mar 2011 22:38:00 -0400
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] FW: GCC 4.6.0 Released



Are you volunteering?  ;-)


On Mar 28, 2011, at 8:04 PM, Jay K wrote:for us to consider..


> Date: Mon, 28 Mar 2011 09:25:57 +0200
> From: jakub at redhat.com
> To: gcc-announce at gcc.gnu.org
> CC: gcc at gcc.gnu.org
> Subject: GCC 4.6.0 Released
> 
> The GNU Compiler Collection version 4.6.0 has been released.
> 
> GCC 4.6.0 is a major release, containing substantial new functionality
> not available in GCC 4.5.x or previous GCC releases.
> 
> The "link-time optimization" framework introduced in GCC 4.5.0 has been
> significantly improved in this release, it is now possible to compile
> very large applications like Mozilla or GCC itself with LTO.
> GCC can now partially inline functions, inlining just hot short path
> to exit and keeping the rest of the function out of line.
> Support for the upcoming C++0x standard has been notably improved,
> Fortran 2003 and 2008 has been greatly extended and many other frontends
> undergone substantial changes as well.
> Many other improvements have been added and more than thousand of bugs
> have been fixed in various parts of the compiler collection.
> 
> See:
> 
> http://gcc.gnu.org/gcc-4.6/changes.html
> 
> for more information about changes in GCC 4.6.0.
> 
> This release is available from the FTP servers listed here:
> 
> http://www.gnu.org/order/ftp.html
> 
> The release is in gcc/gcc-4.6.0/ subdirectory.
> 
> If you encounter difficulties using GCC 4.6, please do not contact me
> directly. Instead, please visit http://gcc.gnu.org for information
> about getting help.
> 
> As always, a vast number of people contributed to this GCC releases --
> far too many to thank individually!

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110329/2599da1f/attachment-0001.html>

From rcolebur at SCIRES.COM  Tue Mar 29 21:40:16 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Tue, 29 Mar 2011 15:40:16 -0400
Subject: [M3devel] About CM3_IDE_UsersGuide format if so
In-Reply-To: <667386.49334.qm@web29719.mail.ird.yahoo.com>
References: <667386.49334.qm@web29719.mail.ird.yahoo.com>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E60341B189BC@atlex02-srv>

Daniel:

I am ok with you or anyone else providing the user guide in additional formats.
I simply provided it in the formats readily available to me at the time.

Regards,
Randy Coleburn

-----Original Message-----
From: Daniel Alejandro Benavides D. [mailto:dabenavidesd at yahoo.es] 
Sent: Monday, March 28, 2011 7:57 PM
To: m3devel at elegosoft.com
Subject: [M3devel] About CM3_IDE_UsersGuide format if so

Hi all:
I wanted to know whether you agree on reformat the CM3_IDE_UserGuide doc file into a standard linear one, like of the doc tools used in cm3 and pm3 repository are based on either tex, html (and back and forth see belo ) or even gnuinfo files, although there some small ones of mtex that I don't know much about and also the noweb files (literate programming like native burs backend is coded or ldb, where still is to be seeing whether generic files are post processed as expected by cm3) that are also plain text files.
I was thinking in make some docs more widely available specifically some improvement over Net Object collector information, since there are two formal proofs of that I believe one is current there (Birrell's collection scheme) and "new" one distributed cyclic garbage collection.
This would allows us to alter proof them by formal and automatic mechanical checking and such gain some more interest in the platform and its collection algorithms:
http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-116.pdf

And subsequent work:
http://kar.kent.ac.uk/21327/

http://www.cs.kent.ac.uk/pubs/1998/926/index.html

and last but not least:
http://www.cs.kent.ac.uk/pubs/2003/1650/

With mechanism such as of the pm3 sgml-obliq it could be shown to convert from ps (with see doi:10.1109/ICDAR.1997.619868 [1]) to html to tex and so on keep improving the situation with respect of lack of annotation information with the current papers, as of anybody who wants to write informally knowledge about it let him do it freely.

Well, just in case you don't mind I will try to add extra converted this docs to lyx, from where it could be later compiled to tex or displayed directly in any other format if so.

Thanks in advance

[1] B. Poirier and M. Dagenais, ?An interactive system to extract structured text from a geometrical representation,? in Document Analysis and Recognition, 1997., Proceedings of the Fourth International Conference on, 1997, vol. 1, pp. 342-346 vol.1.

From dabenavidesd at yahoo.es  Tue Mar 29 22:36:42 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 29 Mar 2011 21:36:42 +0100 (BST)
Subject: [M3devel] About CM3_IDE_UsersGuide format if so
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E60341B189BC@atlex02-srv>
Message-ID: <630972.93901.qm@web29718.mail.ird.yahoo.com>

Hi all:
yes, thanks for the info, would be nice to see some level of integration between the ESC and Modula-3 in cm3ide as I said it shall be pretty easy to deploy network management display of test sessions with the cm3ide tool with Simplify too, so is nice to have documentation on it about that. I guess it would be possible to handle that too in any format, if hosts are kind enough for that, as our hosts allows us to do so, if I am right. Also a good and nice option is for Mobile sessions, to keep an eye on each task, for instance I know you can use some editor for showing error messages, I guess one would be able to reproduce that behavior with ESC errors right, i.e cm3 errors displays line an hyperlinks a editor on line. Thus for instance you can get a report on error messages from the web server and so display a line in the code directly to modify it and run again, I believe.
This is something really useful if we have such an automation of tasks one could think in programming or getting the marked line via twits for instance :) if such agreement is allowed too.
Thanks in advance


--- El mar, 29/3/11, Coleburn, Randy <rcolebur at SCIRES.COM> escribi?:

> De: Coleburn, Randy <rcolebur at SCIRES.COM>
> Asunto: RE: [M3devel] About CM3_IDE_UsersGuide format if so
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>, "m3devel at elegosoft.com" <m3devel at elegosoft.com>
> Fecha: martes, 29 de marzo, 2011 14:40
> Daniel:
> 
> I am ok with you or anyone else providing the user guide in
> additional formats.
> I simply provided it in the formats readily available to me
> at the time.
> 
> Regards,
> Randy Coleburn
> 
> -----Original Message-----
> From: Daniel Alejandro Benavides D. [mailto:dabenavidesd at yahoo.es]
> 
> Sent: Monday, March 28, 2011 7:57 PM
> To: m3devel at elegosoft.com
> Subject: [M3devel] About CM3_IDE_UsersGuide format if so
> 
> Hi all:
> I wanted to know whether you agree on reformat the
> CM3_IDE_UserGuide doc file into a standard linear one, like
> of the doc tools used in cm3 and pm3 repository are based on
> either tex, html (and back and forth see belo ) or even
> gnuinfo files, although there some small ones of mtex that I
> don't know much about and also the noweb files (literate
> programming like native burs backend is coded or ldb, where
> still is to be seeing whether generic files are post
> processed as expected by cm3) that are also plain text
> files.
> I was thinking in make some docs more widely available
> specifically some improvement over Net Object collector
> information, since there are two formal proofs of that I
> believe one is current there (Birrell's collection scheme)
> and "new" one distributed cyclic garbage collection.
> This would allows us to alter proof them by formal and
> automatic mechanical checking and such gain some more
> interest in the platform and its collection algorithms:
> http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-116.pdf

> 
> And subsequent work:
> http://kar.kent.ac.uk/21327/

> 
> http://www.cs.kent.ac.uk/pubs/1998/926/index.html

> 
> and last but not least:
> http://www.cs.kent.ac.uk/pubs/2003/1650/

> 
> With mechanism such as of the pm3 sgml-obliq it could be
> shown to convert from ps (with see
> doi:10.1109/ICDAR.1997.619868 [1]) to html to tex and so on
> keep improving the situation with respect of lack of
> annotation information with the current papers, as of
> anybody who wants to write informally knowledge about it let
> him do it freely.
> 
> Well, just in case you don't mind I will try to add extra
> converted this docs to lyx, from where it could be later
> compiled to tex or displayed directly in any other format if
> so.
> 
> Thanks in advance
> 
> [1] B. Poirier and M. Dagenais, ?An interactive system to
> extract structured text from a geometrical
> representation,? in Document Analysis and Recognition,
> 1997., Proceedings of the Fourth International Conference
> on, 1997, vol. 1, pp. 342-346 vol.1.
> 


From rcolebur at SCIRES.COM  Tue Mar 29 23:26:19 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Tue, 29 Mar 2011 17:26:19 -0400
Subject: [M3devel] About CM3_IDE_UsersGuide format if so
In-Reply-To: <630972.93901.qm@web29718.mail.ird.yahoo.com>
References: <D67F02DDC62F7545A6B84C285F88F3E60341B189BC@atlex02-srv>
	<630972.93901.qm@web29718.mail.ird.yahoo.com>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E60341B18A02@atlex02-srv>

Daniel:

I'm sorry, but I'm not sure I follow your entire train of thought.

If you use CM3IDE to invoke the CM3 builder, any errors during the compilation/build process will be displayed in the browser with a hyperlink to invoke your editor and jump to the line identified as the source of the problem.

The CM3IDE configuration page allows you to specify the editor to be invoked, among other options.

Regards,
Randy Coleburn

-----Original Message-----
From: Daniel Alejandro Benavides D. [mailto:dabenavidesd at yahoo.es] 
Sent: Tuesday, March 29, 2011 4:37 PM
To: m3devel at elegosoft.com; Coleburn, Randy
Subject: RE: [M3devel] About CM3_IDE_UsersGuide format if so

Hi all:
yes, thanks for the info, would be nice to see some level of integration between the ESC and Modula-3 in cm3ide as I said it shall be pretty easy to deploy network management display of test sessions with the cm3ide tool with Simplify too, so is nice to have documentation on it about that. I guess it would be possible to handle that too in any format, if hosts are kind enough for that, as our hosts allows us to do so, if I am right. Also a good and nice option is for Mobile sessions, to keep an eye on each task, for instance I know you can use some editor for showing error messages, I guess one would be able to reproduce that behavior with ESC errors right, i.e cm3 errors displays line an hyperlinks a editor on line. Thus for instance you can get a report on error messages from the web server and so display a line in the code directly to modify it and run again, I believe.
This is something really useful if we have such an automation of tasks one could think in programming or getting the marked line via twits for instance :) if such agreement is allowed too.
Thanks in advance


--- El mar, 29/3/11, Coleburn, Randy <rcolebur at SCIRES.COM> escribi?:

> De: Coleburn, Randy <rcolebur at SCIRES.COM>
> Asunto: RE: [M3devel] About CM3_IDE_UsersGuide format if so
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>, "m3devel at elegosoft.com" <m3devel at elegosoft.com>
> Fecha: martes, 29 de marzo, 2011 14:40
> Daniel:
> 
> I am ok with you or anyone else providing the user guide in
> additional formats.
> I simply provided it in the formats readily available to me
> at the time.
> 
> Regards,
> Randy Coleburn
> 
> -----Original Message-----
> From: Daniel Alejandro Benavides D. [mailto:dabenavidesd at yahoo.es]
> 
> Sent: Monday, March 28, 2011 7:57 PM
> To: m3devel at elegosoft.com
> Subject: [M3devel] About CM3_IDE_UsersGuide format if so
> 
> Hi all:
> I wanted to know whether you agree on reformat the
> CM3_IDE_UserGuide doc file into a standard linear one, like
> of the doc tools used in cm3 and pm3 repository are based on
> either tex, html (and back and forth see belo ) or even
> gnuinfo files, although there some small ones of mtex that I
> don't know much about and also the noweb files (literate
> programming like native burs backend is coded or ldb, where
> still is to be seeing whether generic files are post
> processed as expected by cm3) that are also plain text
> files.
> I was thinking in make some docs more widely available
> specifically some improvement over Net Object collector
> information, since there are two formal proofs of that I
> believe one is current there (Birrell's collection scheme)
> and "new" one distributed cyclic garbage collection.
> This would allows us to alter proof them by formal and
> automatic mechanical checking and such gain some more
> interest in the platform and its collection algorithms:
> http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-116.pdf

> 
> And subsequent work:
> http://kar.kent.ac.uk/21327/

> 
> http://www.cs.kent.ac.uk/pubs/1998/926/index.html

> 
> and last but not least:
> http://www.cs.kent.ac.uk/pubs/2003/1650/

> 
> With mechanism such as of the pm3 sgml-obliq it could be
> shown to convert from ps (with see
> doi:10.1109/ICDAR.1997.619868 [1]) to html to tex and so on
> keep improving the situation with respect of lack of
> annotation information with the current papers, as of
> anybody who wants to write informally knowledge about it let
> him do it freely.
> 
> Well, just in case you don't mind I will try to add extra
> converted this docs to lyx, from where it could be later
> compiled to tex or displayed directly in any other format if
> so.
> 
> Thanks in advance
> 
> [1] B. Poirier and M. Dagenais, ?An interactive system to
> extract structured text from a geometrical
> representation,? in Document Analysis and Recognition,
> 1997., Proceedings of the Fourth International Conference
> on, 1997, vol. 1, pp. 342-346 vol.1.
> 

From dabenavidesd at yahoo.es  Wed Mar 30 02:21:44 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 30 Mar 2011 01:21:44 +0100 (BST)
Subject: [M3devel] About CM3_IDE_UsersGuide format if so
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E60341B18A02@atlex02-srv>
Message-ID: <242549.67696.qm@web29703.mail.ird.yahoo.com>

Hi all:
thanks for your message, and it's Ok, indeed I'm very sorry about that; now the idea behind is that we can invoke "m3build" process (aka cm3) to ESC via esc() quake directive and so subsequently it will call Simplify theorem prover as many times as needed.
As Simplify is able to display its output via ESC command line input parameter and then call the output of it and postprocessed it in ESC to show a source code line number error, e.g array index out of bounds line number xyz, nil deref attempt, unchecked exception, deadlock, etc, so we can get a line number from it and then pass it trough cm3ide to its web output (if Verification Condition VC is correctly generated in ESC that is, Simplify's input and if implied results are positive for source code "errors" at least by its conservatism or formal proof, as also it might be silent in absence of errors either by possible insufficient or too much rigorousness in VCs or if not pass it back to ESC if so to get an error message because of theorem proof is not true or if it doesn't find it, again conservatively speaking), we surely may get this passed through from ESC back to cm3ide to show a similar message hyperlink and "error" line number.
Now in behalf of us we don't have any time to waste we could continue our duties and get a editor call or a twit a message with line and error and enter or twit back the intended solution if so in that line whenever that happens.
As the the Simplify output has html output support for VC falsity, etc, and ESC I still wonder how it will communicate its results, we could adjust that for us in the cm3ide to make that display for us too and show its line number and warning message. Perhaps another cm3ide object method might do that as well, as this "errors" are not fatal, still, it can be shown as warnings (as they really are), then does CM3IDE warning messages come too in same way cm3 errors are shown? If so perhaps this is the way to go. We could select whether to stop compilation process if so if there are selected warnings to do so or if it's asked to continue to do so and don't halt until another instruction is given or it finishes its process. 
As ESC is concerned it would take same time parsing and compiling as cm3 but then another equivalent or more time to check it in VCs theorem proving   meanwhile it might be useful to have that view or display, if for instance it is not happy or unable to prove a given formula to display its VC, in case of false alarm say, or if they are successful steps as they are PROCEDURE by PROCEDURE as ESC goes along each MODULE, so in the end it would take slower time to compile and then recompile it if so as any given module might have a failed proof in a procedure before it checks everything of it. 
Main issue here is that parse trees are different so we can't share their time to type check (assuming we both want to compile and statically check), at least as Verification condition generation is concerned, besides dependency order is determined by cm3 driver and I don't know how it might be get it by m3tk independently if so, so it will for now wait for its type checking and then redo type inference and so and continue to proof so best case scenario both systems will have that to do same type checking and inference to produce a parse tree that will give us a proof that must be verified and if it doesn't satisfy its condition return as an ESC "error" or warning, or finish without complaints if it really does.   
Thanks in advance

--- El mar, 29/3/11, Coleburn, Randy <rcolebur at SCIRES.COM> escribi?:

> De: Coleburn, Randy <rcolebur at SCIRES.COM>
> Asunto: RE: [M3devel] About CM3_IDE_UsersGuide format if so
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>, "m3devel at elegosoft.com" <m3devel at elegosoft.com>
> Fecha: martes, 29 de marzo, 2011 16:26
> Daniel:
> 
> I'm sorry, but I'm not sure I follow your entire train of
> thought.
> 
> If you use CM3IDE to invoke the CM3 builder, any errors
> during the compilation/build process will be displayed in
> the browser with a hyperlink to invoke your editor and jump
> to the line identified as the source of the problem.
> 
> The CM3IDE configuration page allows you to specify the
> editor to be invoked, among other options.
> 
> Regards,
> Randy Coleburn
> 
> -----Original Message-----
> From: Daniel Alejandro Benavides D. [mailto:dabenavidesd at yahoo.es]
> 
> Sent: Tuesday, March 29, 2011 4:37 PM
> To: m3devel at elegosoft.com;
> Coleburn, Randy
> Subject: RE: [M3devel] About CM3_IDE_UsersGuide format if
> so
> 
> Hi all:
> yes, thanks for the info, would be nice to see some level
> of integration between the ESC and Modula-3 in cm3ide as I
> said it shall be pretty easy to deploy network management
> display of test sessions with the cm3ide tool with Simplify
> too, so is nice to have documentation on it about that. I
> guess it would be possible to handle that too in any format,
> if hosts are kind enough for that, as our hosts allows us to
> do so, if I am right. Also a good and nice option is for
> Mobile sessions, to keep an eye on each task, for instance I
> know you can use some editor for showing error messages, I
> guess one would be able to reproduce that behavior with ESC
> errors right, i.e cm3 errors displays line an hyperlinks a
> editor on line. Thus for instance you can get a report on
> error messages from the web server and so display a line in
> the code directly to modify it and run again, I believe.
> This is something really useful if we have such an
> automation of tasks one could think in programming or
> getting the marked line via twits for instance :) if such
> agreement is allowed too.
> Thanks in advance
> 
> 
> --- El mar, 29/3/11, Coleburn, Randy <rcolebur at SCIRES.COM>
> escribi?:
> 
> > De: Coleburn, Randy <rcolebur at SCIRES.COM>
> > Asunto: RE: [M3devel] About CM3_IDE_UsersGuide format
> if so
> > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>,
> "m3devel at elegosoft.com"
> <m3devel at elegosoft.com>
> > Fecha: martes, 29 de marzo, 2011 14:40
> > Daniel:
> > 
> > I am ok with you or anyone else providing the user
> guide in
> > additional formats.
> > I simply provided it in the formats readily available
> to me
> > at the time.
> > 
> > Regards,
> > Randy Coleburn
> > 
> > -----Original Message-----
> > From: Daniel Alejandro Benavides D. [mailto:dabenavidesd at yahoo.es]
> > 
> > Sent: Monday, March 28, 2011 7:57 PM
> > To: m3devel at elegosoft.com
> > Subject: [M3devel] About CM3_IDE_UsersGuide format if
> so
> > 
> > Hi all:
> > I wanted to know whether you agree on reformat the
> > CM3_IDE_UserGuide doc file into a standard linear one,
> like
> > of the doc tools used in cm3 and pm3 repository are
> based on
> > either tex, html (and back and forth see belo ) or
> even
> > gnuinfo files, although there some small ones of mtex
> that I
> > don't know much about and also the noweb files
> (literate
> > programming like native burs backend is coded or ldb,
> where
> > still is to be seeing whether generic files are post
> > processed as expected by cm3) that are also plain
> text
> > files.
> > I was thinking in make some docs more widely
> available
> > specifically some improvement over Net Object
> collector
> > information, since there are two formal proofs of that
> I
> > believe one is current there (Birrell's collection
> scheme)
> > and "new" one distributed cyclic garbage collection.
> > This would allows us to alter proof them by formal
> and
> > automatic mechanical checking and such gain some more
> > interest in the platform and its collection
> algorithms:
> > http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-116.pdf

> 
> > 
> > And subsequent work:
> > http://kar.kent.ac.uk/21327/

> 
> > 
> > http://www.cs.kent.ac.uk/pubs/1998/926/index.html

> 
> > 
> > and last but not least:
> > http://www.cs.kent.ac.uk/pubs/2003/1650/

> 
> > 
> > With mechanism such as of the pm3 sgml-obliq it could
> be
> > shown to convert from ps (with see
> > doi:10.1109/ICDAR.1997.619868 [1]) to html to tex and
> so on
> > keep improving the situation with respect of lack of
> > annotation information with the current papers, as of
> > anybody who wants to write informally knowledge about
> it let
> > him do it freely.
> > 
> > Well, just in case you don't mind I will try to add
> extra
> > converted this docs to lyx, from where it could be
> later
> > compiled to tex or displayed directly in any other
> format if
> > so.
> > 
> > Thanks in advance
> > 
> > [1] B. Poirier and M. Dagenais, ?An interactive
> system to
> > extract structured text from a geometrical
> > representation,? in Document Analysis and
> Recognition,
> > 1997., Proceedings of the Fourth International
> Conference
> > on, 1997, vol. 1, pp. 342-346 vol.1.
> > 
> 


From mika at async.caltech.edu  Tue Mar  1 02:49:49 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Mon, 28 Feb 2011 17:49:49 -0800
Subject: [M3devel] Has anyone seen this crash before?
Message-ID: <20110301014949.B70F01A2078@async.async.caltech.edu>


shownew crashing on LINUXLIBC6 (works fine on e.g., AMD64_LINUX):

This GDB was configured as "i386-redhat-linux-gnu"...
(gdb) run
Starting program: /home/user/mnystrom/cm3/bin/shownew 
[Thread debugging using libthread_db enabled]
[New Thread 0xb7fb16c0 (LWP 30122)]

Program received signal SIGSEGV, Segmentation fault.
0x00be406c in ?? () from /usr/lib/libXcursor.so.1
(gdb) where
#0  0x00be406c in ?? () from /usr/lib/libXcursor.so.1
#1  0x00be44ae in ?? () from /usr/lib/libXcursor.so.1
#2  0x00be45de in XcursorLibraryLoadImages () from /usr/lib/libXcursor.so.1
#3  0x00be462b in XcursorShapeLoadImages () from /usr/lib/libXcursor.so.1
#4  0x00be4f63 in XcursorTryShapeCursor () from /usr/lib/libXcursor.so.1
#5  0x00442d02 in XCreateGlyphCursor () from /usr/lib/libX11.so.6
#6  0x0044318d in XCreateFontCursor () from /usr/lib/libX11.so.6
#7  0x00eb5a8c in XScrnCrsr__CursorLookup (orc=0xb7db6f14, name=0xf50ee4)
    at ../src/xvbt/XScrnCrsr.m3:166
#8  0x00ee491d in Cursor__NameApply (cl=0xb7db4da4, st=0xb7db6ae4)
    at ../src/vbt/Cursor.m3:104
#9  0x00ed44d1 in VBTRep__CursorApply (st=0xb7db6ae4, cl=0xb7db4da4, 
    cs={<No data fields>}) at ../src/vbt/VBTRep.m3:82
#10 0x00ee2b5c in Palette__ResolveCursor (st=0xb7db6ae4, 
    curs={<No data fields>}) at ../src/vbt/Palette.m3:294
#11 0x00ed6738 in VBTRep__CursorResolver (self=0xb7dd1aac)
    at ../src/vbt/VBTRep.m3:488
#12 0x00f9d9ed in ThreadPosix__RunThread ()
    at ../src/thread/POSIX/ThreadPosix.m3:1107
#13 0x0097aa1b in makecontext () from /lib/libc.so.6
#14 0x00000000 in ?? ()
(gdb) 

     Mika


From jay.krell at cornell.edu  Tue Mar  1 11:59:29 2011
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 1 Mar 2011 10:59:29 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <20110227231125.3DC611A2078@async.async.caltech.edu>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>,
	<20110227231125.3DC611A2078@async.async.caltech.edu>
Message-ID: <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>


I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Ah, it just doesn't check command-line arguments that carefully.
> 
> I think what you did is equivalent to "-tests STD".
> 
>      Mika
> 
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist:  On Windows 7, I thought I'd see what the command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash.  Then, I trie=
> >d it again and it ran to completion.  Something seems non-deterministic her=
> >e.  See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >***    Attempt to reference an illegal memory location.
> >***    pc =3D 0x77762262
> >***
> >
> >Stack trace:
> >   FP         PC      Procedure
> >---------  ---------  -------------------------------
> > 0xcdf998  0x130351b  SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0  0x77762262  <???>
> > 0xcdf9d8  0x12e83b7  LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00  0x12c7b08  GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38  0x12c12e3  RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74  0x12e971f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80  0x76543677  <???>
> > 0xcdfbc0  0x77779f02  <???>
> >.........  .........  ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete.  Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2.  That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> >     Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008.  This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung.  I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>***    An array subscript was out of range.
> >>***    file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
> >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>***    <*ASSERT*> failed.
> >>***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >>   threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >>   threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >>     Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results.  Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>***    An enumeration or subrange value was out of range.
> >>>***    file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>>   FP         PC      Procedure
> >>>---------  ---------  -------------------------------
> >>>0x30fbd0  0x127218a  PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0  0x1273825  Main_M3 + 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110301/6c051b49/attachment-0002.html>

From jay.krell at cornell.edu  Tue Mar  1 18:27:40 2011
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 1 Mar 2011 17:27:40 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>
Message-ID: <COL101-W6172E969583BD60401B836E6C10@phx.gbl>


I also haven't seen it fail on OpenBSD/x86/4.7. I'm pretty sure using pthreads there.
But on Solaris/5.10/sparc it hangs, for many hours.

-bash-4.1$ ./threadtest 
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
.

Are we guranteed forward progress in suspending all threads?

I do see it fail usually on Darwin. e.g.:
........pthread_mutex_destroy:EBUSY
pthread_mutex_destroy:EBUSY
..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:
***    An array subscript was out of range.
***    file "../src/runtime/common/RTCollector.m3", line 418
***

I haven't tried Linux yet.
Do note that we have some variance in the pthreads implementation.
The "portable" implementation is used on Linux, Solaris, NetBSD.
And then OpenBSD, Darwin, FreeBSD each have slight differences.

Mika are your machines all multiprocessors?
I do wonder if that helps increase the stress and if I should be sure to use multiprocessors.

I'm also considering taking the time to try various historical versions, either releases or dates in CVS.

 - Jay

From: jay.krell at cornell.edu
To: mika at async.caltech.edu; rcolebur at scires.com
Date: Tue, 1 Mar 2011 10:59:29 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] results of threadtest program on Windows7








I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Ah, it just doesn't check command-line arguments that carefully.
> 
> I think what you did is equivalent to "-tests STD".
> 
>      Mika
> 
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist:  On Windows 7, I thought I'd see what the command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash.  Then, I trie=
> >d it again and it ran to completion.  Something seems non-deterministic her=
> >e.  See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >***    Attempt to reference an illegal memory location.
> >***    pc =3D 0x77762262
> >***
> >
> >Stack trace:
> >   FP         PC      Procedure
> >---------  ---------  -------------------------------
> > 0xcdf998  0x130351b  SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0  0x77762262  <???>
> > 0xcdf9d8  0x12e83b7  LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00  0x12c7b08  GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38  0x12c12e3  RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74  0x12e971f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80  0x76543677  <???>
> > 0xcdfbc0  0x77779f02  <???>
> >.........  .........  ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete.  Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2.  That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> >     Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008.  This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung.  I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>***    An array subscript was out of range.
> >>***    file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
> >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>***    <*ASSERT*> failed.
> >>***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >>   threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >>   threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >>     Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results.  Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>***    An enumeration or subrange value was out of range.
> >>>***    file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>>   FP         PC      Procedure
> >>>---------  ---------  -------------------------------
> >>>0x30fbd0  0x127218a  PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0  0x1273825  Main_M3 + 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110301/8f3b432d/attachment-0002.html>

From mika at async.caltech.edu  Tue Mar  1 19:17:18 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Tue, 01 Mar 2011 10:17:18 -0800
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W6172E969583BD60401B836E6C10@phx.gbl> 
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>
	<COL101-W6172E969583BD60401B836E6C10@phx.gbl>
Message-ID: <20110301181718.12EFC1A2078@async.async.caltech.edu>


Hi Jay,

1. I think you should get forward progress no matter what, although it
might be very slow on some systems.

2. Not sure how you could get negative timings.  That would suggest that
Time.Now() is decreasing---which seems contrary to its specification.
Although the code is doing some nasty stuff with the timings, mainly
reading and writing them without locks.  But it's using INTEGER for
the results so I don't think there can be an atomicity problem there.
Even if there were coherence problems between processors (is this
technically possible?) the "now" value has to be coherent since it's
from the thread that prints the results, and the "then" values could
only be getting older, not newer...

3. Note that there are systems (FreeBSD 4 is an example) that have a
"pthreads" library but where the pthreads library is implemented with
user threads.  Could that be related to why OpenBSD is working?

4. Hm.  I think I am only using multiprocessor systems, yes.  Hard to
find single-CPU systems nowadays!  I think actually the only one I have
is PPC_DARWIN, and I haven't tried the code on that.  So yes this is a
possibility as far as explaining differences...

     Mika

Jay K writes:
>--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>I also haven't seen it fail on OpenBSD/x86/4.7. I'm pretty sure using pthre=
>ads there.
>But on Solaris/5.10/sparc it hangs=2C for many hours.
>
>-bash-4.1$ ./threadtest=20
>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
>.
>
>Are we guranteed forward progress in suspending all threads?
>
>I do see it fail usually on Darwin. e.g.:
>........pthread_mutex_destroy:EBUSY
>pthread_mutex_destroy:EBUSY
>..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:
>***    An array subscript was out of range.
>***    file "../src/runtime/common/RTCollector.m3"=2C line 418
>***
>
>I haven't tried Linux yet.
>Do note that we have some variance in the pthreads implementation.
>The "portable" implementation is used on Linux=2C Solaris=2C NetBSD.
>And then OpenBSD=2C Darwin=2C FreeBSD each have slight differences.
>
>Mika are your machines all multiprocessors?
>I do wonder if that helps increase the stress and if I should be sure to us=
>e multiprocessors.
>
>I'm also considering taking the time to try various historical versions=2C =
>either releases or dates in CVS.
>
> - Jay
>
>From: jay.krell at cornell.edu
>To: mika at async.caltech.edu=3B rcolebur at scires.com
>Date: Tue=2C 1 Mar 2011 10:59:29 +0000
>CC: m3devel at elegosoft.com
>Subject: Re: [M3devel] results of threadtest program on Windows7
>
>
>
>
>
>
>
>
>I haven't seen it fail on NT=2C except for PutCard in the test itself getti=
>ng negative numbers.
>I've run it just a few times now. One single and dual processor virtual mac=
>hines.
>Randy=2C has it failed many times for you?
>
> - Jay
>
>> To: rcolebur at SCIRES.COM
>> Date: Sun=2C 27 Feb 2011 15:11:25 -0800
>> From: mika at async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] results of threadtest program on Windows7
>>=20
>> Ah=2C it just doesn't check command-line arguments that carefully.
>>=20
>> I think what you did is equivalent to "-tests STD".
>=20
>>      Mika
>>=20
>> "Coleburn=2C Randy" writes:
>> >Mika:
>> >
>> >No change with "-tests POSIX".
>> >
>> >Interesting twist:  On Windows 7=2C I thought I'd see what the command l=
>ine o=3D
>> >ptions are=2C and I typed "threadtest -help" rather than reading the cod=
>e.
>> >
>> >First time=2C it produced what appears to be a NIL deref crash.  Then=2C=
> I trie=3D
>> >d it again and it ran to completion.  Something seems non-deterministic =
>her=3D
>> >e.  See below.
>> >
>> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
>> >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
>> >.
>> >
>> >***
>> >*** runtime error:
>> >***    Attempt to reference an illegal memory location.
>> >***    pc =3D3D 0x77762262
>> >***
>> >
>> >Stack trace:
>> >   FP         PC      Procedure
>> >---------  ---------  -------------------------------
>> > 0xcdf998  0x130351b  SystemError + 0x64 in ..\src\runtime\NT386\RTSigna=
>l.m=3D
>> >3
>> > 0xcdf9c0  0x77762262  <???>
>> > 0xcdf9d8  0x12e83b7  LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin3=
>2.m=3D
>> >3
>> > 0xcdfa00  0x12c7b08  GetChar + 0x28 in ..\src\rw\Rd.m3
>> > 0xcdfb38  0x12c12e3  RApply + 0xd3 in ..\src\Main.m3
>> > 0xcdfb74  0x12e971f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWi=
>n32=3D
>> >.m3
>> > 0xcdfb80  0x76543677  <???>
>> > 0xcdfbc0  0x77779f02  <???>
>> >.........  .........  ... more frames ...
>> >
>> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
>> >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
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/=
>0/0=3D
>> > lock 0/0/0)
>> >All tests complete.  Congratulations.
>> >
>> >Regards=2C
>> >Randy Coleburn
>> >
>> >-----Original Message-----
>> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
>> >Sent: Sunday=2C February 27=2C 2011 3:30 PM
>> >To: Coleburn=2C Randy
>> >Cc: m3devel at elegosoft.com
>> >Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
>> >
>> >Hi Randy=2C
>> >
>> >You can try it with -tests POSIX as well.
>> >
>> >I find on user threads it runs very slowly (but it does run) because of =
>how=3D
>> > unfair
>> >the thread scheduler is.
>> >
>> >Next step might be to whittle down the tests and see if you can get a fa=
>ilu=3D
>> >re with
>> >a single test running and -n 2.  That would likely be the simplest scena=
>rio=3D
>> > to
>> >start further debugging from.
>> >
>> >     Mika
>> >
>> >"Coleburn=2C Randy" writes:
>> >>Mika et al:
>> >>
>> >>Thought I would try something else.
>> >>
>> >>I took the sources of your thread test program to an older XP machine t=
>hat=3D
>> > =3D3D
>> >>has CM3 circa August 2008.  This is the machine and implementation I us=
>ed =3D
>> >w=3D3D
>> >>hen building a major project I did a couple years back.
>> >>
>> >>The thread test program does indeed build on this old system=2C but whe=
>n I r=3D
>> >u=3D3D
>> >>n it=2C I get different results than with the latest HEAD branch code. =
>=3D3D20
>> >>
>> >>After it prints "running...printing oldest/median age/newest"=2C on the=
> next=3D
>> > =3D3D
>> >>line I get two periods ".." and now the program seems hung.  I'll let i=
>t "=3D
>> >r=3D3D
>> >>un" for a few more minutes to see if anything else happens before killi=
>ng =3D
>> >i=3D3D
>> >>t.
>> >>
>> >>At least we don't get the subscript and assertion failures on this olde=
>r C=3D
>> >M=3D3D
>> >>3 platform.
>> >>
>> >>Regards=2C
>> >>Randy Coleburn
>> >>
>> >>
>> >>-----Original Message-----
>> >>From: Coleburn=2C Randy=3D3D20
>> >>Sent: Sunday=2C February 27=2C 2011 2:09 PM
>> >>To: m3devel at elegosoft.com
>> >>Subject: Re: [M3devel] results of threadtest program on Windows7
>> >>
>> >>Mika:
>> >>
>> >>Ok=2C I've updated to latest HEAD and I've also built Jay's m3sleep pro=
>gram.
>> >>
>> >>Here is what happens now when I run your threadtest program on Windows =
>7.
>> >>
>> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL=
>=2C-fo=3D
>> >r=3D3D
>> >>k
>> >>Writing file...done
>> >>Creating read threads...done
>> >>Creating nxread threads...done
>> >>Creating tryexcept threads...done
>> >>Creating forktoomuch threads...done
>> >>Creating alloc threads...done
>> >>Creating creat threads...done
>> >>Creating lock threads...done
>> >>running...printing oldest/median age/newest
>> >>
>> >>
>> >>***
>> >>*** runtime error:
>> >>***    An array subscript was out of range.
>> >>***    file "..\src\runtime\common\RTCollector.m3"=2C line 418
>> >>***
>> >>
>> >>
>> >>
>> >>***
>> >>*** runtime error:
>> >>***    <*ASSERT*> failed.
>> >>***    file "..\src\thread\WIN32\ThreadWin32.m3"=2C line 841
>> >>***
>> >>
>> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
>> >>
>> >>I'll send more info on the Windows install of Modula3 in a subsequent p=
>ost=3D
>> >.
>> >>
>> >>Regards=2C
>> >>Randy Coleburn
>> >>
>> >>-----Original Message-----
>> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D3D20
>> >>Sent: Saturday=2C February 26=2C 2011 12:55 PM
>> >>To: Coleburn=2C Randy
>> >>Cc: m3devel at elegosoft.com
>> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D3D20
>> >>
>> >>Hi Randy=2C
>> >>
>> >>Hm yes it looks like my Windows programming skills leave something
>> >>to be desired.
>> >>
>> >>You can run the thread tester while skipping a test as follows
>> >>
>> >>   threadtest -tests ALL=2C-fork
>> >>
>> >>(for instance)
>> >>
>> >>if you just run=3D3D20
>> >>
>> >>   threadtest -sadfassdaf
>> >>
>> >>it'll print the tests that are available.
>> >>
>> >>As it happens=2C I just had to upgrade my windows 2000 system to window=
>s 7.
>> >>Can you give me a very brief description of what you did to install Mod=
>ula=3D
>> >-=3D3D
>> >>3
>> >>on this system?
>> >>
>> >>     Mika
>> >>
>> >>"Coleburn=2C Randy" writes:
>> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
>> >>>Content-Type: text/plain=3B charset=3D3D3D"us-ascii"
>> >>>Content-Transfer-Encoding: quoted-printable
>> >>>
>> >>>Mika:
>> >>>
>> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
>> >>>
>> >>>So=2C I ran your threadtest program.
>> >>>
>> >>>Here are the results.  Note the "..." is where I cut out a bunch of th=
>e r=3D
>> >e=3D3D
>> >>p=3D3D3D
>> >>>eating "ERROR FApply" messages.
>> >>>
>> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
>> >>>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
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>.
>> >>>.
>> >>>.
>> >>>***
>> >>>*** runtime error:
>> >>>***    An enumeration or subrange value was out of range.
>> >>>***    file "..\src\Main.m3"=2C line 340
>> >>>***
>> >>>
>> >>>laziest thread is 0/0/ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: T=
>he sy=3D
>> >ste=3D3D
>> >>m c=3D3D3D
>> >>>annot find the file specified.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>.
>> >>>.
>> >>>.
>> >>>laziest thread is 0/0/ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: T=
>he sy=3D
>> >ste=3D3D
>> >>m c=3D3D3D
>> >>>annot find the file specified.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>.
>> >>>.
>> >>>.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find =
>the f=3D
>> >ile=3D3D
>> >> sp=3D3D3D
>> >>>ecified.
>> >>>Stack trace:
>> >>>   FP         PC      Procedure
>> >>>---------  ---------  -------------------------------
>> >>>0x30fbd0  0x127218a  PutStats + 0x1a3 in ..\src\Main.m3
>> >>>0x30fcc0  0x1273825  Main_M3 + 0x11db(!) in ..\src\Main.m3
>> >>>
>> >>>Regards=2C
>> >>>Randy Coleburn
>> >>>
>> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
>> >>>Content-Type: text/html=3B charset=3D3D3D"us-ascii"
>> >>>Content-Transfer-Encoding: quoted-printable
>> >>>
> 		 	   		  =
>
>--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Tahoma
>}
>--></style>
></head>
><body class=3D'hmmessage'>
>I also haven't seen it fail on OpenBSD/x86/4.7. I'm pretty sure using pthre=
>ads there.<br>But on Solaris/5.10/sparc it hangs=2C for many hours.<br><br>=
>-bash-4.1$ ./threadtest <br>Writing file...done<br>Creating read threads...=
>done<br>Creating fork threads...done<br>Creating alloc threads...done<br>Cr=
>eating lock threads...done<br>running...printing oldest/median age/newest<b=
>r>.<br><br>Are we guranteed forward progress in suspending all threads?<br>=
><br>I do see it fail usually on Darwin. e.g.:<br>........pthread_mutex_dest=
>roy:EBUSY<br>pthread_mutex_destroy:EBUSY<br>..laziest thread is 0/0/0 (test=
>s: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)<br>...<br><br>***<br>*** r=
>untime error:<br>***&nbsp=3B&nbsp=3B&nbsp=3B An array subscript was out of =
>range.<br>***&nbsp=3B&nbsp=3B&nbsp=3B file "../src/runtime/common/RTCollect=
>or.m3"=2C line 418<br>***<br><br>I haven't tried Linux yet.<br>Do note that=
> we have some variance in the pthreads implementation.<br>The "portable" im=
>plementation is used on Linux=2C Solaris=2C NetBSD.<br>And then OpenBSD=2C =
>Darwin=2C FreeBSD each have slight differences.<br><br>Mika are your machin=
>es all multiprocessors?<br>I do wonder if that helps increase the stress an=
>d if I should be sure to use multiprocessors.<br><br>I'm also considering t=
>aking the time to try various historical versions=2C either releases or dat=
>es in CVS.<br><br>&nbsp=3B- Jay<br><br><hr id=3D"stopSpelling">From: jay.kr=
>ell at cornell.edu<br>To: mika at async.caltech.edu=3B rcolebur at scires.com<br>Dat=
>e: Tue=2C 1 Mar 2011 10:59:29 +0000<br>CC: m3devel at elegosoft.com<br>Subject=
>: Re: [M3devel] results of threadtest program on Windows7<br><br>
>
><meta http-equiv=3D"Content-Type" content=3D"text/html=3B charset=3Dunicode=
>">
><meta name=3D"Generator" content=3D"Microsoft SafeHTML">
><style>
>.ExternalClass .ecxhmmessage P
>{padding:0px=3B}
>.ExternalClass body.ecxhmmessage
>{font-size:10pt=3Bfont-family:Tahoma=3B}
>
></style>
>
>
>I haven't seen it fail on NT=2C except for PutCard in the test itself getti=
>ng negative numbers.<br>I've run it just a few times now. One single and du=
>al processor virtual machines.<br>Randy=2C has it failed many times for you=
>?<br><br>&nbsp=3B- Jay<br><br>&gt=3B To: rcolebur at SCIRES.COM<br>&gt=3B Date=
>: Sun=2C 27 Feb 2011 15:11:25 -0800<br>&gt=3B From: mika at async.caltech.edu<=
>br>&gt=3B CC: m3devel at elegosoft.com<br>&gt=3B Subject: Re: [M3devel] result=
>s of threadtest program on Windows7<br>&gt=3B <br>&gt=3B Ah=2C it just does=
>n't check command-line arguments that carefully.<br>&gt=3B <br>&gt=3B I thi=
>nk what you did is equivalent to "-tests STD".<br>&gt=3B <br>&gt=3B      Mi=
>ka<br>&gt=3B <br>&gt=3B "Coleburn=2C Randy" writes:<br>&gt=3B &gt=3BMika:<b=
>r>&gt=3B &gt=3B<br>&gt=3B &gt=3BNo change with "-tests POSIX".<br>&gt=3B &g=
>t=3B<br>&gt=3B &gt=3BInteresting twist:  On Windows 7=2C I thought I'd see =
>what the command line o=3D<br>&gt=3B &gt=3Bptions are=2C and I typed "threa=
>dtest -help" rather than reading the code.<br>&gt=3B &gt=3B<br>&gt=3B &gt=
>=3BFirst time=2C it produced what appears to be a NIL deref crash.  Then=2C=
> I trie=3D<br>&gt=3B &gt=3Bd it again and it ran to completion.  Something =
>seems non-deterministic her=3D<br>&gt=3B &gt=3Be.  See below.<br>&gt=3B &gt=
>=3B<br>&gt=3B &gt=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bt=
>hreadtest.exe -help<br>&gt=3B &gt=3BWriting file...done<br>&gt=3B &gt=3BCre=
>ating read threads...done<br>&gt=3B &gt=3BCreating fork threads...done<br>&=
>gt=3B &gt=3BCreating alloc threads...done<br>&gt=3B &gt=3BCreating lock thr=
>eads...done<br>&gt=3B &gt=3Brunning...printing oldest/median age/newest<br>=
>&gt=3B &gt=3B.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B***<br>&gt=3B &gt=3B*** run=
>time error:<br>&gt=3B &gt=3B***    Attempt to reference an illegal memory l=
>ocation.<br>&gt=3B &gt=3B***    pc =3D3D 0x77762262<br>&gt=3B &gt=3B***<br>=
>&gt=3B &gt=3B<br>&gt=3B &gt=3BStack trace:<br>&gt=3B &gt=3B   FP         PC=
>      Procedure<br>&gt=3B &gt=3B---------  ---------  ---------------------=
>----------<br>&gt=3B &gt=3B 0xcdf998  0x130351b  SystemError + 0x64 in ..\s=
>rc\runtime\NT386\RTSignal.m=3D<br>&gt=3B &gt=3B3<br>&gt=3B &gt=3B 0xcdf9c0 =
> 0x77762262  &lt=3B???&gt=3B<br>&gt=3B &gt=3B 0xcdf9d8  0x12e83b7  LockMute=
>x + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=3D<br>&gt=3B &gt=3B3<br>&gt=
>=3B &gt=3B 0xcdfa00  0x12c7b08  GetChar + 0x28 in ..\src\rw\Rd.m3<br>&gt=3B=
> &gt=3B 0xcdfb38  0x12c12e3  RApply + 0xd3 in ..\src\Main.m3<br>&gt=3B &gt=
>=3B 0xcdfb74  0x12e971f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWi=
>n32=3D<br>&gt=3B &gt=3B.m3<br>&gt=3B &gt=3B 0xcdfb80  0x76543677  &lt=3B???=
>&gt=3B<br>&gt=3B &gt=3B 0xcdfbc0  0x77779f02  &lt=3B???&gt=3B<br>&gt=3B &gt=
>=3B.........  .........  ... more frames ...<br>&gt=3B &gt=3B<br>&gt=3B &gt=
>=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest.exe -he=
>lp<br>&gt=3B &gt=3BWriting file...done<br>&gt=3B &gt=3BCreating read thread=
>s...done<br>&gt=3B &gt=3BCreating fork threads...done<br>&gt=3B &gt=3BCreat=
>ing alloc threads...done<br>&gt=3B &gt=3BCreating lock threads...done<br>&g=
>t=3B &gt=3Brunning...printing oldest/median age/newest<br>&gt=3B &gt=3B....=
>......laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=3D<=
>br>&gt=3B &gt=3B lock 0/0/0)<br>&gt=3B &gt=3B..........laziest thread is 0/=
>0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/=
>0)<br>&gt=3B &gt=3B..........laziest thread is 0/0/0 (tests: read 0/0/0 for=
>k 0/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/0)<br>&gt=3B &gt=3B.......=
>...laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=3D<br>=
>&gt=3B &gt=3B lock 0/0/0)<br>&gt=3B &gt=3B..........laziest thread is 0/0/0=
> (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/0)<=
>br>&gt=3B &gt=3B..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0=
>/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/0)<br>&gt=3B &gt=3B..........=
>laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=3D<br>&gt=
>=3B &gt=3B lock 0/0/0)<br>&gt=3B &gt=3B..........laziest thread is 0/0/0 (t=
ests: read 0/0/0 fork 0/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/0)<br>=
>&gt=3B &gt=3B..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/=
>0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/0)<br>&gt=3B &gt=3B..........laz=
>iest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=3D<br>&gt=3B=
> &gt=3B lock 0/0/0)<br>&gt=3B &gt=3BAll tests complete.  Congratulations.<b=
>r>&gt=3B &gt=3B<br>&gt=3B &gt=3BRegards=2C<br>&gt=3B &gt=3BRandy Coleburn<b=
>r>&gt=3B &gt=3B<br>&gt=3B &gt=3B-----Original Message-----<br>&gt=3B &gt=3B=
>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20<br>&gt=3B &gt=3BSen=
>t: Sunday=2C February 27=2C 2011 3:30 PM<br>&gt=3B &gt=3BTo: Coleburn=2C Ra=
>ndy<br>&gt=3B &gt=3BCc: m3devel at elegosoft.com<br>&gt=3B &gt=3BSubject: Re: =
>[M3devel] results of threadtest program on Windows7=3D20<br>&gt=3B &gt=3B<b=
>r>&gt=3B &gt=3BHi Randy=2C<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BYou can try it =
>with -tests POSIX as well.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BI find on user =
>threads it runs very slowly (but it does run) because of how=3D<br>&gt=3B &=
>gt=3B unfair<br>&gt=3B &gt=3Bthe thread scheduler is.<br>&gt=3B &gt=3B<br>&=
>gt=3B &gt=3BNext step might be to whittle down the tests and see if you can=
> get a failu=3D<br>&gt=3B &gt=3Bre with<br>&gt=3B &gt=3Ba single test runni=
>ng and -n 2.  That would likely be the simplest scenario=3D<br>&gt=3B &gt=
>=3B to<br>&gt=3B &gt=3Bstart further debugging from.<br>&gt=3B &gt=3B<br>&g=
>t=3B &gt=3B     Mika<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B"Coleburn=2C Randy" w=
>rites:<br>&gt=3B &gt=3B&gt=3BMika et al:<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &=
>gt=3B&gt=3BThought I would try something else.<br>&gt=3B &gt=3B&gt=3B<br>&g=
>t=3B &gt=3B&gt=3BI took the sources of your thread test program to an older=
> XP machine that=3D<br>&gt=3B &gt=3B =3D3D<br>&gt=3B &gt=3B&gt=3Bhas CM3 ci=
>rca August 2008.  This is the machine and implementation I used =3D<br>&gt=
>=3B &gt=3Bw=3D3D<br>&gt=3B &gt=3B&gt=3Bhen building a major project I did a=
> couple years back.<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3BThe thread=
> test program does indeed build on this old system=2C but when I r=3D<br>&g=
>t=3B &gt=3Bu=3D3D<br>&gt=3B &gt=3B&gt=3Bn it=2C I get different results tha=
>n with the latest HEAD branch code. =3D3D20<br>&gt=3B &gt=3B&gt=3B<br>&gt=
>=3B &gt=3B&gt=3BAfter it prints "running...printing oldest/median age/newes=
>t"=2C on the next=3D<br>&gt=3B &gt=3B =3D3D<br>&gt=3B &gt=3B&gt=3Bline I ge=
>t two periods ".." and now the program seems hung.  I'll let it "=3D<br>&gt=
>=3B &gt=3Br=3D3D<br>&gt=3B &gt=3B&gt=3Bun" for a few more minutes to see if=
> anything else happens before killing =3D<br>&gt=3B &gt=3Bi=3D3D<br>&gt=3B =
>&gt=3B&gt=3Bt.<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3BAt least we don=
>'t get the subscript and assertion failures on this older C=3D<br>&gt=3B &g=
>t=3BM=3D3D<br>&gt=3B &gt=3B&gt=3B3 platform.<br>&gt=3B &gt=3B&gt=3B<br>&gt=
>=3B &gt=3B&gt=3BRegards=2C<br>&gt=3B &gt=3B&gt=3BRandy Coleburn<br>&gt=3B &=
>gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B-----Original Mess=
>age-----<br>&gt=3B &gt=3B&gt=3BFrom: Coleburn=2C Randy=3D3D20<br>&gt=3B &gt=
>=3B&gt=3BSent: Sunday=2C February 27=2C 2011 2:09 PM<br>&gt=3B &gt=3B&gt=3B=
>To: m3devel at elegosoft.com<br>&gt=3B &gt=3B&gt=3BSubject: Re: [M3devel] resu=
>lts of threadtest program on Windows7<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=
>=3B&gt=3BMika:<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3BOk=2C I've upda=
>ted to latest HEAD and I've also built Jay's m3sleep program.<br>&gt=3B &gt=
>=3B&gt=3B<br>&gt=3B &gt=3B&gt=3BHere is what happens now when I run your th=
>readtest program on Windows 7.<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
>=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest -tests =
>ALL=2C-fo=3D<br>&gt=3B &gt=3Br=3D3D<br>&gt=3B &gt=3B&gt=3Bk<br>&gt=3B &gt=
>=3B&gt=3BWriting file...done<br>&gt=3B &gt=3B&gt=3BCreating read threads...=
>done<br>&gt=3B &gt=3B&gt=3BCreating nxread threads...done<br>&gt=3B &gt=3B&=
>gt=3BCreating tryexcept threads...done<br>&gt=3B &gt=3B&gt=3BCreating forkt=
>oomuch threads...done<br>&gt=3B &gt=3B&gt=3BCreating alloc threads...done<b=
>r>&gt=3B &gt=3B&gt=3BCreating creat threads...done<br>&gt=3B &gt=3B&gt=3BCr=
>eating lock threads...done<br>&gt=3B &gt=3B&gt=3Brunning...printing oldest/=
>median age/newest<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &=
>gt=3B&gt=3B***<br>&gt=3B &gt=3B&gt=3B*** runtime error:<br>&gt=3B &gt=3B&gt=
>=3B***    An array subscript was out of range.<br>&gt=3B &gt=3B&gt=3B***   =
> file "..\src\runtime\common\RTCollector.m3"=2C line 418<br>&gt=3B &gt=3B&g=
>t=3B***<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
>=3B<br>&gt=3B &gt=3B&gt=3B***<br>&gt=3B &gt=3B&gt=3B*** runtime error:<br>&=
>gt=3B &gt=3B&gt=3B***    &lt=3B*ASSERT*&gt=3B failed.<br>&gt=3B &gt=3B&gt=
>=3B***    file "..\src\thread\WIN32\ThreadWin32.m3"=2C line 841<br>&gt=3B &=
>gt=3B&gt=3B***<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3BThe last error =
>repeats ad infinitum until I press CNTRL-C to abort.<br>&gt=3B &gt=3B&gt=3B=
><br>&gt=3B &gt=3B&gt=3BI'll send more info on the Windows install of Modula=
>3 in a subsequent post=3D<br>&gt=3B &gt=3B.<br>&gt=3B &gt=3B&gt=3B<br>&gt=
>=3B &gt=3B&gt=3BRegards=2C<br>&gt=3B &gt=3B&gt=3BRandy Coleburn<br>&gt=3B &=
>gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B-----Original Message-----<br>&gt=3B &gt=
>=3B&gt=3BFrom: Mika Nystrom [mailto:mika at async.caltech.edu]=3D3D20<br>&gt=
>=3B &gt=3B&gt=3BSent: Saturday=2C February 26=2C 2011 12:55 PM<br>&gt=3B &g=
>t=3B&gt=3BTo: Coleburn=2C Randy<br>&gt=3B &gt=3B&gt=3BCc: m3devel at elegosoft=
>.com<br>&gt=3B &gt=3B&gt=3BSubject: Re: [M3devel] results of threadtest pro=
>gram on Windows7=3D3D20<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3BHi Ran=
>dy=2C<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3BHm yes it looks like my =
>Windows programming skills leave something<br>&gt=3B &gt=3B&gt=3Bto be desi=
>red.<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3BYou can run the thread te=
>ster while skipping a test as follows<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=
>=3B&gt=3B   threadtest -tests ALL=2C-fork<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B =
>&gt=3B&gt=3B(for instance)<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3Bif =
>you just run=3D3D20<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B   threadt=
>est -sadfassdaf<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3Bit'll print th=
>e tests that are available.<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3BAs=
> it happens=2C I just had to upgrade my windows 2000 system to windows 7.<b=
>r>&gt=3B &gt=3B&gt=3BCan you give me a very brief description of what you d=
>id to install Modula=3D<br>&gt=3B &gt=3B-=3D3D<br>&gt=3B &gt=3B&gt=3B3<br>&=
>gt=3B &gt=3B&gt=3Bon this system?<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&g=
>t=3B     Mika<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B"Coleburn=2C Ran=
>dy" writes:<br>&gt=3B &gt=3B&gt=3B&gt=3B--_000_D67F02DDC62F7545A6B84C285F88=
>F3E6EE25C849atlex02srv_<br>&gt=3B &gt=3B&gt=3B&gt=3BContent-Type: text/plai=
>n=3B charset=3D3D3D"us-ascii"<br>&gt=3B &gt=3B&gt=3B&gt=3BContent-Transfer-=
>Encoding: quoted-printable<br>&gt=3B &gt=3B&gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
>=3B&gt=3BMika:<br>&gt=3B &gt=3B&gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B&gt=3BI'v=
>e finally managed to get cm3 rebuilt on Windows 7 again.<br>&gt=3B &gt=3B&g=
>t=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B&gt=3BSo=2C I ran your threadtest program.=
><br>&gt=3B &gt=3B&gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B&gt=3BHere are the resu=
>lts.  Note the "..." is where I cut out a bunch of the r=3D<br>&gt=3B &gt=
>=3Be=3D3D<br>&gt=3B &gt=3B&gt=3Bp=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Beating=
> "ERROR FApply" messages.<br>&gt=3B &gt=3B&gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
>=3B&gt=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest.e=
>xe<br>&gt=3B &gt=3B&gt=3B&gt=3BWriting file...done<br>&gt=3B &gt=3B&gt=3B&g=
>t=3BCreating read threads...done<br>&gt=3B &gt=3B&gt=3B&gt=3BCreating fork =
>threads...done<br>&gt=3B &gt=3B&gt=3B&gt=3BCreating alloc threads...done<br=
>>&gt=3B &gt=3B&gt=3B&gt=3BCreating lock threads...done<br>&gt=3B &gt=3B&gt=
>=3B&gt=3Brunning...printing oldest/median age/newest<br>&gt=3B &gt=3B&gt=3B=
>&gt=3BERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find=
> the f=3D<br>&gt=3B &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B sp=3D3D3D<br>&gt=
>=3B &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B &gt=3B&gt=3B&gt=3BERROR FApply: OS=
>Error.E:  ErrorCode=3D3D3D3D2: The system cannot find the f=3D<br>&gt=3B &g=
>t=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B sp=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Be=
>cified.<br>&gt=3B &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E:  ErrorCode=3D3=
>D3D3D2: The system cannot find the f=3D<br>&gt=3B &gt=3Bile=3D3D<br>&gt=3B =
>&gt=3B&gt=3B sp=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B &gt=
>=3B&gt=3B&gt=3B.<br>&gt=3B &gt=3B&gt=3B&gt=3B.<br>&gt=3B &gt=3B&gt=3B&gt=3B=
>.<br>&gt=3B &gt=3B&gt=3B&gt=3B***<br>&gt=3B &gt=3B&gt=3B&gt=3B*** runtime e=
>rror:<br>&gt=3B &gt=3B&gt=3B&gt=3B***    An enumeration or subrange value w=
>as out of range.<br>&gt=3B &gt=3B&gt=3B&gt=3B***    file "..\src\Main.m3"=
>=2C line 340<br>&gt=3B &gt=3B&gt=3B&gt=3B***<br>&gt=3B &gt=3B&gt=3B&gt=3B<b=
>r>&gt=3B &gt=3B&gt=3B&gt=3Blaziest thread is 0/0/ERROR FApply: OSError.E:  =
>ErrorCode=3D3D3D3D2: The sy=3D<br>&gt=3B &gt=3Bste=3D3D<br>&gt=3B &gt=3B&gt=
>=3Bm c=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Bannot find the file specified.<br=
>>&gt=3B &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: Th=
>e system cannot find the f=3D<br>&gt=3B &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=
>=3B sp=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B &gt=3B&gt=3B&g=
>t=3BERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find t=
>he f=3D<br>&gt=3B &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B sp=3D3D3D<br>&gt=3B=
> &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B &gt=3B&gt=3B&gt=3BERROR FApply: OSErr=
>or.E:  ErrorCode=3D3D3D3D2: The system cannot find the f=3D<br>&gt=3B &gt=
>=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B sp=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Bec=
>ified.<br>&gt=3B &gt=3B&gt=3B&gt=3B.<br>&gt=3B &gt=3B&gt=3B&gt=3B.<br>&gt=
>=3B &gt=3B&gt=3B&gt=3B.<br>&gt=3B &gt=3B&gt=3B&gt=3Blaziest thread is 0/0/E=
>RROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The sy=3D<br>&gt=3B &gt=3Bste=
>=3D3D<br>&gt=3B &gt=3B&gt=3Bm c=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Bannot fi=
>nd the file specified.<br>&gt=3B &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E:=
>  ErrorCode=3D3D3D3D2: The system cannot find the f=3D<br>&gt=3B &gt=3Bile=
>=3D3D<br>&gt=3B &gt=3B&gt=3B sp=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Becified.=
><br>&gt=3B &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2:=
> The system cannot find the f=3D<br>&gt=3B &gt=3Bile=3D3D<br>&gt=3B &gt=3B&=
>gt=3B sp=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B &gt=3B&gt=3B=
>&gt=3BERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find=
> the f=3D<br>&gt=3B &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B sp=3D3D3D<br>&gt=
>=3B &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B &gt=3B&gt=3B&gt=3B.<br>&gt=3B &gt=
>=3B&gt=3B&gt=3B.<br>&gt=3B &gt=3B&gt=3B&gt=3B.<br>&gt=3B &gt=3B&gt=3B&gt=3B=
>ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The system cannot find the f=
>=3D<br>&gt=3B &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B sp=3D3D3D<br>&gt=3B &gt=
>=3B&gt=3B&gt=3Becified.<br>&gt=3B &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E=
>:  ErrorCode=3D3D3D3D2: The system cannot find the f=3D<br>&gt=3B &gt=3Bile=
>=3D3D<br>&gt=3B &gt=3B&gt=3B sp=3D3D3D<br>&gt=3B &gt=3B&gt=3B&gt=3Becified.=
><br>&gt=3B &gt=3B&gt=3B&gt=3BStack trace:<br>&gt=3B &gt=3B&gt=3B&gt=3B   FP=
>         PC      Procedure<br>&gt=3B &gt=3B&gt=3B&gt=3B---------  ---------=
>  -------------------------------<br>&gt=3B &gt=3B&gt=3B&gt=3B0x30fbd0  0x1=
>27218a  PutStats + 0x1a3 in ..\src\Main.m3<br>&gt=3B &gt=3B&gt=3B&gt=3B0x30=
>fcc0  0x1273825  Main_M3 + 0x11db(!) in ..\src\Main.m3<br>&gt=3B &gt=3B&gt=
>=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B&gt=3BRegards=2C<br>&gt=3B &gt=3B&gt=3B&gt=
>=3BRandy Coleburn<br>&gt=3B &gt=3B&gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B&gt=3B=
>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_<br>&gt=3B &gt=3B=
>&gt=3B&gt=3BContent-Type: text/html=3B charset=3D3D3D"us-ascii"<br>&gt=3B &=
>gt=3B&gt=3B&gt=3BContent-Transfer-Encoding: quoted-printable<br>&gt=3B &gt=
>=3B&gt=3B&gt=3B<br> 		 	   		  </body>
></html>=
>
>--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_--


From dabenavidesd at yahoo.es  Tue Mar  1 23:10:55 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 1 Mar 2011 22:10:55 +0000 (GMT)
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <20110301181718.12EFC1A2078@async.async.caltech.edu>
Message-ID: <452042.5906.qm@web29706.mail.ird.yahoo.com>

Hi all:
but you could still run a *nix image with uniprocessor support kernel and try on the vbox, qemu, etc.
Perhaps you would get enough simulation to detect that the problem is on the hardware layer (either physically or its abstraction) rather than the execution model (the pthreads scheduling policy), if it does no work may be there is a problem in ThreadPthread implementation of pthreads (don't need to switch its default is - smp 1).
commands i.e in qemu:
qemu -cdrom /path/to/system.iso -smp 2 
and run threadtest from there

Thanks in advance


 



--- El mar, 1/3/11, Mika Nystrom <mika at async.caltech.edu> escribi?:

> De: Mika Nystrom <mika at async.caltech.edu>
> Asunto: Re: [M3devel] results of threadtest program on Windows7
> Para: "Jay K" <jay.krell at cornell.edu>
> CC: m3devel at elegosoft.com
> Fecha: martes, 1 de marzo, 2011 13:17
> 
> Hi Jay,
> 
> 1. I think you should get forward progress no matter what,
> although it
> might be very slow on some systems.
> 
> 2. Not sure how you could get negative timings.  That
> would suggest that
> Time.Now() is decreasing---which seems contrary to its
> specification.
> Although the code is doing some nasty stuff with the
> timings, mainly
> reading and writing them without locks.  But it's
> using INTEGER for
> the results so I don't think there can be an atomicity
> problem there.
> Even if there were coherence problems between processors
> (is this
> technically possible?) the "now" value has to be coherent
> since it's
> from the thread that prints the results, and the "then"
> values could
> only be getting older, not newer...
> 
> 3. Note that there are systems (FreeBSD 4 is an example)
> that have a
> "pthreads" library but where the pthreads library is
> implemented with
> user threads.  Could that be related to why OpenBSD is
> working?
> 
> 4. Hm.  I think I am only using multiprocessor
> systems, yes.  Hard to
> find single-CPU systems nowadays!  I think actually
> the only one I have
> is PPC_DARWIN, and I haven't tried the code on that. 
> So yes this is a
> possibility as far as explaining differences...
> 
>      Mika
> 
> Jay K writes:
> >--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_
> >Content-Type: text/plain; charset="iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
> >
> >
> >I also haven't seen it fail on OpenBSD/x86/4.7. I'm
> pretty sure using pthre=
> >ads there.
> >But on Solaris/5.10/sparc it hangs=2C for many hours.
> >
> >-bash-4.1$ ./threadtest=20
> >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
> >.
> >
> >Are we guranteed forward progress in suspending all
> threads?
> >
> >I do see it fail usually on Darwin. e.g.:
> >........pthread_mutex_destroy:EBUSY
> >pthread_mutex_destroy:EBUSY
> >..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:
> >***    An array subscript was out of range.
> >***    file
> "../src/runtime/common/RTCollector.m3"=2C line 418
> >***
> >
> >I haven't tried Linux yet.
> >Do note that we have some variance in the pthreads
> implementation.
> >The "portable" implementation is used on Linux=2C
> Solaris=2C NetBSD.
> >And then OpenBSD=2C Darwin=2C FreeBSD each have slight
> differences.
> >
> >Mika are your machines all multiprocessors?
> >I do wonder if that helps increase the stress and if I
> should be sure to us=
> >e multiprocessors.
> >
> >I'm also considering taking the time to try various
> historical versions=2C =
> >either releases or dates in CVS.
> >
> > - Jay
> >
> >From: jay.krell at cornell.edu
> >To: mika at async.caltech.edu=3B
> rcolebur at scires.com
> >Date: Tue=2C 1 Mar 2011 10:59:29 +0000
> >CC: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on
> Windows7
> >
> >
> >
> >
> >
> >
> >
> >
> >I haven't seen it fail on NT=2C except for PutCard in
> the test itself getti=
> >ng negative numbers.
> >I've run it just a few times now. One single and dual
> processor virtual mac=
> >hines.
> >Randy=2C has it failed many times for you?
> >
> > - Jay
> >
> >> To: rcolebur at SCIRES.COM
> >> Date: Sun=2C 27 Feb 2011 15:11:25 -0800
> >> From: mika at async.caltech.edu
> >> CC: m3devel at elegosoft.com
> >> Subject: Re: [M3devel] results of threadtest
> program on Windows7
> >>=20
> >> Ah=2C it just doesn't check command-line arguments
> that carefully.
> >>=20
> >> I think what you did is equivalent to "-tests
> STD".
> >=20
> >>      Mika
> >>=20
> >> "Coleburn=2C Randy" writes:
> >> >Mika:
> >> >
> >> >No change with "-tests POSIX".
> >> >
> >> >Interesting twist:  On Windows 7=2C I
> thought I'd see what the command l=
> >ine o=3D
> >> >ptions are=2C and I typed "threadtest -help"
> rather than reading the cod=
> >e.
> >> >
> >> >First time=2C it produced what appears to be a
> NIL deref crash.  Then=2C=
> > I trie=3D
> >> >d it again and it ran to completion. 
> Something seems non-deterministic =
> >her=3D
> >> >e.  See below.
> >> >
> >>
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> -help
> >> >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
> >> >.
> >> >
> >> >***
> >> >*** runtime error:
> >> >***    Attempt to reference an
> illegal memory location.
> >> >***    pc =3D3D 0x77762262
> >> >***
> >> >
> >> >Stack trace:
> >> >   FP     
>    PC      Procedure
> >> >---------  --------- 
> -------------------------------
> >> > 0xcdf998  0x130351b  SystemError +
> 0x64 in ..\src\runtime\NT386\RTSigna=
> >l.m=3D
> >> >3
> >> > 0xcdf9c0  0x77762262  <???>
> >> > 0xcdf9d8  0x12e83b7  LockMutex +
> 0x4f in ..\src\thread\WIN32\ThreadWin3=
> >2.m=3D
> >> >3
> >> > 0xcdfa00  0x12c7b08  GetChar + 0x28
> in ..\src\rw\Rd.m3
> >> > 0xcdfb38  0x12c12e3  RApply + 0xd3
> in ..\src\Main.m3
> >> > 0xcdfb74  0x12e971f  ThreadBase +
> 0x254 in ..\src\thread\WIN32\ThreadWi=
> >n32=3D
> >> >.m3
> >> > 0xcdfb80  0x76543677  <???>
> >> > 0xcdfbc0  0x77779f02  <???>
> >> >.........  .........  ... more
> frames ...
> >> >
> >>
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> -help
> >> >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
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >..........laziest thread is 0/0/0 (tests: read
> 0/0/0 fork 0/0/0 alloc 0/=
> >0/0=3D
> >> > lock 0/0/0)
> >> >All tests complete.  Congratulations.
> >> >
> >> >Regards=2C
> >> >Randy Coleburn
> >> >
> >> >-----Original Message-----
> >> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >> >Sent: Sunday=2C February 27=2C 2011 3:30 PM
> >> >To: Coleburn=2C Randy
> >> >Cc: m3devel at elegosoft.com
> >> >Subject: Re: [M3devel] results of threadtest
> program on Windows7=3D20
> >> >
> >> >Hi Randy=2C
> >> >
> >> >You can try it with -tests POSIX as well.
> >> >
> >> >I find on user threads it runs very slowly
> (but it does run) because of =
> >how=3D
> >> > unfair
> >> >the thread scheduler is.
> >> >
> >> >Next step might be to whittle down the tests
> and see if you can get a fa=
> >ilu=3D
> >> >re with
> >> >a single test running and -n 2.  That
> would likely be the simplest scena=
> >rio=3D
> >> > to
> >> >start further debugging from.
> >> >
> >> >     Mika
> >> >
> >> >"Coleburn=2C Randy" writes:
> >> >>Mika et al:
> >> >>
> >> >>Thought I would try something else.
> >> >>
> >> >>I took the sources of your thread test
> program to an older XP machine t=
> >hat=3D
> >> > =3D3D
> >> >>has CM3 circa August 2008.  This is
> the machine and implementation I us=
> >ed =3D
> >> >w=3D3D
> >> >>hen building a major project I did a
> couple years back.
> >> >>
> >> >>The thread test program does indeed build
> on this old system=2C but whe=
> >n I r=3D
> >> >u=3D3D
> >> >>n it=2C I get different results than with
> the latest HEAD branch code. =
> >=3D3D20
> >> >>
> >> >>After it prints "running...printing
> oldest/median age/newest"=2C on the=
> > next=3D
> >> > =3D3D
> >> >>line I get two periods ".." and now the
> program seems hung.  I'll let i=
> >t "=3D
> >> >r=3D3D
> >> >>un" for a few more minutes to see if
> anything else happens before killi=
> >ng =3D
> >> >i=3D3D
> >> >>t.
> >> >>
> >> >>At least we don't get the subscript and
> assertion failures on this olde=
> >r C=3D
> >> >M=3D3D
> >> >>3 platform.
> >> >>
> >> >>Regards=2C
> >> >>Randy Coleburn
> >> >>
> >> >>
> >> >>-----Original Message-----
> >> >>From: Coleburn=2C Randy=3D3D20
> >> >>Sent: Sunday=2C February 27=2C 2011 2:09
> PM
> >> >>To: m3devel at elegosoft.com
> >> >>Subject: Re: [M3devel] results of
> threadtest program on Windows7
> >> >>
> >> >>Mika:
> >> >>
> >> >>Ok=2C I've updated to latest HEAD and I've
> also built Jay's m3sleep pro=
> >gram.
> >> >>
> >> >>Here is what happens now when I run your
> threadtest program on Windows =
> >7.
> >> >>
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest
> -tests ALL=
> >=2C-fo=3D
> >> >r=3D3D
> >> >>k
> >> >>Writing file...done
> >> >>Creating read threads...done
> >> >>Creating nxread threads...done
> >> >>Creating tryexcept threads...done
> >> >>Creating forktoomuch threads...done
> >> >>Creating alloc threads...done
> >> >>Creating creat threads...done
> >> >>Creating lock threads...done
> >> >>running...printing oldest/median
> age/newest
> >> >>
> >> >>
> >> >>***
> >> >>*** runtime error:
> >> >>***    An array subscript was
> out of range.
> >> >>***    file
> "..\src\runtime\common\RTCollector.m3"=2C line 418
> >> >>***
> >> >>
> >> >>
> >> >>
> >> >>***
> >> >>*** runtime error:
> >> >>***    <*ASSERT*> failed.
> >> >>***    file
> "..\src\thread\WIN32\ThreadWin32.m3"=2C line 841
> >> >>***
> >> >>
> >> >>The last error repeats ad infinitum until
> I press CNTRL-C to abort.
> >> >>
> >> >>I'll send more info on the Windows install
> of Modula3 in a subsequent p=
> >ost=3D
> >> >.
> >> >>
> >> >>Regards=2C
> >> >>Randy Coleburn
> >> >>
> >> >>-----Original Message-----
> >> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D3D20
> >> >>Sent: Saturday=2C February 26=2C 2011
> 12:55 PM
> >> >>To: Coleburn=2C Randy
> >> >>Cc: m3devel at elegosoft.com
> >> >>Subject: Re: [M3devel] results of
> threadtest program on Windows7=3D3D20
> >> >>
> >> >>Hi Randy=2C
> >> >>
> >> >>Hm yes it looks like my Windows
> programming skills leave something
> >> >>to be desired.
> >> >>
> >> >>You can run the thread tester while
> skipping a test as follows
> >> >>
> >> >>   threadtest -tests
> ALL=2C-fork
> >> >>
> >> >>(for instance)
> >> >>
> >> >>if you just run=3D3D20
> >> >>
> >> >>   threadtest -sadfassdaf
> >> >>
> >> >>it'll print the tests that are available.
> >> >>
> >> >>As it happens=2C I just had to upgrade my
> windows 2000 system to window=
> >s 7.
> >> >>Can you give me a very brief description
> of what you did to install Mod=
> >ula=3D
> >> >-=3D3D
> >> >>3
> >> >>on this system?
> >> >>
> >> >>     Mika
> >> >>
> >> >>"Coleburn=2C Randy" writes:
> >>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >> >>>Content-Type: text/plain=3B
> charset=3D3D3D"us-ascii"
> >> >>>Content-Transfer-Encoding:
> quoted-printable
> >> >>>
> >> >>>Mika:
> >> >>>
> >> >>>I've finally managed to get cm3
> rebuilt on Windows 7 again.
> >> >>>
> >> >>>So=2C I ran your threadtest program.
> >> >>>
> >> >>>Here are the results.  Note the
> "..." is where I cut out a bunch of th=
> >e r=3D
> >> >e=3D3D
> >> >>p=3D3D3D
> >> >>>eating "ERROR FApply" messages.
> >> >>>
> >>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >> >>>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
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>.
> >> >>>.
> >> >>>.
> >> >>>***
> >> >>>*** runtime error:
> >> >>>***    An enumeration or
> subrange value was out of range.
> >> >>>***    file
> "..\src\Main.m3"=2C line 340
> >> >>>***
> >> >>>
> >> >>>laziest thread is 0/0/ERROR FApply:
> OSError.E:  ErrorCode=3D3D3D3D2: T=
> >he sy=3D
> >> >ste=3D3D
> >> >>m c=3D3D3D
> >> >>>annot find the file specified.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>.
> >> >>>.
> >> >>>.
> >> >>>laziest thread is 0/0/ERROR FApply:
> OSError.E:  ErrorCode=3D3D3D3D2: T=
> >he sy=3D
> >> >ste=3D3D
> >> >>m c=3D3D3D
> >> >>>annot find the file specified.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>.
> >> >>>.
> >> >>>.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>ERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find =
> >the f=3D
> >> >ile=3D3D
> >> >> sp=3D3D3D
> >> >>>ecified.
> >> >>>Stack trace:
> >> >>>   FP   
>      PC      Procedure
> >> >>>---------  --------- 
> -------------------------------
> >> >>>0x30fbd0  0x127218a 
> PutStats + 0x1a3 in ..\src\Main.m3
> >> >>>0x30fcc0  0x1273825  Main_M3
> + 0x11db(!) in ..\src\Main.m3
> >> >>>
> >> >>>Regards=2C
> >> >>>Randy Coleburn
> >> >>>
> >>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >> >>>Content-Type: text/html=3B
> charset=3D3D3D"us-ascii"
> >> >>>Content-Transfer-Encoding:
> quoted-printable
> >> >>>
> >    
>         
>           
>   =
> >
> >--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_
> >Content-Type: text/html; charset="iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
> >
> ><html>
> ><head>
> ><style><!--
> >.hmmessage P
> >{
> >margin:0px=3B
> >padding:0px
> >}
> >body.hmmessage
> >{
> >font-size: 10pt=3B
> >font-family:Tahoma
> >}
> >--></style>
> ></head>
> ><body class=3D'hmmessage'>
> >I also haven't seen it fail on OpenBSD/x86/4.7. I'm
> pretty sure using pthre=
> >ads there.<br>But on Solaris/5.10/sparc it
> hangs=2C for many hours.<br><br>=
> >-bash-4.1$ ./threadtest <br>Writing
> file...done<br>Creating read threads...=
> >done<br>Creating fork
> threads...done<br>Creating alloc
> threads...done<br>Cr=
> >eating lock threads...done<br>running...printing
> oldest/median age/newest<b=
> >r>.<br><br>Are we guranteed forward
> progress in suspending all threads?<br>=
> ><br>I do see it fail usually on Darwin.
> e.g.:<br>........pthread_mutex_dest=
> >roy:EBUSY<br>pthread_mutex_destroy:EBUSY<br>..laziest
> thread is 0/0/0 (test=
> >s: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock
> 0/0/0)<br>...<br><br>***<br>*** r=
> >untime
> error:<br>***&nbsp=3B&nbsp=3B&nbsp=3B An
> array subscript was out of =
> >range.<br>***&nbsp=3B&nbsp=3B&nbsp=3B
> file "../src/runtime/common/RTCollect=
> >or.m3"=2C line 418<br>***<br><br>I
> haven't tried Linux yet.<br>Do note that=
> > we have some variance in the pthreads
> implementation.<br>The "portable" im=
> >plementation is used on Linux=2C Solaris=2C
> NetBSD.<br>And then OpenBSD=2C =
> >Darwin=2C FreeBSD each have slight
> differences.<br><br>Mika are your machin=
> >es all multiprocessors?<br>I do wonder if that
> helps increase the stress an=
> >d if I should be sure to use
> multiprocessors.<br><br>I'm also considering t=
> >aking the time to try various historical versions=2C
> either releases or dat=
> >es in CVS.<br><br>&nbsp=3B-
> Jay<br><br><hr id=3D"stopSpelling">From:
> jay.kr=
> >ell at cornell.edu<br>To:
> mika at async.caltech.edu=3B
> rcolebur at scires.com<br>Dat=
> >e: Tue=2C 1 Mar 2011 10:59:29 +0000<br>CC: m3devel at elegosoft.com<br>Subject=
> >: Re: [M3devel] results of threadtest program on
> Windows7<br><br>
> >
> ><meta http-equiv=3D"Content-Type"
> content=3D"text/html=3B charset=3Dunicode=
> >">
> ><meta name=3D"Generator" content=3D"Microsoft
> SafeHTML">
> ><style>
> >.ExternalClass .ecxhmmessage P
> >{padding:0px=3B}
> >.ExternalClass body.ecxhmmessage
> >{font-size:10pt=3Bfont-family:Tahoma=3B}
> >
> ></style>
> >
> >
> >I haven't seen it fail on NT=2C except for PutCard in
> the test itself getti=
> >ng negative numbers.<br>I've run it just a few
> times now. One single and du=
> >al processor virtual machines.<br>Randy=2C has it
> failed many times for you=
> >?<br><br>&nbsp=3B-
> Jay<br><br>&gt=3B To: rcolebur at SCIRES.COM<br>&gt=3B
> Date=
> >: Sun=2C 27 Feb 2011 15:11:25 -0800<br>&gt=3B
> From: mika at async.caltech.edu<=
> >br>&gt=3B CC: m3devel at elegosoft.com<br>&gt=3B
> Subject: Re: [M3devel] result=
> >s of threadtest program on Windows7<br>&gt=3B
> <br>&gt=3B Ah=2C it just does=
> >n't check command-line arguments that
> carefully.<br>&gt=3B <br>&gt=3B I thi=
> >nk what you did is equivalent to "-tests
> STD".<br>&gt=3B <br>&gt=3B   
>   Mi=
> >ka<br>&gt=3B <br>&gt=3B
> "Coleburn=2C Randy" writes:<br>&gt=3B
> &gt=3BMika:<b=
> >r>&gt=3B &gt=3B<br>&gt=3B
> &gt=3BNo change with "-tests POSIX".<br>&gt=3B
> &g=
> >t=3B<br>&gt=3B &gt=3BInteresting
> twist:  On Windows 7=2C I thought I'd see =
> >what the command line o=3D<br>&gt=3B
> &gt=3Bptions are=2C and I typed "threa=
> >dtest -help" rather than reading the
> code.<br>&gt=3B &gt=3B<br>&gt=3B
> &gt=
> >=3BFirst time=2C it produced what appears to be a NIL
> deref crash.  Then=2C=
> > I trie=3D<br>&gt=3B &gt=3Bd it again and
> it ran to completion.  Something =
> >seems non-deterministic her=3D<br>&gt=3B
> &gt=3Be.  See below.<br>&gt=3B &gt=
> >=3B<br>&gt=3B
> &gt=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bt=
> >hreadtest.exe -help<br>&gt=3B
> &gt=3BWriting file...done<br>&gt=3B
> &gt=3BCre=
> >ating read threads...done<br>&gt=3B
> &gt=3BCreating fork threads...done<br>&=
> >gt=3B &gt=3BCreating alloc
> threads...done<br>&gt=3B &gt=3BCreating lock
> thr=
> >eads...done<br>&gt=3B
> &gt=3Brunning...printing oldest/median
> age/newest<br>=
> >&gt=3B &gt=3B.<br>&gt=3B
> &gt=3B<br>&gt=3B
> &gt=3B***<br>&gt=3B &gt=3B*** run=
> >time error:<br>&gt=3B &gt=3B*** 
>   Attempt to reference an illegal memory l=
> >ocation.<br>&gt=3B &gt=3B***   
> pc =3D3D 0x77762262<br>&gt=3B
> &gt=3B***<br>=
> >&gt=3B &gt=3B<br>&gt=3B
> &gt=3BStack trace:<br>&gt=3B
> &gt=3B   FP     
>    PC=
> >      Procedure<br>&gt=3B
> &gt=3B---------  --------- 
> ---------------------=
> >----------<br>&gt=3B &gt=3B
> 0xcdf998  0x130351b  SystemError + 0x64 in ..\s=
> >rc\runtime\NT386\RTSignal.m=3D<br>&gt=3B
> &gt=3B3<br>&gt=3B &gt=3B 0xcdf9c0 =
> > 0x77762262 
> &lt=3B???&gt=3B<br>&gt=3B &gt=3B
> 0xcdf9d8  0x12e83b7  LockMute=
> >x + 0x4f in
> ..\src\thread\WIN32\ThreadWin32.m=3D<br>&gt=3B
> &gt=3B3<br>&gt=
> >=3B &gt=3B 0xcdfa00  0x12c7b08  GetChar +
> 0x28 in ..\src\rw\Rd.m3<br>&gt=3B=
> > &gt=3B 0xcdfb38  0x12c12e3  RApply +
> 0xd3 in ..\src\Main.m3<br>&gt=3B &gt=
> >=3B 0xcdfb74  0x12e971f  ThreadBase + 0x254
> in ..\src\thread\WIN32\ThreadWi=
> >n32=3D<br>&gt=3B
> &gt=3B.m3<br>&gt=3B &gt=3B 0xcdfb80 
> 0x76543677  &lt=3B???=
> >&gt=3B<br>&gt=3B &gt=3B
> 0xcdfbc0  0x77779f02 
> &lt=3B???&gt=3B<br>&gt=3B &gt=
> >=3B.........  .........  ... more frames
> ...<br>&gt=3B &gt=3B<br>&gt=3B
> &gt=
> >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest.exe
> -he=
> >lp<br>&gt=3B &gt=3BWriting
> file...done<br>&gt=3B &gt=3BCreating read
> thread=
> >s...done<br>&gt=3B &gt=3BCreating fork
> threads...done<br>&gt=3B &gt=3BCreat=
> >ing alloc threads...done<br>&gt=3B
> &gt=3BCreating lock threads...done<br>&g=
> >t=3B &gt=3Brunning...printing oldest/median
> age/newest<br>&gt=3B &gt=3B....=
> >......laziest thread is 0/0/0 (tests: read 0/0/0 fork
> 0/0/0 alloc 0/0/0=3D<=
> >br>&gt=3B &gt=3B lock
> 0/0/0)<br>&gt=3B &gt=3B..........laziest
> thread is 0/=
> >0/0 (tests: read 0/0/0 fork 0/0/0 alloc
> 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/=
> >0)<br>&gt=3B &gt=3B..........laziest
> thread is 0/0/0 (tests: read 0/0/0 for=
> >k 0/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B
> lock 0/0/0)<br>&gt=3B &gt=3B.......=
> >...laziest thread is 0/0/0 (tests: read 0/0/0 fork
> 0/0/0 alloc 0/0/0=3D<br>=
> >&gt=3B &gt=3B lock 0/0/0)<br>&gt=3B
> &gt=3B..........laziest thread is 0/0/0=
> > (tests: read 0/0/0 fork 0/0/0 alloc
> 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/0)<=
> >br>&gt=3B &gt=3B..........laziest thread is
> 0/0/0 (tests: read 0/0/0 fork 0=
> >/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock
> 0/0/0)<br>&gt=3B &gt=3B..........=
> >laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0
> alloc 0/0/0=3D<br>&gt=
> >=3B &gt=3B lock 0/0/0)<br>&gt=3B
> &gt=3B..........laziest thread is 0/0/0 (t=
> ests: read 0/0/0 fork 0/0/0 alloc
> 0/0/0=3D<br>&gt=3B &gt=3B lock
> 0/0/0)<br>=
> >&gt=3B &gt=3B..........laziest thread is 0/0/0
> (tests: read 0/0/0 fork 0/0/=
> >0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock
> 0/0/0)<br>&gt=3B &gt=3B..........laz=
> >iest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0
> alloc 0/0/0=3D<br>&gt=3B=
> > &gt=3B lock 0/0/0)<br>&gt=3B
> &gt=3BAll tests complete.  Congratulations.<b=
> >r>&gt=3B &gt=3B<br>&gt=3B
> &gt=3BRegards=2C<br>&gt=3B &gt=3BRandy
> Coleburn<b=
> >r>&gt=3B &gt=3B<br>&gt=3B
> &gt=3B-----Original Message-----<br>&gt=3B
> &gt=3B=
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20<br>&gt=3B
> &gt=3BSen=
> >t: Sunday=2C February 27=2C 2011 3:30
> PM<br>&gt=3B &gt=3BTo: Coleburn=2C Ra=
> >ndy<br>&gt=3B &gt=3BCc: m3devel at elegosoft.com<br>&gt=3B
> &gt=3BSubject: Re: =
> >[M3devel] results of threadtest program on
> Windows7=3D20<br>&gt=3B &gt=3B<b=
> >r>&gt=3B &gt=3BHi
> Randy=2C<br>&gt=3B &gt=3B<br>&gt=3B
> &gt=3BYou can try it =
> >with -tests POSIX as well.<br>&gt=3B
> &gt=3B<br>&gt=3B &gt=3BI find on user =
> >threads it runs very slowly (but it does run) because
> of how=3D<br>&gt=3B &=
> >gt=3B unfair<br>&gt=3B &gt=3Bthe thread
> scheduler is.<br>&gt=3B
> &gt=3B<br>&=
> >gt=3B &gt=3BNext step might be to whittle down the
> tests and see if you can=
> > get a failu=3D<br>&gt=3B &gt=3Bre
> with<br>&gt=3B &gt=3Ba single test runni=
> >ng and -n 2.  That would likely be the simplest
> scenario=3D<br>&gt=3B &gt=
> >=3B to<br>&gt=3B &gt=3Bstart further
> debugging from.<br>&gt=3B
> &gt=3B<br>&g=
> >t=3B &gt=3B 
>    Mika<br>&gt=3B
> &gt=3B<br>&gt=3B &gt=3B"Coleburn=2C Randy"
> w=
> >rites:<br>&gt=3B &gt=3B&gt=3BMika et
> al:<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B &=
> >gt=3B&gt=3BThought I would try something
> else.<br>&gt=3B
> &gt=3B&gt=3B<br>&g=
> >t=3B &gt=3B&gt=3BI took the sources of your
> thread test program to an older=
> > XP machine that=3D<br>&gt=3B &gt=3B
> =3D3D<br>&gt=3B &gt=3B&gt=3Bhas CM3 ci=
> >rca August 2008.  This is the machine and
> implementation I used =3D<br>&gt=
> >=3B &gt=3Bw=3D3D<br>&gt=3B
> &gt=3B&gt=3Bhen building a major project I did a=
> > couple years back.<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3BThe thread=
> > test program does indeed build on this old system=2C
> but when I r=3D<br>&g=
> >t=3B &gt=3Bu=3D3D<br>&gt=3B
> &gt=3B&gt=3Bn it=2C I get different results tha=
> >n with the latest HEAD branch code.
> =3D3D20<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=
> >=3B &gt=3B&gt=3BAfter it prints
> "running...printing oldest/median age/newes=
> >t"=2C on the next=3D<br>&gt=3B &gt=3B
> =3D3D<br>&gt=3B &gt=3B&gt=3Bline I ge=
> >t two periods ".." and now the program seems
> hung.  I'll let it "=3D<br>&gt=
> >=3B &gt=3Br=3D3D<br>&gt=3B
> &gt=3B&gt=3Bun" for a few more minutes to see if=
> > anything else happens before killing
> =3D<br>&gt=3B &gt=3Bi=3D3D<br>&gt=3B
> =
> >&gt=3B&gt=3Bt.<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3BAt least we don=
> >'t get the subscript and assertion failures on this
> older C=3D<br>&gt=3B &g=
> >t=3BM=3D3D<br>&gt=3B &gt=3B&gt=3B3
> platform.<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=
> >=3B &gt=3B&gt=3BRegards=2C<br>&gt=3B
> &gt=3B&gt=3BRandy Coleburn<br>&gt=3B
> &=
> >gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B-----Original Mess=
> >age-----<br>&gt=3B &gt=3B&gt=3BFrom:
> Coleburn=2C Randy=3D3D20<br>&gt=3B &gt=
> >=3B&gt=3BSent: Sunday=2C February 27=2C 2011 2:09
> PM<br>&gt=3B &gt=3B&gt=3B=
> >To: m3devel at elegosoft.com<br>&gt=3B
> &gt=3B&gt=3BSubject: Re: [M3devel] resu=
> >lts of threadtest program on
> Windows7<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B &gt=
> >=3B&gt=3BMika:<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3BOk=2C I've upda=
> >ted to latest HEAD and I've also built Jay's m3sleep
> program.<br>&gt=3B &gt=
> >=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3BHere is what happens now when I run your
> th=
> >readtest program on Windows 7.<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
> >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest
> -tests =
> >ALL=2C-fo=3D<br>&gt=3B
> &gt=3Br=3D3D<br>&gt=3B
> &gt=3B&gt=3Bk<br>&gt=3B &gt=
> >=3B&gt=3BWriting file...done<br>&gt=3B
> &gt=3B&gt=3BCreating read threads...=
> >done<br>&gt=3B &gt=3B&gt=3BCreating
> nxread threads...done<br>&gt=3B &gt=3B&=
> >gt=3BCreating tryexcept
> threads...done<br>&gt=3B
> &gt=3B&gt=3BCreating forkt=
> >oomuch threads...done<br>&gt=3B
> &gt=3B&gt=3BCreating alloc threads...done<b=
> >r>&gt=3B &gt=3B&gt=3BCreating creat
> threads...done<br>&gt=3B &gt=3B&gt=3BCr=
> >eating lock threads...done<br>&gt=3B
> &gt=3B&gt=3Brunning...printing oldest/=
> >median age/newest<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B &=
> >gt=3B&gt=3B***<br>&gt=3B
> &gt=3B&gt=3B*** runtime error:<br>&gt=3B
> &gt=3B&gt=
> >=3B***    An array subscript was out of
> range.<br>&gt=3B
> &gt=3B&gt=3B***   =
> > file "..\src\runtime\common\RTCollector.m3"=2C line
> 418<br>&gt=3B &gt=3B&g=
> >t=3B***<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
> >=3B<br>&gt=3B
> &gt=3B&gt=3B***<br>&gt=3B
> &gt=3B&gt=3B*** runtime error:<br>&=
> >gt=3B &gt=3B&gt=3B***   
> &lt=3B*ASSERT*&gt=3B failed.<br>&gt=3B
> &gt=3B&gt=
> >=3B***    file
> "..\src\thread\WIN32\ThreadWin32.m3"=2C line
> 841<br>&gt=3B &=
> >gt=3B&gt=3B***<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3BThe last error =
> >repeats ad infinitum until I press CNTRL-C to
> abort.<br>&gt=3B &gt=3B&gt=3B=
> ><br>&gt=3B &gt=3B&gt=3BI'll send more
> info on the Windows install of Modula=
> >3 in a subsequent post=3D<br>&gt=3B
> &gt=3B.<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=
> >=3B &gt=3B&gt=3BRegards=2C<br>&gt=3B
> &gt=3B&gt=3BRandy Coleburn<br>&gt=3B
> &=
> >gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B-----Original
> Message-----<br>&gt=3B &gt=
> >=3B&gt=3BFrom: Mika Nystrom [mailto:mika at async.caltech.edu]=3D3D20<br>&gt=
> >=3B &gt=3B&gt=3BSent: Saturday=2C February
> 26=2C 2011 12:55 PM<br>&gt=3B &g=
> >t=3B&gt=3BTo: Coleburn=2C Randy<br>&gt=3B
> &gt=3B&gt=3BCc: m3devel at elegosoft=
> >.com<br>&gt=3B &gt=3B&gt=3BSubject:
> Re: [M3devel] results of threadtest pro=
> >gram on Windows7=3D3D20<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3BHi Ran=
> >dy=2C<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3BHm yes it looks like my =
> >Windows programming skills leave
> something<br>&gt=3B &gt=3B&gt=3Bto be
> desi=
> >red.<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3BYou can run the thread te=
> >ster while skipping a test as
> follows<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B &gt=
> >=3B&gt=3B   threadtest -tests
> ALL=2C-fork<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B =
> >&gt=3B&gt=3B(for instance)<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3Bif =
> >you just run=3D3D20<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B   threadt=
> >est -sadfassdaf<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3Bit'll print th=
> >e tests that are available.<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3BAs=
> > it happens=2C I just had to upgrade my windows 2000
> system to windows 7.<b=
> >r>&gt=3B &gt=3B&gt=3BCan you give me a
> very brief description of what you d=
> >id to install Modula=3D<br>&gt=3B
> &gt=3B-=3D3D<br>&gt=3B
> &gt=3B&gt=3B3<br>&=
> >gt=3B &gt=3B&gt=3Bon this
> system?<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B &gt=3B&g=
> >t=3B     Mika<br>&gt=3B
> &gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B"Coleburn=2C Ran=
> >dy" writes:<br>&gt=3B
> &gt=3B&gt=3B&gt=3B--_000_D67F02DDC62F7545A6B84C285F88=
> >F3E6EE25C849atlex02srv_<br>&gt=3B
> &gt=3B&gt=3B&gt=3BContent-Type: text/plai=
> >n=3B charset=3D3D3D"us-ascii"<br>&gt=3B
> &gt=3B&gt=3B&gt=3BContent-Transfer-=
> >Encoding: quoted-printable<br>&gt=3B
> &gt=3B&gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=
> >=3B&gt=3BMika:<br>&gt=3B
> &gt=3B&gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B&gt=3BI'v=
> >e finally managed to get cm3 rebuilt on Windows 7
> again.<br>&gt=3B &gt=3B&g=
> >t=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B&gt=3BSo=2C I ran your threadtest
> program.=
> ><br>&gt=3B
> &gt=3B&gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B&gt=3BHere are the resu=
> >lts.  Note the "..." is where I cut out a bunch of
> the r=3D<br>&gt=3B &gt=
> >=3Be=3D3D<br>&gt=3B
> &gt=3B&gt=3Bp=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Beating=
> > "ERROR FApply" messages.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=
> >=3B&gt=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest.e=
> >xe<br>&gt=3B
> &gt=3B&gt=3B&gt=3BWriting
> file...done<br>&gt=3B &gt=3B&gt=3B&g=
> >t=3BCreating read threads...done<br>&gt=3B
> &gt=3B&gt=3B&gt=3BCreating fork =
> >threads...done<br>&gt=3B
> &gt=3B&gt=3B&gt=3BCreating alloc
> threads...done<br=
> >>&gt=3B &gt=3B&gt=3B&gt=3BCreating
> lock threads...done<br>&gt=3B &gt=3B&gt=
> >=3B&gt=3Brunning...printing oldest/median
> age/newest<br>&gt=3B &gt=3B&gt=3B=
> >&gt=3BERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find=
> > the f=3D<br>&gt=3B
> &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> sp=3D3D3D<br>&gt=
> >=3B
> &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> &gt=3B&gt=3B&gt=3BERROR FApply: OS=
> >Error.E:  ErrorCode=3D3D3D3D2: The system cannot
> find the f=3D<br>&gt=3B &g=
> >t=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> sp=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Be=
> >cified.<br>&gt=3B
> &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E: 
> ErrorCode=3D3=
> >D3D3D2: The system cannot find the
> f=3D<br>&gt=3B
> &gt=3Bile=3D3D<br>&gt=3B =
> >&gt=3B&gt=3B sp=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> &gt=
> >=3B&gt=3B&gt=3B.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B=
> >.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B***<br>&gt=3B
> &gt=3B&gt=3B&gt=3B*** runtime e=
> >rror:<br>&gt=3B
> &gt=3B&gt=3B&gt=3B***    An
> enumeration or subrange value w=
> >as out of range.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B***    file
> "..\src\Main.m3"=
> >=2C line 340<br>&gt=3B
> &gt=3B&gt=3B&gt=3B***<br>&gt=3B
> &gt=3B&gt=3B&gt=3B<b=
> >r>&gt=3B &gt=3B&gt=3B&gt=3Blaziest
> thread is 0/0/ERROR FApply: OSError.E:  =
> >ErrorCode=3D3D3D3D2: The sy=3D<br>&gt=3B
> &gt=3Bste=3D3D<br>&gt=3B &gt=3B&gt=
> >=3Bm c=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Bannot find the file
> specified.<br=
> >>&gt=3B &gt=3B&gt=3B&gt=3BERROR
> FApply: OSError.E:  ErrorCode=3D3D3D3D2: Th=
> >e system cannot find the f=3D<br>&gt=3B
> &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=
> >=3B sp=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> &gt=3B&gt=3B&g=
> >t=3BERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2:
> The system cannot find t=
> >he f=3D<br>&gt=3B
> &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> sp=3D3D3D<br>&gt=3B=
> >
> &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> &gt=3B&gt=3B&gt=3BERROR FApply: OSErr=
> >or.E:  ErrorCode=3D3D3D3D2: The system cannot find
> the f=3D<br>&gt=3B &gt=
> >=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> sp=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Bec=
> >ified.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B.<br>&gt=
> >=3B &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> &gt=3B&gt=3B&gt=3Blaziest thread is 0/0/E=
> >RROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The
> sy=3D<br>&gt=3B &gt=3Bste=
> >=3D3D<br>&gt=3B &gt=3B&gt=3Bm
> c=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Bannot fi=
> >nd the file specified.<br>&gt=3B
> &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E:=
> >  ErrorCode=3D3D3D3D2: The system cannot find the
> f=3D<br>&gt=3B &gt=3Bile=
> >=3D3D<br>&gt=3B &gt=3B&gt=3B
> sp=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Becified.=
> ><br>&gt=3B
> &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2:=
> > The system cannot find the f=3D<br>&gt=3B
> &gt=3Bile=3D3D<br>&gt=3B &gt=3B&=
> >gt=3B sp=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> &gt=3B&gt=3B=
> >&gt=3BERROR FApply: OSError.E: 
> ErrorCode=3D3D3D3D2: The system cannot find=
> > the f=3D<br>&gt=3B
> &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> sp=3D3D3D<br>&gt=
> >=3B
> &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> &gt=
> >=3B&gt=3B&gt=3B.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> &gt=3B&gt=3B&gt=3B=
> >ERROR FApply: OSError.E:  ErrorCode=3D3D3D3D2: The
> system cannot find the f=
> >=3D<br>&gt=3B
> &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> sp=3D3D3D<br>&gt=3B &gt=
> >=3B&gt=3B&gt=3Becified.<br>&gt=3B
> &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E=
> >:  ErrorCode=3D3D3D3D2: The system cannot find the
> f=3D<br>&gt=3B &gt=3Bile=
> >=3D3D<br>&gt=3B &gt=3B&gt=3B
> sp=3D3D3D<br>&gt=3B
> &gt=3B&gt=3B&gt=3Becified.=
> ><br>&gt=3B
> &gt=3B&gt=3B&gt=3BStack
> trace:<br>&gt=3B
> &gt=3B&gt=3B&gt=3B   FP=
> >         PC   
>   Procedure<br>&gt=3B
> &gt=3B&gt=3B&gt=3B---------  ---------=
> > 
> -------------------------------<br>&gt=3B
> &gt=3B&gt=3B&gt=3B0x30fbd0  0x1=
> >27218a  PutStats + 0x1a3 in
> ..\src\Main.m3<br>&gt=3B
> &gt=3B&gt=3B&gt=3B0x30=
> >fcc0  0x1273825  Main_M3 + 0x11db(!) in
> ..\src\Main.m3<br>&gt=3B &gt=3B&gt=
> >=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B&gt=3BRegards=2C<br>&gt=3B
> &gt=3B&gt=3B&gt=
> >=3BRandy Coleburn<br>&gt=3B
> &gt=3B&gt=3B&gt=3B<br>&gt=3B
> &gt=3B&gt=3B&gt=3B=
> >--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_<br>&gt=3B
> &gt=3B=
> >&gt=3B&gt=3BContent-Type: text/html=3B
> charset=3D3D3D"us-ascii"<br>&gt=3B &=
> >gt=3B&gt=3B&gt=3BContent-Transfer-Encoding:
> quoted-printable<br>&gt=3B &gt=
> >=3B&gt=3B&gt=3B<br>    
>         
>           
>   </body>
> ></html>=
> >
> >--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_--
> 


      


From jay.krell at cornell.edu  Wed Mar  2 04:11:49 2011
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Mar 2011 03:11:49 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <452042.5906.qm@web29706.mail.ird.yahoo.com>
References: <20110301181718.12EFC1A2078@async.async.caltech.edu>,
	<452042.5906.qm@web29706.mail.ird.yahoo.com>
Message-ID: <COL101-W3670B74A99994199607C6BE6C00@phx.gbl>


I have still have mostly uniprocessors (though busy selling stuff off...)
  I do have a MacBook Pro and Dell laptop with 2 processors each though.
  It is that MacBook Pro where I can consistently get Darwin to fail, and a 1 and 2 proc Windows virtual machine on the MacBook Pro that consistently works.
  While Modula-3 user threads never run anything truly concurrently, i.e. on multiple prcoessors, there should still be almost arbitrary preemption.
 
 
I'm skeptical of any emulation's or virtualization's ability to simulate more processors than underlying physical processors.
 
 
Most of the runs error or succeed within 10 minutes. The one Solaris/sparc run I made ran for well over 4 hours and didn't get very far. I'd say it was hung forever.
 
 
I didn't debug it.
 
 
Yes, OpenBSD pthreads are user threads and therefore probably only ever use one processor.
But that machine only has one. :)

 
I think this will quite difficult to track down.
It might be useful to find an old starting point that succeeds and upgrade forward looking for when things fail.
That is tedious and has its own set of difficulties, granted.
 There are many points in time that don't compile, many are my fault, and there are also many combinations of starting/ending points that don't compile due to some mismatches between start/end.
 
 
I have to try Linux and/or FreeBSD still.
 
 
The errors on Darwin imply to me that memory is being prematurely reclaimed by the garbage collector -- e.g. EBUSY from pthread_mutex_destroy.
But it could also be arbitrary memory corruption (sort of the same thing), same example, but rather than an actually busy mutex, it could be a corrupted mutex or random pointer. Some of that might be easy to track down, e.g. by tracing which addresses are initialized as mutexes, and maybe by putting pad bytes around mutexes and seeing if they get changed.
I'm reluctant to try draw any conclusions yet though, since I have very very little information/knowledge.
 
 
I also forgot to check if I was using any optimization. I'll be sure to not.
 
 
 - Jay

 
> Date: Tue, 1 Mar 2011 22:10:55 +0000
> From: dabenavidesd at yahoo.es
> To: jay.krell at cornell.edu; mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Hi all:
> but you could still run a *nix image with uniprocessor support kernel and try on the vbox, qemu, etc.
> Perhaps you would get enough simulation to detect that the problem is on the hardware layer (either physically or its abstraction) rather than the execution model (the pthreads scheduling policy), if it does no work may be there is a problem in ThreadPthread implementation of pthreads (don't need to switch its default is - smp 1).
> commands i.e in qemu:
> qemu -cdrom /path/to/system.iso -smp 2 
> and run threadtest from there
> 
> Thanks in advance
> 
> 
> 
> 
> 
> 
> --- El mar, 1/3/11, Mika Nystrom <mika at async.caltech.edu> escribi?:
> 
> > De: Mika Nystrom <mika at async.caltech.edu>
> > Asunto: Re: [M3devel] results of threadtest program on Windows7
> > Para: "Jay K" <jay.krell at cornell.edu>
> > CC: m3devel at elegosoft.com
> > Fecha: martes, 1 de marzo, 2011 13:17
> > 
> > Hi Jay,
> > 
> > 1. I think you should get forward progress no matter what,
> > although it
> > might be very slow on some systems.
> > 
> > 2. Not sure how you could get negative timings. That
> > would suggest that
> > Time.Now() is decreasing---which seems contrary to its
> > specification.
> > Although the code is doing some nasty stuff with the
> > timings, mainly
> > reading and writing them without locks. But it's
> > using INTEGER for
> > the results so I don't think there can be an atomicity
> > problem there.
> > Even if there were coherence problems between processors
> > (is this
> > technically possible?) the "now" value has to be coherent
> > since it's
> > from the thread that prints the results, and the "then"
> > values could
> > only be getting older, not newer...
> > 
> > 3. Note that there are systems (FreeBSD 4 is an example)
> > that have a
> > "pthreads" library but where the pthreads library is
> > implemented with
> > user threads. Could that be related to why OpenBSD is
> > working?
> > 
> > 4. Hm. I think I am only using multiprocessor
> > systems, yes. Hard to
> > find single-CPU systems nowadays! I think actually
> > the only one I have
> > is PPC_DARWIN, and I haven't tried the code on that. 
> > So yes this is a
> > possibility as far as explaining differences...
> > 
> > Mika
> > 
> > Jay K writes:
> > >--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_
> > >Content-Type: text/plain; charset="iso-8859-1"
> > >Content-Transfer-Encoding: quoted-printable
> > >
> > >
> > >I also haven't seen it fail on OpenBSD/x86/4.7. I'm
> > pretty sure using pthre=
> > >ads there.
> > >But on Solaris/5.10/sparc it hangs=2C for many hours.
> > >
> > >-bash-4.1$ ./threadtest=20
> > >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
> > >.
> > >
> > >Are we guranteed forward progress in suspending all
> > threads?
> > >
> > >I do see it fail usually on Darwin. e.g.:
> > >........pthread_mutex_destroy:EBUSY
> > >pthread_mutex_destroy:EBUSY
> > >..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:
> > >*** An array subscript was out of range.
> > >*** file
> > "../src/runtime/common/RTCollector.m3"=2C line 418
> > >***
> > >
> > >I haven't tried Linux yet.
> > >Do note that we have some variance in the pthreads
> > implementation.
> > >The "portable" implementation is used on Linux=2C
> > Solaris=2C NetBSD.
> > >And then OpenBSD=2C Darwin=2C FreeBSD each have slight
> > differences.
> > >
> > >Mika are your machines all multiprocessors?
> > >I do wonder if that helps increase the stress and if I
> > should be sure to us=
> > >e multiprocessors.
> > >
> > >I'm also considering taking the time to try various
> > historical versions=2C =
> > >either releases or dates in CVS.
> > >
> > > - Jay
> > >
> > >From: jay.krell at cornell.edu
> > >To: mika at async.caltech.edu=3B
> > rcolebur at scires.com
> > >Date: Tue=2C 1 Mar 2011 10:59:29 +0000
> > >CC: m3devel at elegosoft.com
> > >Subject: Re: [M3devel] results of threadtest program on
> > Windows7
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >I haven't seen it fail on NT=2C except for PutCard in
> > the test itself getti=
> > >ng negative numbers.
> > >I've run it just a few times now. One single and dual
> > processor virtual mac=
> > >hines.
> > >Randy=2C has it failed many times for you?
> > >
> > > - Jay
> > >
> > >> To: rcolebur at SCIRES.COM
> > >> Date: Sun=2C 27 Feb 2011 15:11:25 -0800
> > >> From: mika at async.caltech.edu
> > >> CC: m3devel at elegosoft.com
> > >> Subject: Re: [M3devel] results of threadtest
> > program on Windows7
> > >>=20
> > >> Ah=2C it just doesn't check command-line arguments
> > that carefully.
> > >>=20
> > >> I think what you did is equivalent to "-tests
> > STD".
> > >=20
> > >> Mika
> > >>=20
> > >> "Coleburn=2C Randy" writes:
> > >> >Mika:
> > >> >
> > >> >No change with "-tests POSIX".
> > >> >
> > >> >Interesting twist: On Windows 7=2C I
> > thought I'd see what the command l=
> > >ine o=3D
> > >> >ptions are=2C and I typed "threadtest -help"
> > rather than reading the cod=
> > >e.
> > >> >
> > >> >First time=2C it produced what appears to be a
> > NIL deref crash. Then=2C=
> > > I trie=3D
> > >> >d it again and it ran to completion. 
> > Something seems non-deterministic =
> > >her=3D
> > >> >e. See below.
> > >> >
> > >>
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > -help
> > >> >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
> > >> >.
> > >> >
> > >> >***
> > >> >*** runtime error:
> > >> >*** Attempt to reference an
> > illegal memory location.
> > >> >*** pc =3D3D 0x77762262
> > >> >***
> > >> >
> > >> >Stack trace:
> > >> > FP 
> > PC Procedure
> > >> >--------- --------- 
> > -------------------------------
> > >> > 0xcdf998 0x130351b SystemError +
> > 0x64 in ..\src\runtime\NT386\RTSigna=
> > >l.m=3D
> > >> >3
> > >> > 0xcdf9c0 0x77762262 <???>
> > >> > 0xcdf9d8 0x12e83b7 LockMutex +
> > 0x4f in ..\src\thread\WIN32\ThreadWin3=
> > >2.m=3D
> > >> >3
> > >> > 0xcdfa00 0x12c7b08 GetChar + 0x28
> > in ..\src\rw\Rd.m3
> > >> > 0xcdfb38 0x12c12e3 RApply + 0xd3
> > in ..\src\Main.m3
> > >> > 0xcdfb74 0x12e971f ThreadBase +
> > 0x254 in ..\src\thread\WIN32\ThreadWi=
> > >n32=3D
> > >> >.m3
> > >> > 0xcdfb80 0x76543677 <???>
> > >> > 0xcdfbc0 0x77779f02 <???>
> > >> >......... ......... ... more
> > frames ...
> > >> >
> > >>
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > -help
> > >> >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
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >All tests complete. Congratulations.
> > >> >
> > >> >Regards=2C
> > >> >Randy Coleburn
> > >> >
> > >> >-----Original Message-----
> > >> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> > >> >Sent: Sunday=2C February 27=2C 2011 3:30 PM
> > >> >To: Coleburn=2C Randy
> > >> >Cc: m3devel at elegosoft.com
> > >> >Subject: Re: [M3devel] results of threadtest
> > program on Windows7=3D20
> > >> >
> > >> >Hi Randy=2C
> > >> >
> > >> >You can try it with -tests POSIX as well.
> > >> >
> > >> >I find on user threads it runs very slowly
> > (but it does run) because of =
> > >how=3D
> > >> > unfair
> > >> >the thread scheduler is.
> > >> >
> > >> >Next step might be to whittle down the tests
> > and see if you can get a fa=
> > >ilu=3D
> > >> >re with
> > >> >a single test running and -n 2. That
> > would likely be the simplest scena=
> > >rio=3D
> > >> > to
> > >> >start further debugging from.
> > >> >
> > >> > Mika
> > >> >
> > >> >"Coleburn=2C Randy" writes:
> > >> >>Mika et al:
> > >> >>
> > >> >>Thought I would try something else.
> > >> >>
> > >> >>I took the sources of your thread test
> > program to an older XP machine t=
> > >hat=3D
> > >> > =3D3D
> > >> >>has CM3 circa August 2008. This is
> > the machine and implementation I us=
> > >ed =3D
> > >> >w=3D3D
> > >> >>hen building a major project I did a
> > couple years back.
> > >> >>
> > >> >>The thread test program does indeed build
> > on this old system=2C but whe=
> > >n I r=3D
> > >> >u=3D3D
> > >> >>n it=2C I get different results than with
> > the latest HEAD branch code. =
> > >=3D3D20
> > >> >>
> > >> >>After it prints "running...printing
> > oldest/median age/newest"=2C on the=
> > > next=3D
> > >> > =3D3D
> > >> >>line I get two periods ".." and now the
> > program seems hung. I'll let i=
> > >t "=3D
> > >> >r=3D3D
> > >> >>un" for a few more minutes to see if
> > anything else happens before killi=
> > >ng =3D
> > >> >i=3D3D
> > >> >>t.
> > >> >>
> > >> >>At least we don't get the subscript and
> > assertion failures on this olde=
> > >r C=3D
> > >> >M=3D3D
> > >> >>3 platform.
> > >> >>
> > >> >>Regards=2C
> > >> >>Randy Coleburn
> > >> >>
> > >> >>
> > >> >>-----Original Message-----
> > >> >>From: Coleburn=2C Randy=3D3D20
> > >> >>Sent: Sunday=2C February 27=2C 2011 2:09
> > PM
> > >> >>To: m3devel at elegosoft.com
> > >> >>Subject: Re: [M3devel] results of
> > threadtest program on Windows7
> > >> >>
> > >> >>Mika:
> > >> >>
> > >> >>Ok=2C I've updated to latest HEAD and I've
> > also built Jay's m3sleep pro=
> > >gram.
> > >> >>
> > >> >>Here is what happens now when I run your
> > threadtest program on Windows =
> > >7.
> > >> >>
> > >>
> > >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest
> > -tests ALL=
> > >=2C-fo=3D
> > >> >r=3D3D
> > >> >>k
> > >> >>Writing file...done
> > >> >>Creating read threads...done
> > >> >>Creating nxread threads...done
> > >> >>Creating tryexcept threads...done
> > >> >>Creating forktoomuch threads...done
> > >> >>Creating alloc threads...done
> > >> >>Creating creat threads...done
> > >> >>Creating lock threads...done
> > >> >>running...printing oldest/median
> > age/newest
> > >> >>
> > >> >>
> > >> >>***
> > >> >>*** runtime error:
> > >> >>*** An array subscript was
> > out of range.
> > >> >>*** file
> > "..\src\runtime\common\RTCollector.m3"=2C line 418
> > >> >>***
> > >> >>
> > >> >>
> > >> >>
> > >> >>***
> > >> >>*** runtime error:
> > >> >>*** <*ASSERT*> failed.
> > >> >>*** file
> > "..\src\thread\WIN32\ThreadWin32.m3"=2C line 841
> > >> >>***
> > >> >>
> > >> >>The last error repeats ad infinitum until
> > I press CNTRL-C to abort.
> > >> >>
> > >> >>I'll send more info on the Windows install
> > of Modula3 in a subsequent p=
> > >ost=3D
> > >> >.
> > >> >>
> > >> >>Regards=2C
> > >> >>Randy Coleburn
> > >> >>
> > >> >>-----Original Message-----
> > >> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D3D20
> > >> >>Sent: Saturday=2C February 26=2C 2011
> > 12:55 PM
> > >> >>To: Coleburn=2C Randy
> > >> >>Cc: m3devel at elegosoft.com
> > >> >>Subject: Re: [M3devel] results of
> > threadtest program on Windows7=3D3D20
> > >> >>
> > >> >>Hi Randy=2C
> > >> >>
> > >> >>Hm yes it looks like my Windows
> > programming skills leave something
> > >> >>to be desired.
> > >> >>
> > >> >>You can run the thread tester while
> > skipping a test as follows
> > >> >>
> > >> >> threadtest -tests
> > ALL=2C-fork
> > >> >>
> > >> >>(for instance)
> > >> >>
> > >> >>if you just run=3D3D20
> > >> >>
> > >> >> threadtest -sadfassdaf
> > >> >>
> > >> >>it'll print the tests that are available.
> > >> >>
> > >> >>As it happens=2C I just had to upgrade my
> > windows 2000 system to window=
> > >s 7.
> > >> >>Can you give me a very brief description
> > of what you did to install Mod=
> > >ula=3D
> > >> >-=3D3D
> > >> >>3
> > >> >>on this system?
> > >> >>
> > >> >> Mika
> > >> >>
> > >> >>"Coleburn=2C Randy" writes:
> > >>
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >> >>>Content-Type: text/plain=3B
> > charset=3D3D3D"us-ascii"
> > >> >>>Content-Transfer-Encoding:
> > quoted-printable
> > >> >>>
> > >> >>>Mika:
> > >> >>>
> > >> >>>I've finally managed to get cm3
> > rebuilt on Windows 7 again.
> > >> >>>
> > >> >>>So=2C I ran your threadtest program.
> > >> >>>
> > >> >>>Here are the results. Note the
> > "..." is where I cut out a bunch of th=
> > >e r=3D
> > >> >e=3D3D
> > >> >>p=3D3D3D
> > >> >>>eating "ERROR FApply" messages.
> > >> >>>
> > >>
> > >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > >> >>>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
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>.
> > >> >>>.
> > >> >>>.
> > >> >>>***
> > >> >>>*** runtime error:
> > >> >>>*** An enumeration or
> > subrange value was out of range.
> > >> >>>*** file
> > "..\src\Main.m3"=2C line 340
> > >> >>>***
> > >> >>>
> > >> >>>laziest thread is 0/0/ERROR FApply:
> > OSError.E: ErrorCode=3D3D3D3D2: T=
> > >he sy=3D
> > >> >ste=3D3D
> > >> >>m c=3D3D3D
> > >> >>>annot find the file specified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>.
> > >> >>>.
> > >> >>>.
> > >> >>>laziest thread is 0/0/ERROR FApply:
> > OSError.E: ErrorCode=3D3D3D3D2: T=
> > >he sy=3D
> > >> >ste=3D3D
> > >> >>m c=3D3D3D
> > >> >>>annot find the file specified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>.
> > >> >>>.
> > >> >>>.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>Stack trace:
> > >> >>> FP 
> > PC Procedure
> > >> >>>--------- --------- 
> > -------------------------------
> > >> >>>0x30fbd0 0x127218a 
> > PutStats + 0x1a3 in ..\src\Main.m3
> > >> >>>0x30fcc0 0x1273825 Main_M3
> > + 0x11db(!) in ..\src\Main.m3
> > >> >>>
> > >> >>>Regards=2C
> > >> >>>Randy Coleburn
> > >> >>>
> > >>
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >> >>>Content-Type: text/html=3B
> > charset=3D3D3D"us-ascii"
> > >> >>>Content-Transfer-Encoding:
> > quoted-printable
> > >> >>>
> > > 
> > 
> > 
> > =
> > >
> > >--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_
> > >Content-Type: text/html; charset="iso-8859-1"
> > >Content-Transfer-Encoding: quoted-printable
> > >
> > ><html>
> > ><head>
> > ><style><!--
> > >.hmmessage P
> > >{
> > >margin:0px=3B
> > >padding:0px
> > >}
> > >body.hmmessage
> > >{
> > >font-size: 10pt=3B
> > >font-family:Tahoma
> > >}
> > >--></style>
> > ></head>
> > ><body class=3D'hmmessage'>
> > >I also haven't seen it fail on OpenBSD/x86/4.7. I'm
> > pretty sure using pthre=
> > >ads there.<br>But on Solaris/5.10/sparc it
> > hangs=2C for many hours.<br><br>=
> > >-bash-4.1$ ./threadtest <br>Writing
> > file...done<br>Creating read threads...=
> > >done<br>Creating fork
> > threads...done<br>Creating alloc
> > threads...done<br>Cr=
> > >eating lock threads...done<br>running...printing
> > oldest/median age/newest<b=
> > >r>.<br><br>Are we guranteed forward
> > progress in suspending all threads?<br>=
> > ><br>I do see it fail usually on Darwin.
> > e.g.:<br>........pthread_mutex_dest=
> > >roy:EBUSY<br>pthread_mutex_destroy:EBUSY<br>..laziest
> > thread is 0/0/0 (test=
> > >s: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock
> > 0/0/0)<br>...<br><br>***<br>*** r=
> > >untime
> > error:<br>***&nbsp=3B&nbsp=3B&nbsp=3B An
> > array subscript was out of =
> > >range.<br>***&nbsp=3B&nbsp=3B&nbsp=3B
> > file "../src/runtime/common/RTCollect=
> > >or.m3"=2C line 418<br>***<br><br>I
> > haven't tried Linux yet.<br>Do note that=
> > > we have some variance in the pthreads
> > implementation.<br>The "portable" im=
> > >plementation is used on Linux=2C Solaris=2C
> > NetBSD.<br>And then OpenBSD=2C =
> > >Darwin=2C FreeBSD each have slight
> > differences.<br><br>Mika are your machin=
> > >es all multiprocessors?<br>I do wonder if that
> > helps increase the stress an=
> > >d if I should be sure to use
> > multiprocessors.<br><br>I'm also considering t=
> > >aking the time to try various historical versions=2C
> > either releases or dat=
> > >es in CVS.<br><br>&nbsp=3B-
> > Jay<br><br><hr id=3D"stopSpelling">From:
> > jay.kr=
> > >ell at cornell.edu<br>To:
> > mika at async.caltech.edu=3B
> > rcolebur at scires.com<br>Dat=
> > >e: Tue=2C 1 Mar 2011 10:59:29 +0000<br>CC: m3devel at elegosoft.com<br>Subject=
> > >: Re: [M3devel] results of threadtest program on
> > Windows7<br><br>
> > >
> > ><meta http-equiv=3D"Content-Type"
> > content=3D"text/html=3B charset=3Dunicode=
> > >">
> > ><meta name=3D"Generator" content=3D"Microsoft
> > SafeHTML">
> > ><style>
> > >.ExternalClass .ecxhmmessage P
> > >{padding:0px=3B}
> > >.ExternalClass body.ecxhmmessage
> > >{font-size:10pt=3Bfont-family:Tahoma=3B}
> > >
> > ></style>
> > >
> > >
> > >I haven't seen it fail on NT=2C except for PutCard in
> > the test itself getti=
> > >ng negative numbers.<br>I've run it just a few
> > times now. One single and du=
> > >al processor virtual machines.<br>Randy=2C has it
> > failed many times for you=
> > >?<br><br>&nbsp=3B-
> > Jay<br><br>&gt=3B To: rcolebur at SCIRES.COM<br>&gt=3B
> > Date=
> > >: Sun=2C 27 Feb 2011 15:11:25 -0800<br>&gt=3B
> > From: mika at async.caltech.edu<=
> > >br>&gt=3B CC: m3devel at elegosoft.com<br>&gt=3B
> > Subject: Re: [M3devel] result=
> > >s of threadtest program on Windows7<br>&gt=3B
> > <br>&gt=3B Ah=2C it just does=
> > >n't check command-line arguments that
> > carefully.<br>&gt=3B <br>&gt=3B I thi=
> > >nk what you did is equivalent to "-tests
> > STD".<br>&gt=3B <br>&gt=3B 
> > Mi=
> > >ka<br>&gt=3B <br>&gt=3B
> > "Coleburn=2C Randy" writes:<br>&gt=3B
> > &gt=3BMika:<b=
> > >r>&gt=3B &gt=3B<br>&gt=3B
> > &gt=3BNo change with "-tests POSIX".<br>&gt=3B
> > &g=
> > >t=3B<br>&gt=3B &gt=3BInteresting
> > twist: On Windows 7=2C I thought I'd see =
> > >what the command line o=3D<br>&gt=3B
> > &gt=3Bptions are=2C and I typed "threa=
> > >dtest -help" rather than reading the
> > code.<br>&gt=3B &gt=3B<br>&gt=3B
> > &gt=
> > >=3BFirst time=2C it produced what appears to be a NIL
> > deref crash. Then=2C=
> > > I trie=3D<br>&gt=3B &gt=3Bd it again and
> > it ran to completion. Something =
> > >seems non-deterministic her=3D<br>&gt=3B
> > &gt=3Be. See below.<br>&gt=3B &gt=
> > >=3B<br>&gt=3B
> > &gt=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bt=
> > >hreadtest.exe -help<br>&gt=3B
> > &gt=3BWriting file...done<br>&gt=3B
> > &gt=3BCre=
> > >ating read threads...done<br>&gt=3B
> > &gt=3BCreating fork threads...done<br>&=
> > >gt=3B &gt=3BCreating alloc
> > threads...done<br>&gt=3B &gt=3BCreating lock
> > thr=
> > >eads...done<br>&gt=3B
> > &gt=3Brunning...printing oldest/median
> > age/newest<br>=
> > >&gt=3B &gt=3B.<br>&gt=3B
> > &gt=3B<br>&gt=3B
> > &gt=3B***<br>&gt=3B &gt=3B*** run=
> > >time error:<br>&gt=3B &gt=3B*** 
> > Attempt to reference an illegal memory l=
> > >ocation.<br>&gt=3B &gt=3B*** 
> > pc =3D3D 0x77762262<br>&gt=3B
> > &gt=3B***<br>=
> > >&gt=3B &gt=3B<br>&gt=3B
> > &gt=3BStack trace:<br>&gt=3B
> > &gt=3B FP 
> > PC=
> > > Procedure<br>&gt=3B
> > &gt=3B--------- --------- 
> > ---------------------=
> > >----------<br>&gt=3B &gt=3B
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\s=
> > >rc\runtime\NT386\RTSignal.m=3D<br>&gt=3B
> > &gt=3B3<br>&gt=3B &gt=3B 0xcdf9c0 =
> > > 0x77762262 
> > &lt=3B???&gt=3B<br>&gt=3B &gt=3B
> > 0xcdf9d8 0x12e83b7 LockMute=
> > >x + 0x4f in
> > ..\src\thread\WIN32\ThreadWin32.m=3D<br>&gt=3B
> > &gt=3B3<br>&gt=
> > >=3B &gt=3B 0xcdfa00 0x12c7b08 GetChar +
> > 0x28 in ..\src\rw\Rd.m3<br>&gt=3B=
> > > &gt=3B 0xcdfb38 0x12c12e3 RApply +
> > 0xd3 in ..\src\Main.m3<br>&gt=3B &gt=
> > >=3B 0xcdfb74 0x12e971f ThreadBase + 0x254
> > in ..\src\thread\WIN32\ThreadWi=
> > >n32=3D<br>&gt=3B
> > &gt=3B.m3<br>&gt=3B &gt=3B 0xcdfb80 
> > 0x76543677 &lt=3B???=
> > >&gt=3B<br>&gt=3B &gt=3B
> > 0xcdfbc0 0x77779f02 
> > &lt=3B???&gt=3B<br>&gt=3B &gt=
> > >=3B......... ......... ... more frames
> > ...<br>&gt=3B &gt=3B<br>&gt=3B
> > &gt=
> > >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest.exe
> > -he=
> > >lp<br>&gt=3B &gt=3BWriting
> > file...done<br>&gt=3B &gt=3BCreating read
> > thread=
> > >s...done<br>&gt=3B &gt=3BCreating fork
> > threads...done<br>&gt=3B &gt=3BCreat=
> > >ing alloc threads...done<br>&gt=3B
> > &gt=3BCreating lock threads...done<br>&g=
> > >t=3B &gt=3Brunning...printing oldest/median
> > age/newest<br>&gt=3B &gt=3B....=
> > >......laziest thread is 0/0/0 (tests: read 0/0/0 fork
> > 0/0/0 alloc 0/0/0=3D<=
> > >br>&gt=3B &gt=3B lock
> > 0/0/0)<br>&gt=3B &gt=3B..........laziest
> > thread is 0/=
> > >0/0 (tests: read 0/0/0 fork 0/0/0 alloc
> > 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/=
> > >0)<br>&gt=3B &gt=3B..........laziest
> > thread is 0/0/0 (tests: read 0/0/0 for=
> > >k 0/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B
> > lock 0/0/0)<br>&gt=3B &gt=3B.......=
> > >...laziest thread is 0/0/0 (tests: read 0/0/0 fork
> > 0/0/0 alloc 0/0/0=3D<br>=
> > >&gt=3B &gt=3B lock 0/0/0)<br>&gt=3B
> > &gt=3B..........laziest thread is 0/0/0=
> > > (tests: read 0/0/0 fork 0/0/0 alloc
> > 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/0)<=
> > >br>&gt=3B &gt=3B..........laziest thread is
> > 0/0/0 (tests: read 0/0/0 fork 0=
> > >/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock
> > 0/0/0)<br>&gt=3B &gt=3B..........=
> > >laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0
> > alloc 0/0/0=3D<br>&gt=
> > >=3B &gt=3B lock 0/0/0)<br>&gt=3B
> > &gt=3B..........laziest thread is 0/0/0 (t=
> > ests: read 0/0/0 fork 0/0/0 alloc
> > 0/0/0=3D<br>&gt=3B &gt=3B lock
> > 0/0/0)<br>=
> > >&gt=3B &gt=3B..........laziest thread is 0/0/0
> > (tests: read 0/0/0 fork 0/0/=
> > >0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock
> > 0/0/0)<br>&gt=3B &gt=3B..........laz=
> > >iest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0
> > alloc 0/0/0=3D<br>&gt=3B=
> > > &gt=3B lock 0/0/0)<br>&gt=3B
> > &gt=3BAll tests complete. Congratulations.<b=
> > >r>&gt=3B &gt=3B<br>&gt=3B
> > &gt=3BRegards=2C<br>&gt=3B &gt=3BRandy
> > Coleburn<b=
> > >r>&gt=3B &gt=3B<br>&gt=3B
> > &gt=3B-----Original Message-----<br>&gt=3B
> > &gt=3B=
> > >From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20<br>&gt=3B
> > &gt=3BSen=
> > >t: Sunday=2C February 27=2C 2011 3:30
> > PM<br>&gt=3B &gt=3BTo: Coleburn=2C Ra=
> > >ndy<br>&gt=3B &gt=3BCc: m3devel at elegosoft.com<br>&gt=3B
> > &gt=3BSubject: Re: =
> > >[M3devel] results of threadtest program on
> > Windows7=3D20<br>&gt=3B &gt=3B<b=
> > >r>&gt=3B &gt=3BHi
> > Randy=2C<br>&gt=3B &gt=3B<br>&gt=3B
> > &gt=3BYou can try it =
> > >with -tests POSIX as well.<br>&gt=3B
> > &gt=3B<br>&gt=3B &gt=3BI find on user =
> > >threads it runs very slowly (but it does run) because
> > of how=3D<br>&gt=3B &=
> > >gt=3B unfair<br>&gt=3B &gt=3Bthe thread
> > scheduler is.<br>&gt=3B
> > &gt=3B<br>&=
> > >gt=3B &gt=3BNext step might be to whittle down the
> > tests and see if you can=
> > > get a failu=3D<br>&gt=3B &gt=3Bre
> > with<br>&gt=3B &gt=3Ba single test runni=
> > >ng and -n 2. That would likely be the simplest
> > scenario=3D<br>&gt=3B &gt=
> > >=3B to<br>&gt=3B &gt=3Bstart further
> > debugging from.<br>&gt=3B
> > &gt=3B<br>&g=
> > >t=3B &gt=3B 
> > Mika<br>&gt=3B
> > &gt=3B<br>&gt=3B &gt=3B"Coleburn=2C Randy"
> > w=
> > >rites:<br>&gt=3B &gt=3B&gt=3BMika et
> > al:<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &=
> > >gt=3B&gt=3BThought I would try something
> > else.<br>&gt=3B
> > &gt=3B&gt=3B<br>&g=
> > >t=3B &gt=3B&gt=3BI took the sources of your
> > thread test program to an older=
> > > XP machine that=3D<br>&gt=3B &gt=3B
> > =3D3D<br>&gt=3B &gt=3B&gt=3Bhas CM3 ci=
> > >rca August 2008. This is the machine and
> > implementation I used =3D<br>&gt=
> > >=3B &gt=3Bw=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bhen building a major project I did a=
> > > couple years back.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BThe thread=
> > > test program does indeed build on this old system=2C
> > but when I r=3D<br>&g=
> > >t=3B &gt=3Bu=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bn it=2C I get different results tha=
> > >n with the latest HEAD branch code.
> > =3D3D20<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=
> > >=3B &gt=3B&gt=3BAfter it prints
> > "running...printing oldest/median age/newes=
> > >t"=2C on the next=3D<br>&gt=3B &gt=3B
> > =3D3D<br>&gt=3B &gt=3B&gt=3Bline I ge=
> > >t two periods ".." and now the program seems
> > hung. I'll let it "=3D<br>&gt=
> > >=3B &gt=3Br=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bun" for a few more minutes to see if=
> > > anything else happens before killing
> > =3D<br>&gt=3B &gt=3Bi=3D3D<br>&gt=3B
> > =
> > >&gt=3B&gt=3Bt.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BAt least we don=
> > >'t get the subscript and assertion failures on this
> > older C=3D<br>&gt=3B &g=
> > >t=3BM=3D3D<br>&gt=3B &gt=3B&gt=3B3
> > platform.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=
> > >=3B &gt=3B&gt=3BRegards=2C<br>&gt=3B
> > &gt=3B&gt=3BRandy Coleburn<br>&gt=3B
> > &=
> > >gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B-----Original Mess=
> > >age-----<br>&gt=3B &gt=3B&gt=3BFrom:
> > Coleburn=2C Randy=3D3D20<br>&gt=3B &gt=
> > >=3B&gt=3BSent: Sunday=2C February 27=2C 2011 2:09
> > PM<br>&gt=3B &gt=3B&gt=3B=
> > >To: m3devel at elegosoft.com<br>&gt=3B
> > &gt=3B&gt=3BSubject: Re: [M3devel] resu=
> > >lts of threadtest program on
> > Windows7<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=
> > >=3B&gt=3BMika:<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BOk=2C I've upda=
> > >ted to latest HEAD and I've also built Jay's m3sleep
> > program.<br>&gt=3B &gt=
> > >=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BHere is what happens now when I run your
> > th=
> > >readtest program on Windows 7.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
> > >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest
> > -tests =
> > >ALL=2C-fo=3D<br>&gt=3B
> > &gt=3Br=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bk<br>&gt=3B &gt=
> > >=3B&gt=3BWriting file...done<br>&gt=3B
> > &gt=3B&gt=3BCreating read threads...=
> > >done<br>&gt=3B &gt=3B&gt=3BCreating
> > nxread threads...done<br>&gt=3B &gt=3B&=
> > >gt=3BCreating tryexcept
> > threads...done<br>&gt=3B
> > &gt=3B&gt=3BCreating forkt=
> > >oomuch threads...done<br>&gt=3B
> > &gt=3B&gt=3BCreating alloc threads...done<b=
> > >r>&gt=3B &gt=3B&gt=3BCreating creat
> > threads...done<br>&gt=3B &gt=3B&gt=3BCr=
> > >eating lock threads...done<br>&gt=3B
> > &gt=3B&gt=3Brunning...printing oldest/=
> > >median age/newest<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &=
> > >gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B*** runtime error:<br>&gt=3B
> > &gt=3B&gt=
> > >=3B*** An array subscript was out of
> > range.<br>&gt=3B
> > &gt=3B&gt=3B*** =
> > > file "..\src\runtime\common\RTCollector.m3"=2C line
> > 418<br>&gt=3B &gt=3B&g=
> > >t=3B***<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
> > >=3B<br>&gt=3B
> > &gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B*** runtime error:<br>&=
> > >gt=3B &gt=3B&gt=3B*** 
> > &lt=3B*ASSERT*&gt=3B failed.<br>&gt=3B
> > &gt=3B&gt=
> > >=3B*** file
> > "..\src\thread\WIN32\ThreadWin32.m3"=2C line
> > 841<br>&gt=3B &=
> > >gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BThe last error =
> > >repeats ad infinitum until I press CNTRL-C to
> > abort.<br>&gt=3B &gt=3B&gt=3B=
> > ><br>&gt=3B &gt=3B&gt=3BI'll send more
> > info on the Windows install of Modula=
> > >3 in a subsequent post=3D<br>&gt=3B
> > &gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=
> > >=3B &gt=3B&gt=3BRegards=2C<br>&gt=3B
> > &gt=3B&gt=3BRandy Coleburn<br>&gt=3B
> > &=
> > >gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B-----Original
> > Message-----<br>&gt=3B &gt=
> > >=3B&gt=3BFrom: Mika Nystrom [mailto:mika at async.caltech.edu]=3D3D20<br>&gt=
> > >=3B &gt=3B&gt=3BSent: Saturday=2C February
> > 26=2C 2011 12:55 PM<br>&gt=3B &g=
> > >t=3B&gt=3BTo: Coleburn=2C Randy<br>&gt=3B
> > &gt=3B&gt=3BCc: m3devel at elegosoft=
> > >.com<br>&gt=3B &gt=3B&gt=3BSubject:
> > Re: [M3devel] results of threadtest pro=
> > >gram on Windows7=3D3D20<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BHi Ran=
> > >dy=2C<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BHm yes it looks like my =
> > >Windows programming skills leave
> > something<br>&gt=3B &gt=3B&gt=3Bto be
> > desi=
> > >red.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BYou can run the thread te=
> > >ster while skipping a test as
> > follows<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=
> > >=3B&gt=3B threadtest -tests
> > ALL=2C-fork<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B =
> > >&gt=3B&gt=3B(for instance)<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3Bif =
> > >you just run=3D3D20<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B threadt=
> > >est -sadfassdaf<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3Bit'll print th=
> > >e tests that are available.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BAs=
> > > it happens=2C I just had to upgrade my windows 2000
> > system to windows 7.<b=
> > >r>&gt=3B &gt=3B&gt=3BCan you give me a
> > very brief description of what you d=
> > >id to install Modula=3D<br>&gt=3B
> > &gt=3B-=3D3D<br>&gt=3B
> > &gt=3B&gt=3B3<br>&=
> > >gt=3B &gt=3B&gt=3Bon this
> > system?<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=3B&g=
> > >t=3B Mika<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B"Coleburn=2C Ran=
> > >dy" writes:<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B--_000_D67F02DDC62F7545A6B84C285F88=
> > >F3E6EE25C849atlex02srv_<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BContent-Type: text/plai=
> > >n=3B charset=3D3D3D"us-ascii"<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BContent-Transfer-=
> > >Encoding: quoted-printable<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=
> > >=3B&gt=3BMika:<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BI'v=
> > >e finally managed to get cm3 rebuilt on Windows 7
> > again.<br>&gt=3B &gt=3B&g=
> > >t=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BSo=2C I ran your threadtest
> > program.=
> > ><br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BHere are the resu=
> > >lts. Note the "..." is where I cut out a bunch of
> > the r=3D<br>&gt=3B &gt=
> > >=3Be=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Beating=
> > > "ERROR FApply" messages.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=
> > >=3B&gt=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest.e=
> > >xe<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BWriting
> > file...done<br>&gt=3B &gt=3B&gt=3B&g=
> > >t=3BCreating read threads...done<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BCreating fork =
> > >threads...done<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BCreating alloc
> > threads...done<br=
> > >>&gt=3B &gt=3B&gt=3B&gt=3BCreating
> > lock threads...done<br>&gt=3B &gt=3B&gt=
> > >=3B&gt=3Brunning...printing oldest/median
> > age/newest<br>&gt=3B &gt=3B&gt=3B=
> > >&gt=3BERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find=
> > > the f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=
> > >=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OS=
> > >Error.E: ErrorCode=3D3D3D3D2: The system cannot
> > find the f=3D<br>&gt=3B &g=
> > >t=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Be=
> > >cified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E: 
> > ErrorCode=3D3=
> > >D3D3D2: The system cannot find the
> > f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B =
> > >&gt=3B&gt=3B sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=
> > >=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B=
> > >.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B*** runtime e=
> > >rror:<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B*** An
> > enumeration or subrange value w=
> > >as out of range.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B*** file
> > "..\src\Main.m3"=
> > >=2C line 340<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<b=
> > >r>&gt=3B &gt=3B&gt=3B&gt=3Blaziest
> > thread is 0/0/ERROR FApply: OSError.E: =
> > >ErrorCode=3D3D3D3D2: The sy=3D<br>&gt=3B
> > &gt=3Bste=3D3D<br>&gt=3B &gt=3B&gt=
> > >=3Bm c=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Bannot find the file
> > specified.<br=
> > >>&gt=3B &gt=3B&gt=3B&gt=3BERROR
> > FApply: OSError.E: ErrorCode=3D3D3D3D2: Th=
> > >e system cannot find the f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=
> > >=3B sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&g=
> > >t=3BERROR FApply: OSError.E: ErrorCode=3D3D3D3D2:
> > The system cannot find t=
> > >he f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B=
> > >
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSErr=
> > >or.E: ErrorCode=3D3D3D3D2: The system cannot find
> > the f=3D<br>&gt=3B &gt=
> > >=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Bec=
> > >ified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=
> > >=3B &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Blaziest thread is 0/0/E=
> > >RROR FApply: OSError.E: ErrorCode=3D3D3D3D2: The
> > sy=3D<br>&gt=3B &gt=3Bste=
> > >=3D3D<br>&gt=3B &gt=3B&gt=3Bm
> > c=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Bannot fi=
> > >nd the file specified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E:=
> > > ErrorCode=3D3D3D3D2: The system cannot find the
> > f=3D<br>&gt=3B &gt=3Bile=
> > >=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.=
> > ><br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2:=
> > > The system cannot find the f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&=
> > >gt=3B sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B=
> > >&gt=3BERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find=
> > > the f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=
> > >=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=
> > >=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B=
> > >ERROR FApply: OSError.E: ErrorCode=3D3D3D3D2: The
> > system cannot find the f=
> > >=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B &gt=
> > >=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E=
> > >: ErrorCode=3D3D3D3D2: The system cannot find the
> > f=3D<br>&gt=3B &gt=3Bile=
> > >=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.=
> > ><br>&gt=3B
> > &gt=3B&gt=3B&gt=3BStack
> > trace:<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B FP=
> > > PC 
> > Procedure<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B--------- ---------=
> > > 
> > -------------------------------<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B0x30fbd0 0x1=
> > >27218a PutStats + 0x1a3 in
> > ..\src\Main.m3<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B0x30=
> > >fcc0 0x1273825 Main_M3 + 0x11db(!) in
> > ..\src\Main.m3<br>&gt=3B &gt=3B&gt=
> > >=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BRegards=2C<br>&gt=3B
> > &gt=3B&gt=3B&gt=
> > >=3BRandy Coleburn<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B=
> > >--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_<br>&gt=3B
> > &gt=3B=
> > >&gt=3B&gt=3BContent-Type: text/html=3B
> > charset=3D3D3D"us-ascii"<br>&gt=3B &=
> > >gt=3B&gt=3B&gt=3BContent-Transfer-Encoding:
> > quoted-printable<br>&gt=3B &gt=
> > >=3B&gt=3B&gt=3B<br> 
> > 
> > 
> > </body>
> > ></html>=
> > >
> > >--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_--
> > 
> 
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110302/cc086c5c/attachment-0002.html>

From hendrik at topoi.pooq.com  Wed Mar  2 04:39:45 2011
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Tue, 1 Mar 2011 22:39:45 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <20110301181718.12EFC1A2078@async.async.caltech.edu>
References: <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>
	<COL101-W6172E969583BD60401B836E6C10@phx.gbl>
	<20110301181718.12EFC1A2078@async.async.caltech.edu>
Message-ID: <20110302033945.GC32641@topoi.pooq.com>

On Tue, Mar 01, 2011 at 10:17:18AM -0800, Mika Nystrom wrote:
> 
> Hi Jay,
> 
> 2. Not sure how you could get negative timings.  That would suggest that
> Time.Now() is decreasing---which seems contrary to its specification.
> Although the code is doing some nasty stuff with the timings, mainly
> reading and writing them without locks.  But it's using INTEGER for
> the results so I don't think there can be an atomicity problem there.
> Even if there were coherence problems between processors (is this
> technically possible?) the "now" value has to be coherent since it's
> from the thread that prints the results, and the "then" values could
> only be getting older, not newer...

I've been on a machine before on which the clock occasinally ran 
backwards -- notably a CDC Cyber machine.  I don't doubt that OS and 
hardware designers have found ways to replicate this behaviour on moderm 
machines.  :-(

-- hendrik


From jay.krell at cornell.edu  Wed Mar  2 05:49:16 2011
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Mar 2011 04:49:16 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <20110302033945.GC32641@topoi.pooq.com>
References: <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	<COL101-W6172E969583BD60401B836E6C10@phx.gbl>,
	<20110301181718.12EFC1A2078@async.async.caltech.edu>,
	<20110302033945.GC32641@topoi.pooq.com>
Message-ID: <COL101-W4908705893B5758DC5446EE6C00@phx.gbl>


> I've been on a machine before on which the clock occasinally ran 
> backwards -- notably a CDC Cyber machine. I don't doubt that OS and 
> hardware designers have found ways to replicate this behaviour on moderm 
> machines. :-(
> I've been on a machine before on which the clock occasinally ran 
> backwards -- notably a CDC Cyber machine. I don't doubt that OS and 

Come on! Widely used modern systems must be and are very high quality,
not like older and little used systems. The clock is not going backwards.
 
 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110302/3f0e8a9c/attachment-0002.html>

From hosking at cs.purdue.edu  Wed Mar  2 15:11:55 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 2 Mar 2011 09:11:55 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W3670B74A99994199607C6BE6C00@phx.gbl>
References: <20110301181718.12EFC1A2078@async.async.caltech.edu>,
	<452042.5906.qm@web29706.mail.ird.yahoo.com>
	<COL101-W3670B74A99994199607C6BE6C00@phx.gbl>
Message-ID: <D8168970-37FE-43C9-8127-BE5024AD43E0@cs.purdue.edu>

'Twould be useful to see a stack dump.

On Mar 1, 2011, at 10:11 PM, Jay K wrote:

> Most of the runs error or succeed within 10 minutes. The one Solaris/sparc run I made ran for well over 4 hours and didn't get very far. I'd say it was hung forever.
>  
>  
> I didn't debug it.
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110302/3228a606/attachment-0002.html>

From dabenavidesd at yahoo.es  Wed Mar  2 22:31:41 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 2 Mar 2011 21:31:41 +0000 (GMT)
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W3670B74A99994199607C6BE6C00@phx.gbl>
Message-ID: <571065.83147.qm@web29715.mail.ird.yahoo.com>

Hi all:
yes, but technically you could insert some empty chips slots on the same wafer but in cases of blade systems I'm sure you can, just don't know how much about something like plug-and-play with that.
Thanks in advance

--- El mar, 1/3/11, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: RE: [M3devel] results of threadtest program on Windows7
Para: dabenavidesd at yahoo.es, "Mika Nystrom" <mika at async.caltech.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: martes, 1 de marzo, 2011 22:11




I have still have mostly uniprocessors (though busy selling stuff off...)

? I do have a MacBook Pro and Dell laptop with 2 processors each though.

? It is that MacBook Pro where I can consistently get Darwin to fail, and a?1 and 2 proc Windows virtual machine on the MacBook Pro?that consistently works.

? While Modula-3 user threads never run anything truly concurrently, i.e. on multiple prcoessors, there should still be almost arbitrary preemption.

?

?

I'm skeptical of?any emulation's or virtualization's ability to simulate more processors than underlying physical processors.

?

?

Most of the runs error or succeed within 10 minutes. The one Solaris/sparc run I made ran for well over 4 hours and didn't get very far. I'd say it was hung forever.

?

?

I didn't debug it.

?

?

Yes, OpenBSD pthreads are user threads and therefore probably only ever use one processor.

But that machine only has one. :)


?

I think this will quite difficult to track down.

It might be useful to find an old starting point that succeeds and upgrade forward looking for when things fail.

That is tedious and has its own set of difficulties, granted.

?There are many points in time that don't compile, many are my fault, and there are also many combinations of starting/ending points that don't compile due to some mismatches between start/end.

?

?

I have to try Linux and/or FreeBSD still.

?

?

The errors on Darwin imply to me that memory is being prematurely reclaimed by the garbage collector -- e.g. EBUSY from pthread_mutex_destroy.

But it could also be arbitrary memory corruption (sort of the same thing), same example, but rather than an actually busy mutex, it could be a corrupted mutex or random pointer. Some of that might be easy to track down, e.g. by tracing which addresses are initialized as mutexes, and maybe by putting pad bytes around mutexes and seeing if they get changed.

I'm reluctant to try draw any conclusions yet though, since I have very very little information/knowledge.

?

?

I also forgot to check if I was using any optimization. I'll be sure to not.

?

?

?- Jay


?

> Date: Tue, 1 Mar 2011 22:10:55 +0000
> From: dabenavidesd at yahoo.es
> To: jay.krell at cornell.edu; mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Hi all:
> but you could still run a *nix image with uniprocessor support kernel and try on the vbox, qemu, etc.
> Perhaps you would get enough simulation to detect that the problem is on the hardware layer (either physically or its abstraction) rather than the execution model (the pthreads scheduling policy), if it does no work may be there is a problem in ThreadPthread implementation of pthreads (don't need to switch its default is - smp 1).
> commands i.e in qemu:
> qemu -cdrom /path/to/system.iso -smp 2 
> and run threadtest from there
> 
> Thanks in advance
> 
> 
> 
> 
> 
> 
> --- El mar, 1/3/11, Mika Nystrom <mika at async.caltech.edu> escribi?:
> 
> > De: Mika Nystrom <mika at async.caltech.edu>
> > Asunto: Re: [M3devel] results of threadtest program on Windows7
> > Para: "Jay K" <jay.krell at cornell.edu>
> > CC: m3devel at elegosoft.com
> > Fecha: martes, 1 de marzo, 2011 13:17
> > 
> > Hi Jay,
> > 
> > 1. I think you should get forward progress no matter what,
> > although it
> > might be very slow on some systems.
> > 
> > 2. Not sure how you could get negative timings. That
> > would suggest that
> > Time.Now() is decreasing---which seems contrary to its
> > specification.
> > Although the code is doing some nasty stuff with the
> > timings, mainly
> > reading and writing them without locks. But it's
> > using INTEGER for
> > the results so I don't think there can be an atomicity
> > problem there.
> > Even if there were coherence problems between processors
> > (is this
> > technically possible?) the "now" value has to be coherent
> > since it's
> > from the thread that prints the results, and the "then"
> > values could
> > only be getting older, not newer...
> > 
> > 3. Note that there are systems (FreeBSD 4 is an example)
> > that have a
> > "pthreads" library but where the pthreads library is
> > implemented with
> > user threads. Could that be related to why OpenBSD is
> > working?
> > 
> > 4. Hm. I think I am only using multiprocessor
> > systems, yes. Hard to
> > find single-CPU systems nowadays! I think actually
> > the only one I have
> > is PPC_DARWIN, and I haven't tried the code on that. 
> > So yes this is a
> > possibility as far as explaining differences...
> > 
> > Mika
> > 
> > Jay K writes:
> > >--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_
> > >Content-Type: text/plain; charset="iso-8859-1"
> > >Content-Transfer-Encoding: quoted-printable
> > >
> > >
> > >I also haven't seen it fail on OpenBSD/x86/4.7. I'm
> > pretty sure using pthre=
> > >ads there.
> > >But on Solaris/5.10/sparc it hangs=2C for many hours.
> > >
> > >-bash-4.1$ ./threadtest=20
> > >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
> > >.
> > >
> > >Are we guranteed forward progress in suspending all
> > threads?
> > >
> > >I do see it fail usually on Darwin. e.g.:
> > >........pthread_mutex_destroy:EBUSY
> > >pthread_mutex_destroy:EBUSY
> > >..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:
> > >*** An array subscript was out of range.
> > >*** file
> > "../src/runtime/common/RTCollector.m3"=2C line 418
> > >***
> > >
> > >I haven't tried Linux yet.
> > >Do note that we have some variance in the pthreads
> > implementation.
> > >The "portable" implementation is used on Linux=2C
> > Solaris=2C NetBSD.
> > >And then OpenBSD=2C Darwin=2C FreeBSD each have slight
> > differences.
> > >
> > >Mika are your machines all multiprocessors?
> > >I do wonder if that helps increase the stress and if I
> > should be sure to us=
> > >e multiprocessors.
> > >
> > >I'm also considering taking the time to try various
> > historical versions=2C =
> > >either releases or dates in CVS.
> > >
> > > - Jay
> > >
> > >From: jay.krell at cornell.edu
> > >To: mika at async.caltech.edu=3B
> > rcolebur at scires.com
> > >Date: Tue=2C 1 Mar 2011 10:59:29 +0000
> > >CC: m3devel at elegosoft.com
> > >Subject: Re: [M3devel] results of threadtest program on
> > Windows7
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >I haven't seen it fail on NT=2C except for PutCard in
> > the test itself getti=
> > >ng negative numbers.
> > >I've run it just a few times now. One single and dual
> > processor virtual mac=
> > >hines.
> > >Randy=2C has it failed many times for you?
> > >
> > > - Jay
> > >
> > >> To: rcolebur at SCIRES.COM
> > >> Date: Sun=2C 27 Feb 2011 15:11:25 -0800
> > >> From: mika at async.caltech.edu
> > >> CC: m3devel at elegosoft.com
> > >> Subject: Re: [M3devel] results of threadtest
> > program on Windows7
> > >>=20
> > >> Ah=2C it just doesn't check command-line arguments
> > that carefully.
> > >>=20
> > >> I think what you did is equivalent to "-tests
> > STD".
> > >=20
> > >> Mika
> > >>=20
> > >> "Coleburn=2C Randy" writes:
> > >> >Mika:
> > >> >
> > >> >No change with "-tests POSIX".
> > >> >
> > >> >Interesting twist: On Windows 7=2C I
> > thought I'd see what the command l=
> > >ine o=3D
> > >> >ptions are=2C and I typed "threadtest -help"
> > rather than reading the cod=
> > >e.
> > >> >
> > >> >First time=2C it produced what appears to be a
> > NIL deref crash. Then=2C=
> > > I trie=3D
> > >> >d it again and it ran to completion. 
> > Something seems non-deterministic =
> > >her=3D
> > >> >e. See below.
> > >> >
> > >>
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > -help
> > >> >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
> > >> >.
> > >> >
> > >> >***
> > >> >*** runtime error:
> > >> >*** Attempt to reference an
> > illegal memory location.
> > >> >*** pc =3D3D 0x77762262
> > >> >***
> > >> >
> > >> >Stack trace:
> > >> > FP 
> > PC Procedure
> > >> >--------- --------- 
> > -------------------------------
> > >> > 0xcdf998 0x130351b SystemError +
> > 0x64 in ..\src\runtime\NT386\RTSigna=
> > >l.m=3D
> > >> >3
> > >> > 0xcdf9c0 0x77762262 <???>
> > >> > 0xcdf9d8 0x12e83b7 LockMutex +
> > 0x4f in ..\src\thread\WIN32\ThreadWin3=
> > >2.m=3D
> > >> >3
> > >> > 0xcdfa00 0x12c7b08 GetChar + 0x28
> > in ..\src\rw\Rd.m3
> > >> > 0xcdfb38 0x12c12e3 RApply + 0xd3
> > in ..\src\Main.m3
> > >> > 0xcdfb74 0x12e971f ThreadBase +
> > 0x254 in ..\src\thread\WIN32\ThreadWi=
> > >n32=3D
> > >> >.m3
> > >> > 0xcdfb80 0x76543677 <???>
> > >> > 0xcdfbc0 0x77779f02 <???>
> > >> >......... ......... ... more
> > frames ...
> > >> >
> > >>
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > -help
> > >> >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
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >..........laziest thread is 0/0/0 (tests: read
> > 0/0/0 fork 0/0/0 alloc 0/=
> > >0/0=3D
> > >> > lock 0/0/0)
> > >> >All tests complete. Congratulations.
> > >> >
> > >> >Regards=2C
> > >> >Randy Coleburn
> > >> >
> > >> >-----Original Message-----
> > >> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> > >> >Sent: Sunday=2C February 27=2C 2011 3:30 PM
> > >> >To: Coleburn=2C Randy
> > >> >Cc: m3devel at elegosoft.com
> > >> >Subject: Re: [M3devel] results of threadtest
> > program on Windows7=3D20
> > >> >
> > >> >Hi Randy=2C
> > >> >
> > >> >You can try it with -tests POSIX as well.
> > >> >
> > >> >I find on user threads it runs very slowly
> > (but it does run) because of =
> > >how=3D
> > >> > unfair
> > >> >the thread scheduler is.
> > >> >
> > >> >Next step might be to whittle down the tests
> > and see if you can get a fa=
> > >ilu=3D
> > >> >re with
> > >> >a single test running and -n 2. That
> > would likely be the simplest scena=
> > >rio=3D
> > >> > to
> > >> >start further debugging from.
> > >> >
> > >> > Mika
> > >> >
> > >> >"Coleburn=2C Randy" writes:
> > >> >>Mika et al:
> > >> >>
> > >> >>Thought I would try something else.
> > >> >>
> > >> >>I took the sources of your thread test
> > program to an older XP machine t=
> > >hat=3D
> > >> > =3D3D
> > >> >>has CM3 circa August 2008. This is
> > the machine and implementation I us=
> > >ed =3D
> > >> >w=3D3D
> > >> >>hen building a major project I did a
> > couple years back.
> > >> >>
> > >> >>The thread test program does indeed build
> > on this old system=2C but whe=
> > >n I r=3D
> > >> >u=3D3D
> > >> >>n it=2C I get different results than with
> > the latest HEAD branch code. =
> > >=3D3D20
> > >> >>
> > >> >>After it prints "running...printing
> > oldest/median age/newest"=2C on the=
> > > next=3D
> > >> > =3D3D
> > >> >>line I get two periods ".." and now the
> > program seems hung. I'll let i=
> > >t "=3D
> > >> >r=3D3D
> > >> >>un" for a few more minutes to see if
> > anything else happens before killi=
> > >ng =3D
> > >> >i=3D3D
> > >> >>t.
> > >> >>
> > >> >>At least we don't get the subscript and
> > assertion failures on this olde=
> > >r C=3D
> > >> >M=3D3D
> > >> >>3 platform.
> > >> >>
> > >> >>Regards=2C
> > >> >>Randy Coleburn
> > >> >>
> > >> >>
> > >> >>-----Original Message-----
> > >> >>From: Coleburn=2C Randy=3D3D20
> > >> >>Sent: Sunday=2C February 27=2C 2011 2:09
> > PM
> > >> >>To: m3devel at elegosoft.com
> > >> >>Subject: Re: [M3devel] results of
> > threadtest program on Windows7
> > >> >>
> > >> >>Mika:
> > >> >>
> > >> >>Ok=2C I've updated to latest HEAD and I've
> > also built Jay's m3sleep pro=
> > >gram.
> > >> >>
> > >> >>Here is what happens now when I run your
> > threadtest program on Windows =
> > >7.
> > >> >>
> > >>
> > >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest
> > -tests ALL=
> > >=2C-fo=3D
> > >> >r=3D3D
> > >> >>k
> > >> >>Writing file...done
> > >> >>Creating read threads...done
> > >> >>Creating nxread threads...done
> > >> >>Creating tryexcept threads...done
> > >> >>Creating forktoomuch threads...done
> > >> >>Creating alloc threads...done
> > >> >>Creating creat threads...done
> > >> >>Creating lock threads...done
> > >> >>running...printing oldest/median
> > age/newest
> > >> >>
> > >> >>
> > >> >>***
> > >> >>*** runtime error:
> > >> >>*** An array subscript was
> > out of range.
> > >> >>*** file
> > "..\src\runtime\common\RTCollector.m3"=2C line 418
> > >> >>***
> > >> >>
> > >> >>
> > >> >>
> > >> >>***
> > >> >>*** runtime error:
> > >> >>*** <*ASSERT*> failed.
> > >> >>*** file
> > "..\src\thread\WIN32\ThreadWin32.m3"=2C line 841
> > >> >>***
> > >> >>
> > >> >>The last error repeats ad infinitum until
> > I press CNTRL-C to abort.
> > >> >>
> > >> >>I'll send more info on the Windows install
> > of Modula3 in a subsequent p=
> > >ost=3D
> > >> >.
> > >> >>
> > >> >>Regards=2C
> > >> >>Randy Coleburn
> > >> >>
> > >> >>-----Original Message-----
> > >> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D3D20
> > >> >>Sent: Saturday=2C February 26=2C 2011
> > 12:55 PM
> > >> >>To: Coleburn=2C Randy
> > >> >>Cc: m3devel at elegosoft.com
> > >> >>Subject: Re: [M3devel] results of
> > threadtest program on Windows7=3D3D20
> > >> >>
> > >> >>Hi Randy=2C
> > >> >>
> > >> >>Hm yes it looks like my Windows
> > programming skills leave something
> > >> >>to be desired.
> > >> >>
> > >> >>You can run the thread tester while
> > skipping a test as follows
> > >> >>
> > >> >> threadtest -tests
> > ALL=2C-fork
> > >> >>
> > >> >>(for instance)
> > >> >>
> > >> >>if you just run=3D3D20
> > >> >>
> > >> >> threadtest -sadfassdaf
> > >> >>
> > >> >>it'll print the tests that are available.
> > >> >>
> > >> >>As it happens=2C I just had to upgrade my
> > windows 2000 system to window=
> > >s 7.
> > >> >>Can you give me a very brief description
> > of what you did to install Mod=
> > >ula=3D
> > >> >-=3D3D
> > >> >>3
> > >> >>on this system?
> > >> >>
> > >> >> Mika
> > >> >>
> > >> >>"Coleburn=2C Randy" writes:
> > >>
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >> >>>Content-Type: text/plain=3B
> > charset=3D3D3D"us-ascii"
> > >> >>>Content-Transfer-Encoding:
> > quoted-printable
> > >> >>>
> > >> >>>Mika:
> > >> >>>
> > >> >>>I've finally managed to get cm3
> > rebuilt on Windows 7 again.
> > >> >>>
> > >> >>>So=2C I ran your threadtest program.
> > >> >>>
> > >> >>>Here are the results. Note the
> > "..." is where I cut out a bunch of th=
> > >e r=3D
> > >> >e=3D3D
> > >> >>p=3D3D3D
> > >> >>>eating "ERROR FApply" messages.
> > >> >>>
> > >>
> > >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > >> >>>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
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>.
> > >> >>>.
> > >> >>>.
> > >> >>>***
> > >> >>>*** runtime error:
> > >> >>>*** An enumeration or
> > subrange value was out of range.
> > >> >>>*** file
> > "..\src\Main.m3"=2C line 340
> > >> >>>***
> > >> >>>
> > >> >>>laziest thread is 0/0/ERROR FApply:
> > OSError.E: ErrorCode=3D3D3D3D2: T=
> > >he sy=3D
> > >> >ste=3D3D
> > >> >>m c=3D3D3D
> > >> >>>annot find the file specified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>.
> > >> >>>.
> > >> >>>.
> > >> >>>laziest thread is 0/0/ERROR FApply:
> > OSError.E: ErrorCode=3D3D3D3D2: T=
> > >he sy=3D
> > >> >ste=3D3D
> > >> >>m c=3D3D3D
> > >> >>>annot find the file specified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>.
> > >> >>>.
> > >> >>>.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>ERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find =
> > >the f=3D
> > >> >ile=3D3D
> > >> >> sp=3D3D3D
> > >> >>>ecified.
> > >> >>>Stack trace:
> > >> >>> FP 
> > PC Procedure
> > >> >>>--------- --------- 
> > -------------------------------
> > >> >>>0x30fbd0 0x127218a 
> > PutStats + 0x1a3 in ..\src\Main.m3
> > >> >>>0x30fcc0 0x1273825 Main_M3
> > + 0x11db(!) in ..\src\Main.m3
> > >> >>>
> > >> >>>Regards=2C
> > >> >>>Randy Coleburn
> > >> >>>
> > >>
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >> >>>Content-Type: text/html=3B
> > charset=3D3D3D"us-ascii"
> > >> >>>Content-Transfer-Encoding:
> > quoted-printable
> > >> >>>
> > > 
> > 
> > 
> > =
> > >
> > >--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_
> > >Content-Type: text/html; charset="iso-8859-1"
> > >Content-Transfer-Encoding: quoted-printable
> > >
> > ><html>
> > ><head>
> > ><style><!--
> > >.hmmessage P
> > >{
> > >margin:0px=3B
> > >padding:0px
> > >}
> > >body.hmmessage
> > >{
> > >font-size: 10pt=3B
> > >font-family:Tahoma
> > >}
> > >--></style>
> > ></head>
> > ><body class=3D'hmmessage'>
> > >I also haven't seen it fail on OpenBSD/x86/4.7. I'm
> > pretty sure using pthre=
> > >ads there.<br>But on Solaris/5.10/sparc it
> > hangs=2C for many hours.<br><br>=
> > >-bash-4.1$ ./threadtest <br>Writing
> > file...done<br>Creating read threads...=
> > >done<br>Creating fork
> > threads...done<br>Creating alloc
> > threads...done<br>Cr=
> > >eating lock threads...done<br>running...printing
> > oldest/median age/newest<b=
> > >r>.<br><br>Are we guranteed forward
> > progress in suspending all threads?<br>=
> > ><br>I do see it fail usually on Darwin.
> > e.g.:<br>........pthread_mutex_dest=
> > >roy:EBUSY<br>pthread_mutex_destroy:EBUSY<br>..laziest
> > thread is 0/0/0 (test=
> > >s: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock
> > 0/0/0)<br>...<br><br>***<br>*** r=
> > >untime
> > error:<br>***&nbsp=3B&nbsp=3B&nbsp=3B An
> > array subscript was out of =
> > >range.<br>***&nbsp=3B&nbsp=3B&nbsp=3B
> > file "../src/runtime/common/RTCollect=
> > >or.m3"=2C line 418<br>***<br><br>I
> > haven't tried Linux yet.<br>Do note that=
> > > we have some variance in the pthreads
> > implementation.<br>The "portable" im=
> > >plementation is used on Linux=2C Solaris=2C
> > NetBSD.<br>And then OpenBSD=2C =
> > >Darwin=2C FreeBSD each have slight
> > differences.<br><br>Mika are your machin=
> > >es all multiprocessors?<br>I do wonder if that
> > helps increase the stress an=
> > >d if I should be sure to use
> > multiprocessors.<br><br>I'm also considering t=
> > >aking the time to try various historical versions=2C
> > either releases or dat=
> > >es in CVS.<br><br>&nbsp=3B-
> > Jay<br><br><hr id=3D"stopSpelling">From:
> > jay.kr=
> > >ell at cornell.edu<br>To:
> > mika at async.caltech.edu=3B
> > rcolebur at scires.com<br>Dat=
> > >e: Tue=2C 1 Mar 2011 10:59:29 +0000<br>CC: m3devel at elegosoft.com<br>Subject=
> > >: Re: [M3devel] results of threadtest program on
> > Windows7<br><br>
> > >
> > ><meta http-equiv=3D"Content-Type"
> > content=3D"text/html=3B charset=3Dunicode=
> > >">
> > ><meta name=3D"Generator" content=3D"Microsoft
> > SafeHTML">
> > ><style>
> > >.ExternalClass .ecxhmmessage P
> > >{padding:0px=3B}
> > >.ExternalClass body.ecxhmmessage
> > >{font-size:10pt=3Bfont-family:Tahoma=3B}
> > >
> > ></style>
> > >
> > >
> > >I haven't seen it fail on NT=2C except for PutCard in
> > the test itself getti=
> > >ng negative numbers.<br>I've run it just a few
> > times now. One single and du=
> > >al processor virtual machines.<br>Randy=2C has it
> > failed many times for you=
> > >?<br><br>&nbsp=3B-
> > Jay<br><br>&gt=3B To: rcolebur at SCIRES.COM<br>&gt=3B
> > Date=
> > >: Sun=2C 27 Feb 2011 15:11:25 -0800<br>&gt=3B
> > From: mika at async.caltech.edu<=
> > >br>&gt=3B CC: m3devel at elegosoft.com<br>&gt=3B
> > Subject: Re: [M3devel] result=
> > >s of threadtest program on Windows7<br>&gt=3B
> > <br>&gt=3B Ah=2C it just does=
> > >n't check command-line arguments that
> > carefully.<br>&gt=3B <br>&gt=3B I thi=
> > >nk what you did is equivalent to "-tests
> > STD".<br>&gt=3B <br>&gt=3B 
> > Mi=
> > >ka<br>&gt=3B <br>&gt=3B
> > "Coleburn=2C Randy" writes:<br>&gt=3B
> > &gt=3BMika:<b=
> > >r>&gt=3B &gt=3B<br>&gt=3B
> > &gt=3BNo change with "-tests POSIX".<br>&gt=3B
> > &g=
> > >t=3B<br>&gt=3B &gt=3BInteresting
> > twist: On Windows 7=2C I thought I'd see =
> > >what the command line o=3D<br>&gt=3B
> > &gt=3Bptions are=2C and I typed "threa=
> > >dtest -help" rather than reading the
> > code.<br>&gt=3B &gt=3B<br>&gt=3B
> > &gt=
> > >=3BFirst time=2C it produced what appears to be a NIL
> > deref crash. Then=2C=
> > > I trie=3D<br>&gt=3B &gt=3Bd it again and
> > it ran to completion. Something =
> > >seems non-deterministic her=3D<br>&gt=3B
> > &gt=3Be. See below.<br>&gt=3B &gt=
> > >=3B<br>&gt=3B
> > &gt=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bt=
> > >hreadtest.exe -help<br>&gt=3B
> > &gt=3BWriting file...done<br>&gt=3B
> > &gt=3BCre=
> > >ating read threads...done<br>&gt=3B
> > &gt=3BCreating fork threads...done<br>&=
> > >gt=3B &gt=3BCreating alloc
> > threads...done<br>&gt=3B &gt=3BCreating lock
> > thr=
> > >eads...done<br>&gt=3B
> > &gt=3Brunning...printing oldest/median
> > age/newest<br>=
> > >&gt=3B &gt=3B.<br>&gt=3B
> > &gt=3B<br>&gt=3B
> > &gt=3B***<br>&gt=3B &gt=3B*** run=
> > >time error:<br>&gt=3B &gt=3B*** 
> > Attempt to reference an illegal memory l=
> > >ocation.<br>&gt=3B &gt=3B*** 
> > pc =3D3D 0x77762262<br>&gt=3B
> > &gt=3B***<br>=
> > >&gt=3B &gt=3B<br>&gt=3B
> > &gt=3BStack trace:<br>&gt=3B
> > &gt=3B FP 
> > PC=
> > > Procedure<br>&gt=3B
> > &gt=3B--------- --------- 
> > ---------------------=
> > >----------<br>&gt=3B &gt=3B
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\s=
> > >rc\runtime\NT386\RTSignal.m=3D<br>&gt=3B
> > &gt=3B3<br>&gt=3B &gt=3B 0xcdf9c0 =
> > > 0x77762262 
> > &lt=3B???&gt=3B<br>&gt=3B &gt=3B
> > 0xcdf9d8 0x12e83b7 LockMute=
> > >x + 0x4f in
> > ..\src\thread\WIN32\ThreadWin32.m=3D<br>&gt=3B
> > &gt=3B3<br>&gt=
> > >=3B &gt=3B 0xcdfa00 0x12c7b08 GetChar +
> > 0x28 in ..\src\rw\Rd.m3<br>&gt=3B=
> > > &gt=3B 0xcdfb38 0x12c12e3 RApply +
> > 0xd3 in ..\src\Main.m3<br>&gt=3B &gt=
> > >=3B 0xcdfb74 0x12e971f ThreadBase + 0x254
> > in ..\src\thread\WIN32\ThreadWi=
> > >n32=3D<br>&gt=3B
> > &gt=3B.m3<br>&gt=3B &gt=3B 0xcdfb80 
> > 0x76543677 &lt=3B???=
> > >&gt=3B<br>&gt=3B &gt=3B
> > 0xcdfbc0 0x77779f02 
> > &lt=3B???&gt=3B<br>&gt=3B &gt=
> > >=3B......... ......... ... more frames
> > ...<br>&gt=3B &gt=3B<br>&gt=3B
> > &gt=
> > >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest.exe
> > -he=
> > >lp<br>&gt=3B &gt=3BWriting
> > file...done<br>&gt=3B &gt=3BCreating read
> > thread=
> > >s...done<br>&gt=3B &gt=3BCreating fork
> > threads...done<br>&gt=3B &gt=3BCreat=
> > >ing alloc threads...done<br>&gt=3B
> > &gt=3BCreating lock threads...done<br>&g=
> > >t=3B &gt=3Brunning...printing oldest/median
> > age/newest<br>&gt=3B &gt=3B....=
> > >......laziest thread is 0/0/0 (tests: read 0/0/0 fork
> > 0/0/0 alloc 0/0/0=3D<=
> > >br>&gt=3B &gt=3B lock
> > 0/0/0)<br>&gt=3B &gt=3B..........laziest
> > thread is 0/=
> > >0/0 (tests: read 0/0/0 fork 0/0/0 alloc
> > 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/=
> > >0)<br>&gt=3B &gt=3B..........laziest
> > thread is 0/0/0 (tests: read 0/0/0 for=
> > >k 0/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B
> > lock 0/0/0)<br>&gt=3B &gt=3B.......=
> > >...laziest thread is 0/0/0 (tests: read 0/0/0 fork
> > 0/0/0 alloc 0/0/0=3D<br>=
> > >&gt=3B &gt=3B lock 0/0/0)<br>&gt=3B
> > &gt=3B..........laziest thread is 0/0/0=
> > > (tests: read 0/0/0 fork 0/0/0 alloc
> > 0/0/0=3D<br>&gt=3B &gt=3B lock 0/0/0)<=
> > >br>&gt=3B &gt=3B..........laziest thread is
> > 0/0/0 (tests: read 0/0/0 fork 0=
> > >/0/0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock
> > 0/0/0)<br>&gt=3B &gt=3B..........=
> > >laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0
> > alloc 0/0/0=3D<br>&gt=
> > >=3B &gt=3B lock 0/0/0)<br>&gt=3B
> > &gt=3B..........laziest thread is 0/0/0 (t=
> > ests: read 0/0/0 fork 0/0/0 alloc
> > 0/0/0=3D<br>&gt=3B &gt=3B lock
> > 0/0/0)<br>=
> > >&gt=3B &gt=3B..........laziest thread is 0/0/0
> > (tests: read 0/0/0 fork 0/0/=
> > >0 alloc 0/0/0=3D<br>&gt=3B &gt=3B lock
> > 0/0/0)<br>&gt=3B &gt=3B..........laz=
> > >iest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0
> > alloc 0/0/0=3D<br>&gt=3B=
> > > &gt=3B lock 0/0/0)<br>&gt=3B
> > &gt=3BAll tests complete. Congratulations.<b=
> > >r>&gt=3B &gt=3B<br>&gt=3B
> > &gt=3BRegards=2C<br>&gt=3B &gt=3BRandy
> > Coleburn<b=
> > >r>&gt=3B &gt=3B<br>&gt=3B
> > &gt=3B-----Original Message-----<br>&gt=3B
> > &gt=3B=
> > >From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20<br>&gt=3B
> > &gt=3BSen=
> > >t: Sunday=2C February 27=2C 2011 3:30
> > PM<br>&gt=3B &gt=3BTo: Coleburn=2C Ra=
> > >ndy<br>&gt=3B &gt=3BCc: m3devel at elegosoft.com<br>&gt=3B
> > &gt=3BSubject: Re: =
> > >[M3devel] results of threadtest program on
> > Windows7=3D20<br>&gt=3B &gt=3B<b=
> > >r>&gt=3B &gt=3BHi
> > Randy=2C<br>&gt=3B &gt=3B<br>&gt=3B
> > &gt=3BYou can try it =
> > >with -tests POSIX as well.<br>&gt=3B
> > &gt=3B<br>&gt=3B &gt=3BI find on user =
> > >threads it runs very slowly (but it does run) because
> > of how=3D<br>&gt=3B &=
> > >gt=3B unfair<br>&gt=3B &gt=3Bthe thread
> > scheduler is.<br>&gt=3B
> > &gt=3B<br>&=
> > >gt=3B &gt=3BNext step might be to whittle down the
> > tests and see if you can=
> > > get a failu=3D<br>&gt=3B &gt=3Bre
> > with<br>&gt=3B &gt=3Ba single test runni=
> > >ng and -n 2. That would likely be the simplest
> > scenario=3D<br>&gt=3B &gt=
> > >=3B to<br>&gt=3B &gt=3Bstart further
> > debugging from.<br>&gt=3B
> > &gt=3B<br>&g=
> > >t=3B &gt=3B 
> > Mika<br>&gt=3B
> > &gt=3B<br>&gt=3B &gt=3B"Coleburn=2C Randy"
> > w=
> > >rites:<br>&gt=3B &gt=3B&gt=3BMika et
> > al:<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &=
> > >gt=3B&gt=3BThought I would try something
> > else.<br>&gt=3B
> > &gt=3B&gt=3B<br>&g=
> > >t=3B &gt=3B&gt=3BI took the sources of your
> > thread test program to an older=
> > > XP machine that=3D<br>&gt=3B &gt=3B
> > =3D3D<br>&gt=3B &gt=3B&gt=3Bhas CM3 ci=
> > >rca August 2008. This is the machine and
> > implementation I used =3D<br>&gt=
> > >=3B &gt=3Bw=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bhen building a major project I did a=
> > > couple years back.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BThe thread=
> > > test program does indeed build on this old system=2C
> > but when I r=3D<br>&g=
> > >t=3B &gt=3Bu=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bn it=2C I get different results tha=
> > >n with the latest HEAD branch code.
> > =3D3D20<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=
> > >=3B &gt=3B&gt=3BAfter it prints
> > "running...printing oldest/median age/newes=
> > >t"=2C on the next=3D<br>&gt=3B &gt=3B
> > =3D3D<br>&gt=3B &gt=3B&gt=3Bline I ge=
> > >t two periods ".." and now the program seems
> > hung. I'll let it "=3D<br>&gt=
> > >=3B &gt=3Br=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bun" for a few more minutes to see if=
> > > anything else happens before killing
> > =3D<br>&gt=3B &gt=3Bi=3D3D<br>&gt=3B
> > =
> > >&gt=3B&gt=3Bt.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BAt least we don=
> > >'t get the subscript and assertion failures on this
> > older C=3D<br>&gt=3B &g=
> > >t=3BM=3D3D<br>&gt=3B &gt=3B&gt=3B3
> > platform.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=
> > >=3B &gt=3B&gt=3BRegards=2C<br>&gt=3B
> > &gt=3B&gt=3BRandy Coleburn<br>&gt=3B
> > &=
> > >gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B-----Original Mess=
> > >age-----<br>&gt=3B &gt=3B&gt=3BFrom:
> > Coleburn=2C Randy=3D3D20<br>&gt=3B &gt=
> > >=3B&gt=3BSent: Sunday=2C February 27=2C 2011 2:09
> > PM<br>&gt=3B &gt=3B&gt=3B=
> > >To: m3devel at elegosoft.com<br>&gt=3B
> > &gt=3B&gt=3BSubject: Re: [M3devel] resu=
> > >lts of threadtest program on
> > Windows7<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=
> > >=3B&gt=3BMika:<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BOk=2C I've upda=
> > >ted to latest HEAD and I've also built Jay's m3sleep
> > program.<br>&gt=3B &gt=
> > >=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BHere is what happens now when I run your
> > th=
> > >readtest program on Windows 7.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
> > >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest
> > -tests =
> > >ALL=2C-fo=3D<br>&gt=3B
> > &gt=3Br=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bk<br>&gt=3B &gt=
> > >=3B&gt=3BWriting file...done<br>&gt=3B
> > &gt=3B&gt=3BCreating read threads...=
> > >done<br>&gt=3B &gt=3B&gt=3BCreating
> > nxread threads...done<br>&gt=3B &gt=3B&=
> > >gt=3BCreating tryexcept
> > threads...done<br>&gt=3B
> > &gt=3B&gt=3BCreating forkt=
> > >oomuch threads...done<br>&gt=3B
> > &gt=3B&gt=3BCreating alloc threads...done<b=
> > >r>&gt=3B &gt=3B&gt=3BCreating creat
> > threads...done<br>&gt=3B &gt=3B&gt=3BCr=
> > >eating lock threads...done<br>&gt=3B
> > &gt=3B&gt=3Brunning...printing oldest/=
> > >median age/newest<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &=
> > >gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B*** runtime error:<br>&gt=3B
> > &gt=3B&gt=
> > >=3B*** An array subscript was out of
> > range.<br>&gt=3B
> > &gt=3B&gt=3B*** =
> > > file "..\src\runtime\common\RTCollector.m3"=2C line
> > 418<br>&gt=3B &gt=3B&g=
> > >t=3B***<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=
> > >=3B<br>&gt=3B
> > &gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B*** runtime error:<br>&=
> > >gt=3B &gt=3B&gt=3B*** 
> > &lt=3B*ASSERT*&gt=3B failed.<br>&gt=3B
> > &gt=3B&gt=
> > >=3B*** file
> > "..\src\thread\WIN32\ThreadWin32.m3"=2C line
> > 841<br>&gt=3B &=
> > >gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BThe last error =
> > >repeats ad infinitum until I press CNTRL-C to
> > abort.<br>&gt=3B &gt=3B&gt=3B=
> > ><br>&gt=3B &gt=3B&gt=3BI'll send more
> > info on the Windows install of Modula=
> > >3 in a subsequent post=3D<br>&gt=3B
> > &gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=
> > >=3B &gt=3B&gt=3BRegards=2C<br>&gt=3B
> > &gt=3B&gt=3BRandy Coleburn<br>&gt=3B
> > &=
> > >gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B-----Original
> > Message-----<br>&gt=3B &gt=
> > >=3B&gt=3BFrom: Mika Nystrom [mailto:mika at async.caltech.edu]=3D3D20<br>&gt=
> > >=3B &gt=3B&gt=3BSent: Saturday=2C February
> > 26=2C 2011 12:55 PM<br>&gt=3B &g=
> > >t=3B&gt=3BTo: Coleburn=2C Randy<br>&gt=3B
> > &gt=3B&gt=3BCc: m3devel at elegosoft=
> > >.com<br>&gt=3B &gt=3B&gt=3BSubject:
> > Re: [M3devel] results of threadtest pro=
> > >gram on Windows7=3D3D20<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BHi Ran=
> > >dy=2C<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BHm yes it looks like my =
> > >Windows programming skills leave
> > something<br>&gt=3B &gt=3B&gt=3Bto be
> > desi=
> > >red.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BYou can run the thread te=
> > >ster while skipping a test as
> > follows<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=
> > >=3B&gt=3B threadtest -tests
> > ALL=2C-fork<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B =
> > >&gt=3B&gt=3B(for instance)<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3Bif =
> > >you just run=3D3D20<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B threadt=
> > >est -sadfassdaf<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3Bit'll print th=
> > >e tests that are available.<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3BAs=
> > > it happens=2C I just had to upgrade my windows 2000
> > system to windows 7.<b=
> > >r>&gt=3B &gt=3B&gt=3BCan you give me a
> > very brief description of what you d=
> > >id to install Modula=3D<br>&gt=3B
> > &gt=3B-=3D3D<br>&gt=3B
> > &gt=3B&gt=3B3<br>&=
> > >gt=3B &gt=3B&gt=3Bon this
> > system?<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B &gt=3B&g=
> > >t=3B Mika<br>&gt=3B
> > &gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B"Coleburn=2C Ran=
> > >dy" writes:<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B--_000_D67F02DDC62F7545A6B84C285F88=
> > >F3E6EE25C849atlex02srv_<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BContent-Type: text/plai=
> > >n=3B charset=3D3D3D"us-ascii"<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BContent-Transfer-=
> > >Encoding: quoted-printable<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=
> > >=3B&gt=3BMika:<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BI'v=
> > >e finally managed to get cm3 rebuilt on Windows 7
> > again.<br>&gt=3B &gt=3B&g=
> > >t=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BSo=2C I ran your threadtest
> > program.=
> > ><br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BHere are the resu=
> > >lts. Note the "..." is where I cut out a bunch of
> > the r=3D<br>&gt=3B &gt=
> > >=3Be=3D3D<br>&gt=3B
> > &gt=3B&gt=3Bp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Beating=
> > > "ERROR FApply" messages.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=
> > >=3B&gt=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt=3Bthreadtest.e=
> > >xe<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BWriting
> > file...done<br>&gt=3B &gt=3B&gt=3B&g=
> > >t=3BCreating read threads...done<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BCreating fork =
> > >threads...done<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BCreating alloc
> > threads...done<br=
> > >>&gt=3B &gt=3B&gt=3B&gt=3BCreating
> > lock threads...done<br>&gt=3B &gt=3B&gt=
> > >=3B&gt=3Brunning...printing oldest/median
> > age/newest<br>&gt=3B &gt=3B&gt=3B=
> > >&gt=3BERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find=
> > > the f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=
> > >=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OS=
> > >Error.E: ErrorCode=3D3D3D3D2: The system cannot
> > find the f=3D<br>&gt=3B &g=
> > >t=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Be=
> > >cified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E: 
> > ErrorCode=3D3=
> > >D3D3D2: The system cannot find the
> > f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B =
> > >&gt=3B&gt=3B sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=
> > >=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B=
> > >.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B*** runtime e=
> > >rror:<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B*** An
> > enumeration or subrange value w=
> > >as out of range.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B*** file
> > "..\src\Main.m3"=
> > >=2C line 340<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B***<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<b=
> > >r>&gt=3B &gt=3B&gt=3B&gt=3Blaziest
> > thread is 0/0/ERROR FApply: OSError.E: =
> > >ErrorCode=3D3D3D3D2: The sy=3D<br>&gt=3B
> > &gt=3Bste=3D3D<br>&gt=3B &gt=3B&gt=
> > >=3Bm c=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Bannot find the file
> > specified.<br=
> > >>&gt=3B &gt=3B&gt=3B&gt=3BERROR
> > FApply: OSError.E: ErrorCode=3D3D3D3D2: Th=
> > >e system cannot find the f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=
> > >=3B sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&g=
> > >t=3BERROR FApply: OSError.E: ErrorCode=3D3D3D3D2:
> > The system cannot find t=
> > >he f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B=
> > >
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSErr=
> > >or.E: ErrorCode=3D3D3D3D2: The system cannot find
> > the f=3D<br>&gt=3B &gt=
> > >=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Bec=
> > >ified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=
> > >=3B &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Blaziest thread is 0/0/E=
> > >RROR FApply: OSError.E: ErrorCode=3D3D3D3D2: The
> > sy=3D<br>&gt=3B &gt=3Bste=
> > >=3D3D<br>&gt=3B &gt=3B&gt=3Bm
> > c=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Bannot fi=
> > >nd the file specified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E:=
> > > ErrorCode=3D3D3D3D2: The system cannot find the
> > f=3D<br>&gt=3B &gt=3Bile=
> > >=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.=
> > ><br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2:=
> > > The system cannot find the f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&=
> > >gt=3B sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B=
> > >&gt=3BERROR FApply: OSError.E: 
> > ErrorCode=3D3D3D3D2: The system cannot find=
> > > the f=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=
> > >=3B
> > &gt=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=
> > >=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B=
> > >ERROR FApply: OSError.E: ErrorCode=3D3D3D3D2: The
> > system cannot find the f=
> > >=3D<br>&gt=3B
> > &gt=3Bile=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B &gt=
> > >=3B&gt=3B&gt=3Becified.<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BERROR FApply: OSError.E=
> > >: ErrorCode=3D3D3D3D2: The system cannot find the
> > f=3D<br>&gt=3B &gt=3Bile=
> > >=3D3D<br>&gt=3B &gt=3B&gt=3B
> > sp=3D3D3D<br>&gt=3B
> > &gt=3B&gt=3B&gt=3Becified.=
> > ><br>&gt=3B
> > &gt=3B&gt=3B&gt=3BStack
> > trace:<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B FP=
> > > PC 
> > Procedure<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B--------- ---------=
> > > 
> > -------------------------------<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B0x30fbd0 0x1=
> > >27218a PutStats + 0x1a3 in
> > ..\src\Main.m3<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B0x30=
> > >fcc0 0x1273825 Main_M3 + 0x11db(!) in
> > ..\src\Main.m3<br>&gt=3B &gt=3B&gt=
> > >=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3BRegards=2C<br>&gt=3B
> > &gt=3B&gt=3B&gt=
> > >=3BRandy Coleburn<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B<br>&gt=3B
> > &gt=3B&gt=3B&gt=3B=
> > >--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_<br>&gt=3B
> > &gt=3B=
> > >&gt=3B&gt=3BContent-Type: text/html=3B
> > charset=3D3D3D"us-ascii"<br>&gt=3B &=
> > >gt=3B&gt=3B&gt=3BContent-Transfer-Encoding:
> > quoted-printable<br>&gt=3B &gt=
> > >=3B&gt=3B&gt=3B<br> 
> > 
> > 
> > </body>
> > ></html>=
> > >
> > >--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_--
> > 
> 
> 
> 
 		 	   		  



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110302/95baa618/attachment-0002.html>

From rcolebur at SCIRES.COM  Thu Mar  3 01:42:47 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>,
	<20110227231125.3DC611A2078@async.async.caltech.edu>
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>

Yes, it fails more often than it runs for me.
Regards,
Randy

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7

I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
>
> Ah, it just doesn't check command-line arguments that carefully.
>
> I think what you did is equivalent to "-tests STD".
>
> Mika
>
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- --------- -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
> >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110302/c3494867/attachment-0002.html>

From jay.krell at cornell.edu  Thu Mar  3 02:17:44 2011
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 3 Mar 2011 01:17:44 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>
Message-ID: <COL101-W4726257303F22627175774E6C30@phx.gbl>


Even with the change I made PutCard to PutInt?
That's the only failure I've seen.
I'll try on a non-virtual dual-proc machine later.
 
Thanks,
 - Jay
 


From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7






Yes, it fails more often than it runs for me.
Regards,
Randy
 


From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7
 
I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Ah, it just doesn't check command-line arguments that carefully.
> 
> I think what you did is equivalent to "-tests STD".
> 
> Mika
> 
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- --------- -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
> >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>> 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110303/cf2fb41d/attachment-0002.html>

From rcolebur at SCIRES.COM  Thu Mar  3 02:36:19 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Wed, 2 Mar 2011 20:36:19 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W4726257303F22627175774E6C30@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>
	<COL101-W4726257303F22627175774E6C30@phx.gbl>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>

Jay:

Ok, I just updated from HEAD and got your latest change to thread test program.

Here are two invocations, back to back, each failing in different ways.

The second one repeats the last error message ad infinitum until you press CNTRL-C to abort.  But note, several different errors reported earlier.

Regards,
Randy

C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cm3
--- building in NT386 ---

ignoring ..\src\m3overrides

new source -> compiling Main.m3
new "Main.mo" -> linking threadtest.exe

C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cd NT386

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
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


***
*** runtime error:
***    <*ASSERT*> failed..
***    file "..\src\runtime\common\RTCollector.m3", line 1086
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0xddfaf0  0x123dffb  CleanBetween + 0x47 in ..\src\runtime\common\RTCollector.m3
0xddfb34  0x1241870  CheckLoadTracedRef + 0xc5 in ..\src\runtime\common\RTCollector.m3
0xddfb74  0x121683c  Init + 0x95 in ..\src\rw\FileRd.m3
0xddfba0  0x121679d  Open + 0x4d in ..\src\rw\FileRd.m3
0xddfcd8  0x1211288  RApply + 0x78 in ..\src\Main.m3
0xddfd14  0x123976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
0xddfd20  0x76d53677  <???>
0xddfd60  0x773c9f02  <???>
.........  .........  ... more frames ...

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
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
.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0x12ec5ad = Move + 0x50 in ..\src\runtime\common\RTCollector.m3
***



***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***



***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Wednesday, March 02, 2011 8:18 PM
To: Coleburn, Randy; m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7

Even with the change I made PutCard to PutInt?
That's the only failure I've seen.
I'll try on a non-virtual dual-proc machine later.

Thanks,
 - Jay

________________________________
From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7
Yes, it fails more often than it runs for me.
Regards,
Randy

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7

I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
>
> Ah, it just doesn't check command-line arguments that carefully.
>
> I think what you did is equivalent to "-tests STD".
>
> Mika
>
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- --------- -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
> >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110302/38ebde7e/attachment-0002.html>

From dabenavidesd at yahoo.es  Thu Mar  3 03:27:58 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 3 Mar 2011 02:27:58 +0000 (GMT)
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W4726257303F22627175774E6C30@phx.gbl>
Message-ID: <974355.12644.qm@web29717.mail.ird.yahoo.com>

Hi all:
I would doubt but there could be some source of problem in smp on the Win32 platform, since there was a SPINE implementation on an intelligent NIC with 2 embedded MIPS CPUs, perhaps this was just a driver RT but it was for real time and in such a case there should be no problem besides that of the scheduling policy, but thinking how about linking MS Win2k R is a kind of crazy not to believe there was some synchronization with CPU board threads and that component threading at some point I believe.

Even more in embedded systems, there was a MPU implementation of it in 80186 a decade ago,? perhaps would be good to have a look of their Thread interface implementation it might be seem interesting if so.

But in any case there should be plenty of ways of implementing the threading tests incrementally of number of threads, besides you may want to check some uniprocessors with hyperThreading technology (sort of thread physical divisions inside the cpu), they are presented to OS as 2 smp processors, it could be interesting, I remember to test? time ago in this machines and anything weird happened, but quite time ago with ThreadPthread LINUXLIBC6 systems with normally distributed programs.
?
What about results in Win2k ?
Thanks in advance

--- El mi?, 2/3/11, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] results of threadtest program on Windows7
Para: rcolebur at scires.com, "m3devel" <m3devel at elegosoft.com>
Fecha: mi?rcoles, 2 de marzo, 2011 20:17




Even with the change?I made?PutCard to PutInt?

That's the only failure I've seen.

I'll try on a non-virtual dual-proc machine later.

?

Thanks,

?- Jay
?



From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7


 

#yiv891226996 .yiv891226996ExternalClass p.yiv891226996ecxMsoNormal, #yiv891226996 .yiv891226996ExternalClass li.yiv891226996ecxMsoNormal, #yiv891226996 .yiv891226996ExternalClass div.yiv891226996ecxMsoNormal
{margin-bottom:.0001pt;font-size:12.0pt;font-family:'serif';}
#yiv891226996 .yiv891226996ExternalClass a:link, #yiv891226996 .yiv891226996ExternalClass span.yiv891226996ecxMsoHyperlink
{color:blue;text-decoration:underline;}
#yiv891226996 .yiv891226996ExternalClass a:visited, #yiv891226996 .yiv891226996ExternalClass span.yiv891226996ecxMsoHyperlinkFollowed
{color:purple;text-decoration:underline;}
#yiv891226996 .yiv891226996ExternalClass p
{margin-right:0in;margin-left:0in;font-size:12.0pt;font-family:'serif';}
#yiv891226996 .yiv891226996ExternalClass span.yiv891226996ecxEmailStyle18
{font-family:'sans-serif';color:#1F497D;}
#yiv891226996 .yiv891226996ExternalClass .yiv891226996ecxMsoChpDefault
{font-size:10.0pt;}
 _filtered #yiv891226996 {}
#yiv891226996 .yiv891226996ExternalClass div.yiv891226996ecxWordSection1
{}




Yes, it fails more often than it runs for me.
Regards,
Randy
?


From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7
?
I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

?- Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Ah, it just doesn't check command-line arguments that carefully.
> 
> I think what you did is equivalent to "-tests STD".
> 
> Mika
> 
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- --------- -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
> >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>> 		 	   		  



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

From jay.krell at cornell.edu  Thu Mar  3 03:46:39 2011
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 3 Mar 2011 02:46:39 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <974355.12644.qm@web29717.mail.ird.yahoo.com>
References: <COL101-W4726257303F22627175774E6C30@phx.gbl>,
	<974355.12644.qm@web29717.mail.ird.yahoo.com>
Message-ID: <COL101-W2637AB63DA6D9866A00D07E6C30@phx.gbl>


There is probably a bug in RTCollector.m3 or RTAllocator.m3.

 - Jay

Date: Thu, 3 Mar 2011 02:27:58 +0000
From: dabenavidesd at yahoo.es
Subject: Re: [M3devel] results of threadtest program on Windows7
To: rcolebur at scires.com; m3devel at elegosoft.com; jay.krell at cornell.edu

Hi all:
I would doubt but there could be some source of problem in smp on the Win32 platform, since there was a SPINE implementation on an intelligent NIC with 2 embedded MIPS CPUs, perhaps this was just a driver RT but it was for real time and in such a case there should be no problem besides that of the scheduling policy, but thinking how about linking MS Win2k R is a kind of crazy not to believe there was some synchronization with CPU board threads and that component threading at some point I believe.

Even more in embedded systems, there was a MPU implementation of it in 80186 a decade ago,  perhaps would be good to have a look of their Thread interface implementation it might be seem interesting if so.

But in any case there should be plenty of ways of implementing the threading tests incrementally of number of threads, besides you may
 want to check some uniprocessors with hyperThreading technology (sort of thread physical divisions inside the cpu), they are presented to OS as 2 smp processors, it could be interesting, I remember to test  time ago in this machines and anything weird happened, but quite time ago with ThreadPthread LINUXLIBC6 systems with normally distributed programs.
 
What about results in Win2k ?
Thanks in advance

--- El mi?, 2/3/11, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] results of threadtest program on Windows7
Para: rcolebur at scires.com, "m3devel" <m3devel at elegosoft.com>
Fecha: mi?rcoles, 2 de marzo, 2011 20:17




Even with the change I made PutCard to PutInt?

That's the only failure I've seen.

I'll try on a non-virtual dual-proc machine later.

 

Thanks,

 - Jay
 



From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7


 



Yes, it fails more often than it runs for me.
Regards,
Randy
 


From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7
 
I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Ah, it just doesn't check command-line arguments that carefully.
> 
> I think what you did is equivalent to "-tests STD".
> 
> Mika
> 
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the
 command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- ---------
 -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
>
 >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle
 down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints
 "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built
 Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
>
 >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm
 yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type:
 text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR
 FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file
 specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply:
 OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 +
 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>> 		 	   		  

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110303/32472aed/attachment-0002.html>

From jay.krell at cornell.edu  Thu Mar  3 07:32:50 2011
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 3 Mar 2011 06:32:50 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W2637AB63DA6D9866A00D07E6C30@phx.gbl>
References: <COL101-W4726257303F22627175774E6C30@phx.gbl>,
	<974355.12644.qm@web29717.mail.ird.yahoo.com>,
	<COL101-W2637AB63DA6D9866A00D07E6C30@phx.gbl>
Message-ID: <COL101-W1943F7B289FE5FD33E5D1EE6C30@phx.gbl>


Solaris doesn't hang now. I didn't change anything. And it succeeds.
Here are some stacks for a failure on I386_DARWIN.
Notice that it *should* abort right after the EBUSY print, but it still run a while.
Possibly too much information is lost.


(gdb) run
Starting program: /Users/jay/dev2/cm3/m3-libs/m3core/tests/thread/I386_DARWIN/threadtest 
Reading symbols for shared libraries ++. done
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
..........laziest thread is 1/0/0 (tests: read 0/0/0 fork 1/1/1 alloc 0/0/0 lock 0/0/0)
.........pthread_mutex_destroy:EBUSY (0)
.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:
***    An array subscript was out of range.
***    file "../src/runtime/common/RTCollector.m3", line 418
***


Program received signal SIGABRT, Aborted.
0x9385f44e in __semwait_signal ()
(gdb) bt
#0  0x9385f44e in __semwait_signal ()
#1  0x9388a3e6 in _pthread_cond_wait ()
#2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
#3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299133562.375689) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
#4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
#5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
#6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
#7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
#8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
#9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
#10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16


(gdb) thread apply all bt

Thread 13 (process 86311 thread 0x2a03):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#4  0x00003ed8 in Main__LApply (cl=0x9557d8) at ../src/Main.m3:290
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01130) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01130) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 12 (process 86311 thread 0x1f03):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#4  0x00003ed8 in Main__LApply (cl=0x9557a0) at ../src/Main.m3:290
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01080) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01080) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 11 (process 86311 thread 0x1e03):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#4  0x00003ed8 in Main__LApply (cl=0x955768) at ../src/Main.m3:290
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 10 (process 86311 thread 0x1d03):
#0  0x93934136 in __semwait_signal_nocancel ()
#1  0x93933d1b in nanosleep$NOCANCEL$UNIX2003 ()
#2  0x9392d013 in usleep$NOCANCEL$UNIX2003 ()
#3  0x93944685 in abort ()
#4  0x0004b5e6 in Cstdlib__abort () at ../src/C/Common/CstdlibC.c:21
#5  0x000434dd in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20
#6  0x0003d51f in RTProcess__Crash (msg=0x0) at ../src/runtime/common/RTProcess.m3:65
#7  0x0003b9d3 in RTError__EndError (crash=1 '\001') at ../src/runtime/common/RTError.m3:118
#8  0x0003b6e6 in RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:40
#9  0x0003bdc7 in RTException__Crash (a=0xb0490a64, raises=0 '\0', rte=0x7d100) at ../src/runtime/common/RTException.m3:79
#10 0x0003bb21 in RTException__DefaultBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:39
#11 0x0003ba7c in RTException__InvokeBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
#12 0x00043ca5 in RTException__Raise (act=0xb0490a64) at ../src/runtime/ex_frame/RTExFrame.m3:85
#13 0x0003bbb4 in RTException__DefaultBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:47
#14 0x0003ba7c in RTException__InvokeBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
#15 0x00043ca5 in RTException__Raise (act=0xb0490a64) at ../src/runtime/ex_frame/RTExFrame.m3:85
#16 0x0002b102 in RTHooks__ReportFault (module=0x70f80, info=13378) at ../src/runtime/common/RTHooks.m3:111
#17 0x000394c5 in _m3_fault (arg=13378) at ../src/runtime/common/RTCollector.m3:393
#18 0x0002fdd2 in RTCollector__Move (self=0xb3000c, cp=0x9a0014) at ../src/runtime/common/RTCollector.m3:418
#19 0x0002e503 in RTHeapMap__Walk (x=0x9a0014, pc=0x79928, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:202
#20 0x0002dc9c in RTHeapMap__DoWalkRef (t=0x6de54, a=0x9a0014, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:62
#21 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e3f4, a=0x9a000c, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:57
#22 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e508, a=0x9a000c, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:57
#23 0x0002dc2e in RTHeapMap__WalkRef (h=0x9a0008, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:47
#24 0x00032279 in RTCollector__CleanBetween (h=0x9a0008, he=0x9b0000, clean=0 '\0') at ../src/runtime/common/RTCollector.m3:1091
#25 0x00032098 in RTCollector__CleanPage (page=0x9a0000) at ../src/runtime/common/RTCollector.m3:1064
#26 0x00031798 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885
#27 0x00030e75 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720
#28 0x00030a97 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654
#29 0x0002cb85 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00f64) at ../src/runtime/common/RTAllocator.m3:367
#30 0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:296
#31 0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:143
#32 0x00003b5f in Main__AApply (cl=0x9556f8) at ../src/Main.m3:260
#33 0x00046ee2 in ThreadPThread__RunThread (me=0xa00f20) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#34 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00f20) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#35 0x93889155 in _pthread_start ()
#36 0x93889012 in thread_start ()

Thread 9 (process 86311 thread 0x1c03):
#0  0x938582a2 in semaphore_wait_trap ()
#1  0x9385fd92 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00eb4) at ../src/runtime/common/RTAllocator.m3:365
#5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:296
#6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:143
#7  0x00003b5f in Main__AApply (cl=0x9556c0) at ../src/Main.m3:260
#8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00e70) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00e70) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#10 0x93889155 in _pthread_start ()
#11 0x93889012 in thread_start ()

Thread 8 (process 86311 thread 0x1b03):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00e04) at ../src/runtime/common/RTAllocator.m3:365
#5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:296
#6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:143
#7  0x00003b5f in Main__AApply (cl=0x955688) at ../src/Main.m3:260
#8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00dc0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00dc0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#10 0x93889155 in _pthread_start ()
#11 0x93889012 in thread_start ()

Thread 7 (process 86311 thread 0x1a03):
#0  0x9389c856 in __wait4 ()
#1  0x9389c847 in waitpid$UNIX2003 ()
#2  0x0004b222 in Uexec__waitpid (i=86384, j=0xb030ad9c, k=0) at ../src/unix/Common/Uexec.c:67
#3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86384, status=0xb030ad9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
#4  0x0000d66a in Process__Wait (p=0xb00018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
#5  0x00003719 in Main__FApply (cl=0x955618) at ../src/Main.m3:230
#6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00d60) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00d60) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#8  0x93889155 in _pthread_start ()
#9  0x93889012 in thread_start ()

Thread 6 (process 86311 thread 0x1903):
#0  0x9389c856 in __wait4 ()
#1  0x9389c847 in waitpid$UNIX2003 ()
#2  0x0004b222 in Uexec__waitpid (i=86385, j=0xb0288d9c, k=0) at ../src/unix/Common/Uexec.c:67
#3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86385, status=0xb0288d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
#4  0x0000d66a in Process__Wait (p=0xbd000c) at ../src/os/POSIX/ProcessPosixCommon.m3:275
#5  0x00003719 in Main__FApply (cl=0x9555e0) at ../src/Main.m3:230
#6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00b70) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00b70) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#8  0x93889155 in _pthread_start ()
#9  0x93889012 in thread_start ()

Thread 5 (process 86311 thread 0x1803):
#0  0x9389c856 in __wait4 ()
#1  0x9389c847 in waitpid$UNIX2003 ()
#2  0x0004b222 in Uexec__waitpid (i=86386, j=0xb0206d9c, k=0) at ../src/unix/Common/Uexec.c:67
#3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86386, status=0xb0206d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
#4  0x0000d66a in Process__Wait (p=0x9d0018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
#5  0x00003719 in Main__FApply (cl=0x9555a8) at ../src/Main.m3:230
#6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00ac0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00ac0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#8  0x93889155 in _pthread_start ()
#9  0x93889012 in thread_start ()

Thread 4 (process 86311 thread 0x1103):
#0  0x9385fb99 in pthread_mutex_lock ()
#1  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00c20) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#2  0x0004503c in ThreadPThread__LockMutex (m=0xb6000c) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#3  0x0000e060 in Rd__GetChar (rd=0xb6000c) at ../src/rw/Rd.m3:33
#4  0x000030b5 in Main__RApply (cl=0x955538) at ../src/Main.m3:177
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 3 (process 86311 thread 0x117):
#0  0x93859304 in pthread_getspecific ()
#1  0x0004a529 in ThreadPThread__GetActivation () at ../src/thread/PTHREAD/ThreadPThreadC.c:309
#2  0x00049f52 in RTHooks__PushEFrame (frame=0xb0102d20) at ../src/thread/PTHREAD/ThreadPThread.m3:1385
#3  0x0000e07b in Rd__GetChar (rd=0x99000c) at ../src/rw/Rd.m3:33
#4  0x000030b5 in Main__RApply (cl=0x955500) at ../src/Main.m3:177
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 2 (process 86311 thread 0x313):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=12, dataAlignment=4, thread=0xa00834) at ../src/runtime/common/RTAllocator.m3:365
#5  0x0002bf13 in RTAllocator__GetTracedObj (def=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:224
#6  0x0002b98a in RTHooks__AllocateTracedObj (defn=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:122
#7  0x00008eeb in FilePosix__New (fd=5, ds=1) at ../src/os/POSIX/FilePosix.m3:63
#8  0x0000a4eb in FS__OpenFileReadonly (pn=0x775b8) at ../src/os/POSIX/FSPosix.m3:182
#9  0x00014dfa in FileRd__Open (p=0x775b8) at ../src/rw/FileRd.m3:16
#10 0x00003046 in Main__RApply (cl=0x9554c8) at ../src/Main.m3:174
#11 0x00046ee2 in ThreadPThread__RunThread (me=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#12 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#13 0x93889155 in _pthread_start ()
#14 0x93889012 in thread_start ()

Thread 1 (process 86311 local thread 0x2e03):
#0  0x9385f44e in __semwait_signal ()
#1  0x9388a3e6 in _pthread_cond_wait ()
#2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
#3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299133562.375689) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
#4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
#5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
#6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
#7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
#8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
#9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
#10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16







From: jay.krell at cornell.edu
To: dabenavidesd at yahoo.es; rcolebur at scires.com; m3devel at elegosoft.com
Subject: RE: [M3devel] results of threadtest program on Windows7
Date: Thu, 3 Mar 2011 02:46:39 +0000








There is probably a bug in RTCollector.m3 or RTAllocator.m3.

 - Jay

Date: Thu, 3 Mar 2011 02:27:58 +0000
From: dabenavidesd at yahoo.es
Subject: Re: [M3devel] results of threadtest program on Windows7
To: rcolebur at scires.com; m3devel at elegosoft.com; jay.krell at cornell.edu

Hi all:
I would doubt but there could be some source of problem in smp on the Win32 platform, since there was a SPINE implementation on an intelligent NIC with 2 embedded MIPS CPUs, perhaps this was just a driver RT but it was for real time and in such a case there should be no problem besides that of the scheduling policy, but thinking how about linking MS Win2k R is a kind of crazy not to believe there was some synchronization with CPU board threads and that component threading at some point I believe.

Even more in embedded systems, there was a MPU implementation of it in 80186 a decade ago,  perhaps would be good to have a look of their Thread interface implementation it might be seem interesting if so.

But in any case there should be plenty of ways of implementing the threading tests incrementally of number of threads, besides you may
 want to check some uniprocessors with hyperThreading technology (sort of thread physical divisions inside the cpu), they are presented to OS as 2 smp processors, it could be interesting, I remember to test  time ago in this machines and anything weird happened, but quite time ago with ThreadPthread LINUXLIBC6 systems with normally distributed programs.
 
What about results in Win2k ?
Thanks in advance

--- El mi?, 2/3/11, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] results of threadtest program on Windows7
Para: rcolebur at scires.com, "m3devel" <m3devel at elegosoft.com>
Fecha: mi?rcoles, 2 de marzo, 2011 20:17




Even with the change I made PutCard to PutInt?

That's the only failure I've seen.

I'll try on a non-virtual dual-proc machine later.

 

Thanks,

 - Jay
 



From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7


 



Yes, it fails more often than it runs for me.
Regards,
Randy
 


From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7
 
I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Ah, it just doesn't check command-line arguments that carefully.
> 
> I think what you did is equivalent to "-tests STD".
> 
> Mika
> 
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the
 command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- ---------
 -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
>
 >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle
 down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints
 "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built
 Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
>
 >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm
 yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type:
 text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR
 FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file
 specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply:
 OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 +
 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>> 		 	   		  

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110303/60fab6ef/attachment-0002.html>

From jay.krell at cornell.edu  Thu Mar  3 07:37:49 2011
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 3 Mar 2011 06:37:49 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W1943F7B289FE5FD33E5D1EE6C30@phx.gbl>
References: <COL101-W4726257303F22627175774E6C30@phx.gbl>,
	<974355.12644.qm@web29717.mail.ird.yahoo.com>,
	<COL101-W2637AB63DA6D9866A00D07E6C30@phx.gbl>,
	<COL101-W1943F7B289FE5FD33E5D1EE6C30@phx.gbl>
Message-ID: <COL101-W52252742B56CBFEAD0A0DFE6C30@phx.gbl>


Here is another failure also I386_DARWIN.


(gdb) break RTError__MsgS
Breakpoint 2 at 0x3b65f: file ../src/runtime/common/RTError.m3, line 30.
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /Users/jay/dev2/cm3/m3-libs/m3core/tests/thread/I386_DARWIN/threadtest 
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
..[Switching to process 86430 thread 0x1503]

Breakpoint 2, RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:30
30        StartError (msgA, msgB, msgC);
(gdb) bt
#0  RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:30
#1  0x0003bdc7 in RTException__Crash (a=0xb040ea64, raises=0 '\0', rte=0x7d100) at ../src/runtime/common/RTException.m3:79
#2  0x0003bb21 in RTException__DefaultBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:39
#3  0x0003ba7c in RTException__InvokeBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
#4  0x00043ca5 in RTException__Raise (act=0xb040ea64) at ../src/runtime/ex_frame/RTExFrame.m3:85
#5  0x0003bbb4 in RTException__DefaultBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:47
#6  0x0003ba7c in RTException__InvokeBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
#7  0x00043ca5 in RTException__Raise (act=0xb040ea64) at ../src/runtime/ex_frame/RTExFrame.m3:85
#8  0x0002b102 in RTHooks__ReportFault (module=0x70f80, info=13378) at ../src/runtime/common/RTHooks.m3:111
#9  0x000394c5 in _m3_fault (arg=13378) at ../src/runtime/common/RTCollector.m3:393
#10 0x0002fdd2 in RTCollector__Move (self=0xb4000c, cp=0xba0014) at ../src/runtime/common/RTCollector.m3:418
#11 0x0002e503 in RTHeapMap__Walk (x=0xba0014, pc=0x79928, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:202
#12 0x0002dc9c in RTHeapMap__DoWalkRef (t=0x6de54, a=0xba0014, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:62
#13 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e3f4, a=0xba000c, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:57
#14 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e508, a=0xba000c, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:57
#15 0x0002dc2e in RTHeapMap__WalkRef (h=0xba0008, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:47
#16 0x00032279 in RTCollector__CleanBetween (h=0xba0008, he=0xbb0000, clean=0 '\0') at ../src/runtime/common/RTCollector.m3:1091
#17 0x00032098 in RTCollector__CleanPage (page=0xba0000) at ../src/runtime/common/RTCollector.m3:1064
#18 0x00031798 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885
#19 0x00030e75 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720
#20 0x00030a97 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654
#21 0x0002cb85 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00e74) at ../src/runtime/common/RTAllocator.m3:367
#22 0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:296
#23 0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:143
#24 0x00003b5f in Main__AApply (cl=0x9556c0) at ../src/Main.m3:260
#25 0x00046ee2 in ThreadPThread__RunThread (me=0xa00e30) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#26 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00e30) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#27 0x93889155 in _pthread_start ()
#28 0x93889012 in thread_start ()
(gdb) threads apply all bt
Undefined command: "threads".  Try "help".
(gdb) thread apply all bt

Thread 13 (process 86430 thread 0x1903):
#0  0x9388a6f1 in semaphore_wait_signal ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00880) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#4  0x00003ed8 in Main__LApply (cl=0x9557d8) at ../src/Main.m3:290
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa010f0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa010f0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 12 (process 86430 thread 0x1803):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00880) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#4  0x00003ed8 in Main__LApply (cl=0x9557a0) at ../src/Main.m3:290
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01040) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01040) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 11 (process 86430 thread 0x1703):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00880) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#4  0x00003ed8 in Main__LApply (cl=0x955768) at ../src/Main.m3:290
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00f90) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00f90) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 10 (process 86430 thread 0x1603):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00f24) at ../src/runtime/common/RTAllocator.m3:365
#5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:296
#6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:143
#7  0x00003b5f in Main__AApply (cl=0x9556f8) at ../src/Main.m3:260
#8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00ee0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00ee0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#10 0x93889155 in _pthread_start ()
#11 0x93889012 in thread_start ()

Thread 9 (process 86430 thread 0x1503):
#0  RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:30
#1  0x0003bdc7 in RTException__Crash (a=0xb040ea64, raises=0 '\0', rte=0x7d100) at ../src/runtime/common/RTException.m3:79
#2  0x0003bb21 in RTException__DefaultBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:39
#3  0x0003ba7c in RTException__InvokeBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
#4  0x00043ca5 in RTException__Raise (act=0xb040ea64) at ../src/runtime/ex_frame/RTExFrame.m3:85
#5  0x0003bbb4 in RTException__DefaultBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:47
#6  0x0003ba7c in RTException__InvokeBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
#7  0x00043ca5 in RTException__Raise (act=0xb040ea64) at ../src/runtime/ex_frame/RTExFrame.m3:85
#8  0x0002b102 in RTHooks__ReportFault (module=0x70f80, info=13378) at ../src/runtime/common/RTHooks.m3:111
#9  0x000394c5 in _m3_fault (arg=13378) at ../src/runtime/common/RTCollector.m3:393
#10 0x0002fdd2 in RTCollector__Move (self=0xb4000c, cp=0xba0014) at ../src/runtime/common/RTCollector.m3:418
#11 0x0002e503 in RTHeapMap__Walk (x=0xba0014, pc=0x79928, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:202
#12 0x0002dc9c in RTHeapMap__DoWalkRef (t=0x6de54, a=0xba0014, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:62
#13 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e3f4, a=0xba000c, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:57
#14 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e508, a=0xba000c, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:57
#15 0x0002dc2e in RTHeapMap__WalkRef (h=0xba0008, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:47
#16 0x00032279 in RTCollector__CleanBetween (h=0xba0008, he=0xbb0000, clean=0 '\0') at ../src/runtime/common/RTCollector.m3:1091
#17 0x00032098 in RTCollector__CleanPage (page=0xba0000) at ../src/runtime/common/RTCollector.m3:1064
#18 0x00031798 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885
#19 0x00030e75 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720
#20 0x00030a97 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654
#21 0x0002cb85 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00e74) at ../src/runtime/common/RTAllocator.m3:367
#22 0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:296
#23 0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:143
#24 0x00003b5f in Main__AApply (cl=0x9556c0) at ../src/Main.m3:260
#25 0x00046ee2 in ThreadPThread__RunThread (me=0xa00e30) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#26 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00e30) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#27 0x93889155 in _pthread_start ()
#28 0x93889012 in thread_start ()

Thread 8 (process 86430 thread 0x1403):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00dc4) at ../src/runtime/common/RTAllocator.m3:365
#5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:296
#6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:143
#7  0x00003b5f in Main__AApply (cl=0x955688) at ../src/Main.m3:260
#8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00d80) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00d80) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#10 0x93889155 in _pthread_start ()
#11 0x93889012 in thread_start ()

Thread 7 (process 86430 thread 0x1303):
#0  0x9389c856 in __wait4 ()
#1  0x9389c847 in waitpid$UNIX2003 ()
#2  0x0004b222 in Uexec__waitpid (i=86436, j=0xb030ad9c, k=0) at ../src/unix/Common/Uexec.c:67
#3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86436, status=0xb030ad9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
#4  0x0000d66a in Process__Wait (p=0xb00018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
#5  0x00003719 in Main__FApply (cl=0x955618) at ../src/Main.m3:230
#6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00d20) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00d20) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#8  0x93889155 in _pthread_start ()
#9  0x93889012 in thread_start ()

Thread 6 (process 86430 thread 0x1203):
#0  0x9389c856 in __wait4 ()
#1  0x9389c847 in waitpid$UNIX2003 ()
#2  0x0004b222 in Uexec__waitpid (i=86437, j=0xb0288d9c, k=0) at ../src/unix/Common/Uexec.c:67
#3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86437, status=0xb0288d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
#4  0x0000d66a in Process__Wait (p=0xbd0018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
#5  0x00003719 in Main__FApply (cl=0x9555e0) at ../src/Main.m3:230
#6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00b30) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00b30) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#8  0x93889155 in _pthread_start ()
#9  0x93889012 in thread_start ()

Thread 5 (process 86430 thread 0x1103):
#0  0x9389c856 in __wait4 ()
#1  0x9389c847 in waitpid$UNIX2003 ()
#2  0x0004b222 in Uexec__waitpid (i=86435, j=0xb0206d9c, k=0) at ../src/unix/Common/Uexec.c:67
#3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86435, status=0xb0206d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
#4  0x0000d66a in Process__Wait (p=0xc2000c) at ../src/os/POSIX/ProcessPosixCommon.m3:275
#5  0x00003719 in Main__FApply (cl=0x9555a8) at ../src/Main.m3:230
#6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00a80) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00a80) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#8  0x93889155 in _pthread_start ()
#9  0x93889012 in thread_start ()

Thread 4 (process 86430 thread 0x1003):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=12, dataAlignment=4, thread=0xa00a14) at ../src/runtime/common/RTAllocator.m3:365
#5  0x0002bf13 in RTAllocator__GetTracedObj (def=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:224
#6  0x0002b98a in RTHooks__AllocateTracedObj (defn=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:122
#7  0x00008eeb in FilePosix__New (fd=5, ds=1) at ../src/os/POSIX/FilePosix.m3:63
#8  0x0000a4eb in FS__OpenFileReadonly (pn=0x775b8) at ../src/os/POSIX/FSPosix.m3:182
#9  0x00014dfa in FileRd__Open (p=0x775b8) at ../src/rw/FileRd.m3:16
#10 0x00003046 in Main__RApply (cl=0x955538) at ../src/Main.m3:174
#11 0x00046ee2 in ThreadPThread__RunThread (me=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#12 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#13 0x93889155 in _pthread_start ()
#14 0x93889012 in thread_start ()

Thread 3 (process 86430 thread 0x117):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x74220) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00044f3a in ThreadPThread__InitMutex (m=0x960010, root=0x96000c, Clean=0x44dac) at ../src/thread/PTHREAD/ThreadPThread.m3:101
#4  0x0004500b in ThreadPThread__LockMutex (m=0x96000c) at ../src/thread/PTHREAD/ThreadPThread.m3:117
#5  0x0000e060 in Rd__GetChar (rd=0x96000c) at ../src/rw/Rd.m3:33
#6  0x000030b5 in Main__RApply (cl=0x955500) at ../src/Main.m3:177
#7  0x00046ee2 in ThreadPThread__RunThread (me=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#8  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#9  0x93889155 in _pthread_start ()
#10 0x93889012 in thread_start ()

Thread 2 (process 86430 thread 0x313):
#0  0x938582a2 in semaphore_wait_trap ()
#1  0x9385fd92 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x00036509 in RTHeapRep__RegisterFinalCleanup (r=0x9b1050, p=0x44dac) at ../src/runtime/common/RTCollector.m3:2148
#5  0x00044fa2 in ThreadPThread__InitMutex (m=0x9b1054, root=0x9b1050, Clean=0x44dac) at ../src/thread/PTHREAD/ThreadPThread.m3:106
#6  0x0004500b in ThreadPThread__LockMutex (m=0x9b1050) at ../src/thread/PTHREAD/ThreadPThread.m3:117
#7  0x0000e060 in Rd__GetChar (rd=0x9b1050) at ../src/rw/Rd.m3:33
#8  0x000030b5 in Main__RApply (cl=0x9554c8) at ../src/Main.m3:177
#9  0x00046ee2 in ThreadPThread__RunThread (me=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#10 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#11 0x93889155 in _pthread_start ()
#12 0x93889012 in thread_start ()

Thread 1 (process 86430 local thread 0x4507):
#0  0x9385f44e in __semwait_signal ()
#1  0x9388a3e6 in _pthread_cond_wait ()
#2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
#3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299134070.4957981) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
#4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
#5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
#6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
#7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
#8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
#9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
#10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16

 - Jay


From: jay.krell at cornell.edu
To: dabenavidesd at yahoo.es; rcolebur at scires.com; m3devel at elegosoft.com
Subject: RE: [M3devel] results of threadtest program on Windows7
Date: Thu, 3 Mar 2011 06:32:50 +0000








Solaris doesn't hang now. I didn't change anything. And it succeeds.
Here are some stacks for a failure on I386_DARWIN.
Notice that it *should* abort right after the EBUSY print, but it still run a while.
Possibly too much information is lost.


(gdb) run
Starting program: /Users/jay/dev2/cm3/m3-libs/m3core/tests/thread/I386_DARWIN/threadtest 
Reading symbols for shared libraries ++. done
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
..........laziest thread is 1/0/0 (tests: read 0/0/0 fork 1/1/1 alloc 0/0/0 lock 0/0/0)
.........pthread_mutex_destroy:EBUSY (0)
.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:
***    An array subscript was out of range.
***    file "../src/runtime/common/RTCollector.m3", line 418
***


Program received signal SIGABRT, Aborted.
0x9385f44e in __semwait_signal ()
(gdb) bt
#0  0x9385f44e in __semwait_signal ()
#1  0x9388a3e6 in _pthread_cond_wait ()
#2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
#3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299133562.375689) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
#4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
#5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
#6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
#7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
#8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
#9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
#10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16


(gdb) thread apply all bt

Thread 13 (process 86311 thread 0x2a03):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#4  0x00003ed8 in Main__LApply (cl=0x9557d8) at ../src/Main.m3:290
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01130) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01130) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 12 (process 86311 thread 0x1f03):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#4  0x00003ed8 in Main__LApply (cl=0x9557a0) at ../src/Main.m3:290
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01080) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01080) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 11 (process 86311 thread 0x1e03):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#4  0x00003ed8 in Main__LApply (cl=0x955768) at ../src/Main.m3:290
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 10 (process 86311 thread 0x1d03):
#0  0x93934136 in __semwait_signal_nocancel ()
#1  0x93933d1b in nanosleep$NOCANCEL$UNIX2003 ()
#2  0x9392d013 in usleep$NOCANCEL$UNIX2003 ()
#3  0x93944685 in abort ()
#4  0x0004b5e6 in Cstdlib__abort () at ../src/C/Common/CstdlibC.c:21
#5  0x000434dd in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20
#6  0x0003d51f in RTProcess__Crash (msg=0x0) at ../src/runtime/common/RTProcess.m3:65
#7  0x0003b9d3 in RTError__EndError (crash=1 '\001') at ../src/runtime/common/RTError.m3:118
#8  0x0003b6e6 in RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:40
#9  0x0003bdc7 in RTException__Crash (a=0xb0490a64, raises=0 '\0', rte=0x7d100) at ../src/runtime/common/RTException.m3:79
#10 0x0003bb21 in RTException__DefaultBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:39
#11 0x0003ba7c in RTException__InvokeBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
#12 0x00043ca5 in RTException__Raise (act=0xb0490a64) at ../src/runtime/ex_frame/RTExFrame.m3:85
#13 0x0003bbb4 in RTException__DefaultBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:47
#14 0x0003ba7c in RTException__InvokeBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
#15 0x00043ca5 in RTException__Raise (act=0xb0490a64) at ../src/runtime/ex_frame/RTExFrame.m3:85
#16 0x0002b102 in RTHooks__ReportFault (module=0x70f80, info=13378) at ../src/runtime/common/RTHooks.m3:111
#17 0x000394c5 in _m3_fault (arg=13378) at ../src/runtime/common/RTCollector.m3:393
#18 0x0002fdd2 in RTCollector__Move (self=0xb3000c, cp=0x9a0014) at ../src/runtime/common/RTCollector.m3:418
#19 0x0002e503 in RTHeapMap__Walk (x=0x9a0014, pc=0x79928, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:202
#20 0x0002dc9c in RTHeapMap__DoWalkRef (t=0x6de54, a=0x9a0014, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:62
#21 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e3f4, a=0x9a000c, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:57
#22 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e508, a=0x9a000c, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:57
#23 0x0002dc2e in RTHeapMap__WalkRef (h=0x9a0008, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:47
#24 0x00032279 in RTCollector__CleanBetween (h=0x9a0008, he=0x9b0000, clean=0 '\0') at ../src/runtime/common/RTCollector.m3:1091
#25 0x00032098 in RTCollector__CleanPage (page=0x9a0000) at ../src/runtime/common/RTCollector.m3:1064
#26 0x00031798 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885
#27 0x00030e75 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720
#28 0x00030a97 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654
#29 0x0002cb85 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00f64) at ../src/runtime/common/RTAllocator.m3:367
#30 0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:296
#31 0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:143
#32 0x00003b5f in Main__AApply (cl=0x9556f8) at ../src/Main.m3:260
#33 0x00046ee2 in ThreadPThread__RunThread (me=0xa00f20) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#34 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00f20) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#35 0x93889155 in _pthread_start ()
#36 0x93889012 in thread_start ()

Thread 9 (process 86311 thread 0x1c03):
#0  0x938582a2 in semaphore_wait_trap ()
#1  0x9385fd92 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00eb4) at ../src/runtime/common/RTAllocator.m3:365
#5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:296
#6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:143
#7  0x00003b5f in Main__AApply (cl=0x9556c0) at ../src/Main.m3:260
#8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00e70) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00e70) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#10 0x93889155 in _pthread_start ()
#11 0x93889012 in thread_start ()

Thread 8 (process 86311 thread 0x1b03):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00e04) at ../src/runtime/common/RTAllocator.m3:365
#5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:296
#6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:143
#7  0x00003b5f in Main__AApply (cl=0x955688) at ../src/Main.m3:260
#8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00dc0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00dc0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#10 0x93889155 in _pthread_start ()
#11 0x93889012 in thread_start ()

Thread 7 (process 86311 thread 0x1a03):
#0  0x9389c856 in __wait4 ()
#1  0x9389c847 in waitpid$UNIX2003 ()
#2  0x0004b222 in Uexec__waitpid (i=86384, j=0xb030ad9c, k=0) at ../src/unix/Common/Uexec.c:67
#3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86384, status=0xb030ad9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
#4  0x0000d66a in Process__Wait (p=0xb00018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
#5  0x00003719 in Main__FApply (cl=0x955618) at ../src/Main.m3:230
#6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00d60) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00d60) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#8  0x93889155 in _pthread_start ()
#9  0x93889012 in thread_start ()

Thread 6 (process 86311 thread 0x1903):
#0  0x9389c856 in __wait4 ()
#1  0x9389c847 in waitpid$UNIX2003 ()
#2  0x0004b222 in Uexec__waitpid (i=86385, j=0xb0288d9c, k=0) at ../src/unix/Common/Uexec.c:67
#3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86385, status=0xb0288d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
#4  0x0000d66a in Process__Wait (p=0xbd000c) at ../src/os/POSIX/ProcessPosixCommon.m3:275
#5  0x00003719 in Main__FApply (cl=0x9555e0) at ../src/Main.m3:230
#6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00b70) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00b70) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#8  0x93889155 in _pthread_start ()
#9  0x93889012 in thread_start ()

Thread 5 (process 86311 thread 0x1803):
#0  0x9389c856 in __wait4 ()
#1  0x9389c847 in waitpid$UNIX2003 ()
#2  0x0004b222 in Uexec__waitpid (i=86386, j=0xb0206d9c, k=0) at ../src/unix/Common/Uexec.c:67
#3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86386, status=0xb0206d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
#4  0x0000d66a in Process__Wait (p=0x9d0018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
#5  0x00003719 in Main__FApply (cl=0x9555a8) at ../src/Main.m3:230
#6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00ac0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00ac0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#8  0x93889155 in _pthread_start ()
#9  0x93889012 in thread_start ()

Thread 4 (process 86311 thread 0x1103):
#0  0x9385fb99 in pthread_mutex_lock ()
#1  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00c20) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#2  0x0004503c in ThreadPThread__LockMutex (m=0xb6000c) at ../src/thread/PTHREAD/ThreadPThread.m3:119
#3  0x0000e060 in Rd__GetChar (rd=0xb6000c) at ../src/rw/Rd.m3:33
#4  0x000030b5 in Main__RApply (cl=0x955538) at ../src/Main.m3:177
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 3 (process 86311 thread 0x117):
#0  0x93859304 in pthread_getspecific ()
#1  0x0004a529 in ThreadPThread__GetActivation () at ../src/thread/PTHREAD/ThreadPThreadC.c:309
#2  0x00049f52 in RTHooks__PushEFrame (frame=0xb0102d20) at ../src/thread/PTHREAD/ThreadPThread.m3:1385
#3  0x0000e07b in Rd__GetChar (rd=0x99000c) at ../src/rw/Rd.m3:33
#4  0x000030b5 in Main__RApply (cl=0x955500) at ../src/Main.m3:177
#5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#7  0x93889155 in _pthread_start ()
#8  0x93889012 in thread_start ()

Thread 2 (process 86311 thread 0x313):
#0  0x938582ae in semaphore_wait_signal_trap ()
#1  0x9385fd85 in pthread_mutex_lock ()
#2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
#3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
#4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=12, dataAlignment=4, thread=0xa00834) at ../src/runtime/common/RTAllocator.m3:365
#5  0x0002bf13 in RTAllocator__GetTracedObj (def=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:224
#6  0x0002b98a in RTHooks__AllocateTracedObj (defn=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:122
#7  0x00008eeb in FilePosix__New (fd=5, ds=1) at ../src/os/POSIX/FilePosix.m3:63
#8  0x0000a4eb in FS__OpenFileReadonly (pn=0x775b8) at ../src/os/POSIX/FSPosix.m3:182
#9  0x00014dfa in FileRd__Open (p=0x775b8) at ../src/rw/FileRd.m3:16
#10 0x00003046 in Main__RApply (cl=0x9554c8) at ../src/Main.m3:174
#11 0x00046ee2 in ThreadPThread__RunThread (me=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
#12 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
#13 0x93889155 in _pthread_start ()
#14 0x93889012 in thread_start ()

Thread 1 (process 86311 local thread 0x2e03):
#0  0x9385f44e in __semwait_signal ()
#1  0x9388a3e6 in _pthread_cond_wait ()
#2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
#3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299133562.375689) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
#4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
#5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
#6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
#7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
#8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
#9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
#10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16







From: jay.krell at cornell.edu
To: dabenavidesd at yahoo.es; rcolebur at scires.com; m3devel at elegosoft.com
Subject: RE: [M3devel] results of threadtest program on Windows7
Date: Thu, 3 Mar 2011 02:46:39 +0000








There is probably a bug in RTCollector.m3 or RTAllocator.m3.

 - Jay

Date: Thu, 3 Mar 2011 02:27:58 +0000
From: dabenavidesd at yahoo.es
Subject: Re: [M3devel] results of threadtest program on Windows7
To: rcolebur at scires.com; m3devel at elegosoft.com; jay.krell at cornell.edu

Hi all:
I would doubt but there could be some source of problem in smp on the Win32 platform, since there was a SPINE implementation on an intelligent NIC with 2 embedded MIPS CPUs, perhaps this was just a driver RT but it was for real time and in such a case there should be no problem besides that of the scheduling policy, but thinking how about linking MS Win2k R is a kind of crazy not to believe there was some synchronization with CPU board threads and that component threading at some point I believe.

Even more in embedded systems, there was a MPU implementation of it in 80186 a decade ago,  perhaps would be good to have a look of their Thread interface implementation it might be seem interesting if so.

But in any case there should be plenty of ways of implementing the threading tests incrementally of number of threads, besides you may
 want to check some uniprocessors with hyperThreading technology (sort of thread physical divisions inside the cpu), they are presented to OS as 2 smp processors, it could be interesting, I remember to test  time ago in this machines and anything weird happened, but quite time ago with ThreadPthread LINUXLIBC6 systems with normally distributed programs.
 
What about results in Win2k ?
Thanks in advance

--- El mi?, 2/3/11, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] results of threadtest program on Windows7
Para: rcolebur at scires.com, "m3devel" <m3devel at elegosoft.com>
Fecha: mi?rcoles, 2 de marzo, 2011 20:17




Even with the change I made PutCard to PutInt?

That's the only failure I've seen.

I'll try on a non-virtual dual-proc machine later.

 

Thanks,

 - Jay
 



From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7


 



Yes, it fails more often than it runs for me.
Regards,
Randy
 


From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7
 
I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Ah, it just doesn't check command-line arguments that carefully.
> 
> I think what you did is equivalent to "-tests STD".
> 
> Mika
> 
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the
 command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- ---------
 -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
>
 >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle
 down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints
 "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built
 Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
>
 >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm
 yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type:
 text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR
 FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file
 specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply:
 OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 +
 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>> 		 	   		  

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

From hosking at cs.purdue.edu  Thu Mar  3 16:39:07 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 3 Mar 2011 10:39:07 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>
	<COL101-W4726257303F22627175774E6C30@phx.gbl>
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>
Message-ID: <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>

Both of these errors indicate major breakdown in the garbage collector.
It could be that the damage was done much earlier than the crash.
To check for earlier damage please run with @M3paranoidgc.
Also, you could try running with @M3nogc, or @M3noincremental, or @M3nogenerational, to see if any of them trigger the errors.


On Mar 2, 2011, at 8:36 PM, Coleburn, Randy wrote:

> Jay:
>  
> Ok, I just updated from HEAD and got your latest change to thread test program.
>  
> Here are two invocations, back to back, each failing in different ways. 
>  
> The second one repeats the last error message ad infinitum until you press CNTRL-C to abort.  But note, several different errors reported earlier.
>  
> Regards,
> Randy
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cm3
> --- building in NT386 ---
>  
> ignoring ..\src\m3overrides
>  
> new source -> compiling Main.m3
> new "Main.mo" -> linking threadtest.exe
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cd NT386
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> 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
>  
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed..
> ***    file "..\src\runtime\common\RTCollector.m3", line 1086
> ***
>  
> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0xddfaf0  0x123dffb  CleanBetween + 0x47 in ..\src\runtime\common\RTCollector.m3
> 0xddfb34  0x1241870  CheckLoadTracedRef + 0xc5 in ..\src\runtime\common\RTCollector.m3
> 0xddfb74  0x121683c  Init + 0x95 in ..\src\rw\FileRd.m3
> 0xddfba0  0x121679d  Open + 0x4d in ..\src\rw\FileRd.m3
> 0xddfcd8  0x1211288  RApply + 0x78 in ..\src\Main.m3
> 0xddfd14  0x123976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
> 0xddfd20  0x76d53677  <???>
> 0xddfd60  0x773c9f02  <???>
> .........  .........  ... more frames ...
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> 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
> .
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
> ***    pc = 0x12ec5ad = Move + 0x50 in ..\src\runtime\common\RTCollector.m3
> ***
>  
>  
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
>  
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Wednesday, March 02, 2011 8:18 PM
> To: Coleburn, Randy; m3devel
> Subject: RE: [M3devel] results of threadtest program on Windows7
>  
> Even with the change I made PutCard to PutInt?
> That's the only failure I've seen.
> I'll try on a non-virtual dual-proc machine later.
>  
> Thanks,
>  - Jay
>  
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Wed, 2 Mar 2011 19:42:47 -0500
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Yes, it fails more often than it runs for me.
> Regards,
> Randy
>  
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Tuesday, March 01, 2011 5:59 AM
> To: Mika Nystrom; Coleburn, Randy
> Cc: m3devel
> Subject: RE: [M3devel] results of threadtest program on Windows7
>  
> I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
> I've run it just a few times now. One single and dual processor virtual machines.
> Randy, has it failed many times for you?
> 
>  - Jay
> 
> > To: rcolebur at SCIRES.COM
> > Date: Sun, 27 Feb 2011 15:11:25 -0800
> > From: mika at async.caltech.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] results of threadtest program on Windows7
> > 
> > Ah, it just doesn't check command-line arguments that carefully.
> > 
> > I think what you did is equivalent to "-tests STD".
> > 
> > Mika
> > 
> > "Coleburn, Randy" writes:
> > >Mika:
> > >
> > >No change with "-tests POSIX".
> > >
> > >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> > >ptions are, and I typed "threadtest -help" rather than reading the code.
> > >
> > >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> > >d it again and it ran to completion. Something seems non-deterministic her=
> > >e. See below.
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >.
> > >
> > >***
> > >*** runtime error:
> > >*** Attempt to reference an illegal memory location.
> > >*** pc =3D 0x77762262
> > >***
> > >
> > >Stack trace:
> > > FP PC Procedure
> > >--------- --------- -------------------------------
> > > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> > >3
> > > 0xcdf9c0 0x77762262 <???>
> > > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> > >3
> > > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> > >.m3
> > > 0xcdfb80 0x76543677 <???>
> > > 0xcdfbc0 0x77779f02 <???>
> > >......... ......... ... more frames ...
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >All tests complete. Congratulations.
> > >
> > >Regards,
> > >Randy Coleburn
> > >
> > >-----Original Message-----
> > >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> > >Sent: Sunday, February 27, 2011 3:30 PM
> > >To: Coleburn, Randy
> > >Cc: m3devel at elegosoft.com
> > >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> > >
> > >Hi Randy,
> > >
> > >You can try it with -tests POSIX as well.
> > >
> > >I find on user threads it runs very slowly (but it does run) because of how=
> > > unfair
> > >the thread scheduler is.
> > >
> > >Next step might be to whittle down the tests and see if you can get a failu=
> > >re with
> > >a single test running and -n 2. That would likely be the simplest scenario=
> > > to
> > >start further debugging from.
> > >
> > > Mika
> > >
> > >"Coleburn, Randy" writes:
> > >>Mika et al:
> > >>
> > >>Thought I would try something else.
> > >>
> > >>I took the sources of your thread test program to an older XP machine that=
> > > =3D
> > >>has CM3 circa August 2008. This is the machine and implementation I used =
> > >w=3D
> > >>hen building a major project I did a couple years back.
> > >>
> > >>The thread test program does indeed build on this old system, but when I r=
> > >u=3D
> > >>n it, I get different results than with the latest HEAD branch code. =3D20
> > >>
> > >>After it prints "running...printing oldest/median age/newest", on the next=
> > > =3D
> > >>line I get two periods ".." and now the program seems hung. I'll let it "=
> > >r=3D
> > >>un" for a few more minutes to see if anything else happens before killing =
> > >i=3D
> > >>t.
> > >>
> > >>At least we don't get the subscript and assertion failures on this older C=
> > >M=3D
> > >>3 platform.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>
> > >>-----Original Message-----
> > >>From: Coleburn, Randy=3D20
> > >>Sent: Sunday, February 27, 2011 2:09 PM
> > >>To: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7
> > >>
> > >>Mika:
> > >>
> > >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> > >>
> > >>Here is what happens now when I run your threadtest program on Windows 7.
> > >>
> > >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> > >r=3D
> > >>k
> > >>Writing file...done
> > >>Creating read threads...done
> > >>Creating nxread threads...done
> > >>Creating tryexcept threads...done
> > >>Creating forktoomuch threads...done
> > >>Creating alloc threads...done
> > >>Creating creat threads...done
> > >>Creating lock threads...done
> > >>running...printing oldest/median age/newest
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** An array subscript was out of range.
> > >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> > >>***
> > >>
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** <*ASSERT*> failed.
> > >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> > >>***
> > >>
> > >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> > >>
> > >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> > >.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>-----Original Message-----
> > >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> > >>Sent: Saturday, February 26, 2011 12:55 PM
> > >>To: Coleburn, Randy
> > >>Cc: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> > >>
> > >>Hi Randy,
> > >>
> > >>Hm yes it looks like my Windows programming skills leave something
> > >>to be desired.
> > >>
> > >>You can run the thread tester while skipping a test as follows
> > >>
> > >> threadtest -tests ALL,-fork
> > >>
> > >>(for instance)
> > >>
> > >>if you just run=3D20
> > >>
> > >> threadtest -sadfassdaf
> > >>
> > >>it'll print the tests that are available.
> > >>
> > >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> > >>Can you give me a very brief description of what you did to install Modula=
> > >-=3D
> > >>3
> > >>on this system?
> > >>
> > >> Mika
> > >>
> > >>"Coleburn, Randy" writes:
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>
> > >>>Mika:
> > >>>
> > >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> > >>>
> > >>>So, I ran your threadtest program.
> > >>>
> > >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> > >e=3D
> > >>p=3D3D
> > >>>eating "ERROR FApply" messages.
> > >>>
> > >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > >>>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
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>***
> > >>>*** runtime error:
> > >>>*** An enumeration or subrange value was out of range.
> > >>>*** file "..\src\Main.m3", line 340
> > >>>***
> > >>>
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>Stack trace:
> > >>> FP PC Procedure
> > >>>--------- --------- -------------------------------
> > >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> > >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> > >>>
> > >>>Regards,
> > >>>Randy Coleburn
> > >>>
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/html; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110303/63ad1ce4/attachment-0002.html>

From hosking at cs.purdue.edu  Thu Mar  3 16:40:35 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 3 Mar 2011 10:40:35 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W2637AB63DA6D9866A00D07E6C30@phx.gbl>
References: <COL101-W4726257303F22627175774E6C30@phx.gbl>,
	<974355.12644.qm@web29717.mail.ird.yahoo.com>
	<COL101-W2637AB63DA6D9866A00D07E6C30@phx.gbl>
Message-ID: <12DDA3F3-61D8-47B6-AF76-9362068A061A@cs.purdue.edu>

The bug is not necessarily there.  If the collector is not kept properly informed of the mutator's actions or the pointers it holds in its stacks then the world will break.  What has changed recently that might affect the collector and allocator?

On Mar 2, 2011, at 9:46 PM, Jay K wrote:

> There is probably a bug in RTCollector.m3 or RTAllocator.m3.
> 
>  - Jay
> 
> Date: Thu, 3 Mar 2011 02:27:58 +0000
> From: dabenavidesd at yahoo.es
> Subject: Re: [M3devel] results of threadtest program on Windows7
> To: rcolebur at scires.com; m3devel at elegosoft.com; jay.krell at cornell.edu
> 
> Hi all:
> I would doubt but there could be some source of problem in smp on the Win32 platform, since there was a SPINE implementation on an intelligent NIC with 2 embedded MIPS CPUs, perhaps this was just a driver RT but it was for real time and in such a case there should be no problem besides that of the scheduling policy, but thinking how about linking MS Win2k R is a kind of crazy not to believe there was some synchronization with CPU board threads and that component threading at some point I believe.
> 
> Even more in embedded systems, there was a MPU implementation of it in 80186 a decade ago,  perhaps would be good to have a look of their Thread interface implementation it might be seem interesting if so.
> 
> But in any case there should be plenty of ways of implementing the threading tests incrementally of number of threads, besides you may want to check some uniprocessors with hyperThreading technology (sort of thread physical divisions inside the cpu), they are presented to OS as 2 smp processors, it could be interesting, I remember to test  time ago in this machines and anything weird happened, but quite time ago with ThreadPthread LINUXLIBC6 systems with normally distributed programs.
>  
> What about results in Win2k ?
> Thanks in advance
> 
> --- El mi?, 2/3/11, Jay K <jay.krell at cornell.edu> escribi?:
> 
> De: Jay K <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] results of threadtest program on Windows7
> Para: rcolebur at scires.com, "m3devel" <m3devel at elegosoft.com>
> Fecha: mi?rcoles, 2 de marzo, 2011 20:17
> 
> Even with the change I made PutCard to PutInt?
> That's the only failure I've seen.
> I'll try on a non-virtual dual-proc machine later.
>  
> Thanks,
>  - Jay
>  
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Wed, 2 Mar 2011 19:42:47 -0500
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Yes, it fails more often than it runs for me.
> Regards,
> Randy
>  
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Tuesday, March 01, 2011 5:59 AM
> To: Mika Nystrom; Coleburn, Randy
> Cc: m3devel
> Subject: RE: [M3devel] results of threadtest program on Windows7
>  
> I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
> I've run it just a few times now. One single and dual processor virtual machines.
> Randy, has it failed many times for you?
> 
>  - Jay
> 
> > To: rcolebur at SCIRES.COM
> > Date: Sun, 27 Feb 2011 15:11:25 -0800
> > From: mika at async.caltech.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] results of threadtest program on Windows7
> > 
> > Ah, it just doesn't check command-line arguments that carefully.
> > 
> > I think what you did is equivalent to "-tests STD".
> > 
> > Mika
> > 
> > "Coleburn, Randy" writes:
> > >Mika:
> > >
> > >No change with "-tests POSIX".
> > >
> > >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> > >ptions are, and I typed "threadtest -help" rather than reading the code.
> > >
> > >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> > >d it again and it ran to completion. Something seems non-deterministic her=
> > >e. See below.
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >.
> > >
> > >***
> > >*** runtime error:
> > >*** Attempt to reference an illegal memory location.
> > >*** pc =3D 0x77762262
> > >***
> > >
> > >Stack trace:
> > > FP PC Procedure
> > >--------- --------- -------------------------------
> > > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> > >3
> > > 0xcdf9c0 0x77762262 <???>
> > > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> > >3
> > > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> > >.m3
> > > 0xcdfb80 0x76543677 <???>
> > > 0xcdfbc0 0x77779f02 <???>
> > >......... ......... ... more frames ...
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >All tests complete. Congratulations.
> > >
> > >Regards,
> > >Randy Coleburn
> > >
> > >-----Original Message-----
> > >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> > >Sent: Sunday, February 27, 2011 3:30 PM
> > >To: Coleburn, Randy
> > >Cc: m3devel at elegosoft.com
> > >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> > >
> > >Hi Randy,
> > >
> > >You can try it with -tests POSIX as well.
> > >
> > >I find on user threads it runs very slowly (but it does run) because of how=
> > > unfair
> > >the thread scheduler is.
> > >
> > >Next step might be to whittle down the tests and see if you can get a failu=
> > >re with
> > >a single test running and -n 2. That would likely be the simplest scenario=
> > > to
> > >start further debugging from.
> > >
> > > Mika
> > >
> > >"Coleburn, Randy" writes:
> > >>Mika et al:
> > >>
> > >>Thought I would try something else.
> > >>
> > >>I took the sources of your thread test program to an older XP machine that=
> > > =3D
> > >>has CM3 circa August 2008. This is the machine and implementation I used =
> > >w=3D
> > >>hen building a major project I did a couple years back.
> > >>
> > >>The thread test program does indeed build on this old system, but when I r=
> > >u=3D
> > >>n it, I get different results than with the latest HEAD branch code. =3D20
> > >>
> > >>After it prints "running...printing oldest/median age/newest", on the next=
> > > =3D
> > >>line I get two periods ".." and now the program seems hung. I'll let it "=
> > >r=3D
> > >>un" for a few more minutes to see if anything else happens before killing =
> > >i=3D
> > >>t.
> > >>
> > >>At least we don't get the subscript and assertion failures on this older C=
> > >M=3D
> > >>3 platform.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>
> > >>-----Original Message-----
> > >>From: Coleburn, Randy=3D20
> > >>Sent: Sunday, February 27, 2011 2:09 PM
> > >>To: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7
> > >>
> > >>Mika:
> > >>
> > >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> > >>
> > >>Here is what happens now when I run your threadtest program on Windows 7.
> > >>
> > >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> > >r=3D
> > >>k
> > >>Writing file...done
> > >>Creating read threads...done
> > >>Creating nxread threads...done
> > >>Creating tryexcept threads...done
> > >>Creating forktoomuch threads...done
> > >>Creating alloc threads...done
> > >>Creating creat threads...done
> > >>Creating lock threads...done
> > >>running...printing oldest/median age/newest
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** An array subscript was out of range.
> > >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> > >>***
> > >>
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** <*ASSERT*> failed.
> > >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> > >>***
> > >>
> > >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> > >>
> > >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> > >.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>-----Original Message-----
> > >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> > >>Sent: Saturday, February 26, 2011 12:55 PM
> > >>To: Coleburn, Randy
> > >>Cc: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> > >>
> > >>Hi Randy,
> > >>
> > >>Hm yes it looks like my Windows programming skills leave something
> > >>to be desired.
> > >>
> > >>You can run the thread tester while skipping a test as follows
> > >>
> > >> threadtest -tests ALL,-fork
> > >>
> > >>(for instance)
> > >>
> > >>if you just run=3D20
> > >>
> > >> threadtest -sadfassdaf
> > >>
> > >>it'll print the tests that are available.
> > >>
> > >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> > >>Can you give me a very brief description of what you did to install Modula=
> > >-=3D
> > >>3
> > >>on this system?
> > >>
> > >> Mika
> > >>
> > >>"Coleburn, Randy" writes:
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>
> > >>>Mika:
> > >>>
> > >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> > >>>
> > >>>So, I ran your threadtest program.
> > >>>
> > >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> > >e=3D
> > >>p=3D3D
> > >>>eating "ERROR FApply" messages.
> > >>>
> > >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > >>>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
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>***
> > >>>*** runtime error:
> > >>>*** An enumeration or subrange value was out of range.
> > >>>*** file "..\src\Main.m3", line 340
> > >>>***
> > >>>
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>Stack trace:
> > >>> FP PC Procedure
> > >>>--------- --------- -------------------------------
> > >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> > >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> > >>>
> > >>>Regards,
> > >>>Randy Coleburn
> > >>>
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/html; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>
> 
> 

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

From hosking at cs.purdue.edu  Thu Mar  3 16:41:48 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 3 Mar 2011 10:41:48 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W52252742B56CBFEAD0A0DFE6C30@phx.gbl>
References: <COL101-W4726257303F22627175774E6C30@phx.gbl>,
	<974355.12644.qm@web29717.mail.ird.yahoo.com>,
	<COL101-W2637AB63DA6D9866A00D07E6C30@phx.gbl>,
	<COL101-W1943F7B289FE5FD33E5D1EE6C30@phx.gbl>
	<COL101-W52252742B56CBFEAD0A0DFE6C30@phx.gbl>
Message-ID: <5572AFA1-4813-4556-B900-B53C1B3F4A00@cs.purdue.edu>

Again, the problem is not necessarily in the collector/allocator.  There has been a lot of churn lately in the threads implementations which could result in confusing the memory manager.


On Mar 3, 2011, at 1:37 AM, Jay K wrote:

> Here is another failure also I386_DARWIN.
> 
> 
> (gdb) break RTError__MsgS
> Breakpoint 2 at 0x3b65f: file ../src/runtime/common/RTError.m3, line 30.
> (gdb) run
> The program being debugged has been started already.
> Start it from the beginning? (y or n) y
> Starting program: /Users/jay/dev2/cm3/m3-libs/m3core/tests/thread/I386_DARWIN/threadtest 
> 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
> ..[Switching to process 86430 thread 0x1503]
> 
> Breakpoint 2, RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:30
> 30        StartError (msgA, msgB, msgC);
> (gdb) bt
> #0  RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:30
> #1  0x0003bdc7 in RTException__Crash (a=0xb040ea64, raises=0 '\0', rte=0x7d100) at ../src/runtime/common/RTException.m3:79
> #2  0x0003bb21 in RTException__DefaultBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:39
> #3  0x0003ba7c in RTException__InvokeBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
> #4  0x00043ca5 in RTException__Raise (act=0xb040ea64) at ../src/runtime/ex_frame/RTExFrame.m3:85
> #5  0x0003bbb4 in RTException__DefaultBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:47
> #6  0x0003ba7c in RTException__InvokeBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
> #7  0x00043ca5 in RTException__Raise (act=0xb040ea64) at ../src/runtime/ex_frame/RTExFrame.m3:85
> #8  0x0002b102 in RTHooks__ReportFault (module=0x70f80, info=13378) at ../src/runtime/common/RTHooks.m3:111
> #9  0x000394c5 in _m3_fault (arg=13378) at ../src/runtime/common/RTCollector.m3:393
> #10 0x0002fdd2 in RTCollector__Move (self=0xb4000c, cp=0xba0014) at ../src/runtime/common/RTCollector.m3:418
> #11 0x0002e503 in RTHeapMap__Walk (x=0xba0014, pc=0x79928, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:202
> #12 0x0002dc9c in RTHeapMap__DoWalkRef (t=0x6de54, a=0xba0014, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:62
> #13 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e3f4, a=0xba000c, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:57
> #14 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e508, a=0xba000c, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:57
> #15 0x0002dc2e in RTHeapMap__WalkRef (h=0xba0008, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:47
> #16 0x00032279 in RTCollector__CleanBetween (h=0xba0008, he=0xbb0000, clean=0 '\0') at ../src/runtime/common/RTCollector.m3:1091
> #17 0x00032098 in RTCollector__CleanPage (page=0xba0000) at ../src/runtime/common/RTCollector.m3:1064
> #18 0x00031798 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885
> #19 0x00030e75 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720
> #20 0x00030a97 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654
> #21 0x0002cb85 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00e74) at ../src/runtime/common/RTAllocator.m3:367
> #22 0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:296
> #23 0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:143
> #24 0x00003b5f in Main__AApply (cl=0x9556c0) at ../src/Main.m3:260
> #25 0x00046ee2 in ThreadPThread__RunThread (me=0xa00e30) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #26 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00e30) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #27 0x93889155 in _pthread_start ()
> #28 0x93889012 in thread_start ()
> (gdb) threads apply all bt
> Undefined command: "threads".  Try "help".
> (gdb) thread apply all bt
> 
> Thread 13 (process 86430 thread 0x1903):
> #0  0x9388a6f1 in semaphore_wait_signal ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00880) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #4  0x00003ed8 in Main__LApply (cl=0x9557d8) at ../src/Main.m3:290
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa010f0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa010f0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 12 (process 86430 thread 0x1803):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00880) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #4  0x00003ed8 in Main__LApply (cl=0x9557a0) at ../src/Main.m3:290
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01040) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01040) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 11 (process 86430 thread 0x1703):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00880) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #4  0x00003ed8 in Main__LApply (cl=0x955768) at ../src/Main.m3:290
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00f90) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00f90) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 10 (process 86430 thread 0x1603):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00f24) at ../src/runtime/common/RTAllocator.m3:365
> #5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:296
> #6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:143
> #7  0x00003b5f in Main__AApply (cl=0x9556f8) at ../src/Main.m3:260
> #8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00ee0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00ee0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #10 0x93889155 in _pthread_start ()
> #11 0x93889012 in thread_start ()
> 
> Thread 9 (process 86430 thread 0x1503):
> #0  RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:30
> #1  0x0003bdc7 in RTException__Crash (a=0xb040ea64, raises=0 '\0', rte=0x7d100) at ../src/runtime/common/RTException.m3:79
> #2  0x0003bb21 in RTException__DefaultBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:39
> #3  0x0003ba7c in RTException__InvokeBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
> #4  0x00043ca5 in RTException__Raise (act=0xb040ea64) at ../src/runtime/ex_frame/RTExFrame.m3:85
> #5  0x0003bbb4 in RTException__DefaultBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:47
> #6  0x0003ba7c in RTException__InvokeBackstop (a=0xb040ea64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
> #7  0x00043ca5 in RTException__Raise (act=0xb040ea64) at ../src/runtime/ex_frame/RTExFrame.m3:85
> #8  0x0002b102 in RTHooks__ReportFault (module=0x70f80, info=13378) at ../src/runtime/common/RTHooks.m3:111
> #9  0x000394c5 in _m3_fault (arg=13378) at ../src/runtime/common/RTCollector.m3:393
> #10 0x0002fdd2 in RTCollector__Move (self=0xb4000c, cp=0xba0014) at ../src/runtime/common/RTCollector.m3:418
> #11 0x0002e503 in RTHeapMap__Walk (x=0xba0014, pc=0x79928, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:202
> #12 0x0002dc9c in RTHeapMap__DoWalkRef (t=0x6de54, a=0xba0014, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:62
> #13 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e3f4, a=0xba000c, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:57
> #14 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e508, a=0xba000c, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:57
> #15 0x0002dc2e in RTHeapMap__WalkRef (h=0xba0008, v=0xb4000c) at ../src/runtime/common/RTHeapMap.m3:47
> #16 0x00032279 in RTCollector__CleanBetween (h=0xba0008, he=0xbb0000, clean=0 '\0') at ../src/runtime/common/RTCollector.m3:1091
> #17 0x00032098 in RTCollector__CleanPage (page=0xba0000) at ../src/runtime/common/RTCollector.m3:1064
> #18 0x00031798 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885
> #19 0x00030e75 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720
> #20 0x00030a97 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654
> #21 0x0002cb85 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00e74) at ../src/runtime/common/RTAllocator.m3:367
> #22 0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:296
> #23 0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:143
> #24 0x00003b5f in Main__AApply (cl=0x9556c0) at ../src/Main.m3:260
> #25 0x00046ee2 in ThreadPThread__RunThread (me=0xa00e30) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #26 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00e30) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #27 0x93889155 in _pthread_start ()
> #28 0x93889012 in thread_start ()
> 
> Thread 8 (process 86430 thread 0x1403):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00dc4) at ../src/runtime/common/RTAllocator.m3:365
> #5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:296
> #6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:143
> #7  0x00003b5f in Main__AApply (cl=0x955688) at ../src/Main.m3:260
> #8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00d80) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00d80) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #10 0x93889155 in _pthread_start ()
> #11 0x93889012 in thread_start ()
> 
> Thread 7 (process 86430 thread 0x1303):
> #0  0x9389c856 in __wait4 ()
> #1  0x9389c847 in waitpid$UNIX2003 ()
> #2  0x0004b222 in Uexec__waitpid (i=86436, j=0xb030ad9c, k=0) at ../src/unix/Common/Uexec.c:67
> #3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86436, status=0xb030ad9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
> #4  0x0000d66a in Process__Wait (p=0xb00018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
> #5  0x00003719 in Main__FApply (cl=0x955618) at ../src/Main.m3:230
> #6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00d20) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00d20) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #8  0x93889155 in _pthread_start ()
> #9  0x93889012 in thread_start ()
> 
> Thread 6 (process 86430 thread 0x1203):
> #0  0x9389c856 in __wait4 ()
> #1  0x9389c847 in waitpid$UNIX2003 ()
> #2  0x0004b222 in Uexec__waitpid (i=86437, j=0xb0288d9c, k=0) at ../src/unix/Common/Uexec.c:67
> #3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86437, status=0xb0288d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
> #4  0x0000d66a in Process__Wait (p=0xbd0018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
> #5  0x00003719 in Main__FApply (cl=0x9555e0) at ../src/Main.m3:230
> #6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00b30) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00b30) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #8  0x93889155 in _pthread_start ()
> #9  0x93889012 in thread_start ()
> 
> Thread 5 (process 86430 thread 0x1103):
> #0  0x9389c856 in __wait4 ()
> #1  0x9389c847 in waitpid$UNIX2003 ()
> #2  0x0004b222 in Uexec__waitpid (i=86435, j=0xb0206d9c, k=0) at ../src/unix/Common/Uexec.c:67
> #3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86435, status=0xb0206d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
> #4  0x0000d66a in Process__Wait (p=0xc2000c) at ../src/os/POSIX/ProcessPosixCommon.m3:275
> #5  0x00003719 in Main__FApply (cl=0x9555a8) at ../src/Main.m3:230
> #6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00a80) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00a80) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #8  0x93889155 in _pthread_start ()
> #9  0x93889012 in thread_start ()
> 
> Thread 4 (process 86430 thread 0x1003):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=12, dataAlignment=4, thread=0xa00a14) at ../src/runtime/common/RTAllocator.m3:365
> #5  0x0002bf13 in RTAllocator__GetTracedObj (def=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:224
> #6  0x0002b98a in RTHooks__AllocateTracedObj (defn=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:122
> #7  0x00008eeb in FilePosix__New (fd=5, ds=1) at ../src/os/POSIX/FilePosix.m3:63
> #8  0x0000a4eb in FS__OpenFileReadonly (pn=0x775b8) at ../src/os/POSIX/FSPosix.m3:182
> #9  0x00014dfa in FileRd__Open (p=0x775b8) at ../src/rw/FileRd.m3:16
> #10 0x00003046 in Main__RApply (cl=0x955538) at ../src/Main.m3:174
> #11 0x00046ee2 in ThreadPThread__RunThread (me=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #12 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #13 0x93889155 in _pthread_start ()
> #14 0x93889012 in thread_start ()
> 
> Thread 3 (process 86430 thread 0x117):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x74220) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00044f3a in ThreadPThread__InitMutex (m=0x960010, root=0x96000c, Clean=0x44dac) at ../src/thread/PTHREAD/ThreadPThread.m3:101
> #4  0x0004500b in ThreadPThread__LockMutex (m=0x96000c) at ../src/thread/PTHREAD/ThreadPThread.m3:117
> #5  0x0000e060 in Rd__GetChar (rd=0x96000c) at ../src/rw/Rd.m3:33
> #6  0x000030b5 in Main__RApply (cl=0x955500) at ../src/Main.m3:177
> #7  0x00046ee2 in ThreadPThread__RunThread (me=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #8  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #9  0x93889155 in _pthread_start ()
> #10 0x93889012 in thread_start ()
> 
> Thread 2 (process 86430 thread 0x313):
> #0  0x938582a2 in semaphore_wait_trap ()
> #1  0x9385fd92 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x00036509 in RTHeapRep__RegisterFinalCleanup (r=0x9b1050, p=0x44dac) at ../src/runtime/common/RTCollector.m3:2148
> #5  0x00044fa2 in ThreadPThread__InitMutex (m=0x9b1054, root=0x9b1050, Clean=0x44dac) at ../src/thread/PTHREAD/ThreadPThread.m3:106
> #6  0x0004500b in ThreadPThread__LockMutex (m=0x9b1050) at ../src/thread/PTHREAD/ThreadPThread.m3:117
> #7  0x0000e060 in Rd__GetChar (rd=0x9b1050) at ../src/rw/Rd.m3:33
> #8  0x000030b5 in Main__RApply (cl=0x9554c8) at ../src/Main.m3:177
> #9  0x00046ee2 in ThreadPThread__RunThread (me=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #10 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #11 0x93889155 in _pthread_start ()
> #12 0x93889012 in thread_start ()
> 
> Thread 1 (process 86430 local thread 0x4507):
> #0  0x9385f44e in __semwait_signal ()
> #1  0x9388a3e6 in _pthread_cond_wait ()
> #2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
> #3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299134070.4957981) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
> #4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
> #5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
> #6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
> #7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
> #8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
> #9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
> #10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16
> 
>  - Jay
> 
> 
> From: jay.krell at cornell.edu
> To: dabenavidesd at yahoo.es; rcolebur at scires.com; m3devel at elegosoft.com
> Subject: RE: [M3devel] results of threadtest program on Windows7
> Date: Thu, 3 Mar 2011 06:32:50 +0000
> 
> Solaris doesn't hang now. I didn't change anything. And it succeeds.
> Here are some stacks for a failure on I386_DARWIN.
> Notice that it *should* abort right after the EBUSY print, but it still run a while.
> Possibly too much information is lost.
> 
> 
> (gdb) run
> Starting program: /Users/jay/dev2/cm3/m3-libs/m3core/tests/thread/I386_DARWIN/threadtest 
> Reading symbols for shared libraries ++. done
> 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
> ..........laziest thread is 1/0/0 (tests: read 0/0/0 fork 1/1/1 alloc 0/0/0 lock 0/0/0)
> .........pthread_mutex_destroy:EBUSY (0)
> .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:
> ***    An array subscript was out of range.
> ***    file "../src/runtime/common/RTCollector.m3", line 418
> ***
> 
> 
> Program received signal SIGABRT, Aborted.
> 0x9385f44e in __semwait_signal ()
> (gdb) bt
> #0  0x9385f44e in __semwait_signal ()
> #1  0x9388a3e6 in _pthread_cond_wait ()
> #2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
> #3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299133562.375689) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
> #4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
> #5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
> #6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
> #7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
> #8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
> #9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
> #10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16
> 
> 
> (gdb) thread apply all bt
> 
> Thread 13 (process 86311 thread 0x2a03):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #4  0x00003ed8 in Main__LApply (cl=0x9557d8) at ../src/Main.m3:290
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01130) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01130) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 12 (process 86311 thread 0x1f03):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #4  0x00003ed8 in Main__LApply (cl=0x9557a0) at ../src/Main.m3:290
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01080) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01080) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 11 (process 86311 thread 0x1e03):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #4  0x00003ed8 in Main__LApply (cl=0x955768) at ../src/Main.m3:290
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 10 (process 86311 thread 0x1d03):
> #0  0x93934136 in __semwait_signal_nocancel ()
> #1  0x93933d1b in nanosleep$NOCANCEL$UNIX2003 ()
> #2  0x9392d013 in usleep$NOCANCEL$UNIX2003 ()
> #3  0x93944685 in abort ()
> #4  0x0004b5e6 in Cstdlib__abort () at ../src/C/Common/CstdlibC.c:21
> #5  0x000434dd in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20
> #6  0x0003d51f in RTProcess__Crash (msg=0x0) at ../src/runtime/common/RTProcess.m3:65
> #7  0x0003b9d3 in RTError__EndError (crash=1 '\001') at ../src/runtime/common/RTError.m3:118
> #8  0x0003b6e6 in RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:40
> #9  0x0003bdc7 in RTException__Crash (a=0xb0490a64, raises=0 '\0', rte=0x7d100) at ../src/runtime/common/RTException.m3:79
> #10 0x0003bb21 in RTException__DefaultBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:39
> #11 0x0003ba7c in RTException__InvokeBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
> #12 0x00043ca5 in RTException__Raise (act=0xb0490a64) at ../src/runtime/ex_frame/RTExFrame.m3:85
> #13 0x0003bbb4 in RTException__DefaultBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:47
> #14 0x0003ba7c in RTException__InvokeBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
> #15 0x00043ca5 in RTException__Raise (act=0xb0490a64) at ../src/runtime/ex_frame/RTExFrame.m3:85
> #16 0x0002b102 in RTHooks__ReportFault (module=0x70f80, info=13378) at ../src/runtime/common/RTHooks.m3:111
> #17 0x000394c5 in _m3_fault (arg=13378) at ../src/runtime/common/RTCollector.m3:393
> #18 0x0002fdd2 in RTCollector__Move (self=0xb3000c, cp=0x9a0014) at ../src/runtime/common/RTCollector.m3:418
> #19 0x0002e503 in RTHeapMap__Walk (x=0x9a0014, pc=0x79928, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:202
> #20 0x0002dc9c in RTHeapMap__DoWalkRef (t=0x6de54, a=0x9a0014, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:62
> #21 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e3f4, a=0x9a000c, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:57
> #22 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e508, a=0x9a000c, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:57
> #23 0x0002dc2e in RTHeapMap__WalkRef (h=0x9a0008, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:47
> #24 0x00032279 in RTCollector__CleanBetween (h=0x9a0008, he=0x9b0000, clean=0 '\0') at ../src/runtime/common/RTCollector.m3:1091
> #25 0x00032098 in RTCollector__CleanPage (page=0x9a0000) at ../src/runtime/common/RTCollector.m3:1064
> #26 0x00031798 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885
> #27 0x00030e75 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720
> #28 0x00030a97 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654
> #29 0x0002cb85 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00f64) at ../src/runtime/common/RTAllocator.m3:367
> #30 0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:296
> #31 0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:143
> #32 0x00003b5f in Main__AApply (cl=0x9556f8) at ../src/Main.m3:260
> #33 0x00046ee2 in ThreadPThread__RunThread (me=0xa00f20) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #34 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00f20) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #35 0x93889155 in _pthread_start ()
> #36 0x93889012 in thread_start ()
> 
> Thread 9 (process 86311 thread 0x1c03):
> #0  0x938582a2 in semaphore_wait_trap ()
> #1  0x9385fd92 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00eb4) at ../src/runtime/common/RTAllocator.m3:365
> #5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:296
> #6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:143
> #7  0x00003b5f in Main__AApply (cl=0x9556c0) at ../src/Main.m3:260
> #8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00e70) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00e70) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #10 0x93889155 in _pthread_start ()
> #11 0x93889012 in thread_start ()
> 
> Thread 8 (process 86311 thread 0x1b03):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00e04) at ../src/runtime/common/RTAllocator.m3:365
> #5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:296
> #6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:143
> #7  0x00003b5f in Main__AApply (cl=0x955688) at ../src/Main.m3:260
> #8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00dc0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00dc0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #10 0x93889155 in _pthread_start ()
> #11 0x93889012 in thread_start ()
> 
> Thread 7 (process 86311 thread 0x1a03):
> #0  0x9389c856 in __wait4 ()
> #1  0x9389c847 in waitpid$UNIX2003 ()
> #2  0x0004b222 in Uexec__waitpid (i=86384, j=0xb030ad9c, k=0) at ../src/unix/Common/Uexec.c:67
> #3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86384, status=0xb030ad9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
> #4  0x0000d66a in Process__Wait (p=0xb00018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
> #5  0x00003719 in Main__FApply (cl=0x955618) at ../src/Main.m3:230
> #6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00d60) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00d60) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #8  0x93889155 in _pthread_start ()
> #9  0x93889012 in thread_start ()
> 
> Thread 6 (process 86311 thread 0x1903):
> #0  0x9389c856 in __wait4 ()
> #1  0x9389c847 in waitpid$UNIX2003 ()
> #2  0x0004b222 in Uexec__waitpid (i=86385, j=0xb0288d9c, k=0) at ../src/unix/Common/Uexec.c:67
> #3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86385, status=0xb0288d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
> #4  0x0000d66a in Process__Wait (p=0xbd000c) at ../src/os/POSIX/ProcessPosixCommon.m3:275
> #5  0x00003719 in Main__FApply (cl=0x9555e0) at ../src/Main.m3:230
> #6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00b70) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00b70) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #8  0x93889155 in _pthread_start ()
> #9  0x93889012 in thread_start ()
> 
> Thread 5 (process 86311 thread 0x1803):
> #0  0x9389c856 in __wait4 ()
> #1  0x9389c847 in waitpid$UNIX2003 ()
> #2  0x0004b222 in Uexec__waitpid (i=86386, j=0xb0206d9c, k=0) at ../src/unix/Common/Uexec.c:67
> #3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86386, status=0xb0206d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
> #4  0x0000d66a in Process__Wait (p=0x9d0018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
> #5  0x00003719 in Main__FApply (cl=0x9555a8) at ../src/Main.m3:230
> #6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00ac0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00ac0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #8  0x93889155 in _pthread_start ()
> #9  0x93889012 in thread_start ()
> 
> Thread 4 (process 86311 thread 0x1103):
> #0  0x9385fb99 in pthread_mutex_lock ()
> #1  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00c20) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #2  0x0004503c in ThreadPThread__LockMutex (m=0xb6000c) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #3  0x0000e060 in Rd__GetChar (rd=0xb6000c) at ../src/rw/Rd.m3:33
> #4  0x000030b5 in Main__RApply (cl=0x955538) at ../src/Main.m3:177
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 3 (process 86311 thread 0x117):
> #0  0x93859304 in pthread_getspecific ()
> #1  0x0004a529 in ThreadPThread__GetActivation () at ../src/thread/PTHREAD/ThreadPThreadC.c:309
> #2  0x00049f52 in RTHooks__PushEFrame (frame=0xb0102d20) at ../src/thread/PTHREAD/ThreadPThread.m3:1385
> #3  0x0000e07b in Rd__GetChar (rd=0x99000c) at ../src/rw/Rd.m3:33
> #4  0x000030b5 in Main__RApply (cl=0x955500) at ../src/Main.m3:177
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 2 (process 86311 thread 0x313):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=12, dataAlignment=4, thread=0xa00834) at ../src/runtime/common/RTAllocator.m3:365
> #5  0x0002bf13 in RTAllocator__GetTracedObj (def=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:224
> #6  0x0002b98a in RTHooks__AllocateTracedObj (defn=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:122
> #7  0x00008eeb in FilePosix__New (fd=5, ds=1) at ../src/os/POSIX/FilePosix.m3:63
> #8  0x0000a4eb in FS__OpenFileReadonly (pn=0x775b8) at ../src/os/POSIX/FSPosix.m3:182
> #9  0x00014dfa in FileRd__Open (p=0x775b8) at ../src/rw/FileRd.m3:16
> #10 0x00003046 in Main__RApply (cl=0x9554c8) at ../src/Main.m3:174
> #11 0x00046ee2 in ThreadPThread__RunThread (me=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #12 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #13 0x93889155 in _pthread_start ()
> #14 0x93889012 in thread_start ()
> 
> Thread 1 (process 86311 local thread 0x2e03):
> #0  0x9385f44e in __semwait_signal ()
> #1  0x9388a3e6 in _pthread_cond_wait ()
> #2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
> #3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299133562.375689) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
> #4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
> #5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
> #6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
> #7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
> #8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
> #9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
> #10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16
> 
> 
> 
> 
> 
> 
> 
> From: jay.krell at cornell.edu
> To: dabenavidesd at yahoo.es; rcolebur at scires.com; m3devel at elegosoft.com
> Subject: RE: [M3devel] results of threadtest program on Windows7
> Date: Thu, 3 Mar 2011 02:46:39 +0000
> 
> There is probably a bug in RTCollector.m3 or RTAllocator.m3.
> 
>  - Jay
> 
> Date: Thu, 3 Mar 2011 02:27:58 +0000
> From: dabenavidesd at yahoo.es
> Subject: Re: [M3devel] results of threadtest program on Windows7
> To: rcolebur at scires.com; m3devel at elegosoft.com; jay.krell at cornell.edu
> 
> Hi all:
> I would doubt but there could be some source of problem in smp on the Win32 platform, since there was a SPINE implementation on an intelligent NIC with 2 embedded MIPS CPUs, perhaps this was just a driver RT but it was for real time and in such a case there should be no problem besides that of the scheduling policy, but thinking how about linking MS Win2k R is a kind of crazy not to believe there was some synchronization with CPU board threads and that component threading at some point I believe.
> 
> Even more in embedded systems, there was a MPU implementation of it in 80186 a decade ago,  perhaps would be good to have a look of their Thread interface implementation it might be seem interesting if so.
> 
> But in any case there should be plenty of ways of implementing the threading tests incrementally of number of threads, besides you may want to check some uniprocessors with hyperThreading technology (sort of thread physical divisions inside the cpu), they are presented to OS as 2 smp processors, it could be interesting, I remember to test  time ago in this machines and anything weird happened, but quite time ago with ThreadPthread LINUXLIBC6 systems with normally distributed programs.
>  
> What about results in Win2k ?
> Thanks in advance
> 
> --- El mi?, 2/3/11, Jay K <jay.krell at cornell.edu> escribi?:
> 
> De: Jay K <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] results of threadtest program on Windows7
> Para: rcolebur at scires.com, "m3devel" <m3devel at elegosoft.com>
> Fecha: mi?rcoles, 2 de marzo, 2011 20:17
> 
> Even with the change I made PutCard to PutInt?
> That's the only failure I've seen.
> I'll try on a non-virtual dual-proc machine later.
>  
> Thanks,
>  - Jay
>  
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Wed, 2 Mar 2011 19:42:47 -0500
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Yes, it fails more often than it runs for me.
> Regards,
> Randy
>  
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Tuesday, March 01, 2011 5:59 AM
> To: Mika Nystrom; Coleburn, Randy
> Cc: m3devel
> Subject: RE: [M3devel] results of threadtest program on Windows7
>  
> I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
> I've run it just a few times now. One single and dual processor virtual machines.
> Randy, has it failed many times for you?
> 
>  - Jay
> 
> > To: rcolebur at SCIRES.COM
> > Date: Sun, 27 Feb 2011 15:11:25 -0800
> > From: mika at async.caltech.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] results of threadtest program on Windows7
> > 
> > Ah, it just doesn't check command-line arguments that carefully.
> > 
> > I think what you did is equivalent to "-tests STD".
> > 
> > Mika
> > 
> > "Coleburn, Randy" writes:
> > >Mika:
> > >
> > >No change with "-tests POSIX".
> > >
> > >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> > >ptions are, and I typed "threadtest -help" rather than reading the code.
> > >
> > >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> > >d it again and it ran to completion. Something seems non-deterministic her=
> > >e. See below.
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >.
> > >
> > >***
> > >*** runtime error:
> > >*** Attempt to reference an illegal memory location.
> > >*** pc =3D 0x77762262
> > >***
> > >
> > >Stack trace:
> > > FP PC Procedure
> > >--------- --------- -------------------------------
> > > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> > >3
> > > 0xcdf9c0 0x77762262 <???>
> > > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> > >3
> > > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> > >.m3
> > > 0xcdfb80 0x76543677 <???>
> > > 0xcdfbc0 0x77779f02 <???>
> > >......... ......... ... more frames ...
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >All tests complete. Congratulations.
> > >
> > >Regards,
> > >Randy Coleburn
> > >
> > >-----Original Message-----
> > >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> > >Sent: Sunday, February 27, 2011 3:30 PM
> > >To: Coleburn, Randy
> > >Cc: m3devel at elegosoft.com
> > >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> > >
> > >Hi Randy,
> > >
> > >You can try it with -tests POSIX as well.
> > >
> > >I find on user threads it runs very slowly (but it does run) because of how=
> > > unfair
> > >the thread scheduler is.
> > >
> > >Next step might be to whittle down the tests and see if you can get a failu=
> > >re with
> > >a single test running and -n 2. That would likely be the simplest scenario=
> > > to
> > >start further debugging from.
> > >
> > > Mika
> > >
> > >"Coleburn, Randy" writes:
> > >>Mika et al:
> > >>
> > >>Thought I would try something else.
> > >>
> > >>I took the sources of your thread test program to an older XP machine that=
> > > =3D
> > >>has CM3 circa August 2008. This is the machine and implementation I used =
> > >w=3D
> > >>hen building a major project I did a couple years back.
> > >>
> > >>The thread test program does indeed build on this old system, but when I r=
> > >u=3D
> > >>n it, I get different results than with the latest HEAD branch code. =3D20
> > >>
> > >>After it prints "running...printing oldest/median age/newest", on the next=
> > > =3D
> > >>line I get two periods ".." and now the program seems hung. I'll let it "=
> > >r=3D
> > >>un" for a few more minutes to see if anything else happens before killing =
> > >i=3D
> > >>t.
> > >>
> > >>At least we don't get the subscript and assertion failures on this older C=
> > >M=3D
> > >>3 platform.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>
> > >>-----Original Message-----
> > >>From: Coleburn, Randy=3D20
> > >>Sent: Sunday, February 27, 2011 2:09 PM
> > >>To: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7
> > >>
> > >>Mika:
> > >>
> > >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> > >>
> > >>Here is what happens now when I run your threadtest program on Windows 7.
> > >>
> > >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> > >r=3D
> > >>k
> > >>Writing file...done
> > >>Creating read threads...done
> > >>Creating nxread threads...done
> > >>Creating tryexcept threads...done
> > >>Creating forktoomuch threads...done
> > >>Creating alloc threads...done
> > >>Creating creat threads...done
> > >>Creating lock threads...done
> > >>running...printing oldest/median age/newest
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** An array subscript was out of range.
> > >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> > >>***
> > >>
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** <*ASSERT*> failed.
> > >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> > >>***
> > >>
> > >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> > >>
> > >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> > >.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>-----Original Message-----
> > >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> > >>Sent: Saturday, February 26, 2011 12:55 PM
> > >>To: Coleburn, Randy
> > >>Cc: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> > >>
> > >>Hi Randy,
> > >>
> > >>Hm yes it looks like my Windows programming skills leave something
> > >>to be desired.
> > >>
> > >>You can run the thread tester while skipping a test as follows
> > >>
> > >> threadtest -tests ALL,-fork
> > >>
> > >>(for instance)
> > >>
> > >>if you just run=3D20
> > >>
> > >> threadtest -sadfassdaf
> > >>
> > >>it'll print the tests that are available.
> > >>
> > >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> > >>Can you give me a very brief description of what you did to install Modula=
> > >-=3D
> > >>3
> > >>on this system?
> > >>
> > >> Mika
> > >>
> > >>"Coleburn, Randy" writes:
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>
> > >>>Mika:
> > >>>
> > >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> > >>>
> > >>>So, I ran your threadtest program.
> > >>>
> > >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> > >e=3D
> > >>p=3D3D
> > >>>eating "ERROR FApply" messages.
> > >>>
> > >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > >>>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
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>***
> > >>>*** runtime error:
> > >>>*** An enumeration or subrange value was out of range.
> > >>>*** file "..\src\Main.m3", line 340
> > >>>***
> > >>>
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>Stack trace:
> > >>> FP PC Procedure
> > >>>--------- --------- -------------------------------
> > >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> > >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> > >>>
> > >>>Regards,
> > >>>Randy Coleburn
> > >>>
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/html; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>
> 
> 

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

From hosking at cs.purdue.edu  Thu Mar  3 16:42:51 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 3 Mar 2011 10:42:51 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W1943F7B289FE5FD33E5D1EE6C30@phx.gbl>
References: <COL101-W4726257303F22627175774E6C30@phx.gbl>,
	<974355.12644.qm@web29717.mail.ird.yahoo.com>,
	<COL101-W2637AB63DA6D9866A00D07E6C30@phx.gbl>
	<COL101-W1943F7B289FE5FD33E5D1EE6C30@phx.gbl>
Message-ID: <DEFD098A-268B-41EB-B59E-03BF19CAF910@cs.purdue.edu>

Running with @M3paranoidgc should let us know how we end up with a pointer that does not refer to an object.

On Mar 3, 2011, at 1:32 AM, Jay K wrote:

> Solaris doesn't hang now. I didn't change anything. And it succeeds.
> Here are some stacks for a failure on I386_DARWIN.
> Notice that it *should* abort right after the EBUSY print, but it still run a while.
> Possibly too much information is lost.
> 
> 
> (gdb) run
> Starting program: /Users/jay/dev2/cm3/m3-libs/m3core/tests/thread/I386_DARWIN/threadtest 
> Reading symbols for shared libraries ++. done
> 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
> ..........laziest thread is 1/0/0 (tests: read 0/0/0 fork 1/1/1 alloc 0/0/0 lock 0/0/0)
> .........pthread_mutex_destroy:EBUSY (0)
> .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:
> ***    An array subscript was out of range.
> ***    file "../src/runtime/common/RTCollector.m3", line 418
> ***
> 
> 
> Program received signal SIGABRT, Aborted.
> 0x9385f44e in __semwait_signal ()
> (gdb) bt
> #0  0x9385f44e in __semwait_signal ()
> #1  0x9388a3e6 in _pthread_cond_wait ()
> #2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
> #3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299133562.375689) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
> #4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
> #5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
> #6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
> #7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
> #8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
> #9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
> #10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16
> 
> 
> (gdb) thread apply all bt
> 
> Thread 13 (process 86311 thread 0x2a03):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #4  0x00003ed8 in Main__LApply (cl=0x9557d8) at ../src/Main.m3:290
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01130) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01130) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 12 (process 86311 thread 0x1f03):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #4  0x00003ed8 in Main__LApply (cl=0x9557a0) at ../src/Main.m3:290
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa01080) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa01080) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 11 (process 86311 thread 0x1e03):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa008f0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x0004503c in ThreadPThread__LockMutex (m=0x9542b8) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #4  0x00003ed8 in Main__LApply (cl=0x955768) at ../src/Main.m3:290
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 10 (process 86311 thread 0x1d03):
> #0  0x93934136 in __semwait_signal_nocancel ()
> #1  0x93933d1b in nanosleep$NOCANCEL$UNIX2003 ()
> #2  0x9392d013 in usleep$NOCANCEL$UNIX2003 ()
> #3  0x93944685 in abort ()
> #4  0x0004b5e6 in Cstdlib__abort () at ../src/C/Common/CstdlibC.c:21
> #5  0x000434dd in RTOS__Crash () at ../src/runtime/POSIX/RTOS.m3:20
> #6  0x0003d51f in RTProcess__Crash (msg=0x0) at ../src/runtime/common/RTProcess.m3:65
> #7  0x0003b9d3 in RTError__EndError (crash=1 '\001') at ../src/runtime/common/RTError.m3:118
> #8  0x0003b6e6 in RTError__MsgS (file=0x7f441, line=418, msgA=0x800e8, msgB=0x7d250, msgC=0x800e8) at ../src/runtime/common/RTError.m3:40
> #9  0x0003bdc7 in RTException__Crash (a=0xb0490a64, raises=0 '\0', rte=0x7d100) at ../src/runtime/common/RTException.m3:79
> #10 0x0003bb21 in RTException__DefaultBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:39
> #11 0x0003ba7c in RTException__InvokeBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
> #12 0x00043ca5 in RTException__Raise (act=0xb0490a64) at ../src/runtime/ex_frame/RTExFrame.m3:85
> #13 0x0003bbb4 in RTException__DefaultBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:47
> #14 0x0003ba7c in RTException__InvokeBackstop (a=0xb0490a64, raises=0 '\0') at ../src/runtime/common/RTException.m3:25
> #15 0x00043ca5 in RTException__Raise (act=0xb0490a64) at ../src/runtime/ex_frame/RTExFrame.m3:85
> #16 0x0002b102 in RTHooks__ReportFault (module=0x70f80, info=13378) at ../src/runtime/common/RTHooks.m3:111
> #17 0x000394c5 in _m3_fault (arg=13378) at ../src/runtime/common/RTCollector.m3:393
> #18 0x0002fdd2 in RTCollector__Move (self=0xb3000c, cp=0x9a0014) at ../src/runtime/common/RTCollector.m3:418
> #19 0x0002e503 in RTHeapMap__Walk (x=0x9a0014, pc=0x79928, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:202
> #20 0x0002dc9c in RTHeapMap__DoWalkRef (t=0x6de54, a=0x9a0014, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:62
> #21 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e3f4, a=0x9a000c, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:57
> #22 0x0002dc77 in RTHeapMap__DoWalkRef (t=0x6e508, a=0x9a000c, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:57
> #23 0x0002dc2e in RTHeapMap__WalkRef (h=0x9a0008, v=0xb3000c) at ../src/runtime/common/RTHeapMap.m3:47
> #24 0x00032279 in RTCollector__CleanBetween (h=0x9a0008, he=0x9b0000, clean=0 '\0') at ../src/runtime/common/RTCollector.m3:1091
> #25 0x00032098 in RTCollector__CleanPage (page=0x9a0000) at ../src/runtime/common/RTCollector.m3:1064
> #26 0x00031798 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885
> #27 0x00030e75 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720
> #28 0x00030a97 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654
> #29 0x0002cb85 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00f64) at ../src/runtime/common/RTAllocator.m3:367
> #30 0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:296
> #31 0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb0490e78) at ../src/runtime/common/RTAllocator.m3:143
> #32 0x00003b5f in Main__AApply (cl=0x9556f8) at ../src/Main.m3:260
> #33 0x00046ee2 in ThreadPThread__RunThread (me=0xa00f20) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #34 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00f20) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #35 0x93889155 in _pthread_start ()
> #36 0x93889012 in thread_start ()
> 
> Thread 9 (process 86311 thread 0x1c03):
> #0  0x938582a2 in semaphore_wait_trap ()
> #1  0x9385fd92 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00eb4) at ../src/runtime/common/RTAllocator.m3:365
> #5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:296
> #6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb040ee78) at ../src/runtime/common/RTAllocator.m3:143
> #7  0x00003b5f in Main__AApply (cl=0x9556c0) at ../src/Main.m3:260
> #8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00e70) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00e70) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #10 0x93889155 in _pthread_start ()
> #11 0x93889012 in thread_start ()
> 
> Thread 8 (process 86311 thread 0x1b03):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=4108, dataAlignment=4, thread=0xa00e04) at ../src/runtime/common/RTAllocator.m3:365
> #5  0x0002c5d6 in RTAllocator__GetOpenArray (def=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:296
> #6  0x0002ba2d in RTHooks__AllocateOpenArray (defn=0x6fe30, s=0xb038ce78) at ../src/runtime/common/RTAllocator.m3:143
> #7  0x00003b5f in Main__AApply (cl=0x955688) at ../src/Main.m3:260
> #8  0x00046ee2 in ThreadPThread__RunThread (me=0xa00dc0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #9  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00dc0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #10 0x93889155 in _pthread_start ()
> #11 0x93889012 in thread_start ()
> 
> Thread 7 (process 86311 thread 0x1a03):
> #0  0x9389c856 in __wait4 ()
> #1  0x9389c847 in waitpid$UNIX2003 ()
> #2  0x0004b222 in Uexec__waitpid (i=86384, j=0xb030ad9c, k=0) at ../src/unix/Common/Uexec.c:67
> #3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86384, status=0xb030ad9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
> #4  0x0000d66a in Process__Wait (p=0xb00018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
> #5  0x00003719 in Main__FApply (cl=0x955618) at ../src/Main.m3:230
> #6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00d60) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00d60) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #8  0x93889155 in _pthread_start ()
> #9  0x93889012 in thread_start ()
> 
> Thread 6 (process 86311 thread 0x1903):
> #0  0x9389c856 in __wait4 ()
> #1  0x9389c847 in waitpid$UNIX2003 ()
> #2  0x0004b222 in Uexec__waitpid (i=86385, j=0xb0288d9c, k=0) at ../src/unix/Common/Uexec.c:67
> #3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86385, status=0xb0288d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
> #4  0x0000d66a in Process__Wait (p=0xbd000c) at ../src/os/POSIX/ProcessPosixCommon.m3:275
> #5  0x00003719 in Main__FApply (cl=0x9555e0) at ../src/Main.m3:230
> #6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00b70) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00b70) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #8  0x93889155 in _pthread_start ()
> #9  0x93889012 in thread_start ()
> 
> Thread 5 (process 86311 thread 0x1803):
> #0  0x9389c856 in __wait4 ()
> #1  0x9389c847 in waitpid$UNIX2003 ()
> #2  0x0004b222 in Uexec__waitpid (i=86386, j=0xb0206d9c, k=0) at ../src/unix/Common/Uexec.c:67
> #3  0x00047d6e in SchedulerPosix__WaitProcess (pid=86386, status=0xb0206d9c) at ../src/thread/PTHREAD/ThreadPThread.m3:657
> #4  0x0000d66a in Process__Wait (p=0x9d0018) at ../src/os/POSIX/ProcessPosixCommon.m3:275
> #5  0x00003719 in Main__FApply (cl=0x9555a8) at ../src/Main.m3:230
> #6  0x00046ee2 in ThreadPThread__RunThread (me=0xa00ac0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #7  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00ac0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #8  0x93889155 in _pthread_start ()
> #9  0x93889012 in thread_start ()
> 
> Thread 4 (process 86311 thread 0x1103):
> #0  0x9385fb99 in pthread_mutex_lock ()
> #1  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0xa00c20) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #2  0x0004503c in ThreadPThread__LockMutex (m=0xb6000c) at ../src/thread/PTHREAD/ThreadPThread.m3:119
> #3  0x0000e060 in Rd__GetChar (rd=0xb6000c) at ../src/rw/Rd.m3:33
> #4  0x000030b5 in Main__RApply (cl=0x955538) at ../src/Main.m3:177
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa009d0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 3 (process 86311 thread 0x117):
> #0  0x93859304 in pthread_getspecific ()
> #1  0x0004a529 in ThreadPThread__GetActivation () at ../src/thread/PTHREAD/ThreadPThreadC.c:309
> #2  0x00049f52 in RTHooks__PushEFrame (frame=0xb0102d20) at ../src/thread/PTHREAD/ThreadPThread.m3:1385
> #3  0x0000e07b in Rd__GetChar (rd=0x99000c) at ../src/rw/Rd.m3:33
> #4  0x000030b5 in Main__RApply (cl=0x955500) at ../src/Main.m3:177
> #5  0x00046ee2 in ThreadPThread__RunThread (me=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #6  0x00046bd7 in ThreadPThread__ThreadBase (param=0xa00920) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #7  0x93889155 in _pthread_start ()
> #8  0x93889012 in thread_start ()
> 
> Thread 2 (process 86311 thread 0x313):
> #0  0x938582ae in semaphore_wait_signal_trap ()
> #1  0x9385fd85 in pthread_mutex_lock ()
> #2  0x0004aa18 in ThreadPThread__pthread_mutex_lock (mutex=0x742a0) at ../src/thread/PTHREAD/ThreadPThreadC.c:487
> #3  0x00049c56 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1334
> #4  0x0002cb80 in RTAllocator__AllocTraced (dataSize=12, dataAlignment=4, thread=0xa00834) at ../src/runtime/common/RTAllocator.m3:365
> #5  0x0002bf13 in RTAllocator__GetTracedObj (def=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:224
> #6  0x0002b98a in RTHooks__AllocateTracedObj (defn=0x6d1b4) at ../src/runtime/common/RTAllocator.m3:122
> #7  0x00008eeb in FilePosix__New (fd=5, ds=1) at ../src/os/POSIX/FilePosix.m3:63
> #8  0x0000a4eb in FS__OpenFileReadonly (pn=0x775b8) at ../src/os/POSIX/FSPosix.m3:182
> #9  0x00014dfa in FileRd__Open (p=0x775b8) at ../src/rw/FileRd.m3:16
> #10 0x00003046 in Main__RApply (cl=0x9554c8) at ../src/Main.m3:174
> #11 0x00046ee2 in ThreadPThread__RunThread (me=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:450
> #12 0x00046bd7 in ThreadPThread__ThreadBase (param=0xa007f0) at ../src/thread/PTHREAD/ThreadPThread.m3:422
> #13 0x93889155 in _pthread_start ()
> #14 0x93889012 in thread_start ()
> 
> Thread 1 (process 86311 local thread 0x2e03):
> #0  0x9385f44e in __semwait_signal ()
> #1  0x9388a3e6 in _pthread_cond_wait ()
> #2  0x938af9f8 in pthread_cond_timedwait$UNIX2003 ()
> #3  0x0004a99a in ThreadPThread__pthread_cond_timedwait (cond=0xa003e0, mutex=0xa003b0, m3timeout=1299133562.375689) at ../src/thread/PTHREAD/ThreadPThreadC.c:451
> #4  0x000477a0 in ThreadPThread__XPause (self=0xa00350, n=1, alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:552
> #5  0x00047877 in Thread__Pause (n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:567
> #6  0x00005d5f in Main_M3 (mode=1) at ../src/Main.m3:494
> #7  0x0003ab84 in RTLinker__RunMainBody (m=0x6c020) at ../src/runtime/common/RTLinker.m3:406
> #8  0x00039fb9 in RTLinker__AddUnitI (m=0x6c020) at ../src/runtime/common/RTLinker.m3:113
> #9  0x0003a03d in RTLinker__AddUnit (b=0x4a6e) at ../src/runtime/common/RTLinker.m3:122
> #10 0x00002d32 in main (argc=1, argv=0xbffff8d8, envp=0xbffff8e0) at _m3main.c:16
> 
> 
> 
> 
> 
> 
> 
> From: jay.krell at cornell.edu
> To: dabenavidesd at yahoo.es; rcolebur at scires.com; m3devel at elegosoft.com
> Subject: RE: [M3devel] results of threadtest program on Windows7
> Date: Thu, 3 Mar 2011 02:46:39 +0000
> 
> There is probably a bug in RTCollector.m3 or RTAllocator.m3.
> 
>  - Jay
> 
> Date: Thu, 3 Mar 2011 02:27:58 +0000
> From: dabenavidesd at yahoo.es
> Subject: Re: [M3devel] results of threadtest program on Windows7
> To: rcolebur at scires.com; m3devel at elegosoft.com; jay.krell at cornell.edu
> 
> Hi all:
> I would doubt but there could be some source of problem in smp on the Win32 platform, since there was a SPINE implementation on an intelligent NIC with 2 embedded MIPS CPUs, perhaps this was just a driver RT but it was for real time and in such a case there should be no problem besides that of the scheduling policy, but thinking how about linking MS Win2k R is a kind of crazy not to believe there was some synchronization with CPU board threads and that component threading at some point I believe.
> 
> Even more in embedded systems, there was a MPU implementation of it in 80186 a decade ago,  perhaps would be good to have a look of their Thread interface implementation it might be seem interesting if so.
> 
> But in any case there should be plenty of ways of implementing the threading tests incrementally of number of threads, besides you may want to check some uniprocessors with hyperThreading technology (sort of thread physical divisions inside the cpu), they are presented to OS as 2 smp processors, it could be interesting, I remember to test  time ago in this machines and anything weird happened, but quite time ago with ThreadPthread LINUXLIBC6 systems with normally distributed programs.
>  
> What about results in Win2k ?
> Thanks in advance
> 
> --- El mi?, 2/3/11, Jay K <jay.krell at cornell.edu> escribi?:
> 
> De: Jay K <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] results of threadtest program on Windows7
> Para: rcolebur at scires.com, "m3devel" <m3devel at elegosoft.com>
> Fecha: mi?rcoles, 2 de marzo, 2011 20:17
> 
> Even with the change I made PutCard to PutInt?
> That's the only failure I've seen.
> I'll try on a non-virtual dual-proc machine later.
>  
> Thanks,
>  - Jay
>  
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Wed, 2 Mar 2011 19:42:47 -0500
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Yes, it fails more often than it runs for me.
> Regards,
> Randy
>  
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Tuesday, March 01, 2011 5:59 AM
> To: Mika Nystrom; Coleburn, Randy
> Cc: m3devel
> Subject: RE: [M3devel] results of threadtest program on Windows7
>  
> I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
> I've run it just a few times now. One single and dual processor virtual machines.
> Randy, has it failed many times for you?
> 
>  - Jay
> 
> > To: rcolebur at SCIRES.COM
> > Date: Sun, 27 Feb 2011 15:11:25 -0800
> > From: mika at async.caltech.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] results of threadtest program on Windows7
> > 
> > Ah, it just doesn't check command-line arguments that carefully.
> > 
> > I think what you did is equivalent to "-tests STD".
> > 
> > Mika
> > 
> > "Coleburn, Randy" writes:
> > >Mika:
> > >
> > >No change with "-tests POSIX".
> > >
> > >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> > >ptions are, and I typed "threadtest -help" rather than reading the code.
> > >
> > >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> > >d it again and it ran to completion. Something seems non-deterministic her=
> > >e. See below.
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >.
> > >
> > >***
> > >*** runtime error:
> > >*** Attempt to reference an illegal memory location.
> > >*** pc =3D 0x77762262
> > >***
> > >
> > >Stack trace:
> > > FP PC Procedure
> > >--------- --------- -------------------------------
> > > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> > >3
> > > 0xcdf9c0 0x77762262 <???>
> > > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> > >3
> > > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> > >.m3
> > > 0xcdfb80 0x76543677 <???>
> > > 0xcdfbc0 0x77779f02 <???>
> > >......... ......... ... more frames ...
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >All tests complete. Congratulations.
> > >
> > >Regards,
> > >Randy Coleburn
> > >
> > >-----Original Message-----
> > >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> > >Sent: Sunday, February 27, 2011 3:30 PM
> > >To: Coleburn, Randy
> > >Cc: m3devel at elegosoft.com
> > >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> > >
> > >Hi Randy,
> > >
> > >You can try it with -tests POSIX as well.
> > >
> > >I find on user threads it runs very slowly (but it does run) because of how=
> > > unfair
> > >the thread scheduler is.
> > >
> > >Next step might be to whittle down the tests and see if you can get a failu=
> > >re with
> > >a single test running and -n 2. That would likely be the simplest scenario=
> > > to
> > >start further debugging from.
> > >
> > > Mika
> > >
> > >"Coleburn, Randy" writes:
> > >>Mika et al:
> > >>
> > >>Thought I would try something else.
> > >>
> > >>I took the sources of your thread test program to an older XP machine that=
> > > =3D
> > >>has CM3 circa August 2008. This is the machine and implementation I used =
> > >w=3D
> > >>hen building a major project I did a couple years back.
> > >>
> > >>The thread test program does indeed build on this old system, but when I r=
> > >u=3D
> > >>n it, I get different results than with the latest HEAD branch code. =3D20
> > >>
> > >>After it prints "running...printing oldest/median age/newest", on the next=
> > > =3D
> > >>line I get two periods ".." and now the program seems hung. I'll let it "=
> > >r=3D
> > >>un" for a few more minutes to see if anything else happens before killing =
> > >i=3D
> > >>t.
> > >>
> > >>At least we don't get the subscript and assertion failures on this older C=
> > >M=3D
> > >>3 platform.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>
> > >>-----Original Message-----
> > >>From: Coleburn, Randy=3D20
> > >>Sent: Sunday, February 27, 2011 2:09 PM
> > >>To: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7
> > >>
> > >>Mika:
> > >>
> > >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> > >>
> > >>Here is what happens now when I run your threadtest program on Windows 7.
> > >>
> > >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> > >r=3D
> > >>k
> > >>Writing file...done
> > >>Creating read threads...done
> > >>Creating nxread threads...done
> > >>Creating tryexcept threads...done
> > >>Creating forktoomuch threads...done
> > >>Creating alloc threads...done
> > >>Creating creat threads...done
> > >>Creating lock threads...done
> > >>running...printing oldest/median age/newest
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** An array subscript was out of range.
> > >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> > >>***
> > >>
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** <*ASSERT*> failed.
> > >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> > >>***
> > >>
> > >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> > >>
> > >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> > >.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>-----Original Message-----
> > >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> > >>Sent: Saturday, February 26, 2011 12:55 PM
> > >>To: Coleburn, Randy
> > >>Cc: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> > >>
> > >>Hi Randy,
> > >>
> > >>Hm yes it looks like my Windows programming skills leave something
> > >>to be desired.
> > >>
> > >>You can run the thread tester while skipping a test as follows
> > >>
> > >> threadtest -tests ALL,-fork
> > >>
> > >>(for instance)
> > >>
> > >>if you just run=3D20
> > >>
> > >> threadtest -sadfassdaf
> > >>
> > >>it'll print the tests that are available.
> > >>
> > >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> > >>Can you give me a very brief description of what you did to install Modula=
> > >-=3D
> > >>3
> > >>on this system?
> > >>
> > >> Mika
> > >>
> > >>"Coleburn, Randy" writes:
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>
> > >>>Mika:
> > >>>
> > >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> > >>>
> > >>>So, I ran your threadtest program.
> > >>>
> > >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> > >e=3D
> > >>p=3D3D
> > >>>eating "ERROR FApply" messages.
> > >>>
> > >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > >>>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
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>***
> > >>>*** runtime error:
> > >>>*** An enumeration or subrange value was out of range.
> > >>>*** file "..\src\Main.m3", line 340
> > >>>***
> > >>>
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>Stack trace:
> > >>> FP PC Procedure
> > >>>--------- --------- -------------------------------
> > >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> > >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> > >>>
> > >>>Regards,
> > >>>Randy Coleburn
> > >>>
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/html; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110303/93b23a6e/attachment-0002.html>

From rcolebur at SCIRES.COM  Thu Mar  3 19:47:11 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 3 Mar 2011 13:47:11 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>
	<COL101-W4726257303F22627175774E6C30@phx.gbl>
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>

Tony:

Here are results using the checks you suggested.  These are running on Windows 7.

*         @M3paranoidgc

*         @M3nogc

*         @M3noincremental

*         @M3nogenerational

As you can see below, the only one where the program ran to completion is when using M3nogenerational; However, this doesn't mean it solves the problem, because I ran a second time with this option (see below) and it crashed.

When using M3nogc, looks like we run out of memory.  The computer I am using for these tests is a Dell Latitude 6510 with 4GB RAM and a system-managed pagefile size.

Hope these test runs give some insight into the problem.

Let me know what else I can do to help.

Regards,
Randy

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc
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
.

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0xa8f9bc = RefSanityCheck + 0x2c in ..\src\runtime\common\RTCollector.m3
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogc
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
.....

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.
***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x1faf970   0xaaa7b2  Raise + 0x3f in ..\src\runtime\common\RuntimeError.m3
0x1faf990   0xa86902  AllocateOpenArray + 0x33 in ..\src\runtime\common\RTAllocator.m3
0x1faf9ec   0xa61ab3  AApply + 0x46 in ..\src\Main.m3
0x1fafa28   0xa8976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
0x1fafa34  0x75c43677  <???>
0x1fafa74  0x77b39f02  <???>
.........  .........  ... more frames ...

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3noincremental
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
.

***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\runtime\common\RTCollector.m3", line 418
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogenerational
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
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
All tests complete.  Congratulations.

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogenerational
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
.

***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\runtime\common\RTCollector.m3", line 418
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***


From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Thursday, March 03, 2011 10:39 AM
To: Coleburn, Randy
Cc: m3devel
Subject: Re: [M3devel] results of threadtest program on Windows7

Both of these errors indicate major breakdown in the garbage collector.
It could be that the damage was done much earlier than the crash.
To check for earlier damage please run with @M3paranoidgc.
Also, you could try running with @M3nogc, or @M3noincremental, or @M3nogenerational, to see if any of them trigger the errors.

On Mar 2, 2011, at 8:36 PM, Coleburn, Randy wrote:


Jay:

Ok, I just updated from HEAD and got your latest change to thread test program.

Here are two invocations, back to back, each failing in different ways.

The second one repeats the last error message ad infinitum until you press CNTRL-C to abort.  But note, several different errors reported earlier.

Regards,
Randy

C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cm3
--- building in NT386 ---

ignoring ..\src\m3overrides

new source -> compiling Main.m3
new "Main.mo" -> linking threadtest.exe

C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cd NT386

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
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


***
*** runtime error:
***    <*ASSERT*> failed..
***    file "..\src\runtime\common\RTCollector.m3", line 1086
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0xddfaf0  0x123dffb  CleanBetween + 0x47 in ..\src\runtime\common\RTCollector.m3
0xddfb34  0x1241870  CheckLoadTracedRef + 0xc5 in ..\src\runtime\common\RTCollector.m3
0xddfb74  0x121683c  Init + 0x95 in ..\src\rw\FileRd.m3
0xddfba0  0x121679d  Open + 0x4d in ..\src\rw\FileRd.m3
0xddfcd8  0x1211288  RApply + 0x78 in ..\src\Main.m3
0xddfd14  0x123976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
0xddfd20  0x76d53677  <???>
0xddfd60  0x773c9f02  <???>
.........  .........  ... more frames ...

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
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
.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0x12ec5ad = Move + 0x50 in ..\src\runtime\common\RTCollector.m3
***



***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***



***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

From: jayk123 at hotmail.com<mailto:jayk123 at hotmail.com> [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Wednesday, March 02, 2011 8:18 PM
To: Coleburn, Randy; m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7

Even with the change I made PutCard to PutInt?
That's the only failure I've seen.
I'll try on a non-virtual dual-proc machine later.

Thanks,
 - Jay

________________________________
From: rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>
To: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7
Yes, it fails more often than it runs for me.
Regards,
Randy

From: jayk123 at hotmail.com<mailto:jayk123 at hotmail.com> [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7

I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu<mailto:mika at async.caltech.edu>
> CC: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> Subject: Re: [M3devel] results of threadtest program on Windows7
>
> Ah, it just doesn't check command-line arguments that carefully.
>
> I think what you did is equivalent to "-tests STD".
>
> Mika
>
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- --------- -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
> >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110303/6613e6a9/attachment-0002.html>

From mika at async.caltech.edu  Thu Mar  3 20:11:52 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Thu, 03 Mar 2011 11:11:52 -0800
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv> 
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>
	<COL101-W4726257303F22627175774E6C30@phx.gbl>
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>
Message-ID: <20110303191152.738111A2078@async.async.caltech.edu>

"Coleburn, Randy" writes:
>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE526EBEatlex02srv_
...
>When using M3nogc, looks like we run out of memory.  The computer I am usin=
>g for these tests is a Dell Latitude 6510 with 4GB RAM and a system-managed=
> pagefile size.

Well some (most) of the tests do allocate memory so perhaps that's not so surprising.

You might try it with -alloc , but creat and fork I'm sure also allocate memory on the
heap.

     Mika


From hosking at cs.purdue.edu  Thu Mar  3 20:19:17 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 3 Mar 2011 14:19:17 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>
	<COL101-W4726257303F22627175774E6C30@phx.gbl>
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>
Message-ID: <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>

Can you try with each of the following?

@M3paranoidgc @M3noincremental @M3nogenerational

@M3paranoidgc @M3noincremental

@M3paranoidgc @M3nogenerational

Also, if possible, can you print the stack dump immediately before the assertion error is printed out?  That means setting a breakpoint on the Raise function that reports assertion failures.  I think it is RTHooks__Raise.  Or perhaps RTHooks__ReportFault.  I don't recall exactly.


On Mar 3, 2011, at 1:47 PM, Coleburn, Randy wrote:

> Tony:
>  
> Here are results using the checks you suggested.  These are running on Windows 7.
> ?         @M3paranoidgc
> ?         @M3nogc
> ?         @M3noincremental
> ?         @M3nogenerational
>  
> As you can see below, the only one where the program ran to completion is when using M3nogenerational; However, this doesn?t mean it solves the problem, because I ran a second time with this option (see below) and it crashed.
>  
> When using M3nogc, looks like we run out of memory.  The computer I am using for these tests is a Dell Latitude 6510 with 4GB RAM and a system-managed pagefile size.
>  
> Hope these test runs give some insight into the problem. 
>  
> Let me know what else I can do to help.
>  
> Regards,
> Randy
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc
> 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
> .
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
> ***    pc = 0xa8f9bc = RefSanityCheck + 0x2c in ..\src\runtime\common\RTCollector.m3
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogc
> 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
> .....
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
> ***    file "..\src\runtime\common\RuntimeError.m3", line 63
> ***
>  
> ***    file "..\src\runtime\common\RuntimeError.m3", line 63
> ***
>  
> ***    file "..\src\runtime\common\RuntimeError.m3", line 63
> ***
>  
> ***    file "..\src\runtime\common\RuntimeError.m3", line 63
> ***
>  
> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0x1faf970   0xaaa7b2  Raise + 0x3f in ..\src\runtime\common\RuntimeError.m3
> 0x1faf990   0xa86902  AllocateOpenArray + 0x33 in ..\src\runtime\common\RTAllocator.m3
> 0x1faf9ec   0xa61ab3  AApply + 0x46 in ..\src\Main.m3
> 0x1fafa28   0xa8976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
> 0x1fafa34  0x75c43677  <???>
> 0x1fafa74  0x77b39f02  <???>
> .........  .........  ... more frames ...
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3noincremental
> 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
> .
>  
> ***
> *** runtime error:
> ***    An array subscript was out of range.
> ***    file "..\src\runtime\common\RTCollector.m3", line 418
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogenerational
> 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
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
> All tests complete.  Congratulations.
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogenerational
> 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
> .
>  
> ***
> *** runtime error:
> ***    An array subscript was out of range.
> ***    file "..\src\runtime\common\RTCollector.m3", line 418
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Thursday, March 03, 2011 10:39 AM
> To: Coleburn, Randy
> Cc: m3devel
> Subject: Re: [M3devel] results of threadtest program on Windows7
>  
> Both of these errors indicate major breakdown in the garbage collector.
> It could be that the damage was done much earlier than the crash.
> To check for earlier damage please run with @M3paranoidgc.
> Also, you could try running with @M3nogc, or @M3noincremental, or @M3nogenerational, to see if any of them trigger the errors.
>  
> 
> On Mar 2, 2011, at 8:36 PM, Coleburn, Randy wrote:
> 
> 
> Jay:
>  
> Ok, I just updated from HEAD and got your latest change to thread test program.
>  
> Here are two invocations, back to back, each failing in different ways. 
>  
> The second one repeats the last error message ad infinitum until you press CNTRL-C to abort.  But note, several different errors reported earlier.
>  
> Regards,
> Randy
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cm3
> --- building in NT386 ---
>  
> ignoring ..\src\m3overrides
>  
> new source -> compiling Main.m3
> new "Main.mo" -> linking threadtest.exe
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cd NT386
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> 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
>  
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed..
> ***    file "..\src\runtime\common\RTCollector.m3", line 1086
> ***
>  
> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0xddfaf0  0x123dffb  CleanBetween + 0x47 in ..\src\runtime\common\RTCollector.m3
> 0xddfb34  0x1241870  CheckLoadTracedRef + 0xc5 in ..\src\runtime\common\RTCollector.m3
> 0xddfb74  0x121683c  Init + 0x95 in ..\src\rw\FileRd.m3
> 0xddfba0  0x121679d  Open + 0x4d in ..\src\rw\FileRd.m3
> 0xddfcd8  0x1211288  RApply + 0x78 in ..\src\Main.m3
> 0xddfd14  0x123976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
> 0xddfd20  0x76d53677  <???>
> 0xddfd60  0x773c9f02  <???>
> .........  .........  ... more frames ...
>  
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> 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
> .
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
> ***    pc = 0x12ec5ad = Move + 0x50 in ..\src\runtime\common\RTCollector.m3
> ***
>  
>  
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
>  
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Wednesday, March 02, 2011 8:18 PM
> To: Coleburn, Randy; m3devel
> Subject: RE: [M3devel] results of threadtest program on Windows7
>  
> Even with the change I made PutCard to PutInt?
> That's the only failure I've seen.
> I'll try on a non-virtual dual-proc machine later.
>  
> Thanks,
>  - Jay
>  
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Wed, 2 Mar 2011 19:42:47 -0500
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Yes, it fails more often than it runs for me.
> Regards,
> Randy
>  
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Tuesday, March 01, 2011 5:59 AM
> To: Mika Nystrom; Coleburn, Randy
> Cc: m3devel
> Subject: RE: [M3devel] results of threadtest program on Windows7
>  
> I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
> I've run it just a few times now. One single and dual processor virtual machines.
> Randy, has it failed many times for you?
> 
>  - Jay
> 
> > To: rcolebur at SCIRES.COM
> > Date: Sun, 27 Feb 2011 15:11:25 -0800
> > From: mika at async.caltech.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] results of threadtest program on Windows7
> > 
> > Ah, it just doesn't check command-line arguments that carefully.
> > 
> > I think what you did is equivalent to "-tests STD".
> > 
> > Mika
> > 
> > "Coleburn, Randy" writes:
> > >Mika:
> > >
> > >No change with "-tests POSIX".
> > >
> > >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> > >ptions are, and I typed "threadtest -help" rather than reading the code.
> > >
> > >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> > >d it again and it ran to completion. Something seems non-deterministic her=
> > >e. See below.
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >.
> > >
> > >***
> > >*** runtime error:
> > >*** Attempt to reference an illegal memory location.
> > >*** pc =3D 0x77762262
> > >***
> > >
> > >Stack trace:
> > > FP PC Procedure
> > >--------- --------- -------------------------------
> > > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> > >3
> > > 0xcdf9c0 0x77762262 <???>
> > > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> > >3
> > > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> > >.m3
> > > 0xcdfb80 0x76543677 <???>
> > > 0xcdfbc0 0x77779f02 <???>
> > >......... ......... ... more frames ...
> > >
> > >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> > >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
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > > lock 0/0/0)
> > >All tests complete. Congratulations.
> > >
> > >Regards,
> > >Randy Coleburn
> > >
> > >-----Original Message-----
> > >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> > >Sent: Sunday, February 27, 2011 3:30 PM
> > >To: Coleburn, Randy
> > >Cc: m3devel at elegosoft.com
> > >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> > >
> > >Hi Randy,
> > >
> > >You can try it with -tests POSIX as well.
> > >
> > >I find on user threads it runs very slowly (but it does run) because of how=
> > > unfair
> > >the thread scheduler is.
> > >
> > >Next step might be to whittle down the tests and see if you can get a failu=
> > >re with
> > >a single test running and -n 2. That would likely be the simplest scenario=
> > > to
> > >start further debugging from.
> > >
> > > Mika
> > >
> > >"Coleburn, Randy" writes:
> > >>Mika et al:
> > >>
> > >>Thought I would try something else.
> > >>
> > >>I took the sources of your thread test program to an older XP machine that=
> > > =3D
> > >>has CM3 circa August 2008. This is the machine and implementation I used =
> > >w=3D
> > >>hen building a major project I did a couple years back.
> > >>
> > >>The thread test program does indeed build on this old system, but when I r=
> > >u=3D
> > >>n it, I get different results than with the latest HEAD branch code. =3D20
> > >>
> > >>After it prints "running...printing oldest/median age/newest", on the next=
> > > =3D
> > >>line I get two periods ".." and now the program seems hung. I'll let it "=
> > >r=3D
> > >>un" for a few more minutes to see if anything else happens before killing =
> > >i=3D
> > >>t.
> > >>
> > >>At least we don't get the subscript and assertion failures on this older C=
> > >M=3D
> > >>3 platform.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>
> > >>-----Original Message-----
> > >>From: Coleburn, Randy=3D20
> > >>Sent: Sunday, February 27, 2011 2:09 PM
> > >>To: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7
> > >>
> > >>Mika:
> > >>
> > >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> > >>
> > >>Here is what happens now when I run your threadtest program on Windows 7.
> > >>
> > >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> > >r=3D
> > >>k
> > >>Writing file...done
> > >>Creating read threads...done
> > >>Creating nxread threads...done
> > >>Creating tryexcept threads...done
> > >>Creating forktoomuch threads...done
> > >>Creating alloc threads...done
> > >>Creating creat threads...done
> > >>Creating lock threads...done
> > >>running...printing oldest/median age/newest
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** An array subscript was out of range.
> > >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> > >>***
> > >>
> > >>
> > >>
> > >>***
> > >>*** runtime error:
> > >>*** <*ASSERT*> failed.
> > >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> > >>***
> > >>
> > >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> > >>
> > >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> > >.
> > >>
> > >>Regards,
> > >>Randy Coleburn
> > >>
> > >>-----Original Message-----
> > >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> > >>Sent: Saturday, February 26, 2011 12:55 PM
> > >>To: Coleburn, Randy
> > >>Cc: m3devel at elegosoft.com
> > >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> > >>
> > >>Hi Randy,
> > >>
> > >>Hm yes it looks like my Windows programming skills leave something
> > >>to be desired.
> > >>
> > >>You can run the thread tester while skipping a test as follows
> > >>
> > >> threadtest -tests ALL,-fork
> > >>
> > >>(for instance)
> > >>
> > >>if you just run=3D20
> > >>
> > >> threadtest -sadfassdaf
> > >>
> > >>it'll print the tests that are available.
> > >>
> > >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> > >>Can you give me a very brief description of what you did to install Modula=
> > >-=3D
> > >>3
> > >>on this system?
> > >>
> > >> Mika
> > >>
> > >>"Coleburn, Randy" writes:
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>
> > >>>Mika:
> > >>>
> > >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> > >>>
> > >>>So, I ran your threadtest program.
> > >>>
> > >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> > >e=3D
> > >>p=3D3D
> > >>>eating "ERROR FApply" messages.
> > >>>
> > >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> > >>>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
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>***
> > >>>*** runtime error:
> > >>>*** An enumeration or subrange value was out of range.
> > >>>*** file "..\src\Main.m3", line 340
> > >>>***
> > >>>
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> > >ste=3D
> > >>m c=3D3D
> > >>>annot find the file specified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>.
> > >>>.
> > >>>.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> > >ile=3D
> > >> sp=3D3D
> > >>>ecified.
> > >>>Stack trace:
> > >>> FP PC Procedure
> > >>>--------- --------- -------------------------------
> > >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> > >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> > >>>
> > >>>Regards,
> > >>>Randy Coleburn
> > >>>
> > >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> > >>>Content-Type: text/html; charset=3D3D"us-ascii"
> > >>>Content-Transfer-Encoding: quoted-printable
> > >>>
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110303/5d0b2362/attachment-0002.html>

From hendrik at topoi.pooq.com  Fri Mar  4 17:19:14 2011
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Fri, 4 Mar 2011 11:19:14 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <571065.83147.qm@web29715.mail.ird.yahoo.com>
References: <COL101-W3670B74A99994199607C6BE6C00@phx.gbl>
	<571065.83147.qm@web29715.mail.ird.yahoo.com>
Message-ID: <20110304161914.GC8263@topoi.pooq.com>

On Wed, Mar 02, 2011 at 09:31:41PM +0000, Daniel Alejandro Benavides D. wrote:
> Hi all:
> yes, but technically you could insert some empty chips slots on the same wafer but in cases of blade systems I'm sure you can, just don't know how much about something like plug-and-play with that.
> Thanks in advance
> 
> --- El mar, 1/3/11, Jay K <jay.krell at cornell.edu> escribi?:
> 
> De: Jay K <jay.krell at cornell.edu>
> Asunto: RE: [M3devel] results of threadtest program on Windows7
> Para: dabenavidesd at yahoo.es, "Mika Nystrom" <mika at async.caltech.edu>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: martes, 1 de marzo, 2011 22:11
> 
> 
> 
> 
> I have still have mostly uniprocessors (though busy selling stuff off...)
> 
> ? I do have a MacBook Pro and Dell laptop with 2 processors each though.
> 
> ? It is that MacBook Pro where I can consistently get Darwin to fail, and a?1 and 2 proc Windows virtual machine on the MacBook Pro?that consistently works.
> 
> ? While Modula-3 user threads never run anything truly 
>   concurrently, i.e. on multiple prcoessors, there should 
>   still be almost arbitrary preemption.

But you won't get parallel execution of instructions: 
user threads can at most switch threads between instructions.  
With two actual processors, it's possible to get races within 
the execution of a single instruction on each processor.

-- hendrik


From rcolebur at SCIRES.COM  Sat Mar  5 04:07:39 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 4 Mar 2011 22:07:39 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>
	<COL101-W4726257303F22627175774E6C30@phx.gbl>
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>
	<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>

Tony:

I do not have a debugger built for Windows, so I can't do the breakpoint yet.  I'll check into trying to build the debugger, but last time I tried this (a few years ago) it didn't work.  I used m3gdb on HPUX long time ago, but nothing for Windows.

Here are test results you requested (you will see I ran each of them twice, getting different results each time).

The very last test run resulted in another stack dump.

Regards,
Randy

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3noincremental @M3nogenerational
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
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
All tests complete.  Congratulations.

Although it ran to completion the first try, I ran again and it crashes, see below:

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3noincremental @M3nogenerational
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
.

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\runtime\common\RTCollector.m3", line 1709
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3noincremental
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
.

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0x12bf9bc = RefSanityCheck + 0x2c in ..\src\runtime\common\RTCollector.m3
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

Running this one a second time, I get these results:

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3noincremental
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
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
All tests complete.  Congratulations.

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3nogenerational
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
.

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0x12bf9bc = RefSanityCheck + 0x2c in ..\src\runtime\common\RTCollector.m3
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

Running a second time, I get these results:

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3nogenerational
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
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........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:
***    An array subscript was out of range.
***    file "..\src\rw\FileRd.m3", line 83
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0xadf764  0x1296ee8  Seek + 0x454 in ..\src\rw\FileRd.m3
0xadf78c  0x1297d84  DoSeek + 0x80 in ..\src\rw\Rd.m3
0xadf7b0  0x1297bf0  FastGetChar + 0x57 in ..\src\rw\Rd.m3
0xadf7d8  0x1297b58  GetChar + 0x48 in ..\src\rw\Rd.m3
0xadf910  0x12912e3  RApply + 0xd3 in ..\src\Main.m3
0xadf94c  0x12b976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
0xadf958  0x74f03677  <???>
0xadf998  0x77009f02  <???>
.........  .........  ... more frames ...

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Thursday, March 03, 2011 2:19 PM
To: Coleburn, Randy
Cc: m3devel
Subject: Re: [M3devel] results of threadtest program on Windows7

Can you try with each of the following?

@M3paranoidgc @M3noincremental @M3nogenerational

@M3paranoidgc @M3noincremental

@M3paranoidgc @M3nogenerational

Also, if possible, can you print the stack dump immediately before the assertion error is printed out?  That means setting a breakpoint on the Raise function that reports assertion failures.  I think it is RTHooks__Raise.  Or perhaps RTHooks__ReportFault.  I don't recall exactly.


On Mar 3, 2011, at 1:47 PM, Coleburn, Randy wrote:


Tony:

Here are results using the checks you suggested.  These are running on Windows 7.
*         @M3paranoidgc
*         @M3nogc
*         @M3noincremental
*         @M3nogenerational

As you can see below, the only one where the program ran to completion is when using M3nogenerational; However, this doesn't mean it solves the problem, because I ran a second time with this option (see below) and it crashed.

When using M3nogc, looks like we run out of memory.  The computer I am using for these tests is a Dell Latitude 6510 with 4GB RAM and a system-managed pagefile size.

Hope these test runs give some insight into the problem.

Let me know what else I can do to help.

Regards,
Randy

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc
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
.

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0xa8f9bc = RefSanityCheck + 0x2c in ..\src\runtime\common\RTCollector.m3
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogc
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
.....

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.
***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x1faf970   0xaaa7b2  Raise + 0x3f in ..\src\runtime\common\RuntimeError.m3
0x1faf990   0xa86902  AllocateOpenArray + 0x33 in ..\src\runtime\common\RTAllocator.m3
0x1faf9ec   0xa61ab3  AApply + 0x46 in ..\src\Main.m3
0x1fafa28   0xa8976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
0x1fafa34  0x75c43677  <???>
0x1fafa74  0x77b39f02  <???>
.........  .........  ... more frames ...

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3noincremental
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
.

***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\runtime\common\RTCollector.m3", line 418
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogenerational
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
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
All tests complete.  Congratulations.

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogenerational
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
.

***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\runtime\common\RTCollector.m3", line 418
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***


From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Thursday, March 03, 2011 10:39 AM
To: Coleburn, Randy
Cc: m3devel
Subject: Re: [M3devel] results of threadtest program on Windows7

Both of these errors indicate major breakdown in the garbage collector.
It could be that the damage was done much earlier than the crash.
To check for earlier damage please run with @M3paranoidgc.
Also, you could try running with @M3nogc, or @M3noincremental, or @M3nogenerational, to see if any of them trigger the errors.

On Mar 2, 2011, at 8:36 PM, Coleburn, Randy wrote:



Jay:

Ok, I just updated from HEAD and got your latest change to thread test program.

Here are two invocations, back to back, each failing in different ways.

The second one repeats the last error message ad infinitum until you press CNTRL-C to abort.  But note, several different errors reported earlier.

Regards,
Randy

C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cm3
--- building in NT386 ---

ignoring ..\src\m3overrides

new source -> compiling Main.m3
new "Main.mo" -> linking threadtest.exe

C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cd NT386

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
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


***
*** runtime error:
***    <*ASSERT*> failed..
***    file "..\src\runtime\common\RTCollector.m3", line 1086
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0xddfaf0  0x123dffb  CleanBetween + 0x47 in ..\src\runtime\common\RTCollector.m3
0xddfb34  0x1241870  CheckLoadTracedRef + 0xc5 in ..\src\runtime\common\RTCollector.m3
0xddfb74  0x121683c  Init + 0x95 in ..\src\rw\FileRd.m3
0xddfba0  0x121679d  Open + 0x4d in ..\src\rw\FileRd.m3
0xddfcd8  0x1211288  RApply + 0x78 in ..\src\Main.m3
0xddfd14  0x123976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
0xddfd20  0x76d53677  <???>
0xddfd60  0x773c9f02  <???>
.........  .........  ... more frames ...

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
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
.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0x12ec5ad = Move + 0x50 in ..\src\runtime\common\RTCollector.m3
***



***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***



***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

From: jayk123 at hotmail.com<mailto:jayk123 at hotmail.com> [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Wednesday, March 02, 2011 8:18 PM
To: Coleburn, Randy; m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7

Even with the change I made PutCard to PutInt?
That's the only failure I've seen.
I'll try on a non-virtual dual-proc machine later.

Thanks,
 - Jay

________________________________
From: rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>
To: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7
Yes, it fails more often than it runs for me.
Regards,
Randy

From: jayk123 at hotmail.com<mailto:jayk123 at hotmail.com> [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7

I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu<mailto:mika at async.caltech.edu>
> CC: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> Subject: Re: [M3devel] results of threadtest program on Windows7
>
> Ah, it just doesn't check command-line arguments that carefully.
>
> I think what you did is equivalent to "-tests STD".
>
> Mika
>
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- --------- -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
> >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110304/40ce9634/attachment-0002.html>

From jay.krell at cornell.edu  Sat Mar  5 06:37:47 2011
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 5 Mar 2011 05:37:47 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>,
	,,<20110226175511.3F7D21A2078@async.async.caltech.edu>,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>,
	,,<20110227202950.46F3B1A2078@async.async.caltech.edu>,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>,
	, , <20110227231125.3DC611A2078@async.async.caltech.edu>, ,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>,
	<COL101-W4726257303F22627175774E6C30@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>,
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>,
	<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>
Message-ID: <COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>

Microsoft debuggers are freely downloadable. 

 Jay/phone

From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Fri, 4 Mar 2011 22:07:39 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7



Tony: I do not have a debugger built for Windows, so I can?t do the breakpoint yet.  I?ll check into trying to build the debugger, but last time I tried this (a few years ago) it didn?t work.  I used m3gdb on HPUX long time ago, but nothing for Windows. Here are test results you requested (you will see I ran each of them twice, getting different results each time).   The very last test run resulted in another stack dump. Regards,Randy C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3noincremental @M3nogenerationalWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)All tests complete.  Congratulations. Although it ran to completion the first try, I ran again and it crashes, see below: C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3noincremental @M3nogenerationalWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest. ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\runtime\common\RTCollector.m3", line 1709*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3noincrementalWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest. ****** runtime error:***    Attempt to reference an illegal memory location.***    pc = 0x12bf9bc = RefSanityCheck + 0x2c in ..\src\runtime\common\RTCollector.m3*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** Running this one a second time, I get these results: C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3noincrementalWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)All tests complete.  Congratulations. C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3nogenerationalWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest. ****** runtime error:***    Attempt to reference an illegal memory location.***    pc = 0x12bf9bc = RefSanityCheck + 0x2c in ..\src\runtime\common\RTCollector.m3*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** Running a second time, I get these results: C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgc @M3nogenerationalWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........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:***    An array subscript was out of range.***    file "..\src\rw\FileRd.m3", line 83*** Stack trace:   FP         PC      Procedure---------  ---------  ------------------------------- 0xadf764  0x1296ee8  Seek + 0x454 in ..\src\rw\FileRd.m3 0xadf78c  0x1297d84  DoSeek + 0x80 in ..\src\rw\Rd.m3 0xadf7b0  0x1297bf0  FastGetChar + 0x57 in ..\src\rw\Rd.m3 0xadf7d8  0x1297b58  GetChar + 0x48 in ..\src\rw\Rd.m3 0xadf910  0x12912e3  RApply + 0xd3 in ..\src\Main.m3 0xadf94c  0x12b976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3 0xadf958  0x74f03677  <???> 0xadf998  0x77009f02  <???>.........  .........  ... more frames ... From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
Sent: Thursday, March 03, 2011 2:19 PM
To: Coleburn, Randy
Cc: m3devel
Subject: Re: [M3devel] results of threadtest program on Windows7 Can you try with each of the following? @M3paranoidgc @M3noincremental @M3nogenerational @M3paranoidgc @M3noincremental @M3paranoidgc @M3nogenerational Also, if possible, can you print the stack dump immediately before the assertion error is printed out?  That means setting a breakpoint on the Raise function that reports assertion failures.  I think it is RTHooks__Raise.  Or perhaps RTHooks__ReportFault.  I don't recall exactly.  On Mar 3, 2011, at 1:47 PM, Coleburn, Randy wrote:

Tony: Here are results using the checks you suggested.  These are running on Windows 7.?         @M3paranoidgc?         @M3nogc?         @M3noincremental?         @M3nogenerational As you can see below, the only one where the program ran to completion is when using M3nogenerational; However, this doesn?t mean it solves the problem, because I ran a second time with this option (see below) and it crashed. When using M3nogc, looks like we run out of memory.  The computer I am using for these tests is a Dell Latitude 6510 with 4GB RAM and a system-managed pagefile size. Hope these test runs give some insight into the problem.  Let me know what else I can do to help. Regards,Randy C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3paranoidgcWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest. ****** runtime error:***    Attempt to reference an illegal memory location.***    pc = 0xa8f9bc = RefSanityCheck + 0x2c in ..\src\runtime\common\RTCollector.m3*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogcWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest..... ****** runtime error:***    NEW() was unable to allocate more memory. ****** runtime error:***    NEW() was unable to allocate more memory. ****** runtime error:***    NEW() was unable to allocate more memory. ****** runtime error:***    NEW() was unable to allocate more memory. ****** runtime error:***    NEW() was unable to allocate more memory. ****** runtime error:***    NEW() was unable to allocate more memory. ****** runtime error:***    NEW() was unable to allocate more memory. ****** runtime error:***    NEW() was unable to allocate more memory. ****** runtime error:***    NEW() was unable to allocate more memory. ****** runtime error:***    NEW() was unable to allocate more memory.***    file "..\src\runtime\common\RuntimeError.m3", line 63*** ***    file "..\src\runtime\common\RuntimeError.m3", line 63*** ***    file "..\src\runtime\common\RuntimeError.m3", line 63*** ***    file "..\src\runtime\common\RuntimeError.m3", line 63*** Stack trace:   FP         PC      Procedure---------  ---------  -------------------------------0x1faf970   0xaaa7b2  Raise + 0x3f in ..\src\runtime\common\RuntimeError.m30x1faf990   0xa86902  AllocateOpenArray + 0x33 in ..\src\runtime\common\RTAllocator.m30x1faf9ec   0xa61ab3  AApply + 0x46 in ..\src\Main.m30x1fafa28   0xa8976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m30x1fafa34  0x75c43677  <???>0x1fafa74  0x77b39f02  <???>.........  .........  ... more frames ... C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3noincrementalWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest. ****** runtime error:***    An array subscript was out of range.***    file "..\src\runtime\common\RTCollector.m3", line 418*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogenerationalWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)All tests complete.  Congratulations. C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe @M3nogenerationalWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest. ****** runtime error:***    An array subscript was out of range.***    file "..\src\runtime\common\RTCollector.m3", line 418*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841***  From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
Sent: Thursday, March 03, 2011 10:39 AM
To: Coleburn, Randy
Cc: m3devel
Subject: Re: [M3devel] results of threadtest program on Windows7 Both of these errors indicate major breakdown in the garbage collector.It could be that the damage was done much earlier than the crash.To check for earlier damage please run with @M3paranoidgc.Also, you could try running with @M3nogc, or @M3noincremental, or @M3nogenerational, to see if any of them trigger the errors. On Mar 2, 2011, at 8:36 PM, Coleburn, Randy wrote:


Jay: Ok, I just updated from HEAD and got your latest change to thread test program. Here are two invocations, back to back, each failing in different ways.  The second one repeats the last error message ad infinitum until you press CNTRL-C to abort.  But note, several different errors reported earlier. Regards,Randy C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cm3--- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling Main.m3new "Main.mo" -> linking threadtest.exe C:\cm3\Sandbox\m3-libs\m3core\tests\thread>cd NT386 C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exeWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest  ****** runtime error:***    <*ASSERT*> failed..***    file "..\src\runtime\common\RTCollector.m3", line 1086*** Stack trace:   FP         PC      Procedure---------  ---------  -------------------------------0xddfaf0  0x123dffb  CleanBetween + 0x47 in ..\src\runtime\common\RTCollector.m30xddfb34  0x1241870  CheckLoadTracedRef + 0xc5 in ..\src\runtime\common\RTCollector.m30xddfb74  0x121683c  Init + 0x95 in ..\src\rw\FileRd.m30xddfba0  0x121679d  Open + 0x4d in ..\src\rw\FileRd.m30xddfcd8  0x1211288  RApply + 0x78 in ..\src\Main.m30xddfd14  0x123976f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m30xddfd20  0x76d53677  <???>0xddfd60  0x773c9f02  <???>.........  .........  ... more frames ... C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exeWriting file...doneCreating read threads...doneCreating fork threads...doneCreating alloc threads...doneCreating lock threads...donerunning...printing oldest/median age/newest. ****** runtime error:***    Attempt to reference an illegal memory location. ****** runtime error:***    Attempt to reference an illegal memory location. ****** runtime error:***    Attempt to reference an illegal memory location.***    pc = 0x12ec5ad = Move + 0x50 in ..\src\runtime\common\RTCollector.m3***   ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841***   ****** runtime error:***    <*ASSERT*> failed.***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841*** From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Wednesday, March 02, 2011 8:18 PM
To: Coleburn, Randy; m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7 Even with the change I made PutCard to PutInt?
That's the only failure I've seen.
I'll try on a non-virtual dual-proc machine later.
 
Thanks,
 - Jay
 From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Wed, 2 Mar 2011 19:42:47 -0500
Subject: Re: [M3devel] results of threadtest program on Windows7Yes, it fails more often than it runs for me.Regards,Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Tuesday, March 01, 2011 5:59 AM
To: Mika Nystrom; Coleburn, Randy
Cc: m3devel
Subject: RE: [M3devel] results of threadtest program on Windows7 I haven't seen it fail on NT, except for PutCard in the test itself getting negative numbers.
I've run it just a few times now. One single and dual processor virtual machines.
Randy, has it failed many times for you?

 - Jay

> To: rcolebur at SCIRES.COM
> Date: Sun, 27 Feb 2011 15:11:25 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> Ah, it just doesn't check command-line arguments that carefully.
> 
> I think what you did is equivalent to "-tests STD".
> 
> Mika
> 
> "Coleburn, Randy" writes:
> >Mika:
> >
> >No change with "-tests POSIX".
> >
> >Interesting twist: On Windows 7, I thought I'd see what the command line o=
> >ptions are, and I typed "threadtest -help" rather than reading the code.
> >
> >First time, it produced what appears to be a NIL deref crash. Then, I trie=
> >d it again and it ran to completion. Something seems non-deterministic her=
> >e. See below.
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >.
> >
> >***
> >*** runtime error:
> >*** Attempt to reference an illegal memory location.
> >*** pc =3D 0x77762262
> >***
> >
> >Stack trace:
> > FP PC Procedure
> >--------- --------- -------------------------------
> > 0xcdf998 0x130351b SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m=
> >3
> > 0xcdf9c0 0x77762262 <???>
> > 0xcdf9d8 0x12e83b7 LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=
> >3
> > 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
> > 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
> > 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32=
> >.m3
> > 0xcdfb80 0x76543677 <???>
> > 0xcdfbc0 0x77779f02 <???>
> >......... ......... ... more frames ...
> >
> >C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -help
> >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
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=
> > lock 0/0/0)
> >All tests complete. Congratulations.
> >
> >Regards,
> >Randy Coleburn
> >
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
> >Sent: Sunday, February 27, 2011 3:30 PM
> >To: Coleburn, Randy
> >Cc: m3devel at elegosoft.com
> >Subject: Re: [M3devel] results of threadtest program on Windows7=20
> >
> >Hi Randy,
> >
> >You can try it with -tests POSIX as well.
> >
> >I find on user threads it runs very slowly (but it does run) because of how=
> > unfair
> >the thread scheduler is.
> >
> >Next step might be to whittle down the tests and see if you can get a failu=
> >re with
> >a single test running and -n 2. That would likely be the simplest scenario=
> > to
> >start further debugging from.
> >
> > Mika
> >
> >"Coleburn, Randy" writes:
> >>Mika et al:
> >>
> >>Thought I would try something else.
> >>
> >>I took the sources of your thread test program to an older XP machine that=
> > =3D
> >>has CM3 circa August 2008. This is the machine and implementation I used =
> >w=3D
> >>hen building a major project I did a couple years back.
> >>
> >>The thread test program does indeed build on this old system, but when I r=
> >u=3D
> >>n it, I get different results than with the latest HEAD branch code. =3D20
> >>
> >>After it prints "running...printing oldest/median age/newest", on the next=
> > =3D
> >>line I get two periods ".." and now the program seems hung. I'll let it "=
> >r=3D
> >>un" for a few more minutes to see if anything else happens before killing =
> >i=3D
> >>t.
> >>
> >>At least we don't get the subscript and assertion failures on this older C=
> >M=3D
> >>3 platform.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>
> >>-----Original Message-----
> >>From: Coleburn, Randy=3D20
> >>Sent: Sunday, February 27, 2011 2:09 PM
> >>To: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7
> >>
> >>Mika:
> >>
> >>Ok, I've updated to latest HEAD and I've also built Jay's m3sleep program.
> >>
> >>Here is what happens now when I run your threadtest program on Windows 7.
> >>
> >>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest -tests ALL,-fo=
> >r=3D
> >>k
> >>Writing file...done
> >>Creating read threads...done
> >>Creating nxread threads...done
> >>Creating tryexcept threads...done
> >>Creating forktoomuch threads...done
> >>Creating alloc threads...done
> >>Creating creat threads...done
> >>Creating lock threads...done
> >>running...printing oldest/median age/newest
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** An array subscript was out of range.
> >>*** file "..\src\runtime\common\RTCollector.m3", line 418
> >>***
> >>
> >>
> >>
> >>***
> >>*** runtime error:
> >>*** <*ASSERT*> failed.
> >>*** file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> >>***
> >>
> >>The last error repeats ad infinitum until I press CNTRL-C to abort.
> >>
> >>I'll send more info on the Windows install of Modula3 in a subsequent post=
> >.
> >>
> >>Regards,
> >>Randy Coleburn
> >>
> >>-----Original Message-----
> >>From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
> >>Sent: Saturday, February 26, 2011 12:55 PM
> >>To: Coleburn, Randy
> >>Cc: m3devel at elegosoft.com
> >>Subject: Re: [M3devel] results of threadtest program on Windows7=3D20
> >>
> >>Hi Randy,
> >>
> >>Hm yes it looks like my Windows programming skills leave something
> >>to be desired.
> >>
> >>You can run the thread tester while skipping a test as follows
> >>
> >> threadtest -tests ALL,-fork
> >>
> >>(for instance)
> >>
> >>if you just run=3D20
> >>
> >> threadtest -sadfassdaf
> >>
> >>it'll print the tests that are available.
> >>
> >>As it happens, I just had to upgrade my windows 2000 system to windows 7.
> >>Can you give me a very brief description of what you did to install Modula=
> >-=3D
> >>3
> >>on this system?
> >>
> >> Mika
> >>
> >>"Coleburn, Randy" writes:
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/plain; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>
> >>>Mika:
> >>>
> >>>I've finally managed to get cm3 rebuilt on Windows 7 again.
> >>>
> >>>So, I ran your threadtest program.
> >>>
> >>>Here are the results. Note the "..." is where I cut out a bunch of the r=
> >e=3D
> >>p=3D3D
> >>>eating "ERROR FApply" messages.
> >>>
> >>>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe
> >>>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
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>***
> >>>*** runtime error:
> >>>*** An enumeration or subrange value was out of range.
> >>>*** file "..\src\Main.m3", line 340
> >>>***
> >>>
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>laziest thread is 0/0/ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The sy=
> >ste=3D
> >>m c=3D3D
> >>>annot find the file specified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>.
> >>>.
> >>>.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>ERROR FApply: OSError.E: ErrorCode=3D3D3D2: The system cannot find the f=
> >ile=3D
> >> sp=3D3D
> >>>ecified.
> >>>Stack trace:
> >>> FP PC Procedure
> >>>--------- --------- -------------------------------
> >>>0x30fbd0 0x127218a PutStats + 0x1a3 in ..\src\Main.m3
> >>>0x30fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
> >>>
> >>>Regards,
> >>>Randy Coleburn
> >>>
> >>>--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
> >>>Content-Type: text/html; charset=3D3D"us-ascii"
> >>>Content-Transfer-Encoding: quoted-printable
> >>>   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110305/259e7726/attachment-0002.html>

From mika at async.caltech.edu  Sat Mar  5 19:05:58 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Sat, 05 Mar 2011 10:05:58 -0800
Subject: [M3devel] m3gdb broken
Message-ID: <20110305180558.451421A2078@async.async.caltech.edu>

Hi m3devel,

I don't know what's happened here.  m3gdb used to work, and work fairly
well (never perfectly, but...).  Now I'm trying to debug a program and
I get the following:

(m3gdb) break Main.m3:65
Debug info for file "Main.mc" not in stabs format
(m3gdb) 

The system/architecture is AMD64_FREEBSD but I've seen this problem on other
systems too.

Everything is from the CVS head.

Main was compiled as follows, says cm3 -commands:

gcc -gstabs+ -m64 -fPIC -z origin -Wl,--warn-common -Wl,-rpath,\$ORIGIN -Wl,-rpath,\$ORIGIN/../lib  -Wl,--fatal-warnings -z now -Bsymbolic -L/usr/local/lib -o sstubgen  _m3main.o Main.mo /home/mika/t/mscheme/sstubgen/AMD64_FREEBSD/libsstubgen.a /home/mika/t/mscheme/schemereadline/AMD64_FREEBSD/libschemereadline.a /home/mika/t/mscheme/schemesig/AMD64_FREEBSD/libschemesig.a /home/mika/t/calarm/m3readline/AMD64_FREEBSD/libm3readline.a /home/mika/t/calarm/sx/AMD64_FREEBSD/libsx.a /home/mika/t/mscheme/modula3scheme/AMD64_FREEBSD/libmodula3scheme.a /home/mika/t/rdwr/AMD64_FREEBSD/librdwr.a /home/mika/t/mscheme/AMD64_FREEBSD/libmscheme.a /home/mika/t/cit_util/AMD64_FREEBSD/libcit_util.a /usr/local/cm3/pkg/netobj/AMD64_FREEBSD/libm3netobj.a /usr/local/cm3/pkg/tcp/AMD64_FREEBSD/libm3tcp.a /usr/local/cm3/pkg/patternmatching/AMD64_FREEBSD/libpatternmatching.a /home/mika/t/mscheme/scheme-lib/AMD64_FREEBSD/libscheme-lib.a /usr/local/cm3/pkg/libbuf/AMD64_FREEBSD/liblibbuf.a /home/mika/t/ci
 t_common/AMD64_FREEBSD/libcit_common.a /usr/local/cm3/pkg/set/AMD64_FREEBSD/libset.a /home/mika/t/rdwrreset/AMD64_FREEBSD/librdwrreset.a /usr/local/cm3/pkg/m3tk/AMD64_FREEBSD/libm3tk.a /usr/local/cm3/pkg/m3tk-misc/AMD64_FREEBSD/libm3tk-misc.a /usr/local/cm3/pkg/libm3/AMD64_FREEBSD/libm3.a /usr/local/cm3/pkg/m3core/AMD64_FREEBSD/libm3core.a -lm -lcrypt -lssl -L/usr/local/lib -lintl -lreadline

I'm not even sure where to begin looking.  Is it a configuration issue,
something broken in the compiler, or what?

I fear m3gdb is essentially useless at the moment.

     Mika


From mika at async.caltech.edu  Sat Mar  5 21:06:30 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Sat, 05 Mar 2011 12:06:30 -0800
Subject: [M3devel] MODULEs in .M3IMPTAB
Message-ID: <20110305200630.F26711A2078@async.async.caltech.edu>

Hi again m3devel,

Can anyone think of a reason that cm3 should *not* emit information
about MODULEs that it compiles to .M3IMPTAB?  (It doesn't, today,
which means that m3tk-based tools can't find implementations, only
interfaces.)

    Mika


From hosking at cs.purdue.edu  Sat Mar  5 23:43:35 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 5 Mar 2011 17:43:35 -0500
Subject: [M3devel] MODULEs in .M3IMPTAB
In-Reply-To: <20110305200630.F26711A2078@async.async.caltech.edu>
References: <20110305200630.F26711A2078@async.async.caltech.edu>
Message-ID: <F14FF404-B88C-4C46-B433-744E45311209@cs.purdue.edu>

It used to work... :-(

On Mar 5, 2011, at 3:06 PM, Mika Nystrom wrote:

> Hi again m3devel,
> 
> Can anyone think of a reason that cm3 should *not* emit information
> about MODULEs that it compiles to .M3IMPTAB?  (It doesn't, today,
> which means that m3tk-based tools can't find implementations, only
> interfaces.)
> 
>    Mika



From mika at async.caltech.edu  Sat Mar  5 23:53:51 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Sat, 05 Mar 2011 14:53:51 -0800
Subject: [M3devel] MODULEs in .M3IMPTAB
In-Reply-To: <F14FF404-B88C-4C46-B433-744E45311209@cs.purdue.edu> 
References: <20110305200630.F26711A2078@async.async.caltech.edu>
	<F14FF404-B88C-4C46-B433-744E45311209@cs.purdue.edu>
Message-ID: <20110305225351.2A2AD1A2078@async.async.caltech.edu>


Tony, are you sure?  There don't seem to be any tools in CM3 that process
implementations with m3tk, or have I been looking in the wrong places?
stubgen doesn't, I don't think stablegen does, and m3pp and m3tohtml
don't even use m3tk.  Also it doesn't seem to work on PM3-1.13.2.  Hmmmmm....

     Mika

Tony Hosking writes:
>It used to work... :-(
>
>On Mar 5, 2011, at 3:06 PM, Mika Nystrom wrote:
>
>> Hi again m3devel,
>> 
>> Can anyone think of a reason that cm3 should *not* emit information
>> about MODULEs that it compiles to .M3IMPTAB?  (It doesn't, today,
>> which means that m3tk-based tools can't find implementations, only
>> interfaces.)
>> 
>>    Mika


From rcolebur at SCIRES.COM  Sun Mar  6 02:35:41 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Sat, 5 Mar 2011 20:35:41 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>,
	,,<20110226175511.3F7D21A2078@async.async.caltech.edu>,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>,
	,,<20110227202950.46F3B1A2078@async.async.caltech.edu>,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>,
	, , <20110227231125.3DC611A2078@async.async.caltech.edu>, ,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>,
	<COL101-W4726257303F22627175774E6C30@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>,
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>,
	<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>
	<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>

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/20110305/c882dbac/attachment-0002.html>

From rodney_bates at lcwb.coop  Sun Mar  6 03:30:29 2011
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 05 Mar 2011 20:30:29 -0600
Subject: [M3devel] m3gdb broken
In-Reply-To: <20110305180558.451421A2078@async.async.caltech.edu>
References: <20110305180558.451421A2078@async.async.caltech.edu>
Message-ID: <4D72F1C5.2020504@lcwb.coop>



On 03/05/2011 12:05 PM, Mika Nystrom wrote:
> Hi m3devel,
>
> I don't know what's happened here.  m3gdb used to work, and work fairly
> well (never perfectly, but...).  Now I'm trying to debug a program and
> I get the following:
>
> (m3gdb) break Main.m3:65
> Debug info for file "Main.mc" not in stabs format

This message looks vaguely familiar to me, but I'm not recalling just yet.

> (m3gdb)
>
> The system/architecture is AMD64_FREEBSD but I've seen this problem on other
> systems too.
>
> Everything is from the CVS head.
>
> Main was compiled as follows, says cm3 -commands:
>
> gcc -gstabs+ -m64 -fPIC -z origin -Wl,--warn-common -Wl,-rpath,\$ORIGIN -Wl,-rpath,\$ORIGIN/../lib  -Wl,--fatal-warnings -z now -Bsymbolic -L/usr/local/lib -o sstubgen  _m3main.o Main.mo /home/mika/t/mscheme/sstubgen/AMD64_FREEBSD/libsstubgen.a /home/mika/t/mscheme/schemereadline/AMD64_FREEBSD/libschemereadline.a /home/mika/t/mscheme/schemesig/AMD64_FREEBSD/libschemesig.a /home/mika/t/calarm/m3readline/AMD64_FREEBSD/libm3readline.a /home/mika/t/calarm/sx/AMD64_FREEBSD/libsx.a /home/mika/t/mscheme/modula3scheme/AMD64_FREEBSD/libmodula3scheme.a /home/mika/t/rdwr/AMD64_FREEBSD/librdwr.a /home/mika/t/mscheme/AMD64_FREEBSD/libmscheme.a /home/mika/t/cit_util/AMD64_FREEBSD/libcit_util.a /usr/local/cm3/pkg/netobj/AMD64_FREEBSD/libm3netobj.a /usr/local/cm3/pkg/tcp/AMD64_FREEBSD/libm3tcp.a /usr/local/cm3/pkg/patternmatching/AMD64_FREEBSD/libpatternmatching.a /home/mika/t/mscheme/scheme-lib/AMD64_FREEBSD/libscheme-lib.a /usr/local/cm3/pkg/libbuf/AMD64_FREEBSD/liblibbuf.a /home/mika/t/
ci
>   t_common/AMD64_FREEBSD/libcit_common.a /usr/local/cm3/pkg/set/AMD64_FREEBSD/libset.a /home/mika/t/rdwrreset/AMD64_FREEBSD/librdwrreset.a /usr/local/cm3/pkg/m3tk/AMD64_FREEBSD/libm3tk.a /usr/local/cm3/pkg/m3tk-misc/AMD64_FREEBSD/libm3tk-misc.a /usr/local/cm3/pkg/libm3/AMD64_FREEBSD/libm3.a /usr/local/cm3/pkg/m3core/AMD64_FREEBSD/libm3core.a -lm -lcrypt -lssl -L/usr/local/lib -lintl -lreadline
>

This looks like the gcc command for the link step.  Everything it gets is either .o or .a.,
and it invokes gcc, not cm3cg.

I think the problem might lie in the compile step for Main, which would be giving
Main.mc as the input file name.  Its -g option could be the culprit. It should
look something like:

/usr/local/cm3//bin/cm3cg -gstabs+ -m64 -fPIC -mno-align-double -funwind-tables -quiet -fno-reorder-blocks Main.mc -o Main.ms



> I'm not even sure where to begin looking.  Is it a configuration issue,
> something broken in the compiler, or what?
>
> I fear m3gdb is essentially useless at the moment.
>
>       Mika
>

Rodney Bates


From mika at async.caltech.edu  Sun Mar  6 03:37:49 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Sat, 05 Mar 2011 18:37:49 -0800
Subject: [M3devel] m3gdb broken
In-Reply-To: <4D72F1C5.2020504@lcwb.coop> 
References: <20110305180558.451421A2078@async.async.caltech.edu>
	<4D72F1C5.2020504@lcwb.coop>
Message-ID: <20110306023749.88D321A2078@async.async.caltech.edu>

"Rodney M. Bates" writes:
...
>> Debug info for file "Main.mc" not in stabs format
>
>This message looks vaguely familiar to me, but I'm not recalling just yet.
>
>> (m3gdb)
>>
>> The system/architecture is AMD64_FREEBSD but I've seen this problem on other
...
>> Everything is from the CVS head.
>>
>> Main was compiled as follows, says cm3 -commands:
>>
>> gcc -gstabs+ -m64 -fPIC -z origin -Wl,--warn-common -Wl,-rpath,\$ORIGIN -Wl,-rpath,\$ORIGIN/../lib  -Wl,--fatal-warnings -z now -Bsymbolic -
>L/usr/local/lib -o sstubgen  _m3main.o Main.mo /home/mika/t/mscheme/sstubgen/AMD64_FREEBSD/libsstubgen.a /home/mika/t/mscheme/schemereadline/A
>MD64_FREEBSD/libschemereadline.a /home/mika/t/mscheme/schemesig/AMD64_FREEBSD/libschemesig.a /home/mika/t/calarm/m3readline/AMD64_FREEBSD/libm
>3readline.a /home/mika/t/calarm/sx/AMD64_FREEBSD/libsx.a /home/mika/t/mscheme/modula3scheme/AMD64_FREEBSD/libmodula3scheme.a /home/mika/t/rdwr
>/AMD64_FREEBSD/librdwr.a /home/mika/t/mscheme/AMD64_FREEBSD/libmscheme.a /home/mika/t/cit_util/AMD64_FREEBSD/libcit_util.a /usr/local/cm3/pkg/
>netobj/AMD64_FREEBSD/libm3netobj.a /usr/local/cm3/pkg/tcp/AMD64_FREEBSD/libm3tcp.a /usr/local/cm3/pkg/patternmatching/AMD64_FREEBSD/libpattern
>matching.a /home/mika/t/mscheme/scheme-lib/AMD64_FREEBSD/libscheme-lib.a /usr/local/cm3/pkg/libbuf/AMD64_FREEBSD/liblibbuf.a /home/mika/t/
>ci
>>   t_common/AMD64_FREEBSD/libcit_common.a /usr/local/cm3/pkg/set/AMD64_FREEBSD/libset.a /home/mika/t/rdwrreset/AMD64_FREEBSD/librdwrreset.a /
>usr/local/cm3/pkg/m3tk/AMD64_FREEBSD/libm3tk.a /usr/local/cm3/pkg/m3tk-misc/AMD64_FREEBSD/libm3tk-misc.a /usr/local/cm3/pkg/libm3/AMD64_FREEBS
>D/libm3.a /usr/local/cm3/pkg/m3core/AMD64_FREEBSD/libm3core.a -lm -lcrypt -lssl -L/usr/local/lib -lintl -lreadline
>>
>
>This looks like the gcc command for the link step.  Everything it gets is either .o or .a.,
>and it invokes gcc, not cm3cg.
>
>I think the problem might lie in the compile step for Main, which would be giving
>Main.mc as the input file name.  Its -g option could be the culprit. It should
>look something like:
>
>/usr/local/cm3//bin/cm3cg -gstabs+ -m64 -fPIC -mno-align-double -funwind-tables -quiet -fno-reorder-blocks Main.mc -o Main.ms
>

Sorry, I wasn't thinking.  But my cm3cg is also configured right, I think:

(236)ginger:~/t/mscheme/sstubgen/program/src>cm3 -x -commands | & grep Main
new source -> compiling Main.m3
m3front ../src/Main.m3 -w1
/usr/local/cm3//bin/cm3cg -mno-align-double -quiet -fno-reorder-blocks -funwind-tables -fPIC   -m64 -gstabs+ Main.mc -o Main.ms
as -64 Main.ms -o Main.mo
/usr/local/cm3//bin/cm3cg -mno-align-double -quiet -fno-reorder-blocks -funwind-tables -fPIC   -m64 -gstabs+ Main.mc -o Main.ms
as -64 Main.ms -o Main.mo
rm Main.mc
rm Main.ms
gcc -gstabs+ -m64 -fPIC -z origin -Wl,--warn-common -Wl,-rpath,\$ORIGIN -Wl,-rpath,\$ORIGIN/../lib  -Wl,--fatal-warnings -z now -Bsymbolic -L/usr/local/lib -o sstubgen  _m3main.o Main.mo /home/mika/t/mscheme/sstubgen/AMD64_FREEBSD/libsstubgen.a /home/mika/t/mscheme/schemereadline/AMD64_FREEBSD/libschemereadline.a /home/mika/t/mscheme/schemesig/AMD64_FREEBSD/libschemesig.a /home/mika/t/calarm/m3readline/AMD64_FREEBSD/libm3readline.a /home/mika/t/calarm/sx/AMD64_FREEBSD/libsx.a /home/mika/t/mscheme/modula3scheme/AMD64_FREEBSD/libmodula3scheme.a /home/mika/t/rdwr/AMD64_FREEBSD/librdwr.a /home/mika/t/mscheme/AMD64_FREEBSD/libmscheme.a /home/mika/t/cit_util/AMD64_FREEBSD/libcit_util.a /usr/local/cm3/pkg/netobj/AMD64_FREEBSD/libm3netobj.a /usr/local/cm3/pkg/tcp/AMD64_FREEBSD/libm3tcp.a /usr/local/cm3/pkg/patternmatching/AMD64_FREEBSD/libpatternmatching.a /home/mika/t/mscheme/scheme-lib/AMD64_FREEBSD/libscheme-lib.a /usr/local/cm3/pkg/libbuf/AMD64_FREEBSD/liblibbuf.a /home/mika/t/ci
 t_common/AMD64_FREEBSD/libcit_common.a /usr/local/cm3/pkg/set/AMD64_FREEBSD/libset.a /home/mika/t/rdwrreset/AMD64_FREEBSD/librdwrreset.a /usr/local/cm3/pkg/m3tk/AMD64_FREEBSD/libm3tk.a /usr/local/cm3/pkg/m3tk-misc/AMD64_FREEBSD/libm3tk-misc.a /usr/local/cm3/pkg/libm3/AMD64_FREEBSD/libm3.a /usr/local/cm3/pkg/m3core/AMD64_FREEBSD/libm3core.a -lm -lcrypt -lssl -L/usr/local/lib -lintl -lreadline




From mika at async.caltech.edu  Sun Mar  6 05:24:37 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Sat, 05 Mar 2011 20:24:37 -0800
Subject: [M3devel] MODULEs in .M3IMPTAB
In-Reply-To: <12847.73267.qm@web29719.mail.ird.yahoo.com> 
References: <12847.73267.qm@web29719.mail.ird.yahoo.com>
Message-ID: <20110306042437.D48591A2078@async.async.caltech.edu>

Let me be perfectly clear.

m3tk processes interfaces just fine.

m3tk at the moment doesn't know where to find implementations (MODULEs).

One can tell m3tk where to find them with a command-line switch specifying
a list of directories.  But that's not right, because only cm3 (the
compiler driver) knows which source files have been processed to build
which implementation.

I think my argument suggests the .m3s should be emitted to .M3IMPTAB together
with the .i3s (and .igs oh and also .mgs)

    Mika

"Daniel Alejandro Benavides D." writes:
>Hi all:
>yes, I think I did mention it in a past message because about the ESC, it n=
>eedes as it m3tk too, I didn't know it was a requirement of m3tk though. Bu=
>t because is just a module dependency analyzer I thought we could just crea=
>te one in m3tk, sort of a chicken and egg problem it seems now. OK, I with =
>an older cm3 we could use it to build it in a setting and then supply itsel=
>f in m3tk, if that's the way to go, therefore I think this is really needed=
> for ESC release.
>Another thing if you allow me is about again the ESC itself, I think that o=
>ne of the ways we could improve some of the ESC checks is to reuse some sor=
>t automatic program debugger I already mentioned about Juno which language =
>has a subset of Simplify language so we could try to postprocess further er=
>rors to guarantee they are so and the more important it could be possible t=
>o think in analyzing checks for soundness so we may try to put closer Simpl=
>if0y to its (in results terms) goal of finding more errors it can catch. Th=
>at said I would go for double checked proofs so me can arguably guarantee t=
>hey are sound proved theoretically and passing through it Simplify again, a=
>ll of this without modification to ESC per se. This is traditional approach=
> for debuggers, so its not a new idea again, just that we need to be smarte=
>r in certain way to catch with the less computation effort the most bugs we=
> can. Another thing I was thinking was to integrate this proofs in
> regular builds so for example a given all program proofs modified by the d=
>ebugger should be presented as warnings of error and something that must be=
> checked closely (supervised).
>Ok, let mw now your thoughts on this points, thanks in advance
>
>--- El s=E1b, 5/3/11, Mika Nystrom <mika at async.caltech.edu> escribi=F3:
>
>> De: Mika Nystrom <mika at async.caltech.edu>
>> Asunto: Re: [M3devel] MODULEs in .M3IMPTAB
>> Para: "Tony Hosking" <hosking at cs.purdue.edu>
>> CC: m3devel at elegosoft.com
>> Fecha: s=E1bado, 5 de marzo, 2011 17:53
>>=20
>> Tony, are you sure?  There don't seem to be any tools
>> in CM3 that process
>> implementations with m3tk, or have I been looking in the
>> wrong places?
>> stubgen doesn't, I don't think stablegen does, and m3pp and
>> m3tohtml
>> don't even use m3tk.  Also it doesn't seem to work on
>> PM3-1.13.2.  Hmmmmm....
>>=20
>>      Mika
>>=20
>> Tony Hosking writes:
>> >It used to work... :-(
>> >
>> >On Mar 5, 2011, at 3:06 PM, Mika Nystrom wrote:
>> >
>> >> Hi again m3devel,
>> >>=20
>> >> Can anyone think of a reason that cm3 should *not*
>> emit information
>> >> about MODULEs that it compiles to .M3IMPTAB?=20
>> (It doesn't, today,
>> >> which means that m3tk-based tools can't find
>> implementations, only
>> >> interfaces.)
>> >>=20
>> >>    Mika
>> =0A=0A=0A      


From dabenavidesd at yahoo.es  Sun Mar  6 05:20:10 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sun, 6 Mar 2011 04:20:10 +0000 (GMT)
Subject: [M3devel] MODULEs in .M3IMPTAB
In-Reply-To: <20110305225351.2A2AD1A2078@async.async.caltech.edu>
Message-ID: <12847.73267.qm@web29719.mail.ird.yahoo.com>

Hi all:
yes, I think I did mention it in a past message because about the ESC, it needes as it m3tk too, I didn't know it was a requirement of m3tk though. But because is just a module dependency analyzer I thought we could just create one in m3tk, sort of a chicken and egg problem it seems now. OK, I with an older cm3 we could use it to build it in a setting and then supply itself in m3tk, if that's the way to go, therefore I think this is really needed for ESC release.
Another thing if you allow me is about again the ESC itself, I think that one of the ways we could improve some of the ESC checks is to reuse some sort automatic program debugger I already mentioned about Juno which language has a subset of Simplify language so we could try to postprocess further errors to guarantee they are so and the more important it could be possible to think in analyzing checks for soundness so we may try to put closer Simplif0y to its (in results terms) goal of finding more errors it can catch. That said I would go for double checked proofs so me can arguably guarantee they are sound proved theoretically and passing through it Simplify again, all of this without modification to ESC per se. This is traditional approach for debuggers, so its not a new idea again, just that we need to be smarter in certain way to catch with the less computation effort the most bugs we can. Another thing I was thinking was to integrate this proofs in
 regular builds so for example a given all program proofs modified by the debugger should be presented as warnings of error and something that must be checked closely (supervised).
Ok, let mw now your thoughts on this points, thanks in advance

--- El s?b, 5/3/11, Mika Nystrom <mika at async.caltech.edu> escribi?:

> De: Mika Nystrom <mika at async.caltech.edu>
> Asunto: Re: [M3devel] MODULEs in .M3IMPTAB
> Para: "Tony Hosking" <hosking at cs.purdue.edu>
> CC: m3devel at elegosoft.com
> Fecha: s?bado, 5 de marzo, 2011 17:53
> 
> Tony, are you sure?  There don't seem to be any tools
> in CM3 that process
> implementations with m3tk, or have I been looking in the
> wrong places?
> stubgen doesn't, I don't think stablegen does, and m3pp and
> m3tohtml
> don't even use m3tk.  Also it doesn't seem to work on
> PM3-1.13.2.  Hmmmmm....
> 
>      Mika
> 
> Tony Hosking writes:
> >It used to work... :-(
> >
> >On Mar 5, 2011, at 3:06 PM, Mika Nystrom wrote:
> >
> >> Hi again m3devel,
> >> 
> >> Can anyone think of a reason that cm3 should *not*
> emit information
> >> about MODULEs that it compiles to .M3IMPTAB? 
> (It doesn't, today,
> >> which means that m3tk-based tools can't find
> implementations, only
> >> interfaces.)
> >> 
> >>    Mika
> 


      


From hosking at cs.purdue.edu  Sun Mar  6 15:54:14 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 6 Mar 2011 09:54:14 -0500
Subject: [M3devel] MODULEs in .M3IMPTAB
In-Reply-To: <20110305225351.2A2AD1A2078@async.async.caltech.edu>
References: <20110305200630.F26711A2078@async.async.caltech.edu>
	<F14FF404-B88C-4C46-B433-744E45311209@cs.purdue.edu>
	<20110305225351.2A2AD1A2078@async.async.caltech.edu>
Message-ID: <D09FFA7F-549C-41F6-AA59-05A6D4B1B48B@cs.purdue.edu>

m3browser?

Sent from my iPhone

On Mar 5, 2011, at 5:53 PM, Mika Nystrom <mika at async.caltech.edu> wrote:

> 
> Tony, are you sure?  There don't seem to be any tools in CM3 that process
> implementations with m3tk, or have I been looking in the wrong places?
> stubgen doesn't, I don't think stablegen does, and m3pp and m3tohtml
> don't even use m3tk.  Also it doesn't seem to work on PM3-1.13.2.  Hmmmmm....
> 
>     Mika
> 
> Tony Hosking writes:
>> It used to work... :-(
>> 
>> On Mar 5, 2011, at 3:06 PM, Mika Nystrom wrote:
>> 
>>> Hi again m3devel,
>>> 
>>> Can anyone think of a reason that cm3 should *not* emit information
>>> about MODULEs that it compiles to .M3IMPTAB?  (It doesn't, today,
>>> which means that m3tk-based tools can't find implementations, only
>>> interfaces.)
>>> 
>>>   Mika


From mika at async.caltech.edu  Sun Mar  6 17:46:35 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Sun, 06 Mar 2011 08:46:35 -0800
Subject: [M3devel] MODULEs in .M3IMPTAB
In-Reply-To: <D09FFA7F-549C-41F6-AA59-05A6D4B1B48B@cs.purdue.edu> 
References: <20110305200630.F26711A2078@async.async.caltech.edu>
	<F14FF404-B88C-4C46-B433-744E45311209@cs.purdue.edu>
	<20110305225351.2A2AD1A2078@async.async.caltech.edu>
	<D09FFA7F-549C-41F6-AA59-05A6D4B1B48B@cs.purdue.edu>
Message-ID: <20110306164635.A86E61A2078@async.async.caltech.edu>

Nope, m3browser uses something called "m3scan"...

Tony Hosking writes:
>m3browser?
>
>Sent from my iPhone
>
>On Mar 5, 2011, at 5:53 PM, Mika Nystrom <mika at async.caltech.edu> wrote:
>
>>=20
>> Tony, are you sure?  There don't seem to be any tools in CM3 that process
>> implementations with m3tk, or have I been looking in the wrong places?
>> stubgen doesn't, I don't think stablegen does, and m3pp and m3tohtml
>> don't even use m3tk.  Also it doesn't seem to work on PM3-1.13.2.  Hmmmmm.=
>...
>>=20
>>     Mika
>>=20
>> Tony Hosking writes:
>>> It used to work... :-(
>>>=20
>>> On Mar 5, 2011, at 3:06 PM, Mika Nystrom wrote:
>>>=20
>>>> Hi again m3devel,
>>>>=20
>>>> Can anyone think of a reason that cm3 should *not* emit information
>>>> about MODULEs that it compiles to .M3IMPTAB?  (It doesn't, today,
>>>> which means that m3tk-based tools can't find implementations, only
>>>> interfaces.)
>>>>=20
>>>>   Mika


From jay.krell at cornell.edu  Mon Mar  7 02:25:59 2011
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 7 Mar 2011 01:25:59 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , , ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , 
	, <20110227231125.3DC611A2078@async.async.caltech.edu>,
	,,<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, ,
	<COL101-W4726257303F22627175774E6C30@phx.gbl>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, ,
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, ,
	<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>,
	<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>
Message-ID: <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>


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/20110307/05931f46/attachment-0002.html>

From jay.krell at cornell.edu  Mon Mar  7 06:39:53 2011
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 7 Mar 2011 05:39:53 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , ,
	,,<20110226175511.3F7D21A2078@async.async.caltech.edu>, , ,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , ,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , ,
	,,<20110227202950.46F3B1A2078@async.async.caltech.edu>, , ,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , ,,,
	<20110227231125.3DC611A2078@async.async.caltech.edu>, , , ,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , 
	, <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>,
	,,<COL101-W4726257303F22627175774E6C30@phx.gbl>,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>,
	,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>,
	,,<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, ,
	<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>,
	<COL101-W1162A9B603898CC921B557E6C70@phx.gbl>
Message-ID: <COL101-W26D3B03885998122254013E6C70@phx.gbl>


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/20110307/816bd520/attachment-0002.html>

From jay.krell at cornell.edu  Mon Mar  7 06:51:32 2011
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 7 Mar 2011 05:51:32 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W26D3B03885998122254013E6C70@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, ,
	,,,,<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, ,
	,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	,,,,<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	,,,,<20110227231125.3DC611A2078@async.async.caltech.edu>, , ,
	,,<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , ,,,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , ,
	<COL101-W4726257303F22627175774E6C30@phx.gbl>, , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , ,
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , , ,
	<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, , , 
	, <D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>,
	,,<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, ,
	<COL101-W1162A9B603898CC921B557E6C70@phx.gbl>,
	<COL101-W26D3B03885998122254013E6C70@phx.gbl>
Message-ID: <COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>


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/20110307/b5340413/attachment-0002.html>

From jay.krell at cornell.edu  Mon Mar  7 07:53:06 2011
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 7 Mar 2011 06:53:06 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>,
	,,,,,,<20110226175511.3F7D21A2078@async.async.caltech.edu>,
	,,,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>,
	,,,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>,
	,,,,,,<20110227202950.46F3B1A2078@async.async.caltech.edu>,
	,,,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>,
	,,,,,,<20110227231125.3DC611A2078@async.async.caltech.edu>, ,
	,,,,<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, ,
	,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , ,
	,,<COL101-W4726257303F22627175774E6C30@phx.gbl>, , ,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , ,
	,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , ,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , ,
	,,<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, , ,,,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , ,
	<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , 
	, <D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>,
	, , <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, ,
	<COL101-W26D3B03885998122254013E6C70@phx.gbl>,
	<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>
Message-ID: <COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>


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/20110307/2ad39231/attachment-0002.html>

From jay.krell at cornell.edu  Mon Mar  7 07:58:45 2011
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 7 Mar 2011 06:58:45 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , , , , ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , ,
	, <D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , ,
	, , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , ,
	, , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	, , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , ,
	, , <20110227231125.3DC611A2078@async.async.caltech.edu>, 
	,,,,,,<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>,
	,,,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, ,
	,,,,<COL101-W4726257303F22627175774E6C30@phx.gbl>, ,
	,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, ,
	,,,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, ,
	,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, ,
	,,,,<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, ,
	,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , ,
	,,<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , ,,,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>,,, ,
	<COL101-W1162A9B603898CC921B557E6C70@phx.gbl>,
	, , <COL101-W26D3B03885998122254013E6C70@phx.gbl>, ,
	<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>,
	<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>
Message-ID: <COL101-W510B831AC595A3597FE281E6C70@phx.gbl>


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/20110307/4689d5a0/attachment-0002.html>

From jay.krell at cornell.edu  Wed Mar  9 21:10:37 2011
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 9 Mar 2011 20:10:37 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W510B831AC595A3597FE281E6C70@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , , , , ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , ,
	, <D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , ,
	, , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , ,
	, , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	, , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , ,
	, , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , ,
	, , , <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , , ,
	, <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, 
	,,,,,,<COL101-W4726257303F22627175774E6C30@phx.gbl>,
	,,,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>,
	,,,,,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>,
	,,,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>,
	,,,,,,<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>,
	,,,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, ,
	,,,,<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, ,
	,,,,<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>,,,
	, , <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , , ,
	<COL101-W26D3B03885998122254013E6C70@phx.gbl>, ,
	<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>,
	<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>,
	<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>
Message-ID: <COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>


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/20110309/f55d5318/attachment-0002.html>

From jay.krell at cornell.edu  Thu Mar 10 11:09:02 2011
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 10 Mar 2011 10:09:02 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , , , , ,
	<20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , ,
	, <D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , ,
	, , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , ,
	, , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, ,
	, , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , ,
	, , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , ,
	, , , <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , , ,
	, <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , ,
	, , , <COL101-W4726257303F22627175774E6C30@phx.gbl>, , , , , , ,
	, <D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , ,
	, , , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, ,
	, , , , , , <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>,
	, , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, 
	,,,,,,<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>,
	, , , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , ,
	, , <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , , ,
	<COL101-W26D3B03885998122254013E6C70@phx.gbl>, ,
	<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>,
	<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>,
	<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>,
	<COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>
Message-ID: <COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>


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/105955e1/attachment-0002.html>

From jay.krell at cornell.edu  Thu Mar 10 11:40:58 2011
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 10 Mar 2011 10:40:58 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , ,
	, , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , ,
	, , 
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , ,,, , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , ,,, , , , ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,,, , , , ,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , , , ,
	, 
	<20110227231125.3DC611A2078@async.async.caltech.edu>, , , , ,,, , ,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , , ,,,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , ,,, , ,
	<COL101-W4726257303F22627175774E6C30@phx.gbl>, , , , , , ,,,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , ,,, , ,
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , ,,, , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, ,,, , , , , ,
	<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>,,, , , , , ,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , , , ,
	<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , 
	, , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , , ,
	, , <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , ,
	,,<COL101-W26D3B03885998122254013E6C70@phx.gbl>,
	, , <COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>, ,
	<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>, ,
	<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>, ,
	<COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>,
	<COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>
Message-ID: <COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>


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/c8e8b320/attachment-0002.html>

From jay.krell at cornell.edu  Thu Mar 10 12:05:40 2011
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 10 Mar 2011 11:05:40 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , ,
	, , , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , ,
	, 
	, , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , ,
	, , , 
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , ,,, , , ,
	, , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , , , ,
	, , 
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , , ,
	,,,,<20110227231125.3DC611A2078@async.async.caltech.edu>, , , , ,,, ,
	,,<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , , ,
	, , ,,<COL101-W4726257303F22627175774E6C30@phx.gbl>, , , , , ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , , ,
	, , 
	,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , ,,, , ,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, ,,, , , , ,
	, , <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, , , , , , , , ,
	, , 
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , , ,
	,,<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , ,,, , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , , ,,, ,
	<COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, ,
	,,,,<COL101-W26D3B03885998122254013E6C70@phx.gbl>,,, ,
	<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>,
	,,<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>,
	,,<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>,
	, , <COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>, ,
	<COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>,
	<COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>
Message-ID: <COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>


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/01a78fc7/attachment-0002.html>

From jay.krell at cornell.edu  Thu Mar 10 12:11:35 2011
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 10 Mar 2011 11:11:35 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , ,,,
	, , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , ,
	, , , 
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , , ,
	, , 
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , , , , ,
	, , , , , 
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , , , , , ,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , ,
	,,,,,,<20110227231125.3DC611A2078@async.async.caltech.edu>, , , , ,,,
	,,,,<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , ,,, , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , , ,,, ,
	,,<COL101-W4726257303F22627175774E6C30@phx.gbl>, , , , , ,,, , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , , ,,,
	,,,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , ,,, ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , , , , ,
	, , , , , 
	<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, , , , , , , , , , ,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , ,
	,,,,<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , ,,, , , ,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , , ,,,
	,,<COL101-W1162A9B603898CC921B557E6C70@phx.gbl>,
	,,,,,,<COL101-W26D3B03885998122254013E6C70@phx.gbl>,,,
	, , <COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>, , , ,
	<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>, , , ,
	<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>, , , 
	, <COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>,
	, , <COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>, ,
	<COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>,
	<COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>
Message-ID: <COL101-W1593ED3DF56A0900656FCE6C80@phx.gbl>


I forgot to point out: I'll stick to 32bit Windows for now, while looking at Mika's threadtest.

 - Jay

From: jay.krell at cornell.edu
To: rcolebur at scires.com; m3devel at elegosoft.com
Date: Thu, 10 Mar 2011 11:05:40 +0000
Subject: Re: [M3devel] results of threadtest program on Windows7








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/e60c249b/attachment-0002.html>

From rcolebur at SCIRES.COM  Thu Mar 10 17:18:31 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 10 Mar 2011 11:18:31 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , ,
	, , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , ,
	, , 
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , ,,, , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , ,,, , , , ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,,, , , , ,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , , , ,
	, 
	<20110227231125.3DC611A2078@async.async.caltech.edu>, , , , ,,, , ,
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , , ,,,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , ,,, , ,
	<COL101-W4726257303F22627175774E6C30@phx.gbl>, , , , , , ,,,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , ,,, , ,
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , ,,, , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, ,,, , , , , ,
	<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>,,, , , , , ,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , , , ,
	<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , 
	, , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , , ,
	, , <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , ,
	,,<COL101-W26D3B03885998122254013E6C70@phx.gbl>,
	, , <COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>, ,
	<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>, ,
	<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>, ,
	<COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>,
	<COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>
	<COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E6EE527A91@atlex02-srv>

Jay et al:

CM3's use of native windows threads has worked very well for me in the past, and the majority of all my programs have always been multithreaded.

Surely there must be some collection of changes in last couple of years that is responsible for the runtime errors we are seeing now with the thread test program.  Another possibility is that maybe there is something wrong with the thread test program itself that we haven't spotted yet.

I will try to take some time soon to go back to an earlier cm3 release and run the thread test program there to see how it fares.

Regards,
Randy

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Thursday, March 10, 2011 5:41 AM
To: Coleburn, Randy; m3devel
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/14057194/attachment-0002.html>

From hosking at cs.purdue.edu  Thu Mar 10 17:50:40 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 10 Mar 2011 11:50:40 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , , , ,
	, , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , ,
	, , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , , ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, ,
	, , , , , , , ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, ,
	, , , , , , , , ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , , ,
	, , , <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , , ,
	, , , <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , ,
	, , , , , , , <COL101-W4726257303F22627175774E6C30@phx.gbl>, , ,
	, , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , , ,
	, , , , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , ,
	, , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , , , , ,
	, , , , <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, !
	, , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , ,
	, , , <COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , , , , ,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , ,
	, , , , <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , , , , ,
	<COL101-W26D3B03885998122254013E6C70@phx.gbl>, , , ,
	<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>, , ,
	<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>, , ,
	<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>, , ,
	<COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>, ,
	<COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>,
	<COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>
	<COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>
Message-ID: <FDAEB2B4-BC12-45DB-8F60-639A9B8E48EF@cs.purdue.edu>

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>

From dabenavidesd at yahoo.es  Thu Mar 10 20:19:00 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 10 Mar 2011 19:19:00 +0000 (GMT)
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <FDAEB2B4-BC12-45DB-8F60-639A9B8E48EF@cs.purdue.edu>
Message-ID: <291871.70222.qm@web29714.mail.ird.yahoo.com>

Hi all:
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.
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.
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.
Thanks in advance

--- El jue, 10/3/11, Tony Hosking <hosking at cs.purdue.edu> escribi?:

De: Tony Hosking <hosking at cs.purdue.edu>
Asunto: Re: [M3devel] results of threadtest program on Windows7
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 10 de marzo, 2011 11:50

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/3b78b82d/attachment-0002.html>

From jay.krell at cornell.edu  Thu Mar 10 22:03:58 2011
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 10 Mar 2011 21:03:58 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <FDAEB2B4-BC12-45DB-8F60-639A9B8E48EF@cs.purdue.edu>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , ,
	, , , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , ,
	, , , 
	, , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , ,
	, , , 
	, , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , , , , , ,
	, , 
	, , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , , ,
	, , , 
	, <D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , , , , ,
	, , 
	, , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , , , , ,
	, , 
	<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , , ,,, , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , , , , , , ,
	, <COL101-W4726257303F22627175774E6C30@phx.gbl>, , ,,, , , , , ,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , , , , ,
	, , , 
	<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , ,,, , , , , ,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , , , , , , ,
	, , , 
	<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, !, , , , , , , , ,
	, 
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , , , ,
	, , <COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , , , , ,,, ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , ,,, , , ,
	<COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , , , ,
	,,<COL101-W26D3B03885998122254013E6C70@phx.gbl>, , ,
	,,<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>, ,
	,,<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>, ,
	,,<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>, ,
	,,<COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>,
	, , <COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>, ,
	<COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>,
	<COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>,
	<FDAEB2B4-BC12-45DB-8F60-639A9B8E48EF@cs.purdue.edu>
Message-ID: <COL101-w573D2FF7546A4BCDD27275E6C80@phx.gbl>


I often forget this. Thank you.

 - Jay

From: hosking at cs.purdue.edu
Date: Thu, 10 Mar 2011 11:50:40 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] results of threadtest program on Windows7



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/35d57c4d/attachment-0002.html>

From jay.krell at cornell.edu  Sat Mar 12 10:57:13 2011
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 12 Mar 2011 09:57:13 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-w573D2FF7546A4BCDD27275E6C80@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , ,
	, , , , , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , ,
	, , , , 
	, , , , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , ,
	, , 
	, , , , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , ,
	, , , , 
	, , , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , ,
	, , , , 
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , ,
	, , , 
	, , , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , ,
	, , , , 
	,,<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , , ,,, ,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , , , , ,
	, , ,,<COL101-W4726257303F22627175774E6C30@phx.gbl>, , ,,, , , , ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , , ,
	, , , , 
	,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , ,,, , , , ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , , , , ,
	, , , , 
	, , <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, !, , , , , , ,
	, , 
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , ,
	, , , 
	,,<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , , , , ,,,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , ,,, , ,
	,,<COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , , ,
	,,,,<COL101-W26D3B03885998122254013E6C70@phx.gbl>, ,
	,,,,<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>,
	,,,,<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>,
	,,,,<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>,
	, , , , <COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>, , , ,
	<COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>, ,
	<COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>,
	<COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>,
	<FDAEB2B4-BC12-45DB-8F60-639A9B8E48EF@cs.purdue.edu>,
	<COL101-w573D2FF7546A4BCDD27275E6C80@phx.gbl>
Message-ID: <COL101-w65CBD25BD3FC0BFF9115BBE6CA0@phx.gbl>


There is a lack of evidence that Java does things in a way at all resembling what Modula-3 does, on Win32.
 There is precious little in the way of calling the Win32 functions SuspendThread and GetThreadContext.
There is evidence that they use cooperative suspend.
It isn't conclusive, to me..just because there is so much there, it is not immediately clear.
That is, pretty clear there is code implementing cooperative suspend, but is that their entire story? I don't know.

 - Jay

From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] results of threadtest program on Windows7
Date: Thu, 10 Mar 2011 21:03:58 +0000








I often forget this. Thank you.

 - Jay

From: hosking at cs.purdue.edu
Date: Thu, 10 Mar 2011 11:50:40 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] results of threadtest program on Windows7



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/20110312/0a47c8d0/attachment-0002.html>

From hosking at cs.purdue.edu  Sat Mar 12 17:23:04 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 12 Mar 2011 11:23:04 -0500
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-w65CBD25BD3FC0BFF9115BBE6CA0@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , , , ,
	, , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	, , , , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , , ,
	, , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , , , , ,
	, , , , , , ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , ,
	, , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , ,
	, , , , , , , ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , , ,
	, , , , , <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , ,
	, , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , , ,
	, , , , , , <COL101-W4726257303F22627175774E6C30@phx.gbl>, , , ,
	, , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , , ,
	, , , , , , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>,
	, , , , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , , , , ,
	, , , , , , <44BAC21C-4375-478B-9FDF-27181181D7!
	65@cs.purdue.edu>, !, , , , , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , ,
	, , , , , <COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , , ,
	, , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , , , ,
	, , , , <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , , , , ,
	, , <COL101-W26D3B03885998122254013E6C70@phx.gbl>, , , , , ,
	<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>, , , , ,
	<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>, , , , ,
	<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>, , , , ,
	<COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>, , , ,
	<COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>, ,
	<COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>,
	<COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>,
	<FDAEB2B4-BC12-45DB-8F60-639A9B8E48EF@cs.purdue.edu>,
	<COL101-w573D2FF7546A4BCDD27275E6C80@phx.gbl>
	<COL101-w65CBD25BD3FC0BFF9115BBE6CA0@phx.gbl>
Message-ID: <8972478C-50D2-41D1-8DEB-57323B1D3580@cs.purdue.edu>

I know they use cooperative suspend.
We do in Jikes RVM too.
That's another code base to look at.  Probably easier as it is all in Java.

On Mar 12, 2011, at 4:57 AM, Jay K wrote:

> There is a lack of evidence that Java does things in a way at all resembling what Modula-3 does, on Win32.
>  There is precious little in the way of calling the Win32 functions SuspendThread and GetThreadContext.
> There is evidence that they use cooperative suspend.
> It isn't conclusive, to me..just because there is so much there, it is not immediately clear.
> That is, pretty clear there is code implementing cooperative suspend, but is that their entire story? I don't know.
> 
>  - Jay
> 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] results of threadtest program on Windows7
> Date: Thu, 10 Mar 2011 21:03:58 +0000
> 
> I often forget this. Thank you.
> 
>  - Jay
> 
> From: hosking at cs.purdue.edu
> Date: Thu, 10 Mar 2011 11:50:40 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> 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/20110312/3f9c933e/attachment-0002.html>

From jay.krell at cornell.edu  Sun Mar 13 01:40:36 2011
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 13 Mar 2011 00:40:36 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <8972478C-50D2-41D1-8DEB-57323B1D3580@cs.purdue.edu>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , ,
	, , , , , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , ,
	, , , , 
	, , , , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , ,
	, , 
	, , , , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , ,
	, , , , 
	, , , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , ,
	, , , , 
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , ,
	, , , 
	, , , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , ,
	, , , , 
	,,<COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , , ,,, ,
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , , , , ,
	, , ,,<COL101-W4726257303F22627175774E6C30@phx.gbl>, , ,,, , , , ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , , ,
	, , , , 
	,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , ,,, , , , ,
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , , , , ,
	, , , , 
	, , <44BAC21C-4375-478B-9FDF-27181181D7!, 65@cs.purdue.edu>, !, , , , , ,
	, , , 
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , ,
	, , , 
	,,<COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , , , , ,,,
	,,<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , ,,, , ,
	,,<COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , , ,
	,,,,<COL101-W26D3B03885998122254013E6C70@phx.gbl>, ,
	,,,,<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>,
	,,,,<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>,
	,,,,<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>,
	, , , , <COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>, , , ,
	<COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>, ,
	<COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>,
	<COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>,
	<FDAEB2B4-BC12-45DB-8F60-639A9B8E48EF@cs.purdue.edu>,
	<COL101-w573D2FF7546A4BCDD27275E6C80@phx.gbl>
	<COL101-w65CBD25BD3FC0BFF9115BBE6CA0@phx.gbl>,
	<8972478C-50D2-41D1-8DEB-57323B1D3580@cs.purdue.edu>
Message-ID: <COL101-W640F123E3C9A858317508E6CD0@phx.gbl>


I thought maybe they'd show a way for us to get away with "preemptive suspend",
a way to use SuspendThread/GetThreadContext with confidence.

So, you agree we want cooperative suspend then?
And we should maybe get going on implementing it?
Maybe do that before debugging Mika's problem?
  Well, to repeat myself, I'm ok with looking into 32bit-only Windows for Mika's problem.
  Though, clearly, as i've said, I have A LOT less time for Modula-3 now and probably ever.

 - Jay

Subject: Re: [M3devel] results of threadtest program on Windows7
From: hosking at cs.purdue.edu
Date: Sat, 12 Mar 2011 11:23:04 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu



I know they use cooperative suspend.We do in Jikes RVM too.That's another code base to look at.  Probably easier as it is all in Java.

On Mar 12, 2011, at 4:57 AM, Jay K wrote:There is a lack of evidence that Java does things in a way at all resembling what Modula-3 does, on Win32.
 There is precious little in the way of calling the Win32 functions SuspendThread and GetThreadContext.
There is evidence that they use cooperative suspend.
It isn't conclusive, to me..just because there is so much there, it is not immediately clear.
That is, pretty clear there is code implementing cooperative suspend, but is that their entire story? I don't know.

 - Jay

From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] results of threadtest program on Windows7
Date: Thu, 10 Mar 2011 21:03:58 +0000

I often forget this. Thank you.

 - Jay

From: hosking at cs.purdue.edu
Date: Thu, 10 Mar 2011 11:50:40 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] results of threadtest program on Windows7

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/20110313/8d270d25/attachment-0002.html>

From hosking at cs.purdue.edu  Sun Mar 13 19:08:10 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 13 Mar 2011 14:08:10 -0400
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <COL101-W640F123E3C9A858317508E6CD0@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , , , ,
	, , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, ,
	, , , , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , , , , ,
	, , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, , , , , ,
	, , , , , , ,
	<20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , ,
	, , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , ,
	, , , , , , , ,
	<20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , , ,
	, , , , , <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , ,
	, , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , , ,
	, , , , , , <COL101-W4726257303F22627175774E6C30@phx.gbl>, , , ,
	, , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , , ,
	, , , , , , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>,
	, , , , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , , , , ,
	, , , , , , <44BAC21C-4375-478B-9FDF-27181181D7!
	!, 65@cs.purdue.edu>, !, , , , , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , , , , ,
	, , , , , <COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , , ,
	, , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , , , ,
	, , , , <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , , , , ,
	, , <COL101-W26D3B03885998122254013E6C70@phx.gbl>, , , , , ,
	<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>, , , , ,
	<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>, , , , ,
	<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>, , , , ,
	<COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>, , , ,
	<COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>, ,
	<COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>,
	<COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>,
	<FDAEB2B4-BC12-45DB-8F60-639A9B8E48EF@cs.purdue.edu>,
	<COL101-w573D2FF7546A4BCDD27275E6C80@phx.gbl>
	<COL101-w65CBD25BD3FC0BFF9115BBE6CA0@phx.gbl>,
	<8972478C-50D2-41D1-8DEB-57323B1D3580@cs.purdue.edu>
	<COL101-W640F123E3C9A858317508E6CD0@phx.gbl>
Message-ID: <685C8B05-23D1-4BE8-93BB-3B11FFD28AFF@cs.purdue.edu>

I'd like to debug the current problem because it does not seem to imply any problem with suspend/resume.  More likely is losing a reference in the stacks somehow.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On Mar 12, 2011, at 7:40 PM, Jay K wrote:

> I thought maybe they'd show a way for us to get away with "preemptive suspend",
> a way to use SuspendThread/GetThreadContext with confidence.
> 
> So, you agree we want cooperative suspend then?
> And we should maybe get going on implementing it?
> Maybe do that before debugging Mika's problem?
>   Well, to repeat myself, I'm ok with looking into 32bit-only Windows for Mika's problem.
>   Though, clearly, as i've said, I have A LOT less time for Modula-3 now and probably ever.
> 
>  - Jay
> 
> Subject: Re: [M3devel] results of threadtest program on Windows7
> From: hosking at cs.purdue.edu
> Date: Sat, 12 Mar 2011 11:23:04 -0500
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> I know they use cooperative suspend.
> We do in Jikes RVM too.
> That's another code base to look at.  Probably easier as it is all in Java.
> 
> On Mar 12, 2011, at 4:57 AM, Jay K wrote:
> 
> There is a lack of evidence that Java does things in a way at all resembling what Modula-3 does, on Win32.
>  There is precious little in the way of calling the Win32 functions SuspendThread and GetThreadContext.
> There is evidence that they use cooperative suspend.
> It isn't conclusive, to me..just because there is so much there, it is not immediately clear.
> That is, pretty clear there is code implementing cooperative suspend, but is that their entire story? I don't know.
> 
>  - Jay
> 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] results of threadtest program on Windows7
> Date: Thu, 10 Mar 2011 21:03:58 +0000
> 
> I often forget this. Thank you.
> 
>  - Jay
> 
> From: hosking at cs.purdue.edu
> Date: Thu, 10 Mar 2011 11:50:40 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] results of threadtest program on Windows7
> 
> 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/20110313/f58adf71/attachment-0002.html>

From dabenavidesd at yahoo.es  Sun Mar 13 21:34:27 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sun, 13 Mar 2011 20:34:27 +0000 (GMT)
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <685C8B05-23D1-4BE8-93BB-3B11FFD28AFF@cs.purdue.edu>
Message-ID: <895304.26763.qm@web29717.mail.ird.yahoo.com>

Hi all:
I was wondering how it might to produce an environment such of gcc level compatibility, without breaking the runtime in two languages, that is sort of the idea I guess never fully released GNU Modula-3. Perhaps that was the idea of RMS, to make compatible interfaces so anything misbehaved in any platform could be replaced with something more usable for those purposes (and so he was just interested in code generator that accompanied m3tk) see:
http://opensource.apple.com/source/gcc/gcc-5479/boehm-gc/doc/README.macros

So in that case we could use some of the RT requirements more easily and give each platform free compatibility of our RT so more freedom for further developments, say GPL interface against implementations, etc and stabilize more the RT in terms of more up to date requirements, with openjdk, or any other RT, even OS deprecated ones (say we would want that applied in Android OS or any other lightweight system e.g Java I/O subsystem borrow):

http://www.semiramis.org.uk/rrw/software/misc/ksynch.html

Indeed a contracted developer by MIT developed such automating of information recovery from C interfaces (well an OO C dialect) to link with Modula-3 runtime without too much replication and much more smoothly? results? in terms of stability of? Modula-3 RT such e.g apply it too Atoms, etc with full compatiblity if so:
http://www.doc.ic.ac.uk/~pcc03/transfer.pdf
Perhaps this way can we reuse some more time of current developers and historical ones too, which I believe are very important too (especially ESC in Java for any kind of developer even from smartphones and innovative systems like? see:
http://whiley.org/about/overview/
).

Thanks in advance

--- El dom, 13/3/11, Tony Hosking <hosking at cs.purdue.edu> escribi?:

De: Tony Hosking <hosking at cs.purdue.edu>
Asunto: Re: [M3devel] results of threadtest program on Windows7
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: domingo, 13 de marzo, 2011 13:08

I'd like to debug the current problem because it does not seem to imply any problem with suspend/resume. ?More likely is losing a reference in the stacks somehow.

Antony Hosking?|?Associate Professor?| Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice?+1 765 494 6001 |?Mobile?+1 765 427 5484





On Mar 12, 2011, at 7:40 PM, Jay K wrote:
I thought maybe they'd show a way for us to get away with "preemptive suspend",
a way to use SuspendThread/GetThreadContext with confidence.

So, you agree we want cooperative suspend then?
And we should maybe get going on implementing it?
Maybe do that before debugging Mika's problem?
? Well, to repeat myself, I'm ok with looking into 32bit-only Windows for Mika's problem.
? Though, clearly, as i've said, I have A LOT less time for Modula-3 now and probably ever.

?- Jay

Subject: Re: [M3devel] results of threadtest program on Windows7
From:?hosking at cs.purdue.edu
Date: Sat, 12 Mar 2011 11:23:04 -0500
CC:?m3devel at elegosoft.com
To:?jay.krell at cornell.edu

I know they use cooperative suspend.We do in Jikes RVM too.That's another code base to look at. ?Probably easier as it is all in Java.
On Mar 12, 2011, at 4:57 AM, Jay K wrote:
There is a lack of evidence that Java does things in a way at all resembling what Modula-3 does, on Win32.
?There is precious little in the way of calling the Win32 functions SuspendThread and GetThreadContext.
There is evidence that they use cooperative suspend.
It isn't conclusive, to me..just because there is so much there, it is not immediately clear.
That is, pretty clear there is code implementing cooperative suspend, but is that their entire story? I don't know.

?- Jay

From:?jay.krell at cornell.edu
To:?hosking at cs.purdue.edu
CC:?m3devel at elegosoft.com
Subject: RE: [M3devel] results of threadtest program on Windows7
Date: Thu, 10 Mar 2011 21:03:58 +0000

I often forget this. Thank you.

?- Jay

From:?hosking at cs.purdue.edu
Date: Thu, 10 Mar 2011 11:50:40 -0500
To:?jay.krell at cornell.edu
CC:?m3devel at elegosoft.com
Subject: Re: [M3devel] results of threadtest program on Windows7

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/20110313/c6361136/attachment-0002.html>

From dabenavidesd at yahoo.es  Sun Mar 13 21:44:39 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sun, 13 Mar 2011 20:44:39 +0000 (GMT)
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <895304.26763.qm@web29717.mail.ird.yahoo.com>
Message-ID: <234847.43171.qm@web29704.mail.ird.yahoo.com>

Hi all:
instead of before http://www.doc.ic.ac.uk/~pcc03/transfer.pdf
see:
ftp://asg3.andrew.cmu.edu/pub/AUIS/auis-6.3.1/doc/papers/atk/conference/Orgass.paper.ps
at cmu, the first at another too. 
Sorry, thanks in advance

--- El dom, 13/3/11, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] results of threadtest program on Windows7
Para: "Jay K" <jay.krell at cornell.edu>, "Tony Hosking" <hosking at cs.purdue.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: domingo, 13 de marzo, 2011 15:34

Hi all:
I was wondering how it might to produce an environment such of gcc level compatibility, without breaking the runtime in two languages, that is sort of the idea I guess never fully released GNU Modula-3. Perhaps that was the idea of RMS, to make compatible interfaces so anything misbehaved in any platform could be replaced with something more usable for those purposes (and so he was just interested in code generator that accompanied m3tk) see:
http://opensource.apple.com/source/gcc/gcc-5479/boehm-gc/doc/README.macros

So in that case we could use some of the RT requirements more easily and give each platform free compatibility of our RT so more freedom for further developments, say GPL interface against implementations, etc and stabilize more the RT in terms of more up to date requirements, with openjdk, or any other RT, even OS deprecated
 ones (say we would want that applied in Android OS or any other lightweight system e.g Java I/O subsystem borrow):

http://www.semiramis.org.uk/rrw/software/misc/ksynch.html

Indeed a contracted developer by MIT developed such automating of information recovery from C interfaces (well an OO C dialect) to link with Modula-3 runtime without too much replication and much more smoothly? results? in terms of stability of? Modula-3 RT such e.g apply it too Atoms, etc with full compatiblity if so:
http://www.doc.ic.ac.uk/~pcc03/transfer.pdf
Perhaps this way can we reuse some more time of current developers and historical ones too, which I believe are very important too (especially ESC in Java for any kind of developer even from smartphones and innovative systems like? see:
http://whiley.org/about/overview/
).

Thanks in advance

--- El dom, 13/3/11, Tony Hosking <hosking at cs.purdue.edu>
 escribi?:

De: Tony Hosking <hosking at cs.purdue.edu>
Asunto: Re: [M3devel] results of threadtest program on Windows7
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: domingo, 13 de marzo, 2011 13:08

I'd like to debug the current problem because it does not seem to imply any problem with suspend/resume. ?More likely is losing a reference in the stacks somehow.

Antony
 Hosking?|?Associate Professor?| Computer Science | Purdue University305 N. University
 Street | West Lafayette | IN 47907 | USAOffice?+1 765 494 6001 |?Mobile?+1 765 427 5484





On Mar 12, 2011, at 7:40 PM, Jay K wrote:
I thought maybe they'd show a way for us to get away with "preemptive suspend",
a way to use SuspendThread/GetThreadContext with confidence.

So, you agree we want cooperative suspend then?
And we should maybe get going on implementing it?
Maybe do that before debugging Mika's problem?
? Well, to repeat myself, I'm ok with looking into 32bit-only Windows for Mika's problem.
? Though,
 clearly, as i've said, I have A LOT less time for Modula-3 now and probably ever.

?- Jay

Subject: Re: [M3devel] results of threadtest program on Windows7
From:?hosking at cs.purdue.edu
Date: Sat, 12 Mar 2011 11:23:04 -0500
CC:?m3devel at elegosoft.com
To:?jay.krell at cornell.edu

I know they use cooperative suspend.We do in Jikes RVM
 too.That's another code base to look at. ?Probably easier as it is all in Java.
On Mar 12, 2011, at 4:57 AM, Jay K wrote:
There is a lack of evidence that Java does things in a way at all resembling what Modula-3 does, on Win32.
?There is precious little in the way of calling the Win32 functions SuspendThread and GetThreadContext.
There is evidence that they use cooperative suspend.
It isn't conclusive, to me..just because there is so much
 there, it is not immediately clear.
That is, pretty clear there is code implementing cooperative suspend, but is that their entire story? I don't know.

?- Jay

From:?jay.krell at cornell.edu
To:?hosking at cs.purdue.edu
CC:?m3devel at elegosoft.com
Subject: RE: [M3devel] results of threadtest program on Windows7
Date: Thu, 10 Mar 2011 21:03:58
 +0000

I often forget this. Thank you.

?- Jay

From:?hosking at cs.purdue.edu
Date: Thu, 10 Mar 2011 11:50:40 -0500
To:?jay.krell at cornell.edu
CC:?m3devel at elegosoft.com
Subject: Re: [M3devel] results of threadtest program on Windows7

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/20110313/5435f0b3/attachment-0002.html>

From jay.krell at cornell.edu  Sun Mar 13 23:34:06 2011
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 13 Mar 2011 22:34:06 +0000
Subject: [M3devel] results of threadtest program on Windows7
In-Reply-To: <685C8B05-23D1-4BE8-93BB-3B11FFD28AFF@cs.purdue.edu>
References: <D67F02DDC62F7545A6B84C285F88F3E6EE25C849@atlex02-srv>, , , , ,
	, , , , , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , ,
	, , , , , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C863@atlex02-srv>, , 
	, , , , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE25C868@atlex02-srv>, 
	, , , , ,,, , , , , ,
	, , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , , , ,
	, , , 
	, , , <D67F02DDC62F7545A6B84C285F88F3E6EE25C869@atlex02-srv>, , , , , , ,
	, , , 
	, , , , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , ,
	, 
	, , , , , , , <COL101-W2882A84597FD276A3FD4BFE6C10@phx.gbl>, , , , , , ,
	, , , , 
	, , , <D67F02DDC62F7545A6B84C285F88F3E6EE25D05D@atlex02-srv>, , , , , , ,
	, , , 
	, , , <COL101-W4726257303F22627175774E6C30@phx.gbl>, , , , , , , , , , ,
	, , 
	, , <D67F02DDC62F7545A6B84C285F88F3E6EE25D064@atlex02-srv>, , , , , , , ,
	, , , 
	, , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , , , , , , ,
	, , 
	, , , , <D67F02DDC62F7545A6B84C285F88F3E6EE526EBE@atlex02-srv>, , , , , ,
	, , , 
	, , , , <44BAC21C-4375-478B-9FDF-27181181D7!, !, 65@cs.purdue.edu>, !, ,
	, , , , , , , , , , , ,
	<D67F02DDC62F7545A6B84C285F88F3E6EE527209@atlex02-srv>, , 
	, , , , , , , , , , <COL101-W562F6B290D1FA93998AAE6E6C50@phx.gbl>, , , ,
	, , , , 
	, , , , , <D67F02DDC62F7545A6B84C285F88F3E6EE527232@atlex02-srv>, , , , ,
	, , , 
	, , , <COL101-W1162A9B603898CC921B557E6C70@phx.gbl>, , , , , ,,, ,
	<COL101-W26D3B03885998122254013E6C70@phx.gbl>, , , , ,
	,,<COL101-W53138C01E447E76B3C5081E6C70@phx.gbl>, , , ,
	,,<COL101-W10A75CCF1743F4BE827A1AE6C70@phx.gbl>, , , ,
	,,<COL101-W510B831AC595A3597FE281E6C70@phx.gbl>, , , ,
	,,<COL101-W189D1CDFCA71CF2A4924D3E6C90@phx.gbl>, , ,
	,,<COL101-W15C1D5EA0857D5DABEB21BE6C80@phx.gbl>,
	, , <COL101-W242088C3C3AE5EC5903F94E6C80@phx.gbl>, ,
	<COL101-W30B6DF3AF733D1C0B77711E6C80@phx.gbl>, ,
	<FDAEB2B4-BC12-45DB-8F60-639A9B8E48EF@cs.purdue.edu>, ,
	<COL101-w573D2FF7546A4BCDD27275E6C80@phx.gbl>,
	<COL101-w65CBD25BD3FC0BFF9115BBE6CA0@phx.gbl>, ,
	<8972478C-50D2-41D1-8DEB-57323B1D3580@cs.purdue.edu>,
	<COL101-W640F123E3C9A858317508E6CD0@phx.gbl>,
	<685C8B05-23D1-4BE8-93BB-3B11FFD28AFF@cs.purdue.edu>
Message-ID: <COL101-W27E336FE3D9BE3CC4F1320E6CD0@phx.gbl>


Huh? Imagine the stack/registers of a suspended thread cannot be reliably correctly retrieved.
That seems to be the case on wow64.
That would lead to these problems, right?
Anyone seen the tests fail on Win32 on a 32bit OS?
  Even so, I'd want to make sure that 32bit, we don't get the kernel thread context sometimes.
  But that shouldn't be hard to to detect and avoid, i.e. an out of range stack pointer.
I'll see how it goes on a 32bit Windows OS.

 - Jay

From: hosking at cs.purdue.edu
Date: Sun, 13 Mar 2011 14:08:10 -0400
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] results of threadtest program on Windows7



I'd like to debug the current problem because it does not seem to imply any problem with suspend/resume.  More likely is losing a reference in the stacks somehow.

Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484


On Mar 12, 2011, at 7:40 PM, Jay K wrote:I thought maybe they'd show a way for us to get away with "preemptive suspend",
a way to use SuspendThread/GetThreadContext with confidence.

So, you agree we want cooperative suspend then?
And we should maybe get going on implementing it?
Maybe do that before debugging Mika's problem?
  Well, to repeat myself, I'm ok with looking into 32bit-only Windows for Mika's problem.
  Though, clearly, as i've said, I have A LOT less time for Modula-3 now and probably ever.

 - Jay

Subject: Re: [M3devel] results of threadtest program on Windows7
From: hosking at cs.purdue.edu
Date: Sat, 12 Mar 2011 11:23:04 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

I know they use cooperative suspend.We do in Jikes RVM too.That's another code base to look at.  Probably easier as it is all in Java.
On Mar 12, 2011, at 4:57 AM, Jay K wrote:There is a lack of evidence that Java does things in a way at all resembling what Modula-3 does, on Win32.
 There is precious little in the way of calling the Win32 functions SuspendThread and GetThreadContext.
There is evidence that they use cooperative suspend.
It isn't conclusive, to me..just because there is so much there, it is not immediately clear.
That is, pretty clear there is code implementing cooperative suspend, but is that their entire story? I don't know.

 - Jay

From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] results of threadtest program on Windows7
Date: Thu, 10 Mar 2011 21:03:58 +0000

I often forget this. Thank you.

 - Jay

From: hosking at cs.purdue.edu
Date: Thu, 10 Mar 2011 11:50:40 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] results of threadtest program on Windows7

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/20110313/ee993653/attachment-0002.html>

From dabenavidesd at yahoo.es  Mon Mar 14 17:26:54 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 14 Mar 2011 16:26:54 +0000 (GMT)
Subject: [M3devel] About current DCVS and Elego Compact version to don't
	fear the fork
Message-ID: <224092.3263.qm@web29710.mail.ird.yahoo.com>

Hi all:
I just was wondering was the current status of integration if so of both tools, as I have been reading this techguide, see:
http://www.zdnetasia.com/don-t-fear-the-fork-how-dvcs-aids-open-source-development-62207783.htm?scid=nl_z_tgos

about forks and distributed control version systems (maybe that should I call it diversion?).
Ok, I read that some of the Modules are ready for cvsup in Elego-compact but what about dcvs, does it makes sense for it to have it if it's not already integrated, or would you have considered this before current elego compact release, if there is anything specific towards that integration if so what else would be needed or are they loosely coupled?
I appreciate any comments and opinion about doing that, for instance a given php developer which already has cvsup as its control version system mirror of cvs may want to contract someone to make a fork and so to do that.
Thanks in advance



      


From jay.krell at cornell.edu  Mon Mar 14 20:52:22 2011
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 14 Mar 2011 19:52:22 +0000
Subject: [M3devel] About current DCVS and Elego Compact version to don't
 fear the fork
In-Reply-To: <224092.3263.qm@web29710.mail.ird.yahoo.com>
References: <224092.3263.qm@web29710.mail.ird.yahoo.com>
Message-ID: <COL101-W426E1F003C66371CECA627E6CC0@phx.gbl>


Surely the answer is to use GIT or Mercurial or Monotone.
And not anything based on CVS.
 
 - Jay
 
> Date: Mon, 14 Mar 2011 16:26:54 +0000
> From: dabenavidesd at yahoo.es
> To: m3devel at elegosoft.com
> Subject: [M3devel] About current DCVS and Elego Compact version to don't fear the fork
> 
> Hi all:
> I just was wondering was the current status of integration if so of both tools, as I have been reading this techguide, see:
> http://www.zdnetasia.com/don-t-fear-the-fork-how-dvcs-aids-open-source-development-62207783.htm?scid=nl_z_tgos
> 
> about forks and distributed control version systems (maybe that should I call it diversion?).
> Ok, I read that some of the Modules are ready for cvsup in Elego-compact but what about dcvs, does it makes sense for it to have it if it's not already integrated, or would you have considered this before current elego compact release, if there is anything specific towards that integration if so what else would be needed or are they loosely coupled?
> I appreciate any comments and opinion about doing that, for instance a given php developer which already has cvsup as its control version system mirror of cvs may want to contract someone to make a fork and so to do that.
> Thanks in advance 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/9eab90bd/attachment-0002.html>

From wagner at elegosoft.com  Mon Mar 14 21:25:14 2011
From: wagner at elegosoft.com (Olaf Wagner)
Date: Mon, 14 Mar 2011 21:25:14 +0100
Subject: [M3devel] About current DCVS and Elego Compact version to	don't
	fear the fork
In-Reply-To: <COL101-W426E1F003C66371CECA627E6CC0@phx.gbl>
References: <224092.3263.qm@web29710.mail.ird.yahoo.com>
	<COL101-W426E1F003C66371CECA627E6CC0@phx.gbl>
Message-ID: <20110314212514.edcnep7i8wk8gwkc@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

>
> Surely the answer is to use GIT or Mercurial or Monotone.
> And not anything based on CVS.

Yes. There has never been enough interest in DCVS, though it was fully
functional and quite usable for its time. I would have recommended it
six years ago, but not today.

Olaf

>  - Jay
>
>> Date: Mon, 14 Mar 2011 16:26:54 +0000
>> From: dabenavidesd at yahoo.es
>> To: m3devel at elegosoft.com
>> Subject: [M3devel] About current DCVS and Elego Compact version to   
>> don't fear the fork
>>
>> Hi all:
>> I just was wondering was the current status of integration if so of  
>>  both tools, as I have been reading this techguide, see:
>> http://www.zdnetasia.com/don-t-fear-the-fork-how-dvcs-aids-open-source-development-62207783.htm?scid=nl_z_tgos
>>
>> about forks and distributed control version systems (maybe that   
>> should I call it diversion?).
>> Ok, I read that some of the Modules are ready for cvsup in   
>> Elego-compact but what about dcvs, does it makes sense for it to   
>> have it if it's not already integrated, or would you have   
>> considered this before current elego compact release, if there is   
>> anything specific towards that integration if so what else would be  
>>  needed or are they loosely coupled?
>> I appreciate any comments and opinion about doing that, for   
>> instance a given php developer which already has cvsup as its   
>> control version system mirror of cvs may want to contract someone   
>> to make a fork and so to do that.
>> Thanks in advance



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From dabenavidesd at yahoo.es  Mon Mar 14 22:04:04 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 14 Mar 2011 21:04:04 +0000 (GMT)
Subject: [M3devel] About current DCVS and Elego Compact version to don't
	fear the fork
In-Reply-To: <20110314212514.edcnep7i8wk8gwkc@mail.elegosoft.com>
Message-ID: <707155.91060.qm@web29716.mail.ird.yahoo.com>

Hi all:
Ok, in that sense, how easy would be to abstract it the control machinery of Elego ComPact from its version management (does it subversion classify as DVCS?).
Thanks in advance

--- El lun, 14/3/11, Olaf Wagner <wagner at elegosoft.com> escribi?:

> De: Olaf Wagner <wagner at elegosoft.com>
> Asunto: Re: [M3devel] About current DCVS and Elego Compact version to don't fear the fork
> Para: m3devel at elegosoft.com
> Fecha: lunes, 14 de marzo, 2011 15:25
> Quoting Jay K <jay.krell at cornell.edu>:
> 
> > 
> > Surely the answer is to use GIT or Mercurial or
> Monotone.
> > And not anything based on CVS.
> 
> Yes. There has never been enough interest in DCVS, though
> it was fully
> functional and quite usable for its time. I would have
> recommended it
> six years ago, but not today.
> 
> Olaf
> 
> >  - Jay
> > 
> >> Date: Mon, 14 Mar 2011 16:26:54 +0000
> >> From: dabenavidesd at yahoo.es
> >> To: m3devel at elegosoft.com
> >> Subject: [M3devel] About current DCVS and Elego
> Compact version to  don't fear the fork
> >> 
> >> Hi all:
> >> I just was wondering was the current status of
> integration if so of  both tools, as I have been
> reading this techguide, see:
> >> http://www.zdnetasia.com/don-t-fear-the-fork-how-dvcs-aids-open-source-development-62207783.htm?scid=nl_z_tgos
> >> 
> >> about forks and distributed control version
> systems (maybe that  should I call it diversion?).
> >> Ok, I read that some of the Modules are ready for
> cvsup in  Elego-compact but what about dcvs, does it
> makes sense for it to  have it if it's not already
> integrated, or would you have  considered this before
> current elego compact release, if there is  anything
> specific towards that integration if so what else would
> be  needed or are they loosely coupled?
> >> I appreciate any comments and opinion about doing
> that, for  instance a given php developer which already
> has cvsup as its  control version system mirror of cvs
> may want to contract someone  to make a fork and so to
> do that.
> >> Thanks in advance
> 
> 
> 
> --Olaf Wagner -- elego Software Solutions GmbH
>            
>    Gustav-Meyer-Allee 25 / Geb?ude 12, 13355
> Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345
> 869  fax: +49 30 23 45 86 95
>    http://www.elegosoft.com |
> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 |
> USt-IdNr: DE163214194
> 
> 


      


From rcolebur at SCIRES.COM  Mon Mar 14 22:14:20 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Mon, 14 Mar 2011 17:14:20 -0400
Subject: [M3devel] question re LONGINT
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E603418BD67F@atlex02-srv>

I was making some local mods to Mika's threadtest program to help me debug things a bit more on Windows.

I am trying to do:
   INC(counts[i]);
Where counts is REF ARRAY OF LONGINT

The compiler is complaining:
"..\src\Main.m3", line 189: ** INTERNAL CG ERROR *** unable to find integer type?  type=Int.64  s/o/a=64/0/32

I'm not sure what the status of LONGINT is on Windows.  If it is not fully implemented, let me know and I'll switch to REF ARRAY OF INTEGER, but I really need LONGINT.

Regards,
Randy Coleburn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/937a33f2/attachment-0002.html>

From hosking at cs.purdue.edu  Mon Mar 14 22:21:01 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 14 Mar 2011 17:21:01 -0400
Subject: [M3devel] question re LONGINT
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BD67F@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BD67F@atlex02-srv>
Message-ID: <82BC458A-AEC4-4148-B65D-D6B4B0692CDD@cs.purdue.edu>

This is a known problem which I am still to fix.  I know what the issue is...
You can probably make do by reading counts[i] to a variable, incrementing, and assigning.

On Mar 14, 2011, at 5:14 PM, Coleburn, Randy wrote:

> I was making some local mods to Mika?s threadtest program to help me debug things a bit more on Windows.
>  
> I am trying to do:
>    INC(counts[i]);
> Where counts is REF ARRAY OF LONGINT
>  
> The compiler is complaining:
> "..\src\Main.m3", line 189: ** INTERNAL CG ERROR *** unable to find integer type?  type=Int.64  s/o/a=64/0/32
>  
> I?m not sure what the status of LONGINT is on Windows.  If it is not fully implemented, let me know and I?ll switch to REF ARRAY OF INTEGER, but I really need LONGINT.
>  
> Regards,
> Randy Coleburn
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/4b0192d1/attachment-0002.html>

From jay.krell at cornell.edu  Mon Mar 14 23:33:43 2011
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 14 Mar 2011 22:33:43 +0000
Subject: [M3devel] question re LONGINT
In-Reply-To: <82BC458A-AEC4-4148-B65D-D6B4B0692CDD@cs.purdue.edu>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BD67F@atlex02-srv>,
	<82BC458A-AEC4-4148-B65D-D6B4B0692CDD@cs.purdue.edu>
Message-ID: <COL101-W1613B5382CDB4AA0998526E6CC0@phx.gbl>


 - That error is likely from the frontend and will likely occur for any target. Tony's reply implies this as well.
 
 - LONGINT is believed to fully work on NT386. But more testing is welcome.
 
 - (atomics ditto -- believed to work, testing welcome -- and we should probably use them some, e.g. in MUTEX initialization)
 
 - I would be curious to see if threadtest only fails on 64bit Windows. I haven't tried 32bit yet but I will soon.
   - I was thinking more about this WOW64 GetThreadContext problem and ways to mitigate it, other than cooperative suspend.
     I had already suggested and started to implement scanning the entire stack -- i.e. not depending on an ability to get ESP from a suspended thread.
     Like how FreeBSD and OpenBSD work, albeit it is a significant deoptimization.
     Regarding the rest of the context, perhaps it is a reasonable assumption for now to declare that it doesn't matter? e.g. to know/assume
     that m3back never leaves a value only in registers, that anything in a register will also be on the stack? And to disable optimization on the
     hypothetical MINGW platforms. ?
     But still to confirm if there are no problems on 32bit, and to mull over implementing cooperative suspend..in the little time available...
     (Oh, and also, I wonder if SuspendThread can suspend a thread while in the kernel, probably, and if GetThreadContext returns
     the kernel context in that case; should be easy to determine via some experimentation -- which would imply a problem on 32bit Windows also.)
 
 
 - Jay
 


From: hosking at cs.purdue.edu
Date: Mon, 14 Mar 2011 17:21:01 -0400
To: rcolebur at SCIRES.COM
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] question re LONGINT


This is a known problem which I am still to fix.  I know what the issue is...
You can probably make do by reading counts[i] to a variable, incrementing, and assigning.




On Mar 14, 2011, at 5:14 PM, Coleburn, Randy wrote:



I was making some local mods to Mika?s threadtest program to help me debug things a bit more on Windows.
 
I am trying to do:
   INC(counts[i]);
Where counts is REF ARRAY OF LONGINT
 
The compiler is complaining:
"..\src\Main.m3", line 189: ** INTERNAL CG ERROR *** unable to find integer type?  type=Int.64  s/o/a=64/0/32
 
I?m not sure what the status of LONGINT is on Windows.  If it is not fully implemented, let me know and I?ll switch to REF ARRAY OF INTEGER, but I really need LONGINT.
 
Regards,
Randy Coleburn
 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/38fe3b7e/attachment-0002.html>

From rcolebur at SCIRES.COM  Mon Mar 14 23:45:44 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Mon, 14 Mar 2011 18:45:44 -0400
Subject: [M3devel] question on use of Time.Now in thread test program
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E603418BD6A3@atlex02-srv>

I have a question/concern regarding Mika's thread test program.

Each of the threads makes use of the Time.Now() call during each iteration of the thread's main loop.

I haven't fully investigated, but does anyone have concern that so many calls to the system clock from multiple competing threads might have some side effect on the running of multiple threads?

I've also done some limited experimentation with use of counters to see how many times each type of thread is able to go thru its loop between reporting intervals.

I continue to see various types of crashes on Windows 7 (64-bit), but sometimes tests are able to succeed.  I haven't found a repeatable pattern yet to the crashes, so I am still investigating, but just thought it worth asking the above question about use of Time.Now().

I will also try to experiment with Windows XP 32-bit and report back.

Regards,
Randy Coleburn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/4fc9452e/attachment-0002.html>

From jay.krell at cornell.edu  Tue Mar 15 00:07:15 2011
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 14 Mar 2011 23:07:15 +0000
Subject: [M3devel] question on use of Time.Now in thread test program
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BD6A3@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BD6A3@atlex02-srv>
Message-ID: <COL101-W16E61CE9DCE94C7C824631E6CC0@phx.gbl>


Time.Now() is very cheap on Windows and should cause no concern.
It is just GetSystemTimeAsFileTime, which just reads some globals, followed by a simple unit and integer to double conversion.
I would avoid 64bit Windows for now, very unfortunate, but I don't trust GetThreadContext.
 
 
PROCEDURE Now(): T=
  VAR
    fileTime: WinBase.FILETIME;
  BEGIN
    WinBase.GetSystemTimeAsFileTime(fileTime);
    RETURN TimeWin32.FromFileTime(fileTime);
  END Now;


double
__cdecl
TimeWin32__FromFileTime(FILETIME ft)
{
    LARGE_INTEGER li;

    li.LowPart = ft.dwLowDateTime;
    li.HighPart = ft.dwHighDateTime;
    return ((double)li.QuadPart) / 1.0e7;
}


Hm -- I don't like passing structs by value, too hard to be sure how it works -- I'd like to change this to be "READONLY" -- passed by pointer.
Maybe code the entire thing in Modula-3 -- or more likely, the entire thing in C.
 
Time.Now() might be more expensive on other platform, I don't know.
 
I also see some failures, some success, no pattern.
I think the success is just luck and the code is by its nature very non-deterministic.
 
 - Jay
 


From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Mon, 14 Mar 2011 18:45:44 -0400
Subject: [M3devel] question on use of Time.Now in thread test program






I have a question/concern regarding Mika?s thread test program.
 
Each of the threads makes use of the Time.Now() call during each iteration of the thread?s main loop.  
 
I haven?t fully investigated, but does anyone have concern that so many calls to the system clock from multiple competing threads might have some side effect on the running of multiple threads?
 
I?ve also done some limited experimentation with use of counters to see how many times each type of thread is able to go thru its loop between reporting intervals.
 
I continue to see various types of crashes on Windows 7 (64-bit), but sometimes tests are able to succeed.  I haven?t found a repeatable pattern yet to the crashes, so I am still investigating, but just thought it worth asking the above question about use of Time.Now().
 
I will also try to experiment with Windows XP 32-bit and report back.
 
Regards,
Randy Coleburn 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/b0dca15e/attachment-0002.html>

From dabenavidesd at yahoo.es  Tue Mar 15 00:21:49 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 14 Mar 2011 23:21:49 +0000 (GMT)
Subject: [M3devel] question on use of Time.Now in thread test program
In-Reply-To: <COL101-W16E61CE9DCE94C7C824631E6CC0@phx.gbl>
Message-ID: <569254.84801.qm@web29712.mail.ird.yahoo.com>

Hi all:
see at:
http://www.ic.unicamp.br/~stolfi/EXPORT/software/m3/Misc.html 

CPUTime module.
Thanks in advance

--- El lun, 14/3/11, Jay K <jay.krell at cornell.edu> escribi?:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] question on use of Time.Now in thread test program
Para: rcolebur at scires.com, "m3devel" <m3devel at elegosoft.com>
Fecha: lunes, 14 de marzo, 2011 18:07




Time.Now() is very cheap on Windows and should cause no concern.

It is just GetSystemTimeAsFileTime, which just reads some globals, followed by a simple unit and integer to double conversion.

I would avoid 64bit Windows for now, very unfortunate, but I don't trust GetThreadContext.

?

?

PROCEDURE Now(): T=
? VAR
??? fileTime: WinBase.FILETIME;
? BEGIN
??? WinBase.GetSystemTimeAsFileTime(fileTime);
??? RETURN TimeWin32.FromFileTime(fileTime);
? END Now;



double
__cdecl
TimeWin32__FromFileTime(FILETIME ft)
{
??? LARGE_INTEGER li;

??? li.LowPart = ft.dwLowDateTime;
??? li.HighPart = ft.dwHighDateTime;
??? return ((double)li.QuadPart) / 1.0e7;
}



Hm -- I don't like passing structs by value, too hard to be sure how it works -- I'd like to change this to be "READONLY" -- passed by pointer.

Maybe code the entire thing in Modula-3 -- or more likely, the entire thing in C.

?

Time.Now() might be more expensive on other platform, I don't know.

?

I also see some failures, some success, no pattern.

I think the success is just luck and the code is by its nature very non-deterministic.

?

?- Jay
?



From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Mon, 14 Mar 2011 18:45:44 -0400
Subject: [M3devel] question on use of Time.Now in thread test program


 

#yiv1082952660 .yiv1082952660ExternalClass p.yiv1082952660ecxMsoNormal, #yiv1082952660 .yiv1082952660ExternalClass li.yiv1082952660ecxMsoNormal, #yiv1082952660 .yiv1082952660ExternalClass div.yiv1082952660ecxMsoNormal
{margin-bottom:.0001pt;font-size:11.0pt;font-family:'sans-serif';}
#yiv1082952660 .yiv1082952660ExternalClass a:link, #yiv1082952660 .yiv1082952660ExternalClass span.yiv1082952660ecxMsoHyperlink
{color:blue;text-decoration:underline;}
#yiv1082952660 .yiv1082952660ExternalClass a:visited, #yiv1082952660 .yiv1082952660ExternalClass span.yiv1082952660ecxMsoHyperlinkFollowed
{color:purple;text-decoration:underline;}
#yiv1082952660 .yiv1082952660ExternalClass span.yiv1082952660ecxEmailStyle17
{font-family:'sans-serif';color:windowtext;}
#yiv1082952660 .yiv1082952660ExternalClass .yiv1082952660ecxMsoChpDefault
{}
 _filtered #yiv1082952660 {}
#yiv1082952660 .yiv1082952660ExternalClass div.yiv1082952660ecxWordSection1
{}




I have a question/concern regarding Mika?s thread test program.
?
Each of the threads makes use of the Time.Now() call during each iteration of the thread?s main loop.? 
?
I haven?t fully investigated, but does anyone have concern that so many calls to the system clock from multiple competing threads might have some side effect on the running of multiple threads?
?
I?ve also done some limited experimentation with use of counters to see how many times each type of thread is able to go thru its loop between reporting intervals.
?
I continue to see various types of crashes on Windows 7 (64-bit), but sometimes tests are able to succeed.? I haven?t found a repeatable pattern yet to the crashes, so I am still investigating, but just thought it worth asking the above question about use of Time.Now().
?
I will also try to experiment with Windows XP 32-bit and report back.
?
Regards,
Randy Coleburn 		 	   		  



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/5b36d1fd/attachment-0002.html>

From jay.krell at cornell.edu  Tue Mar 15 00:48:23 2011
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 14 Mar 2011 23:48:23 +0000
Subject: [M3devel] question on use of Time.Now in thread test program
In-Reply-To: <569254.84801.qm@web29712.mail.ird.yahoo.com>
References: <COL101-W16E61CE9DCE94C7C824631E6CC0@phx.gbl>,
	<569254.84801.qm@web29712.mail.ird.yahoo.com>
Message-ID: <COL101-W2A6D6D82DFF94AD42BA35E6CC0@phx.gbl>


Please don't use Uresource.struct_rusage in Modula-3.
I removed it. It is a portabilty/maintenance problem.
 
 - Jay

 


Date: Mon, 14 Mar 2011 23:21:49 +0000
From: dabenavidesd at yahoo.es
To: rcolebur at scires.com; m3devel at elegosoft.com; jay.krell at cornell.edu
Subject: Re: [M3devel] question on use of Time.Now in thread test program





Hi all:
see at:
http://www.ic.unicamp.br/~stolfi/EXPORT/software/m3/Misc.html 

CPUTime module.
Thanks in advance

--- El lun, 14/3/11, Jay K <jay.krell at cornell.edu> escribi?:


De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] question on use of Time.Now in thread test program
Para: rcolebur at scires.com, "m3devel" <m3devel at elegosoft.com>
Fecha: lunes, 14 de marzo, 2011 18:07




Time.Now() is very cheap on Windows and should cause no concern.
It is just GetSystemTimeAsFileTime, which just reads some globals, followed by a simple unit and integer to double conversion.
I would avoid 64bit Windows for now, very unfortunate, but I don't trust GetThreadContext.
 
 
PROCEDURE Now(): T=
  VAR
    fileTime: WinBase.FILETIME;
  BEGIN
    WinBase.GetSystemTimeAsFileTime(fileTime);
    RETURN TimeWin32.FromFileTime(fileTime);
  END Now;


double
__cdecl
TimeWin32__FromFileTime(FILETIME ft)
{
    LARGE_INTEGER li;

    li.LowPart = ft.dwLowDateTime;
    li.HighPart = ft.dwHighDateTime;
    return ((double)li.QuadPart) / 1.0e7;
}


Hm -- I don't like passing structs by value, too hard to be sure how it works -- I'd like to change this to be "READONLY" -- passed by pointer.
Maybe code the entire thing in Modula-3 -- or more likely, the entire thing in C.
 
Time.Now() might be more expensive on other platform, I don't know.
 
I also see some failures, some success, no pattern.
I think the success is just luck and the code is by its nature very non-deterministic.
 
 - Jay
 


From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Mon, 14 Mar 2011 18:45:44 -0400
Subject: [M3devel] question on use of Time.Now in thread test program





I have a question/concern regarding Mika?s thread test program.
 
Each of the threads makes use of the Time.Now() call during each iteration of the thread?s main loop.  
 
I haven?t fully investigated, but does anyone have concern that so many calls to the system clock from multiple competing threads might have some side effect on the running of multiple threads?
 
I?ve also done some limited experimentation with use of counters to see how many times each type of thread is able to go thru its loop between reporting intervals.
 
I continue to see various types of crashes on Windows 7 (64-bit), but sometimes tests are able to succeed.  I haven?t found a repeatable pattern yet to the crashes, so I am still investigating, but just thought it worth asking the above question about use of Time.Now().
 
I will also try to experiment with Windows XP 32-bit and report back.
 
Regards,
Randy Coleburn
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/7153deb4/attachment-0002.html>

From hosking at cs.purdue.edu  Tue Mar 15 00:50:24 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 14 Mar 2011 19:50:24 -0400
Subject: [M3devel] question re LONGINT
In-Reply-To: <COL101-W1613B5382CDB4AA0998526E6CC0@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BD67F@atlex02-srv>,
	<82BC458A-AEC4-4148-B65D-D6B4B0692CDD@cs.purdue.edu>
	<COL101-W1613B5382CDB4AA0998526E6CC0@phx.gbl>
Message-ID: <C1309C40-1D9F-4C67-80A7-E04C9FDF3554@cs.purdue.edu>

On Mar 14, 2011, at 6:33 PM, Jay K wrote:

>  - That error is likely from the frontend and will likely occur for any target. Tony's reply implies this as well.
>  
>  - LONGINT is believed to fully work on NT386. But more testing is welcome.
>  
>  - (atomics ditto -- believed to work, testing welcome -- and we should probably use them some, e.g. in MUTEX initialization)

They are still slightly broken.  I have some fixes still to check in.  If only I could find some time to test everything...
But, they will be essential if we ever do cooperative thread suspension.

>   - I would be curious to see if threadtest only fails on 64bit Windows. I haven't tried 32bit yet but I will soon.
>    - I was thinking more about this WOW64 GetThreadContext problem and ways to mitigate it, other than cooperative suspend.
>      I had already suggested and started to implement scanning the entire stack -- i.e. not depending on an ability to get ESP from a suspended thread.
>      Like how FreeBSD and OpenBSD work, albeit it is a significant deoptimization.
>      Regarding the rest of the context, perhaps it is a reasonable assumption for now to declare that it doesn't matter? e.g. to know/assume
>      that m3back never leaves a value only in registers, that anything in a register will also be on the stack? And to disable optimization on the
>      hypothetical MINGW platforms. ?
>      But still to confirm if there are no problems on 32bit, and to mull over implementing cooperative suspend..in the little time available...
>      (Oh, and also, I wonder if SuspendThread can suspend a thread while in the kernel, probably, and if GetThreadContext returns
>      the kernel context in that case; should be easy to determine via some experimentation -- which would imply a problem on 32bit Windows also.)
>  
>  
>  - Jay
>  
> From: hosking at cs.purdue.edu
> Date: Mon, 14 Mar 2011 17:21:01 -0400
> To: rcolebur at SCIRES.COM
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] question re LONGINT
> 
> This is a known problem which I am still to fix.  I know what the issue is...
> You can probably make do by reading counts[i] to a variable, incrementing, and assigning.
> 
> On Mar 14, 2011, at 5:14 PM, Coleburn, Randy wrote:
> 
> I was making some local mods to Mika?s threadtest program to help me debug things a bit more on Windows.
>  
> I am trying to do:
>    INC(counts[i]);
> Where counts is REF ARRAY OF LONGINT
>  
> The compiler is complaining:
> "..\src\Main.m3", line 189: ** INTERNAL CG ERROR *** unable to find integer type?  type=Int.64  s/o/a=64/0/32
>  
> I?m not sure what the status of LONGINT is on Windows.  If it is not fully implemented, let me know and I?ll switch to REF ARRAY OF INTEGER, but I really need LONGINT.
>  
> Regards,
> Randy Coleburn
>  
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/552f4ee8/attachment-0002.html>

From hosking at cs.purdue.edu  Tue Mar 15 02:06:53 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 14 Mar 2011 21:06:53 -0400
Subject: [M3devel] question re LONGINT
In-Reply-To: <COL101-W1613B5382CDB4AA0998526E6CC0@phx.gbl>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BD67F@atlex02-srv>,
	<82BC458A-AEC4-4148-B65D-D6B4B0692CDD@cs.purdue.edu>
	<COL101-W1613B5382CDB4AA0998526E6CC0@phx.gbl>
Message-ID: <5B02FDDE-41EA-42FD-A57B-ECED6C626AC8@cs.purdue.edu>

On Mar 14, 2011, at 6:33 PM, Jay K wrote:

>  - That error is likely from the frontend and will likely occur for any target. Tony's reply implies this as well.
>  
>  - LONGINT is believed to fully work on NT386. But more testing is welcome.
>  
>  - (atomics ditto -- believed to work, testing welcome -- and we should probably use them some, e.g. in MUTEX initialization)

They are still slightly broken.  I have some fixes still to check in.  If only I could find some time to test everything...
But, they will be essential if we ever do cooperative thread suspension.

>   - I would be curious to see if threadtest only fails on 64bit Windows. I haven't tried 32bit yet but I will soon.
>    - I was thinking more about this WOW64 GetThreadContext problem and ways to mitigate it, other than cooperative suspend.
>      I had already suggested and started to implement scanning the entire stack -- i.e. not depending on an ability to get ESP from a suspended thread.
>      Like how FreeBSD and OpenBSD work, albeit it is a significant deoptimization.
>      Regarding the rest of the context, perhaps it is a reasonable assumption for now to declare that it doesn't matter? e.g. to know/assume
>      that m3back never leaves a value only in registers, that anything in a register will also be on the stack? And to disable optimization on the
>      hypothetical MINGW platforms. ?
>      But still to confirm if there are no problems on 32bit, and to mull over implementing cooperative suspend..in the little time available...
>      (Oh, and also, I wonder if SuspendThread can suspend a thread while in the kernel, probably, and if GetThreadContext returns
>      the kernel context in that case; should be easy to determine via some experimentation -- which would imply a problem on 32bit Windows also.)
>  
>  
>  - Jay
>  
> From: hosking at cs.purdue.edu
> Date: Mon, 14 Mar 2011 17:21:01 -0400
> To: rcolebur at SCIRES.COM
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] question re LONGINT
> 
> This is a known problem which I am still to fix.  I know what the issue is...
> You can probably make do by reading counts[i] to a variable, incrementing, and assigning.
> 
> On Mar 14, 2011, at 5:14 PM, Coleburn, Randy wrote:
> 
> I was making some local mods to Mika?s threadtest program to help me debug things a bit more on Windows.
>  
> I am trying to do:
>    INC(counts[i]);
> Where counts is REF ARRAY OF LONGINT
>  
> The compiler is complaining:
> "..\src\Main.m3", line 189: ** INTERNAL CG ERROR *** unable to find integer type?  type=Int.64  s/o/a=64/0/32
>  
> I?m not sure what the status of LONGINT is on Windows.  If it is not fully implemented, let me know and I?ll switch to REF ARRAY OF INTEGER, but I really need LONGINT.
>  
> Regards,
> Randy Coleburn
>  
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/7a5b1085/attachment-0002.html>

From rcolebur at SCIRES.COM  Tue Mar 15 02:40:12 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Mon, 14 Mar 2011 21:40:12 -0400
Subject: [M3devel] draft new edition of thread test program
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E603418BD6AD@atlex02-srv>

Mika et al:

I didn't want to check in a modified version of your program without everyone agreeing my modifications are desired.

Attached is my modified source code.  See if you think the modifications are worthy of adding to the program, or feel free to adjust further, or just tell me you don't want to add them.  If you want me to check in the modified source, let me know.

Basically, I've done 2 things:


1.       Added pp.finish() in command line parsing so that if you put extra arguments on command line that aren't parsed, you will get an error message.  For example, I keep finding I sometimes separate the test names with space instead of comma, only to realize after program starts that the extra arguments were ignored.  (We could also change the specs to allow for comma to be used as a test name separator.)


2.       Added "-verbose" command line option.  If you choose this option, extra information is printed, namely:  as threads are created, their "id" is printed and then for each iteration, the number of times each thread executed its main loop is printed.  Also, if a thread doesn't make any progress on an iteration, a notice that the thread may be starved or deadlocked is printed.

Unless you use -verbose, the program output is the same as your version, except that if you give extra command line arguments, the program will abort and notify you.  For example,
C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -tests read lock
ParseParams: parameter 4 = "lock" extraneous or misplaced.

*** Couldnt parse cmd-line args.

Now, running on Windows 7 (64-bit), I still get non-deterministic behavior and some crashes.  For example:
C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,lock
Writing file...done
Creating read threads...
   read=0
   read=1
   read=2
done
Creating lock threads...
   lock=21
   lock=22
   lock=23
done
running...printing oldest/median age/newest
..........laziest thread is 0/0/0 (tests: read 0/0/0 lock 0/0/0)
   read Thread 0 completed 1670 loops.
   read Thread 1 completed 1692 loops.
   read Thread 2 completed 1849 loops.
   lock Thread 21 completed 11788253 loops.
   lock Thread 22 completed 9448889 loops.
   lock Thread 23 completed 9480853 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 lock 0/0/0)
   read Thread 0 completed 2148 loops.
   read Thread 1 completed 2113 loops.
   read Thread 2 completed 2343 loops.
   lock Thread 21 completed 13326765 loops.
   lock Thread 22 completed 11327588 loops.
   lock Thread 23 completed 12743882 loops.
.......

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0x126e37d = Move + 0x50 in ..\src\runtime\common\RTCollector.m3
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

I'll try on 32-bit XP soon and report.

Regards,
Randy Coleburn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/448a0612/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Main.m3
Type: application/octet-stream
Size: 18584 bytes
Desc: Main.m3
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/448a0612/attachment-0002.obj>

From hosking at cs.purdue.edu  Tue Mar 15 03:44:10 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 14 Mar 2011 22:44:10 -0400
Subject: [M3devel] draft new edition of thread test program
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BD6AD@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BD6AD@atlex02-srv>
Message-ID: <A347E6AC-DAD7-4792-AD0D-C45712E46299@cs.purdue.edu>

In the face of these crashes it would be best to run all tests with the @M3paranoidgc flag at all times.

On Mar 14, 2011, at 9:40 PM, Coleburn, Randy wrote:

> Mika et al:
>  
> I didn?t want to check in a modified version of your program without everyone agreeing my modifications are desired.
>  
> Attached is my modified source code.  See if you think the modifications are worthy of adding to the program, or feel free to adjust further, or just tell me you don?t want to add them.  If you want me to check in the modified source, let me know.
>  
> Basically, I?ve done 2 things:
> 
> 1.       Added pp.finish() in command line parsing so that if you put extra arguments on command line that aren?t parsed, you will get an error message.  For example, I keep finding I sometimes separate the test names with space instead of comma, only to realize after program starts that the extra arguments were ignored.  (We could also change the specs to allow for comma to be used as a test name separator.)
> 
> 2.       Added ??verbose? command line option.  If you choose this option, extra information is printed, namely:  as threads are created, their ?id? is printed and then for each iteration, the number of times each thread executed its main loop is printed.  Also, if a thread doesn?t make any progress on an iteration, a notice that the thread may be starved or deadlocked is printed.
>  
> Unless you use ?verbose, the program output is the same as your version, except that if you give extra command line arguments, the program will abort and notify you.  For example,
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -tests read lock
> ParseParams: parameter 4 = "lock" extraneous or misplaced.
>  
> *** Couldnt parse cmd-line args.
>  
> Now, running on Windows 7 (64-bit), I still get non-deterministic behavior and some crashes.  For example:
> C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,lock
> Writing file...done
> Creating read threads...
>    read=0
>    read=1
>    read=2
> done
> Creating lock threads...
>    lock=21
>    lock=22
>    lock=23
> done
> running...printing oldest/median age/newest
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 lock 0/0/0)
>    read Thread 0 completed 1670 loops.
>    read Thread 1 completed 1692 loops.
>    read Thread 2 completed 1849 loops.
>    lock Thread 21 completed 11788253 loops.
>    lock Thread 22 completed 9448889 loops.
>    lock Thread 23 completed 9480853 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 lock 0/0/0)
>    read Thread 0 completed 2148 loops.
>    read Thread 1 completed 2113 loops.
>    read Thread 2 completed 2343 loops.
>    lock Thread 21 completed 13326765 loops.
>    lock Thread 22 completed 11327588 loops.
>    lock Thread 23 completed 12743882 loops.
> .......
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
> ***    pc = 0x126e37d = Move + 0x50 in ..\src\runtime\common\RTCollector.m3
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
> ***
>  
> I?ll try on 32-bit XP soon and report.
>  
> Regards,
> Randy Coleburn
>  
> <Main.m3>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110314/13a33906/attachment-0002.html>

From mika at async.caltech.edu  Wed Mar 16 16:40:27 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Wed, 16 Mar 2011 08:40:27 -0700
Subject: [M3devel] draft new edition of thread test program
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BD6AD@atlex02-srv> 
References: <D67F02DDC62F7545A6B84C285F88F3E603418BD6AD@atlex02-srv>
Message-ID: <20110316154027.14DAF1A2078@async.async.caltech.edu>

Hi Randy,

No objections from me!

     Mika

"Coleburn, Randy" writes:
>--_004_D67F02DDC62F7545A6B84C285F88F3E603418BD6ADatlex02srv_
>Content-Type: multipart/alternative;
>	boundary="_000_D67F02DDC62F7545A6B84C285F88F3E603418BD6ADatlex02srv_"
>
>--_000_D67F02DDC62F7545A6B84C285F88F3E603418BD6ADatlex02srv_
>Content-Type: text/plain; charset="us-ascii"
>Content-Transfer-Encoding: quoted-printable
>
>Mika et al:
>
>I didn't want to check in a modified version of your program without everyo=
>ne agreeing my modifications are desired.
>
>Attached is my modified source code.  See if you think the modifications ar=
>e worthy of adding to the program, or feel free to adjust further, or just =
>tell me you don't want to add them.  If you want me to check in the modifie=
>d source, let me know.
>
>Basically, I've done 2 things:
>
>
>1.       Added pp.finish() in command line parsing so that if you put extra=
> arguments on command line that aren't parsed, you will get an error messag=
>e.  For example, I keep finding I sometimes separate the test names with sp=
>ace instead of comma, only to realize after program starts that the extra a=
>rguments were ignored.  (We could also change the specs to allow for comma =
>to be used as a test name separator.)
>
>
>2.       Added "-verbose" command line option.  If you choose this option, =
>extra information is printed, namely:  as threads are created, their "id" i=
>s printed and then for each iteration, the number of times each thread exec=
>uted its main loop is printed.  Also, if a thread doesn't make any progress=
> on an iteration, a notice that the thread may be starved or deadlocked is =
>printed.
>
>Unless you use -verbose, the program output is the same as your version, ex=
>cept that if you give extra command line arguments, the program will abort =
>and notify you.  For example,
>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -tests read=
> lock
>ParseParams: parameter 4 =3D "lock" extraneous or misplaced.
>
>*** Couldnt parse cmd-line args.
>
>Now, running on Windows 7 (64-bit), I still get non-deterministic behavior =
>and some crashes.  For example:
>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -t=
>ests read,lock
>Writing file...done
>Creating read threads...
>   read=3D0
>   read=3D1
>   read=3D2
>done
>Creating lock threads...
>   lock=3D21
>   lock=3D22
>   lock=3D23
>done
>running...printing oldest/median age/newest
>..........laziest thread is 0/0/0 (tests: read 0/0/0 lock 0/0/0)
>   read Thread 0 completed 1670 loops.
>   read Thread 1 completed 1692 loops.
>   read Thread 2 completed 1849 loops.
>   lock Thread 21 completed 11788253 loops.
>   lock Thread 22 completed 9448889 loops.
>   lock Thread 23 completed 9480853 loops.
>..........laziest thread is 0/0/0 (tests: read 0/0/0 lock 0/0/0)
>   read Thread 0 completed 2148 loops.
>   read Thread 1 completed 2113 loops.
>   read Thread 2 completed 2343 loops.
>   lock Thread 21 completed 13326765 loops.
>   lock Thread 22 completed 11327588 loops.
>   lock Thread 23 completed 12743882 loops.
>.......
>
>***
>*** runtime error:
>***    Attempt to reference an illegal memory location.
>
>***
>*** runtime error:
>***    Attempt to reference an illegal memory location.
>
>***
>*** runtime error:
>***    Attempt to reference an illegal memory location.
>***    pc =3D 0x126e37d =3D Move + 0x50 in ..\src\runtime\common\RTCollecto=
>r.m3
>***
>
>***
>*** runtime error:
>***    <*ASSERT*> failed.
>***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
>***
>
>***
>*** runtime error:
>***    <*ASSERT*> failed.
>***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
>***
>
>***
>*** runtime error:
>***    <*ASSERT*> failed.
>***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
>***
>
>I'll try on 32-bit XP soon and report.
>
>Regards,
>Randy Coleburn
>
>
>--_000_D67F02DDC62F7545A6B84C285F88F3E603418BD6ADatlex02srv_
>Content-Type: text/html; charset="us-ascii"
>Content-Transfer-Encoding: quoted-printable
>
><html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
>osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
>xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
>icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
>:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
>uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
>t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
>m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
>t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
>:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
>soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
>xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
>icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
>schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
>point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
>/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
>=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
>schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
>.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
>/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
>://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
>repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
> xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
>schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
>/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
>ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
>p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
>/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
>mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
>crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
>s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
>ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
>om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
>ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
>partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
>06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
>6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
>deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
>Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
>st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta http-equi=
>v=3DContent-Type content=3D"text/html; charset=3Dus-ascii"><meta name=3DGen=
>erator content=3D"Microsoft Word 12 (filtered medium)"><style><!--
>/* Font Definitions */
>@font-face
>	{font-family:"Cambria Math";
>	panose-1:2 4 5 3 5 4 6 3 2 4;}
>@font-face
>	{font-family:Calibri;
>	panose-1:2 15 5 2 2 2 4 3 2 4;}
>/* Style Definitions */
>p.MsoNormal, li.MsoNormal, div.MsoNormal
>	{margin:0in;
>	margin-bottom:.0001pt;
>	font-size:11.0pt;
>	font-family:"Calibri","sans-serif";}
>a:link, span.MsoHyperlink
>	{mso-style-priority:99;
>	color:blue;
>	text-decoration:underline;}
>a:visited, span.MsoHyperlinkFollowed
>	{mso-style-priority:99;
>	color:purple;
>	text-decoration:underline;}
>p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
>	{mso-style-priority:34;
>	margin-top:0in;
>	margin-right:0in;
>	margin-bottom:0in;
>	margin-left:.5in;
>	margin-bottom:.0001pt;
>	font-size:11.0pt;
>	font-family:"Calibri","sans-serif";}
>span.EmailStyle17
>	{mso-style-type:personal-compose;
>	font-family:"Calibri","sans-serif";
>	color:windowtext;}
>.MsoChpDefault
>	{mso-style-type:export-only;}
>@page WordSection1
>	{size:8.5in 11.0in;
>	margin:1.0in 1.0in 1.0in 1.0in;}
>div.WordSection1
>	{page:WordSection1;}
>/* List Definitions */
>@list l0
>	{mso-list-id:384720956;
>	mso-list-type:hybrid;
>	mso-list-template-ids:982285054 67698703 67698713 67698715 67698703 676987=
>13 67698715 67698703 67698713 67698715;}
>@list l0:level1
>	{mso-level-tab-stop:none;
>	mso-level-number-position:left;
>	text-indent:-.25in;}
>ol
>	{margin-bottom:0in;}
>ul
>	{margin-bottom:0in;}
>--></style><!--[if gte mso 9]><xml>
><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
></xml><![endif]--><!--[if gte mso 9]><xml>
><o:shapelayout v:ext=3D"edit">
><o:idmap v:ext=3D"edit" data=3D"1" />
></o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
>nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>Mika et al:<o:p>=
></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>I =
>didn&#8217;t want to check in a modified version of your program without ev=
>eryone agreeing my modifications are desired.<o:p></o:p></p><p class=3DMsoN=
>ormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>Attached is my modified sou=
>rce code.&nbsp; See if you think the modifications are worthy of adding to =
>the program, or feel free to adjust further, or just tell me you don&#8217;=
>t want to add them.&nbsp; If you want me to check in the modified source, l=
>et me know.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p clas=
>s=3DMsoNormal>Basically, I&#8217;ve done 2 things:<br><br><o:p></o:p></p><p=
> class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 lf=
>o1'><![if !supportLists]><span style=3D'mso-list:Ignore'>1.<span style=3D'f=
>ont:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></=
>span><![endif]>Added <b>pp.finish()</b> in command line parsing so that if =
>you put extra arguments on command line that aren&#8217;t parsed, you will =
>get an error message.&nbsp; For example, I keep finding I sometimes separat=
>e the test names with space instead of comma, only to realize after program=
> starts that the extra arguments were ignored.&nbsp; (We could also change =
>the specs to allow for comma to be used as a test name separator.)<br><br><=
>o:p></o:p></p><p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-l=
>ist:l0 level1 lfo1'><![if !supportLists]><span style=3D'mso-list:Ignore'>2.=
><span style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
>&nbsp; </span></span><![endif]>Added &#8220;<b>&#8211;verbose</b>&#8221; co=
>mmand line option.&nbsp; If you choose this option, extra information is pr=
>inted, namely: &nbsp;as threads are created, their &#8220;id&#8221; is prin=
>ted and then for each iteration, the number of times each thread executed i=
>ts main loop is printed.&nbsp; Also, if a thread doesn&#8217;t make any pro=
>gress on an iteration, a notice that the thread may be starved or deadlocke=
>d is printed.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p cl=
>ass=3DMsoNormal>Unless you use &#8211;verbose, the program output is the sa=
>me as your version, except that if you give extra command line arguments, t=
>he program will abort and notify you.&nbsp; For example,<o:p></o:p></p><p c=
>lass=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Cou=
>rier New"'>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt;threadtest.e=
>xe -tests read lock<o:p></o:p></span></p><p class=3DMsoNormal style=3D'marg=
>in-left:.5in'><span style=3D'font-family:"Courier New"'>ParseParams: parame=
>ter 4 =3D &quot;lock&quot; extraneous or misplaced.<o:p></o:p></span></p><p=
> class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"C=
>ourier New"'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal style=3D'marg=
>in-left:.5in'><span style=3D'font-family:"Courier New"'>*** Couldnt parse c=
>md-line args.<o:p></o:p></span></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></=
>p><p class=3DMsoNormal>Now, running on Windows 7 (64-bit), I still get non-=
>deterministic behavior and some crashes.&nbsp; For example:<o:p></o:p></p><=
>p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"=
>Courier New"'>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386&gt;threadtes=
>t.exe -verbose -tests read,lock<o:p></o:p></span></p><p class=3DMsoNormal s=
>tyle=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'>Writing=
> file...done<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left=
>:.5in'><span style=3D'font-family:"Courier New"'>Creating read threads...<o=
>:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span s=
>tyle=3D'font-family:"Courier New"'>&nbsp;&nbsp; read=3D0<o:p></o:p></span><=
>/p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-fami=
>ly:"Courier New"'>&nbsp;&nbsp; read=3D1<o:p></o:p></span></p><p class=3DMso=
>Normal style=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'=
>>&nbsp;&nbsp; read=3D2<o:p></o:p></span></p><p class=3DMsoNormal style=3D'm=
>argin-left:.5in'><span style=3D'font-family:"Courier New"'>done<o:p></o:p><=
>/span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'fo=
>nt-family:"Courier New"'>Creating lock threads...<o:p></o:p></span></p><p c=
>lass=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Cou=
>rier New"'>&nbsp;&nbsp; lock=3D21<o:p></o:p></span></p><p class=3DMsoNormal=
> style=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'>&nbsp=
>;&nbsp; lock=3D22<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin=
>-left:.5in'><span style=3D'font-family:"Courier New"'>&nbsp;&nbsp; lock=3D2=
>3<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><spa=
>n style=3D'font-family:"Courier New"'>done<o:p></o:p></span></p><p class=3D=
>MsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Courier Ne=
>w"'>running...printing oldest/median age/newest<o:p></o:p></span></p><p cla=
>ss=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Couri=
>er New"'>..........laziest thread is 0/0/0 (tests: read 0/0/0 lock 0/0/0)<o=
>:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span s=
>tyle=3D'font-family:"Courier New"'>&nbsp;&nbsp; read Thread 0 completed 167=
>0 loops.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5i=
>n'><span style=3D'font-family:"Courier New"'>&nbsp;&nbsp; read Thread 1 com=
>pleted 1692 loops.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margi=
>n-left:.5in'><span style=3D'font-family:"Courier New"'>&nbsp;&nbsp; read Th=
>read 2 completed 1849 loops.<o:p></o:p></span></p><p class=3DMsoNormal styl=
>e=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'>&nbsp;&nbs=
>p; lock Thread 21 completed 11788253 loops.<o:p></o:p></span></p><p class=
>=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Courier=
> New"'>&nbsp;&nbsp; lock Thread 22 completed 9448889 loops.<o:p></o:p></spa=
>n></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-f=
>amily:"Courier New"'>&nbsp;&nbsp; lock Thread 23 completed 9480853 loops.<o=
>:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span s=
>tyle=3D'font-family:"Courier New"'>..........laziest thread is 0/0/0 (tests=
>: read 0/0/0 lock 0/0/0)<o:p></o:p></span></p><p class=3DMsoNormal style=3D=
>'margin-left:.5in'><span style=3D'font-family:"Courier New"'>&nbsp;&nbsp; r=
>ead Thread 0 completed 2148 loops.<o:p></o:p></span></p><p class=3DMsoNorma=
>l style=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'>&nbs=
>p;&nbsp; read Thread 1 completed 2113 loops.<o:p></o:p></span></p><p class=
>=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Courier=
> New"'>&nbsp;&nbsp; read Thread 2 completed 2343 loops.<o:p></o:p></span></=
>p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-famil=
>y:"Courier New"'>&nbsp;&nbsp; lock Thread 21 completed 13326765 loops.<o:p>=
></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span styl=
>e=3D'font-family:"Courier New"'>&nbsp;&nbsp; lock Thread 22 completed 11327=
>588 loops.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.=
>5in'><span style=3D'font-family:"Courier New"'>&nbsp;&nbsp; lock Thread 23 =
>completed 12743882 loops.<o:p></o:p></span></p><p class=3DMsoNormal style=
>=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'>.......<o:p=
>></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span sty=
>le=3D'font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=3DMso=
>Normal style=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'=
>>***<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><=
>span style=3D'font-family:"Courier New"'>*** runtime error:<o:p></o:p></spa=
>n></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-f=
>amily:"Courier New"'>***&nbsp;&nbsp;&nbsp; Attempt to reference an illegal =
>memory location.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-=
>left:.5in'><span style=3D'font-family:"Courier New"'><o:p>&nbsp;</o:p></spa=
>n></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-f=
>amily:"Courier New"'>***<o:p></o:p></span></p><p class=3DMsoNormal style=3D=
>'margin-left:.5in'><span style=3D'font-family:"Courier New"'>*** runtime er=
>ror:<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><=
>span style=3D'font-family:"Courier New"'>***&nbsp;&nbsp;&nbsp; Attempt to r=
>eference an illegal memory location.<o:p></o:p></span></p><p class=3DMsoNor=
>mal style=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'><o=
>:p>&nbsp;</o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><=
>span style=3D'font-family:"Courier New"'>***<o:p></o:p></span></p><p class=
>=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Courier=
> New"'>*** runtime error:<o:p></o:p></span></p><p class=3DMsoNormal style=
>=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'>***&nbsp;&n=
>bsp;&nbsp; Attempt to reference an illegal memory location.<o:p></o:p></spa=
>n></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-f=
>amily:"Courier New"'>***&nbsp;&nbsp;&nbsp; pc =3D 0x126e37d =3D Move + 0x50=
> in ..\src\runtime\common\RTCollector.m3<o:p></o:p></span></p><p class=3DMs=
>oNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"=
>'>***<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'>=
><span style=3D'font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p cl=
>ass=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Cour=
>ier New"'>***<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-lef=
>t:.5in'><span style=3D'font-family:"Courier New"'>*** runtime error:<o:p></=
>o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=
>=3D'font-family:"Courier New"'>***&nbsp;&nbsp;&nbsp; &lt;*ASSERT*&gt; faile=
>d.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><sp=
>an style=3D'font-family:"Courier New"'>***&nbsp;&nbsp;&nbsp; file &quot;..\=
>src\thread\WIN32\ThreadWin32.m3&quot;, line 841<o:p></o:p></span></p><p cla=
>ss=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:"Couri=
>er New"'>***<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left=
>:.5in'><span style=3D'font-family:"Courier New"'><o:p>&nbsp;</o:p></span></=
>p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-famil=
>y:"Courier New"'>***<o:p></o:p></span></p><p class=3DMsoNormal style=3D'mar=
>gin-left:.5in'><span style=3D'font-family:"Courier New"'>*** runtime error:=
><o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span=
> style=3D'font-family:"Courier New"'>***&nbsp;&nbsp;&nbsp; &lt;*ASSERT*&gt;=
> failed.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5i=
>n'><span style=3D'font-family:"Courier New"'>***&nbsp;&nbsp;&nbsp; file &qu=
>ot;..\src\thread\WIN32\ThreadWin32.m3&quot;, line 841<o:p></o:p></span></p>=
><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-family:=
>"Courier New"'>***<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margi=
>n-left:.5in'><span style=3D'font-family:"Courier New"'><o:p>&nbsp;</o:p></s=
>pan></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font=
>-family:"Courier New"'>***<o:p></o:p></span></p><p class=3DMsoNormal style=
>=3D'margin-left:.5in'><span style=3D'font-family:"Courier New"'>*** runtime=
> error:<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-left:.5in=
>'><span style=3D'font-family:"Courier New"'>***&nbsp;&nbsp;&nbsp; &lt;*ASSE=
>RT*&gt; failed.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'margin-l=
>eft:.5in'><span style=3D'font-family:"Courier New"'>***&nbsp;&nbsp;&nbsp; f=
>ile &quot;..\src\thread\WIN32\ThreadWin32.m3&quot;, line 841<o:p></o:p></sp=
>an></p><p class=3DMsoNormal style=3D'margin-left:.5in'><span style=3D'font-=
>family:"Courier New"'>***<o:p></o:p></span></p><p class=3DMsoNormal><o:p>&n=
>bsp;</o:p></p><p class=3DMsoNormal>I&#8217;ll try on 32-bit XP soon and rep=
>ort.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMso=
>Normal>Regards,<o:p></o:p></p><p class=3DMsoNormal>Randy Coleburn<o:p></o:p=
>></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></body></html>=
>
>--_000_D67F02DDC62F7545A6B84C285F88F3E603418BD6ADatlex02srv_--
>
>--_004_D67F02DDC62F7545A6B84C285F88F3E603418BD6ADatlex02srv_
>Content-Type: application/octet-stream; name="Main.m3"
>Content-Description: Main.m3
>Content-Disposition: attachment; filename="Main.m3"; size=18584;
>	creation-date="Thu, 03 Mar 2011 01:28:22 GMT";
>	modification-date="Tue, 15 Mar 2011 01:30:19 GMT"
>Content-Transfer-Encoding: base64
>
>TU9EVUxFIE1haW47DQoNCigqIFRocmVhZGluZyBzdHJlc3MtdGVzdC4NCg0KICAgQ3JlYXRlIGEg
>bnVtYmVyIG9mIHRocmVhZHMuICBuIGlzIHNwZWNpZmllZCB2aWEgblBlciwgSXQgaXMNCiAgIHJl
>YXNvbmFibGUgZm9yIG5QZXIgdG8gYmUgZnJvbSAxIHRvIGEgZmV3IGh1bmRyZWQuICBuUGVyIGRl
>ZmF1bHRzDQogICB0byAzIGJ1dCBjYW4gYmUgc2V0IGJ5IHRoZSAtbiBjb21tYW5kLWxpbmUgc3dp
>dGNoLg0KDQogICBPdGhlciBjb21tYW5kLWxpbmUgc3dpdGNoZXM6DQoNCiAgIC13YWl0IDxzdGVw
>cz4NCiAgICAgIGhvdyBtYW55IG9uZS1zZWNvbmQgd2FpdHMgdG8gZXhlY3V0ZSBiZXR3ZWVuIHBy
>aW50cyAoZGVmYXVsdCAxMCkNCg0KICAgLWl0ZXJzIDxpdGVycz4NCiAgICAgIGhvdyBtYW55IGl0
>ZXJhdGlvbnMgdG8gcnVuIGZvciAoZGVmYXVsdCAxMCkNCg0KICAgLXRlc3RzIDx0ZXN0MT4sPHRl
>c3QyPiwuLi4NCiAgICAgIGNvbW1hLXNlcGFyYXRlZCBsaXN0IG9mIHRlc3RzIChkZWZhdWx0IHN0
>ZCB0eXBlcykNCiAgICAgIGNhbiBzcGVjaWZ5IGFsbCB3aXRoICJBTEwiIG9yIHN0YW5kYXJkIHRl
>c3RzIHdpdGggIlNURCINCiAgICAgIGFuZCBjYW4gc3VidHJhY3QgdGVzdHMgd2l0aCAtPG5hbWUg
>b2YgdGVzdD4NCiAgICAgIGV4YW1wbGVzLg0KICAgICAgICAgLXRlc3RzIHJlYWQsYWxsb2MsY3Jl
>YXQNCg0KICAgICAgICAgLXRlc3RzIEFMTCwtcmVhZA0KDQogICBUaGUgdGhyZWFkcyBjcmVhdGVk
>IGFyZSBvZiBmaXZlIHR5cGVzLiAgRWFjaCB0eXBlIG9mIHRocmVhZCBzdGFydHMNCiAgIGJ5IHNs
>ZWVwaW5nIGZvciBhIHdoaWxlLCB0byBnaXZlIHRoZSBvdGhlciB0aHJlYWRzIGEgY2hhbmNlIHRv
>IGJlDQogICBjcmVhdGVkLg0KDQogICBUaGUgdGhyZWFkcyBhcmUgb2YgdGhlIGZvbGxvd2luZyB0
>eXBlczoNCg0KICAgMS4gUmVhZGVyIC0tIGNvbnRpbnVvdXNseSByZWFkIHRoZSBjb250ZW50cyBv
>ZiB0aGUgZmlsZSAiaG9odW0iLA0KICAgICAgY3JlYXRlZCBkdXJpbmcgc3RhcnR1cCBpbiBDV0Qg
>YnkgdGhlIG1haW4gdGhyZWFkLg0KDQogICAyLiBGb3JrZXIgLS0gcmVwZWF0ZWRseSBmb3JrIGEg
>c3VicHJvY2VzcyB0aGF0IHNsZWVwcyBmb3Igb25lIHNlY29uZA0KICAgICAgdXNpbmcgUHJvY2Vz
>cy5DcmVhdGUuDQoNCiAgIDJiLiBGb3JrVG9vTXVjaCAtLSBmb3JrICJzbGVlcCAxMCIgYW5kIGRv
>IE5PVCBjYWxsIFByb2Nlc3MuV2FpdC4NCiAgICAgIE1heSBnZW5lcmF0ZSBsb3RzIG9mIHpvbWJp
>ZXMuDQoNCiAgIDMuIEFsbG9jYXRvciAtLSByZXBlYXRlZGx5IGFsbG9jYXRlIGhlYXAgbWVtb3J5
>IGFuZCBwZXJmb3JtDQogICAgICBtZWFuaW5nbGVzcyBvcGVyYXRpb25zIG9uIGl0Lg0KDQogICA0
>LiBDcmVhdG9yIC0tIHJlcGVhdGVkbHkgZm9yayBhIHNpbXBsZSBUaHJlYWQuVCB0aGF0IGRvZXMg
>bm90aGluZw0KICAgICAgYW5kIGV4aXRzLiAgV2FpdCBmb3IgaXQgdG8gZXhpdCBiZWZvcmUgZm9y
>a2luZyBhbm90aGVyLg0KDQogICA1LiBMb2NrZXIgLS0gcmVwZWF0ZWRseSBpbmNyZW1lbnQgb3Ig
>ZGVjcmVtZW50IGEgc2luZ2xlIGludGVnZXINCiAgICAgIHZhcmlhYmxlIGZyb20gd2l0aGluIGEg
>TVVURVgtcHJvdGVjdGVkIGNyaXRpY2FsIHNlY3Rpb24uDQoNCiAgIDYuIFJlYWRlck5vRXhjZXB0
>IC0tIGxpa2UgUmVhZGVyIGJ1dCB3aXRob3V0IFRSWS1FWENFUFQNCg0KICAgNy4gVHJ5RXhjZXB0
>IC0tIGEgbG9vcCB0aGF0IGNhdGNoZXMgYW4gZXhjZXB0aW9uIHRoYXQgbmV2ZXIgaGFwcGVucw0K
>DQogICBFYWNoIHRocmVhZCB3cml0ZXMgdGhlIHRoZSBpdCBwZXJmb3JtcyBhbiBvcGVyYXRpb24g
>dG8gdGhlIHRpbWVzMQ0KICAgYXJyYXkuICBUaGUgdGltZXMxIGFycmF5IGlzIGNvcGllZCBieSB0
>aGUgbWFpbiB0aHJlYWQsIGV2ZXJ5IDEwKw0KICAgc2Vjb25kcywgaW50byB0aGUgdGltZXMyIGFy
>cmF5LiAgTm8gbG9ja3MgYXJlIHVzZWQgdG8gc3luY2hyb25pemUNCiAgIHRoaXMgY29weWluZyBh
>Y3Rpdml0eSBhcyB3ZSBkb24ndCB3YW50IHRvIGludHJvZHVjZSB0b28gbWFueSBwb3NzaWJsZQ0K
>ICAgcGxhY2VzIHRoaW5ncyBjb3VsZCBkZWFkbG9jay4NCg0KICAgVGhlIG1haW4gdGhyZWFkIHRo
>ZW4gcHJpbnRzIG91dCBob3cgbG9uZyBhZ28gdGhlIHRocmVhZCB0aGF0IGhhcyBub3QNCiAgIHdy
>aXR0ZW4gdGltZXMxIGxhc3Qgd3JvdGUgdGhhdCBhcnJheS4NCg0KICAgTm90ZSB0aGF0IGFjdGlv
>bnMgaW4gdGhlIG1haW4gdGhyZWFkIG1heSBhbGxvY2F0ZSBtZW1vcnkgYW5kIHRoZXJlZm9yZQ0K
>ICAgYWNxdWlyZXMgbG9ja3MgaW4gVGhyZWFkUFRocmVhZC5tMywgdGhlIGZpbGUgd2hpY2ggdGhl
>IHByb2dyYW0gaXMNCiAgIG1haW5seSBpbnRlbmRlZCB0byB0ZXN0LiAgVGhlIGRlc2lnbiBpcyBi
>YXNlZCBvbiBhIGtub3dsZWRnZSBvZiB0aGUNCiAgIGludGVybmFsIGJlaGF2aW9yIG9mIFRocmVh
>ZFBUaHJlYWQubTMgYW5kIGFsc28gb24gYSBrbm93bGVkZ2Ugb2YgdGhlDQogICBtaXNiZWhhdmlv
>ciBvZiBleGlzdGluZywgaGlnaGx5IG11bHRpdGhyZWFkZWQgYXBwbGljYXRpb25zLg0KDQoNCiAg
>IEZBSVJORVNTIElTU1VFUw0KDQogICBFc3BlY2lhbGx5IHdpdGggdXNlciB0aHJlYWRzLCB0aGVy
>ZSBtYXkgYmUgZmFpcm5lc3MgcHJvYmxlbXMuICBUaGUNCiAgIHBvaW50IG9mIHRoZSBwcm9ncmFt
>IGlzIHRvIHRlc3QgdGhyZWFkaW5nIHNvIHRoZXJlIGlzIG9idmlvdXNseSBubw0KICAgYXR0ZW1w
>dCBhdCBlbmZvcmNpbmcgZmFpcm5lc3MuICBXaXRoIHVzZXIgdGhyZWFkcywgdGhpcyBtYXkgY2F1
>c2UNCiAgIGNlcnRhaW4gdHlwZXMgb2YgdGhyZWFkcyB0byBtb25vcG9saXplIHRoZSBjcHUuICAi
>U1RELC1sb2NrIiBtaWdodA0KICAgYmUgYWR2aXNlZCBmb3IgdGhlIGxpc3Qgb2YgdGVzdHMgZm9y
>IHVzZXIgdGhyZWFkcy4NCg0KICAgQXV0aG9yOiBNaWthIE55c3Ryb20gPG1pa2FAYWx1bS5taXQu
>ZWR1Pg0KDQogICBDb3B5cmlnaHQgKGMpIDIwMTEgR2VuZXJhdGlvbiBDYXBpdGFsIEx0ZC4gIEFs
>bCByaWdodHMgcmVzZXJ2ZWQuDQoNCiAgIFBlcm1pc3Npb24gdG8gdXNlLCBjb3B5LCBtb2RpZnks
>IGFuZCBkaXN0cmlidXRlIHRoaXMgc29mdHdhcmUNCiAgIGFuZCBpdHMgZG9jdW1lbnRhdGlvbiBm
>b3IgYW55IHB1cnBvc2UgYW5kIHdpdGhvdXQgZmVlIGlzIGhlcmVieQ0KICAgZ3JhbnRlZCwgcHJv
>dmlkZWQgdGhhdCB0aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhcHBlYXIgaW4gYWxsDQogICBj
>b3BpZXMuIEdlbmVyYXRpb24gQ2FwaXRhbCBMdGQuIG1ha2VzIG5vIHJlcHJlc2VudGF0aW9ucw0K
>ICAgYWJvdXQgdGhlIHN1aXRhYmlsaXR5IG9mIHRoaXMgc29mdHdhcmUgZm9yIGFueSBwdXJwb3Nl
>LiBJdCBpcw0KICAgcHJvdmlkZWQgImFzIGlzIiB3aXRob3V0IGV4cHJlc3Mgb3IgaW1wbGllZCB3
>YXJyYW50eS4NCg0KICopDQogKCogTWFyY2ggMTQsIDIwMTEsIFIuQy5Db2xlYnVybjoNCiAgICAg
>ICBBZGRlZCAtdmVyYm9zZSBvcHRpb24gYW5kIHRocmVhZCBsb29wIGl0ZXJhdGlvbiBjb3VudGlu
>ZyB3aXRoIGV4cGxpY2l0IG5vdGlmaWNhdGlvbiBvZiBzdGFydmVkL2RlYWRsb2NrZWQgdGhyZWFk
>cy4NCiAgICAgICBBZGRlZCBwcC5maW5pc2goKSB0byB0ZWxsIGlmIGFsbCBjb21tYW5kIGxpbmUg
>cGFyYW1ldGVycyB3ZXJlIHByb2Nlc3NlZC4NCiAqKQ0KDQoNCklNUE9SVCBUaHJlYWQsIFJkLCBG
>aWxlUmQsIFdyLCBGaWxlV3IsIFByb2Nlc3M7DQpJTVBPUlQgVGltZTsNCklNUE9SVCBJbnRBcnJh
>eVNvcnQ7DQpJTVBPUlQgQXRvbSwgQXRvbUxpc3Q7DQpJTVBPUlQgT1NFcnJvcjsNCklNUE9SVCBQ
>YXJzZVBhcmFtcywgUGFyYW1zOw0KSU1QT1JUIFN0ZGlvOw0KSU1QT1JUIFRleHQ7DQpJTVBPUlQg
>Rm10Ow0KDQo8KiBGQVRBTCBUaHJlYWQuQWxlcnRlZCwgV3IuRmFpbHVyZSAqPg0KDQpDT05TVCBJ
>bml0UGF1c2UgPSAxLjBkMDsNCg0KVFlQRSBDbG9zdXJlID0gVGhyZWFkLkNsb3N1cmUgT0JKRUNU
>IGlkIDogQ0FSRElOQUwgRU5EOw0KDQpQUk9DRURVUkUgTWFrZVJlYWRlclRocmVhZChpIDogQ0FS
>RElOQUwpID0NCiAgQkVHSU4NCiAgICBFVkFMIFRocmVhZC5Gb3JrKE5FVyhDbG9zdXJlLCBpZCA6
>PSBpLCBhcHBseSA6PSBSQXBwbHkpKQ0KICBFTkQgTWFrZVJlYWRlclRocmVhZDsNCg0KUFJPQ0VE
>VVJFIE1ha2VSZWFkZXJOb0V4Y2VwdFRocmVhZChpIDogQ0FSRElOQUwpID0NCiAgQkVHSU4NCiAg
>ICBFVkFMIFRocmVhZC5Gb3JrKE5FVyhDbG9zdXJlLCBpZCA6PSBpLCBhcHBseSA6PSBOQXBwbHkp
>KQ0KICBFTkQgTWFrZVJlYWRlck5vRXhjZXB0VGhyZWFkOw0KDQpQUk9DRURVUkUgTWFrZVRyeUV4
>Y2VwdFRocmVhZChpIDogQ0FSRElOQUwpID0NCiAgQkVHSU4NCiAgICBFVkFMIFRocmVhZC5Gb3Jr
>KE5FVyhDbG9zdXJlLCBpZCA6PSBpLCBhcHBseSA6PSBUQXBwbHkpKQ0KICBFTkQgTWFrZVRyeUV4
>Y2VwdFRocmVhZDsNCg0KUFJPQ0VEVVJFIE1ha2VGb3JrZXJUaHJlYWQoaSA6IENBUkRJTkFMKSA9
>DQogIEJFR0lODQogICAgRVZBTCBUaHJlYWQuRm9yayhORVcoQ2xvc3VyZSwgaWQgOj0gaSwgYXBw
>bHkgOj0gRkFwcGx5KSkNCiAgRU5EIE1ha2VGb3JrZXJUaHJlYWQ7DQoNClBST0NFRFVSRSBNYWtl
>Rm9ya1Rvb011Y2hUaHJlYWQoaSA6IENBUkRJTkFMKSA9DQogIEJFR0lODQogICAgRVZBTCBUaHJl
>YWQuRm9yayhORVcoQ2xvc3VyZSwgaWQgOj0gaSwgYXBwbHkgOj0gTUFwcGx5KSkNCiAgRU5EIE1h
>a2VGb3JrVG9vTXVjaFRocmVhZDsNCg0KUFJPQ0VEVVJFIE1ha2VBbGxvY2F0b3JUaHJlYWQoaSA6
>IENBUkRJTkFMKSA9DQogIEJFR0lODQogICAgRVZBTCBUaHJlYWQuRm9yayhORVcoQ2xvc3VyZSwg
>aWQgOj0gaSwgYXBwbHkgOj0gQUFwcGx5KSkNCiAgRU5EIE1ha2VBbGxvY2F0b3JUaHJlYWQ7DQoN
>ClBST0NFRFVSRSBNYWtlQ3JlYXRvclRocmVhZChpIDogQ0FSRElOQUwpID0NCiAgQkVHSU4NCiAg
>ICBFVkFMIFRocmVhZC5Gb3JrKE5FVyhDbG9zdXJlLCBpZCA6PSBpLCBhcHBseSA6PSBDQXBwbHkp
>KQ0KICBFTkQgTWFrZUNyZWF0b3JUaHJlYWQ7DQoNClBST0NFRFVSRSBNYWtlTG9ja2VyVGhyZWFk
>KGkgOiBDQVJESU5BTCkgPQ0KICBCRUdJTg0KICAgIEVWQUwgVGhyZWFkLkZvcmsoTkVXKENsb3N1
>cmUsIGlkIDo9IGksIGFwcGx5IDo9IExBcHBseSkpDQogIEVORCBNYWtlTG9ja2VyVGhyZWFkOw0K
>DQpUWVBFDQogIFRocmVhZE1ha2VyID0gUFJPQ0VEVVJFKGkgOiBDQVJESU5BTCk7DQogIE5hbWVk
>ID0gUkVDT1JEIG1ha2VyIDogVGhyZWFkTWFrZXI7IG5hbWVkIDogVEVYVCBFTkQ7DQoNCkNPTlNU
>DQogIE1ha2VycyA9IEFSUkFZIE9GIE5hbWVkIHsNCiAgICBOYW1lZCB7IE1ha2VSZWFkZXJUaHJl
>YWQsICAgICAgICAgInJlYWQiICB9LA0KICAgIE5hbWVkIHsgTWFrZVJlYWRlck5vRXhjZXB0VGhy
>ZWFkLCAibnhyZWFkIiAgfSwNCiAgICBOYW1lZCB7IE1ha2VUcnlFeGNlcHRUaHJlYWQsICAgICAg
>InRyeWV4Y2VwdCIgIH0sDQogICAgTmFtZWQgeyBNYWtlRm9ya2VyVGhyZWFkLCAgICAgICAgICJm
>b3JrIiAgfSwNCiAgICBOYW1lZCB7IE1ha2VGb3JrVG9vTXVjaFRocmVhZCwgICAgImZvcmt0b29t
>dWNoIiAgfSwNCiAgICBOYW1lZCB7IE1ha2VBbGxvY2F0b3JUaHJlYWQsICAgICAgImFsbG9jIiB9
>LA0KICAgIE5hbWVkIHsgTWFrZUNyZWF0b3JUaHJlYWQsICAgICAgICAiY3JlYXQiIH0sDQogICAg
>TmFtZWQgeyBNYWtlTG9ja2VyVGhyZWFkLCAgICAgICAgICJsb2NrIiAgfQ0KICB9Ow0KDQpDT05T
>VCBTdGRUZXN0QXJyID0gQVJSQVkgT0YgVEVYVCB7ICJyZWFkIiwgImZvcmsiLCAiYWxsb2MiLCAi
>Y3JlYXRlIiwgImxvY2siIH07DQooKiBkZXNpZ25hdGVkICJzdGFuZGFyZCIgdGVzdHMgKikNCg0K
>VFlQRSBNID0gWyBGSVJTVChNYWtlcnMpLi5MQVNUKE1ha2VycykgXTsNCg0KKCoqKioqKioqKioq
>KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
>KiopDQoNClBST0NFRFVSRSBSQXBwbHkoY2wgOiBDbG9zdXJlKSA6IFJFRkFOWSA9DQogIEJFR0lO
>DQogICAgY291bnRzMVtjbC5pZF0gOj0gMEw7DQogICAgY291bnRzM1tjbC5pZF0gOj0gMEw7DQog
>ICAgVGhyZWFkLlBhdXNlKEluaXRQYXVzZSk7DQogICAgTE9PUA0KICAgICAgVFJZDQogICAgICAg
>IFdJVEggcmQgPSBGaWxlUmQuT3BlbihGaWxlbmFtZSkgRE8NCiAgICAgICAgICBUUlkNCiAgICAg
>ICAgICAgIExPT1ANCiAgICAgICAgICAgICAgPCpVTlVTRUQqPlZBUiBjIDo9IFJkLkdldENoYXIo
>cmQpOyBCRUdJTiAgRU5EDQogICAgICAgICAgICBFTkQNCiAgICAgICAgICBFWENFUFQNCiAgICAg
>ICAgICAgIFJkLkVuZE9mRmlsZSA9PiBSZC5DbG9zZShyZCkNCiAgICAgICAgICBFTkQ7DQogICAg
>ICAgICAgdGltZXMxW2NsLmlkXTo9IEZMT09SKFRpbWUuTm93KCkpDQogICAgICAgIEVORA0KICAg
>ICAgRVhDRVBUDQogICAgICAgIE9TRXJyb3IuRSh4KSA9PiBFcnJvcigiUkFwcGx5OiBPU0Vycm9y
>LkU6ICIgJiBGbXRBdG9tTGlzdCh4KSkNCiAgICAgIHwNCiAgICAgICAgUmQuRmFpbHVyZSh4KSA9
>PiBFcnJvcigiUkFwcGx5OiBSZC5GYWlsdXJlOiAiICYgRm10QXRvbUxpc3QoeCkpDQogICAgICBF
>TkQ7DQogICAgICBjb3VudHMxW2NsLmlkXSA6PSBjb3VudHMxW2NsLmlkXSArIDFMOyAoKiB3b3Vs
>ZCBiZSBuaWNlIHRvIHVzZSBJTkMgaGVyZSwgYnV0IHRoZXJlIGlzIGEgQ0cgYnVnIG9uIE5UMzg2
>IHdpdGggSU5DIG9mIExPTkdJTlQgKikNCiAgICBFTkQNCiAgRU5EIFJBcHBseTsNCg0KUFJPQ0VE
>VVJFIE5BcHBseShjbCA6IENsb3N1cmUpIDogUkVGQU5ZID0NCiAgPCpGQVRBTCBPU0Vycm9yLkUs
>IFJkLkZhaWx1cmUsIFJkLkVuZE9mRmlsZSo+DQogIEJFR0lODQogICAgY291bnRzMVtjbC5pZF0g
>Oj0gMEw7DQogICAgY291bnRzM1tjbC5pZF0gOj0gMEw7DQogICAgVGhyZWFkLlBhdXNlKEluaXRQ
>YXVzZSk7DQogICAgTE9PUA0KICAgICAgV0lUSCByZCA9IEZpbGVSZC5PcGVuKEZpbGVuYW1lKSBE
>Tw0KICAgICAgICBXSElMRSBOT1QgUmQuRU9GKHJkKSBETw0KICAgICAgICAgIDwqVU5VU0VEKj5W
>QVIgYyA6PSBSZC5HZXRDaGFyKHJkKTsgQkVHSU4gIEVORA0KICAgICAgICBFTkQ7DQogICAgICAg
>IFJkLkNsb3NlKHJkKTsNCiAgICAgICAgdGltZXMxW2NsLmlkXTo9IEZMT09SKFRpbWUuTm93KCkp
>DQogICAgICBFTkQ7DQogICAgICBjb3VudHMxW2NsLmlkXSA6PSBjb3VudHMxW2NsLmlkXSArIDFM
>OyAoKiB3b3VsZCBiZSBuaWNlIHRvIHVzZSBJTkMgaGVyZSwgYnV0IHRoZXJlIGlzIGEgQ0cgYnVn
>IG9uIE5UMzg2IHdpdGggSU5DIG9mIExPTkdJTlQgKikNCiAgICBFTkQNCiAgRU5EIE5BcHBseTsN
>Cg0KRVhDRVBUSU9OIFg7DQoNClBST0NFRFVSRSBUQXBwbHkoY2wgOiBDbG9zdXJlKSA6IFJFRkFO
>WSA9DQogIEJFR0lODQogICAgY291bnRzMVtjbC5pZF0gOj0gMEw7DQogICAgY291bnRzM1tjbC5p
>ZF0gOj0gMEw7DQogICAgVGhyZWFkLlBhdXNlKEluaXRQYXVzZSk7DQogICAgTE9PUA0KICAgICAg
>VFJZDQogICAgICAgIFdJVEggbm93ID0gVGltZS5Ob3coKSBETw0KICAgICAgICAgIHRpbWVzMVtj
>bC5pZF06PSBGTE9PUihub3cpOw0KICAgICAgICAgIElGIG5vdyA8IDAuMGQwIFRIRU4gUkFJU0Ug
>WCBFTkQNCiAgICAgICAgRU5EDQogICAgICBFWENFUFQgWCA9PiA8KkFTU0VSVCBGQUxTRSo+DQog
>ICAgICBFTkQ7DQogICAgICBjb3VudHMxW2NsLmlkXSA6PSBjb3VudHMxW2NsLmlkXSArIDFMOyAo
>KiB3b3VsZCBiZSBuaWNlIHRvIHVzZSBJTkMgaGVyZSwgYnV0IHRoZXJlIGlzIGEgQ0cgYnVnIG9u
>IE5UMzg2IHdpdGggSU5DIG9mIExPTkdJTlQgKikNCiAgICBFTkQNCiAgRU5EIFRBcHBseTsNCg0K
>UFJPQ0VEVVJFIEZBcHBseShjbCA6IENsb3N1cmUpIDogUkVGQU5ZID0NCiAgQkVHSU4NCiAgICBj
>b3VudHMxW2NsLmlkXSA6PSAwTDsNCiAgICBjb3VudHMzW2NsLmlkXSA6PSAwTDsNCiAgICBUaHJl
>YWQuUGF1c2UoSW5pdFBhdXNlKTsNCiAgICBMT09QDQogICAgICBUUlkNCiAgICAgICAgV0lUSCBw
>cm9jID0gUHJvY2Vzcy5DcmVhdGUoUGFyYW1zLkdldCgwKSwNCiAgICAgICAgICAgICAgICAgICAg
>ICAgICAgICAgICAgICAgQVJSQVkgT0YgVEVYVCB7ICItc2xlZXAiIH0pIERPDQogICAgICAgICAg
>RVZBTCBQcm9jZXNzLldhaXQocHJvYyk7IHRpbWVzMVtjbC5pZF0gOj0gRkxPT1IoVGltZS5Ob3co
>KSkNCiAgICAgICAgRU5EDQogICAgICBFWENFUFQNCiAgICAgICAgT1NFcnJvci5FKHgpID0+IEVy
>cm9yKCJGQXBwbHk6IE9TRXJyb3IuRTogIiAmIEZtdEF0b21MaXN0KHgpKQ0KICAgICAgRU5EOw0K
>ICAgICAgY291bnRzMVtjbC5pZF0gOj0gY291bnRzMVtjbC5pZF0gKyAxTDsgKCogd291bGQgYmUg
>bmljZSB0byB1c2UgSU5DIGhlcmUsIGJ1dCB0aGVyZSBpcyBhIENHIGJ1ZyBvbiBOVDM4NiB3aXRo
>IElOQyBvZiBMT05HSU5UICopDQogICAgRU5EDQogIEVORCBGQXBwbHk7DQoNClBST0NFRFVSRSBN
>QXBwbHkoY2wgOiBDbG9zdXJlKSA6IFJFRkFOWSA9DQogIEJFR0lODQogICAgY291bnRzMVtjbC5p
>ZF0gOj0gMEw7DQogICAgY291bnRzM1tjbC5pZF0gOj0gMEw7DQogICAgVGhyZWFkLlBhdXNlKElu
>aXRQYXVzZSk7DQogICAgTE9PUA0KICAgICAgVFJZDQogICAgICAgIDwqTk9XQVJOKj5XSVRIIHBy
>b2MgPSBQcm9jZXNzLkNyZWF0ZShQYXJhbXMuR2V0KDApLA0KICAgICAgICAgICAgICAgICAgICAg
>ICAgICAgICAgICAgICBBUlJBWSBPRiBURVhUIHsgIi1zbGVlcDEwIiB9KSBETw0KICAgICAgICAg
>ICgqIG5vIFByb2Nlc3MuV2FpdCAqKQ0KICAgICAgICAgIHRpbWVzMVtjbC5pZF0gOj0gRkxPT1Io
>VGltZS5Ob3coKSk7DQogICAgICAgICAgVGhyZWFkLlBhdXNlKDEuMGQwKQ0KICAgICAgICBFTkQN
>CiAgICAgIEVYQ0VQVA0KICAgICAgICBPU0Vycm9yLkUoeCkgPT4gRXJyb3IoIkZBcHBseTogT1NF
>cnJvci5FOiAiICYgRm10QXRvbUxpc3QoeCkpDQogICAgICBFTkQ7DQogICAgICBjb3VudHMxW2Ns
>LmlkXSA6PSBjb3VudHMxW2NsLmlkXSArIDFMOyAoKiB3b3VsZCBiZSBuaWNlIHRvIHVzZSBJTkMg
>aGVyZSwgYnV0IHRoZXJlIGlzIGEgQ0cgYnVnIG9uIE5UMzg2IHdpdGggSU5DIG9mIExPTkdJTlQg
>KikNCiAgICBFTkQNCiAgRU5EIE1BcHBseTsNCg0KUFJPQ0VEVVJFIEFBcHBseShjbCA6IENsb3N1
>cmUpIDogUkVGQU5ZID0NCiAgQkVHSU4NCiAgICBjb3VudHMxW2NsLmlkXSA6PSAwTDsNCiAgICBj
>b3VudHMzW2NsLmlkXSA6PSAwTDsNCiAgICBUaHJlYWQuUGF1c2UoSW5pdFBhdXNlKTsNCiAgICBM
>T09QDQogICAgICBWQVINCiAgICAgICAgYXJyIDo9IE5FVyhSRUYgQVJSQVkgT0YgSU5URUdFUiwg
>MTAyNSk7DQogICAgICBCRUdJTg0KICAgICAgICBGT1IgaSA6PSBGSVJTVChhcnJeKSsxIFRPIExB
>U1QoYXJyXikgRE8NCiAgICAgICAgICBhcnJbaV0gOj0gYXJyW2ldIC0gYXJyW2ktMV0NCiAgICAg
>ICAgRU5EOyB0aW1lczFbY2wuaWRdIDo9IEZMT09SKFRpbWUuTm93KCkpDQogICAgICBFTkQ7DQog
>ICAgICBjb3VudHMxW2NsLmlkXSA6PSBjb3VudHMxW2NsLmlkXSArIDFMOyAoKiB3b3VsZCBiZSBu
>aWNlIHRvIHVzZSBJTkMgaGVyZSwgYnV0IHRoZXJlIGlzIGEgQ0cgYnVnIG9uIE5UMzg2IHdpdGgg
>SU5DIG9mIExPTkdJTlQgKikNCiAgICBFTkQNCiAgRU5EIEFBcHBseTsNCg0KUFJPQ0VEVVJFIENB
>cHBseShjbCA6IENsb3N1cmUpIDogUkVGQU5ZID0NCiAgQkVHSU4NCiAgICBjb3VudHMxW2NsLmlk
>XSA6PSAwTDsNCiAgICBjb3VudHMzW2NsLmlkXSA6PSAwTDsNCiAgICBUaHJlYWQuUGF1c2UoSW5p
>dFBhdXNlKTsNCiAgICBMT09QDQogICAgICBWQVINCiAgICAgICAgdCA6PSBUaHJlYWQuRm9yayhO
>RVcoVGhyZWFkLkNsb3N1cmUsIGFwcGx5IDo9IFRocmVhZE5PUCkpOw0KICAgICAgQkVHSU4NCiAg
>ICAgICAgRVZBTCBUaHJlYWQuSm9pbih0KTsgdGltZXMxW2NsLmlkXSA6PSBGTE9PUihUaW1lLk5v
>dygpKQ0KICAgICAgRU5EOw0KICAgICAgY291bnRzMVtjbC5pZF0gOj0gY291bnRzMVtjbC5pZF0g
>KyAxTDsgKCogd291bGQgYmUgbmljZSB0byB1c2UgSU5DIGhlcmUsIGJ1dCB0aGVyZSBpcyBhIENH
>IGJ1ZyBvbiBOVDM4NiB3aXRoIElOQyBvZiBMT05HSU5UICopDQogICAgRU5EDQogIEVORCBDQXBw
>bHk7DQoNClBST0NFRFVSRSBUaHJlYWROT1AoPCpVTlVTRUQqPmNsIDogVGhyZWFkLkNsb3N1cmUp
>IDogUkVGQU5ZID0gQkVHSU4gUkVUVVJOIE5JTCBFTkQgVGhyZWFkTk9QOw0KDQpWQVIgbXUgICAg
>IDo9IE5FVyhNVVRFWCk7DQpWQVIgc2hhcmVkIDo9IDA7DQoNClBST0NFRFVSRSBMQXBwbHkoY2wg
>OiBDbG9zdXJlKSA6IFJFRkFOWSA9DQogIEJFR0lODQogICAgY291bnRzMVtjbC5pZF0gOj0gMEw7
>DQogICAgY291bnRzM1tjbC5pZF0gOj0gMEw7DQogICAgVGhyZWFkLlBhdXNlKEluaXRQYXVzZSk7
>DQogICAgTE9PUA0KICAgICAgTE9DSyBtdSBETw0KICAgICAgICBDQVNFIGNsLmlkIE1PRCAyIE9G
>DQogICAgICAgICAgMSA9PiBJTkMoc2hhcmVkKQ0KICAgICAgICB8DQogICAgICAgICAgMCA9PiBE
>RUMoc2hhcmVkKQ0KICAgICAgICBFTFNFDQogICAgICAgICAgPCpBU1NFUlQgRkFMU0UqPg0KICAg
>ICAgICBFTkQNCiAgICAgIEVORDsgdGltZXMxW2NsLmlkXSA6PSBGTE9PUihUaW1lLk5vdygpKTsN
>CiAgICAgIGNvdW50czFbY2wuaWRdIDo9IGNvdW50czFbY2wuaWRdICsgMUw7ICgqIHdvdWxkIGJl
>IG5pY2UgdG8gdXNlIElOQyBoZXJlLCBidXQgdGhlcmUgaXMgYSBDRyBidWcgb24gTlQzODYgd2l0
>aCBJTkMgb2YgTE9OR0lOVCAqKQ0KICAgIEVORA0KICBFTkQgTEFwcGx5Ow0KDQoNCkNPTlNUIEZp
>bGVuYW1lID0gImhvaHVtIjsNCg0KUFJPQ0VEVVJFIFdyaXRlQUZpbGUoKSA9DQogIDwqRkFUQUwg
>V3IuRmFpbHVyZSwgT1NFcnJvci5FKj4gICgqIGVycm9ycyBkdXJpbmcgc2V0dXAgYXJlIGp1c3Qg
>ZmF0YWwgKikNCiAgQkVHSU4NCiAgICBXSVRIIHdyID0gRmlsZVdyLk9wZW4oRmlsZW5hbWUpIERP
>DQogICAgICBGT1IgaSA6PSAxIFRPIDI1NiBETw0KICAgICAgICBGT1IgaiA6PSAxIFRPIGkgRE8N
>CiAgICAgICAgICBXci5QdXRDaGFyKHdyLCBWQUwoT1JEKCdBJykgKyBpIE1PRCAyNSwgQ0hBUikp
>DQogICAgICAgIEVORDsNCiAgICAgICAgV3IuUHV0VGV4dCh3ciwgV3IuRU9MKQ0KICAgICAgRU5E
>Ow0KICAgICAgV3IuQ2xvc2Uod3IpDQogICAgRU5EDQogIEVORCBXcml0ZUFGaWxlOw0KDQpQUk9D
>RURVUkUgUHV0SW50KGMgOiBJTlRFR0VSKSA9DQogIEJFR0lODQogICAgSUYgYyA8IDAgVEhFTg0K
>ICAgICAgV3IuUHV0Q2hhcihTdGRpby5zdGRvdXQsJy0nKTsNCiAgICAgIGMgOj0gLWM7DQogICAg
>RU5EOw0KICAgIElGIGMgPiAxMCBUSEVODQogICAgICBQdXRJbnQoYyBESVYgMTApDQogICAgRU5E
>Ow0KICAgIFdyLlB1dENoYXIoU3RkaW8uc3Rkb3V0LFZBTChjIE1PRCAxMCArIE9SRCgnMCcpLENI
>QVIpKQ0KICBFTkQgUHV0SW50Ow0KDQpQUk9DRURVUkUgUHV0U3RhdHMoVkFSIGEgOiBBUlJBWSBP
>RiBJTlRFR0VSKSA9DQogICgqIG5vdyBpcyBnbG9iYWwgaW4gTWFpbi5tMyAqKQ0KICBCRUdJTg0K
>ICAgIEludEFycmF5U29ydC5Tb3J0KGEpOw0KDQogICAgKCogdGhlIHJlc3VsdCBpc24ndCBxdWl0
>ZSByaWdodCBpZiBOVU1CRVIoYSkgaXMgZXZlbiAqKQ0KICAgIFdJVEggbWluID0gYVtGSVJTVChh
>KV0sDQogICAgICAgICBtYXggPSBhW0xBU1QoYSldLA0KICAgICAgICAgbWVkID0gYVtMQVNUKGEp
>IERJViAyXSBETw0KICAgICAgUHV0SW50KG5vdy1taW4pOw0KICAgICAgV3IuUHV0Q2hhcihTdGRp
>by5zdGRvdXQsJy8nKTsNCiAgICAgIFB1dEludChub3ctbWVkKTsNCiAgICAgIFdyLlB1dENoYXIo
>U3RkaW8uc3Rkb3V0LCcvJyk7DQogICAgICBQdXRJbnQobm93LW1heCkNCiAgICBFTkQNCiAgRU5E
>IFB1dFN0YXRzOw0KDQpQUk9DRURVUkUgRm10QXRvbUxpc3QoZXJyIDogQXRvbUxpc3QuVCkgOiBU
>RVhUID0NCiAgVkFSDQogICAgbXNnIDo9ICIiOw0KICAgIHAgOj0gZXJyOw0KICBCRUdJTg0KICAg
>IFdISUxFIHAgIyBOSUwgRE8NCiAgICAgIG1zZyA6PSBtc2cgJiAiICIgJiBBdG9tLlRvVGV4dChw
>LmhlYWQpOyBwIDo9IHAudGFpbA0KICAgIEVORDsNCiAgICBSRVRVUk4gbXNnDQogIEVORCBGbXRB
>dG9tTGlzdDsNCg0KUFJPQ0VEVVJFIEVycm9yKG1zZyA6IFRFWFQpID0NCiAgQkVHSU4NCiAgICBX
>ci5QdXRUZXh0KFN0ZGlvLnN0ZG91dCwiRVJST1IgIiAmIG1zZyAmIFdyLkVPTCkNCiAgRU5EIEVy
>cm9yOw0KDQpQUk9DRURVUkUgQWRkVGVzdCh0ZXN0IDogVEVYVCkgPQ0KICBCRUdJTg0KICAgIElG
>ICAgIFRleHQuRXF1YWwoIkFMTCIsdGVzdCkgVEhFTg0KICAgICAgc2V0cyA6PSBTRVQgT0YgTSB7
>IEZJUlNUKE0pIC4uIExBU1QoTSkgfTsNCiAgICAgIFJFVFVSTg0KICAgIEVMU0lGIFRleHQuRXF1
>YWwoIlNURCIsdGVzdCkgVEhFTg0KICAgICAgc2V0cyA6PSBTdGRUZXN0czsNCiAgICAgIFJFVFVS
>Tg0KICAgIEVMU0lGIFRleHQuRXF1YWwoIlBPU0lYIix0ZXN0KSBUSEVODQogICAgICAoKiBlcXVh
>bCB0byBTVEQsLWxvY2sgKikNCiAgICAgIHNldHMgOj0gU3RkVGVzdHM7DQogICAgICB0ZXN0IDo9
>ICItbG9jayINCiAgICBFTkQ7DQoNCiAgICBGT1IgaSA6PSBGSVJTVChNYWtlcnMpIFRPIExBU1Qo
>TWFrZXJzKSBETw0KICAgICAgSUYgICAgVGV4dC5FcXVhbChNYWtlcnNbaV0ubmFtZWQsdGVzdCkg
>VEhFTg0KICAgICAgICBzZXRzIDo9IHNldHMgKyBTRVQgT0YgTSB7IGkgfTsgUkVUVVJODQogICAg
>ICBFTFNJRiBUZXh0LkVxdWFsKCItIiAmIE1ha2Vyc1tpXS5uYW1lZCx0ZXN0KSBUSEVODQogICAg
>ICAgIHNldHMgOj0gc2V0cyAtIFNFVCBPRiBNIHsgaSB9OyBSRVRVUk4NCiAgICAgIEVORA0KICAg
>IEVORDsNCg0KICAgICgqIG5vIG1hdGNoICopDQoNCiAgICBWQVINCiAgICAgIG1zZyA6PSAiTm8g
>dGVzdCBuYW1lZCBcIiIgJiB0ZXN0ICYgIlwiLCBrbm93biB0ZXN0czoiOw0KICAgIEJFR0lODQog
>ICAgICBGT1IgaSA6PSBGSVJTVChNYWtlcnMpIFRPIExBU1QoTWFrZXJzKSBETw0KICAgICAgICBt
>c2cgOj0gbXNnICYgIiAiICYgTWFrZXJzW2ldLm5hbWVkDQogICAgICBFTkQ7DQogICAgICBQcm9j
>ZXNzLkNyYXNoKG1zZykNCiAgICBFTkQNCiAgRU5EIEFkZFRlc3Q7DQoNCkNPTlNUDQogIERlZmF1
>bHROUGVyID0gMzsNClZBUg0KICBuUGVyIDo9IERlZmF1bHROUGVyOyAoKiBtdXN0IGJlIG9kZCAq
>KQ0KDQogIG4gOiBDQVJESU5BTDsNCg0KICB0aW1lczEsIHRpbWVzMiwgdGltZXMzIDogUkVGIEFS
>UkFZIE9GIElOVEVHRVI7DQogICgqIHRpbWVzMSA6IGlucHV0IGFycmF5DQogICAgIHRpbWVzMiA6
>IGEgc3RhYmxlIGNvcHkgb2YgdGltZXMxDQoNCiAgICAgdGltZXMzIDogYSBjb3B5IG9mIHRob3Nl
>IGJpdHMgb2YgdGltZXMxIHRoYXQgYXJlIGFjdGl2ZQ0KICAqKQ0KICBjb3VudHMxLCBjb3VudHMy
>LCBjb3VudHMzIDogUkVGIEFSUkFZIE9GIExPTkdJTlQ7DQogICgqIGNvdW50czEgOiBpbnB1dA0K
>ICAgICBjb3VudHMyIDogc3RhYmxlIGNvcHkgb2YgY291bnRzMQ0KICAgICBjb3VudHMzIDogY29w
>eSBvZiBwcmlvciBjb3VudHMyIHZhbHVlcyB1c2VkIGZvciBjb21wYXJpc29uDQogICopDQogIGFj
>dGl2ZTogUkVGIEFSUkFZIE9GIEJPT0xFQU47ICgqIHRlbGxzIGlmIGEgcGFydGljdWxhciB0aHJl
>YWQgaWQgaXMgYW4gYWN0aXZlIHRocmVhZCAqKQ0KICB0aHJlYWRNOiBSRUYgQVJSQVkgT0YgTTsg
>KCogZm9yIGFjdGl2ZSB0aHJlYWRzLCB0ZWxscyB0aGUgdHlwZSBvZiB0aHJlYWQsIGkuZS4sIGl0
>cyBNICopDQogIG5vdyA6IElOVEVHRVI7DQogIHNldHMgOiBTRVQgT0YgTTsNCg0KICBwcCA6PSBO
>RVcoUGFyc2VQYXJhbXMuVCkuaW5pdChTdGRpby5zdGRlcnIpOw0KDQogIGl0ZXJzIDo9IDEwOw0K
>ICB3YWl0ICA6PSAxMDsNCiAgU3RkVGVzdHMgOj0gU0VUIE9GIE0geyB9Ow0KICB2ZXJib3NlOiBC
>T09MRUFOIDo9IEZBTFNFOw0KDQpCRUdJTg0KICBGT1IgaSA6PSBGSVJTVChTdGRUZXN0QXJyKSBU
>TyBMQVNUKFN0ZFRlc3RBcnIpIERPDQogICAgRk9SIGogOj0gRklSU1QoTSkgVE8gTEFTVChNKSBE
>Tw0KICAgICAgSUYgVGV4dC5FcXVhbChTdGRUZXN0QXJyW2ldLE1ha2Vyc1tqXS5uYW1lZCkgVEhF
>Tg0KICAgICAgICBTdGRUZXN0cyA6PSBTdGRUZXN0cyArIFNFVCBPRiBNIHsgaiB9DQogICAgICBF
>TkQNCiAgICBFTkQNCiAgRU5EOw0KDQogIHNldHMgOj0gU3RkVGVzdHM7DQoNCiAgVFJZDQogICAg
>SUYgcHAua2V5d29yZFByZXNlbnQoIi1zbGVlcDEwIikgVEhFTg0KICAgICAgKCogc2xlZXAgYW5k
>IGV4aXQgKikNCiAgICAgIFRocmVhZC5QYXVzZSgxMC4wZDApOw0KICAgICAgUHJvY2Vzcy5FeGl0
>KDApDQogICAgRU5EOw0KICAgIElGIHBwLmtleXdvcmRQcmVzZW50KCItc2xlZXAiKSBUSEVODQog
>ICAgICAoKiBzbGVlcCBhbmQgZXhpdCAqKQ0KICAgICAgVGhyZWFkLlBhdXNlKDEuMGQwKTsNCiAg
>ICAgIFByb2Nlc3MuRXhpdCgwKQ0KICAgIEVORDsNCg0KICAgIElGIHBwLmtleXdvcmRQcmVzZW50
>KCItbiIpICAgICBUSEVOIG5QZXIgOj0gcHAuZ2V0TmV4dEludCgpIEVORDsNCiAgICBJRiBwcC5r
>ZXl3b3JkUHJlc2VudCgiLXdhaXQiKSAgVEhFTiB3YWl0IDo9IHBwLmdldE5leHRJbnQoKSBFTkQ7
>DQogICAgSUYgcHAua2V5d29yZFByZXNlbnQoIi1pdGVycyIpIFRIRU4gaXRlcnMgOj0gcHAuZ2V0
>TmV4dEludCgpIEVORDsNCiAgICBJRiBwcC5rZXl3b3JkUHJlc2VudCgiLXZlcmJvc2UiKSBUSEVO
>IHZlcmJvc2UgOj0gVFJVRTsgRU5EOw0KDQogICAgSUYgcHAua2V5d29yZFByZXNlbnQoIi10ZXN0
>cyIpIFRIRU4NCiAgICAgIFZBUg0KICAgICAgICBzIDo9IDA7DQogICAgICBCRUdJTg0KICAgICAg
>ICBzZXRzIDo9IFNFVCBPRiBNIHt9IDsNCg0KICAgICAgICBXSVRIIHRlc3RzID0gcHAuZ2V0TmV4
>dCgpLA0KICAgICAgICAgICAgIGwgICAgID0gVGV4dC5MZW5ndGgodGVzdHMpIERPDQogICAgICAg
>ICAgRk9SIGkgOj0gMCBUTyBsLTEgRE8NCiAgICAgICAgICAgIElGIGkgPSBsLTEgVEhFTg0KICAg
>ICAgICAgICAgICBBZGRUZXN0KFRleHQuU3ViKHRlc3RzLHMsbC1zKSkNCiAgICAgICAgICAgIEVM
>U0lGIFRleHQuR2V0Q2hhcih0ZXN0cyxpKSA9ICcsJyBUSEVODQogICAgICAgICAgICAgIEFkZFRl
>c3QoVGV4dC5TdWIodGVzdHMscyxpLXMpKTsNCiAgICAgICAgICAgICAgcyA6PSBpKzENCiAgICAg
>ICAgICAgIEVORA0KICAgICAgICAgIEVORA0KICAgICAgICBFTkQNCiAgICAgIEVORDsNCiAgICAg
>IHBwLmZpbmlzaCgpOw0KICAgIEVORA0KDQogIEVYQ0VQVA0KICAgIFBhcnNlUGFyYW1zLkVycm9y
>ID0+IFByb2Nlc3MuQ3Jhc2goIkNvdWxkbnQgcGFyc2UgY21kLWxpbmUgYXJncy4iKQ0KICBFTkQ7
>DQoNCiAgbiA6PSBOVU1CRVIoTWFrZXJzKSAqIG5QZXI7DQogIHRpbWVzMSA6PSBORVcoUkVGIEFS
>UkFZIE9GIElOVEVHRVIsIG4pOw0KICB0aW1lczIgOj0gTkVXKFJFRiBBUlJBWSBPRiBJTlRFR0VS
>LCBuKTsNCiAgdGltZXMzIDo9IE5FVyhSRUYgQVJSQVkgT0YgSU5URUdFUiwgbik7DQogIGNvdW50
>czEgOj0gTkVXKFJFRiBBUlJBWSBPRiBMT05HSU5ULCBuKTsNCiAgY291bnRzMiA6PSBORVcoUkVG
>IEFSUkFZIE9GIExPTkdJTlQsIG4pOw0KICBjb3VudHMzIDo9IE5FVyhSRUYgQVJSQVkgT0YgTE9O
>R0lOVCwgbik7DQogIGFjdGl2ZSA6PSBORVcoUkVGIEFSUkFZIE9GIEJPT0xFQU4sIG4pOw0KICB0
>aHJlYWRNIDo9IE5FVyhSRUYgQVJSQVkgT0YgTSwgbik7DQoNCiAgRk9SIGkgOj0gMCBUTyBuLTEN
>CiAgRE8NCiAgICAgYWN0aXZlW2ldIDo9IEZBTFNFOw0KICBFTkQ7ICgqIGZvciAqKQ0KDQogIFdy
>LlB1dFRleHQoU3RkaW8uc3Rkb3V0LCJXcml0aW5nIGZpbGUuLi4iKTsgV3IuRmx1c2goU3RkaW8u
>c3Rkb3V0KTsNCiAgV3JpdGVBRmlsZSgpOw0KICBXci5QdXRUZXh0KFN0ZGlvLnN0ZG91dCwiZG9u
>ZSIgJiBXci5FT0wpOyBXci5GbHVzaChTdGRpby5zdGRvdXQpOw0KDQogIEZPUiBpIDo9IEZJUlNU
>KE0pIFRPIExBU1QoTSkgRE8NCiAgICBJRiBpIElOIHNldHMgVEhFTg0KICAgICAgV3IuUHV0VGV4
>dChTdGRpby5zdGRvdXQsIkNyZWF0aW5nICIgJiBNYWtlcnNbaV0ubmFtZWQgJiAiIHRocmVhZHMu
>Li4iKTsNCiAgICAgIFdyLkZsdXNoKFN0ZGlvLnN0ZG91dCk7DQogICAgICBGT1IgaiA6PSAwIFRP
>IG5QZXIgLSAxIERPDQogICAgICAgIFdJVEggaWQgPSBpICogblBlciArIGoNCiAgICAgICAgRE8N
>CiAgICAgICAgICAgTWFrZXJzW2ldLm1ha2VyKGlkKTsNCiAgICAgICAgICAgYWN0aXZlW2lkXSA6
>PSBUUlVFOw0KICAgICAgICAgICB0aHJlYWRNW2lkXSA6PSBpOw0KICAgICAgICAgICBJRiB2ZXJi
>b3NlDQogICAgICAgICAgIFRIRU4NCiAgICAgICAgICAgICAgV3IuUHV0VGV4dChTdGRpby5zdGRv
>dXQsIFdyLkVPTCk7IFdyLlB1dFRleHQoU3RkaW8uc3Rkb3V0LCAiICAgIiAmIE1ha2Vyc1tpXS5u
>YW1lZCAmICI9Iik7IFB1dEludChpZCk7DQogICAgICAgICAgIEVORDsgKCogaWYgKikNCiAgICAg
>ICAgRU5EOyAoKiB3aXRoICopDQogICAgICBFTkQ7DQogICAgICBJRiB2ZXJib3NlDQogICAgICBU
>SEVODQogICAgICAgICBXci5QdXRUZXh0KFN0ZGlvLnN0ZG91dCwgV3IuRU9MKTsNCiAgICAgIEVO
>RDsgKCogaWYgKikNCiAgICAgIFdyLlB1dFRleHQoU3RkaW8uc3Rkb3V0LCAiZG9uZSIgJiBXci5F
>T0wpOyAgV3IuRmx1c2goU3RkaW8uc3Rkb3V0KQ0KICAgIEVORA0KICBFTkQ7DQoNCiAgV3IuUHV0
>VGV4dChTdGRpby5zdGRvdXQsInJ1bm5pbmcuLi5wcmludGluZyBvbGRlc3QvbWVkaWFuIGFnZS9u
>ZXdlc3QiICYgV3IuRU9MKTsNCiAgV3IuRmx1c2goU3RkaW8uc3Rkb3V0KTsNCiAgRk9SIGkgOj0g
>MSBUTyBpdGVycyBETw0KICAgIEZPUiBqIDo9IDEgVE8gd2FpdCBETw0KICAgICAgVGhyZWFkLlBh
>dXNlKDEuMGQwKTsNCiAgICAgIFdyLlB1dFRleHQoU3RkaW8uc3Rkb3V0LCIuIik7DQogICAgICBX
>ci5GbHVzaChTdGRpby5zdGRvdXQpDQogICAgRU5EOw0KICAgIHRpbWVzMl4gOj0gdGltZXMxXjsN
>CiAgICBub3cgIDo9IEZMT09SKFRpbWUuTm93KCkpOw0KICAgIGNvdW50czJeIDo9IGNvdW50czFe
>Ow0KICAgIFZBUg0KICAgICAgcCA6PSAwOw0KICAgIEJFR0lODQogICAgICBGT1IgaSA6PSBGSVJT
>VChNKSBUTyBMQVNUKE0pIERPDQogICAgICAgIElGIGkgSU4gc2V0cyBUSEVODQogICAgICAgICAg
>U1VCQVJSQVkodGltZXMzXixwLG5QZXIpIDo9IFNVQkFSUkFZKHRpbWVzMl4saSpuUGVyLG5QZXIp
>Ow0KICAgICAgICAgIElOQyhwLG5QZXIpDQogICAgICAgIEVORA0KICAgICAgRU5EOw0KICAgICAg
>V3IuUHV0VGV4dChTdGRpby5zdGRvdXQsImxhemllc3QgdGhyZWFkIGlzICIpOw0KICAgICAgUHV0
>U3RhdHMoU1VCQVJSQVkodGltZXMzXiwwLHApKTsNCiAgICAgIFdyLlB1dFRleHQoU3RkaW8uc3Rk
>b3V0LCIgKHRlc3RzOiIpOw0KDQogICAgICBGT1IgaSA6PSBGSVJTVChNKSBUTyBMQVNUKE0pIERP
>DQogICAgICAgIElGIGkgSU4gc2V0cyBUSEVODQogICAgICAgICAgV3IuUHV0VGV4dChTdGRpby5z
>dGRvdXQsIiAiKTsNCiAgICAgICAgICBXci5QdXRUZXh0KFN0ZGlvLnN0ZG91dCxNYWtlcnNbaV0u
>bmFtZWQpOw0KICAgICAgICAgIFdyLlB1dFRleHQoU3RkaW8uc3Rkb3V0LCIgIik7DQogICAgICAg
>ICAgUHV0U3RhdHMoU1VCQVJSQVkodGltZXMyXixpKm5QZXIsblBlcikpDQogICAgICAgIEVORA0K
>ICAgICAgRU5EOw0KICAgICAgV3IuUHV0VGV4dChTdGRpby5zdGRvdXQsIikiKTtXci5QdXRUZXh0
>KFN0ZGlvLnN0ZG91dCxXci5FT0wpOw0KICAgICAgV3IuRmx1c2goU3RkaW8uc3Rkb3V0KTsNCg0K
>ICAgICAgRk9SIGkgOj0gMCBUTyBuLTENCiAgICAgIERPDQogICAgICAgICBJRiBhY3RpdmVbaV0g
>QU5EIChjb3VudHMyW2ldID0gY291bnRzM1tpXSkNCiAgICAgICAgIFRIRU4NCiAgICAgICAgICAg
>IFdyLlB1dFRleHQoU3RkaW8uc3Rkb3V0LCBNYWtlcnNbdGhyZWFkTVtpXV0ubmFtZWQgJiAiIFRo
>cmVhZCAiICYgRm10LkludChpKSAmICIgYXBwZWFycyBzdGFydmVkIG9yIGRlYWRsb2NrZWQgISEh
>IiAmIFdyLkVPTCk7DQogICAgICAgICBFTFNJRiB2ZXJib3NlIEFORCBhY3RpdmVbaV0gQU5EIChj
>b3VudHMyW2ldID4gY291bnRzM1tpXSkNCiAgICAgICAgIFRIRU4NCiAgICAgICAgICAgIFdyLlB1
>dFRleHQoU3RkaW8uc3Rkb3V0LCAiICAgIiAmIE1ha2Vyc1t0aHJlYWRNW2ldXS5uYW1lZCAmICIg
>VGhyZWFkICIgJiBGbXQuSW50KGkpICYgIiBjb21wbGV0ZWQgIiAmIEZtdC5Mb25nSW50KGNvdW50
>czJbaV0gLSBjb3VudHMzW2ldKSAmICIgbG9vcHMuIiAmIFdyLkVPTCk7DQogICAgICAgICBFTkQ7
>ICgqIGlmICopDQogICAgICBFTkQ7ICgqIGZvciAqKQ0KICAgICAgY291bnRzM14gOj0gY291bnRz
>Ml47DQogICAgICBXci5GbHVzaChTdGRpby5zdGRvdXQpOw0KICAgIEVORA0KICBFTkQ7DQogIFdy
>LlB1dFRleHQoU3RkaW8uc3Rkb3V0LCAiQWxsIHRlc3RzIGNvbXBsZXRlLiAgQ29uZ3JhdHVsYXRp
>b25zLiIpOw0KICBXci5QdXRUZXh0KFN0ZGlvLnN0ZG91dCwgV3IuRU9MKTsNCkVORCBNYWluLg0K
>DQo=
>
>--_004_D67F02DDC62F7545A6B84C285F88F3E603418BD6ADatlex02srv_--


From rcolebur at SCIRES.COM  Wed Mar 16 19:42:10 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Wed, 16 Mar 2011 14:42:10 -0400
Subject: [M3devel] thread tests on NT386 32-bit circa 2008, not good so far
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E603418BDAF8@atlex02-srv>

I've gone back to a CM3 built on June 21, 2008.
Platform is IBM ThinkPad T60, Windows XP Professional, 32-bit.

If I try to put the "@M3paranoidgc" option on the command line, the thread test program always crashes, even before it reports anything about creating the threads.

"read", "nxread", "tryexcept", "fork", "forktoomuch", and "lock" tests seem to succeed.

"creat" and "alloc" seem to hang the program on the first iteration.  I see one "." printed and nothing else.  Have to CTRL-C abort.
BUT, if you run them with "@M3nogc" they will run until we run out of memory.  Tony, does this give any hint as to what may be wrong?

Output of the various runs is shown below:


C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read @M3paranoidgc

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0x42fb8c = AllocTraced + 0x3e in ..\src\runtime\common\RTCollector.m3
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 845
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 845
***


C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests alloc
Writing file...done
Creating alloc threads...
   alloc=15
   alloc=16
   alloc=17
done
running...printing oldest/median age/newest
.^C

C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests creat
Writing file...done
Creating creat threads...
   creat=18
   creat=19
   creat=20
done
running...printing oldest/median age/newest
.^C


C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests creat,alloc @M3nogc
Writing file...done
Creating alloc threads...
   alloc=15
   alloc=16
   alloc=17
done
Creating creat threads...
   creat=18
   creat=19
   creat=20
done
running...printing oldest/median age/newest
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 29204 loops.
   alloc Thread 16 completed 38868 loops.
   alloc Thread 17 completed 29118 loops.
   creat Thread 18 completed 111114 loops.
   creat Thread 19 completed 114913 loops.
   creat Thread 20 completed 108555 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 6968 loops.
   alloc Thread 16 completed 6747 loops.
   alloc Thread 17 completed 6331 loops.
   creat Thread 18 completed 40626 loops.
   creat Thread 19 completed 46526 loops.
   creat Thread 20 completed 43511 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 4857 loops.
   alloc Thread 16 completed 5409 loops.
   alloc Thread 17 completed 4601 loops.
   creat Thread 18 completed 50836 loops.
   creat Thread 19 completed 50108 loops.
   creat Thread 20 completed 53645 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 6249 loops.
   alloc Thread 16 completed 7252 loops.
   alloc Thread 17 completed 6770 loops.
   creat Thread 18 completed 62606 loops.
   creat Thread 19 completed 66036 loops.
   creat Thread 20 completed 62561 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 7000 loops.
   alloc Thread 16 completed 7559 loops.
   alloc Thread 17 completed 7389 loops.
   creat Thread 18 completed 66873 loops.
   creat Thread 19 completed 81612 loops.
   creat Thread 20 completed 62607 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 6666 loops.
   alloc Thread 16 completed 7579 loops.
   alloc Thread 17 completed 6964 loops.
   creat Thread 18 completed 89667 loops.
   creat Thread 19 completed 90794 loops.
   creat Thread 20 completed 90528 loops.
.....

***
*** runtime error:
***    NEW() was unable to allocate more memory.
***    file "..\src\runtime\common\RTCollector.m3", line 1545
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x4e7fe34   0x430197  LongAlloc + 0x89 in ..\src\runtime\common\RTCollector.m3
0x4e7fe90   0x42fd06  AllocTraced + 0x1b8 in ..\src\runtime\common\RTCollector.m3
0x4e7fed4   0x427ea9  GetOpenArray + 0x80 in ..\src\runtime\common\RTAllocator.m3
0x4e7fef8   0x427738  AllocateOpenArray + 0x19 in ..\src\runtime\common\RTAllocator.m3
0x4e7ff50   0x402293  AApply + 0x109 in ..\src\Main.m3
0x4e7ff88   0x42a34a  RunThread + 0x1f6 in ..\src\thread\WIN32\ThreadWin32.m3
0x4e7ffb4   0x42a0e3  ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3
.........  .........  ... more frames ...


C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lock
Writing file...done
Creating read threads...
   read=0
   read=1
   read=2
done
Creating nxread threads...
   nxread=3
   nxread=4
   nxread=5
done
Creating tryexcept threads...
   tryexcept=6
   tryexcept=7
   tryexcept=8
done
Creating fork threads...
   fork=9
   fork=0
   fork=11
done
Creating forktoomuch threads...
   forktoomuch=12
   forktoomuch=13
   forktoomuch=14
done
Creating lock threads...
   lock=21
   lock=22
   lock=23
done
running...printing oldest/median age/newest
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 2 loops.
   read Thread 1 completed 6 loops.
   read Thread 2 completed 4 loops.
   nxread Thread 3 completed 3 loops.
   nxread Thread 4 completed 1 loops.
   nxread Thread 5 completed 3 loops.
   tryexcept Thread 6 completed 14293296 loops.
   tryexcept Thread 7 completed 23332343 loops.
   tryexcept Thread 8 completed 14563267 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 5 loops.
   forktoomuch Thread 12 completed 6 loops.
   forktoomuch Thread 13 completed 7 loops.
   forktoomuch Thread 14 completed 6 loops.
   lock Thread 21 completed 1395 loops.
   lock Thread 22 completed 1613 loops.
   lock Thread 23 completed 2354 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 6 loops.
   read Thread 1 completed 13 loops.
   read Thread 2 completed 5 loops.
   nxread Thread 3 completed 8 loops.
   nxread Thread 4 completed 7 loops.
   nxread Thread 5 completed 10 loops.
   tryexcept Thread 6 completed 15350367 loops.
   tryexcept Thread 7 completed 22864059 loops.
   tryexcept Thread 8 completed 14516795 loops.
   fork Thread 9 completed 6 loops.
   fork Thread 10 completed 7 loops.
   fork Thread 11 completed 6 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 9 loops.
   forktoomuch Thread 14 completed 8 loops.
   lock Thread 21 completed 3742 loops.
   lock Thread 22 completed 2342 loops.
   lock Thread 23 completed 3827 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 5 loops.
   read Thread 1 completed 10 loops.
   read Thread 2 completed 4 loops.
   nxread Thread 3 completed 5 loops.
   nxread Thread 4 completed 3 loops.
   nxread Thread 5 completed 4 loops.
   tryexcept Thread 6 completed 14205335 loops.
   tryexcept Thread 7 completed 23955466 loops.
   tryexcept Thread 8 completed 14597334 loops.
   fork Thread 9 completed 7 loops.
   fork Thread 10 completed 6 loops.
   fork Thread 11 completed 7 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 9 loops.
   forktoomuch Thread 14 completed 8 loops.
   lock Thread 21 completed 1384 loops.
   lock Thread 22 completed 3801 loops.
   lock Thread 23 completed 4735 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 5 loops.
   read Thread 1 completed 9 loops.
   read Thread 2 completed 6 loops.
   nxread Thread 3 completed 5 loops.
   nxread Thread 4 completed 4 loops.
   nxread Thread 5 completed 9 loops.
   tryexcept Thread 6 completed 13962901 loops.
   tryexcept Thread 7 completed 22999610 loops.
   tryexcept Thread 8 completed 14123517 loops.
   fork Thread 9 completed 6 loops.
   fork Thread 10 completed 6 loops.
   fork Thread 11 completed 5 loops.
   forktoomuch Thread 12 completed 7 loops.
   forktoomuch Thread 13 completed 8 loops.
   forktoomuch Thread 14 completed 8 loops.
   lock Thread 21 completed 1744 loops.
   lock Thread 22 completed 2095 loops.
   lock Thread 23 completed 1503 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 2 loops.
   read Thread 1 completed 6 loops.
   read Thread 2 completed 2 loops.
   nxread Thread 3 completed 3 loops.
   nxread Thread 4 completed 3 loops.
   nxread Thread 5 completed 3 loops.
   tryexcept Thread 6 completed 15715885 loops.
   tryexcept Thread 7 completed 24769727 loops.
   tryexcept Thread 8 completed 15414675 loops.
   fork Thread 9 completed 7 loops.
   fork Thread 10 completed 6 loops.
   fork Thread 11 completed 7 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 8 loops.
   forktoomuch Thread 14 completed 9 loops.
   lock Thread 21 completed 1523 loops.
   lock Thread 22 completed 1922 loops.
   lock Thread 23 completed 1204 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 5 loops.
   read Thread 1 completed 9 loops.
   read Thread 2 completed 6 loops.
   nxread Thread 3 completed 4 loops.
   nxread Thread 4 completed 2 loops.
   nxread Thread 5 completed 8 loops.
   tryexcept Thread 6 completed 14688224 loops.
   tryexcept Thread 7 completed 23710577 loops.
   tryexcept Thread 8 completed 15355622 loops.
   fork Thread 9 completed 6 loops.
   fork Thread 10 completed 7 loops.
   fork Thread 11 completed 6 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 9 loops.
   forktoomuch Thread 14 completed 7 loops.
   lock Thread 21 completed 9427 loops.
   lock Thread 22 completed 3941 loops.
   lock Thread 23 completed 4421 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 9 loops.
   read Thread 1 completed 11 loops.
   read Thread 2 completed 6 loops.
   nxread Thread 3 completed 7 loops.
   nxread Thread 4 completed 5 loops.
   nxread Thread 5 completed 9 loops.
   tryexcept Thread 6 completed 16315690 loops.
   tryexcept Thread 7 completed 25110147 loops.
   tryexcept Thread 8 completed 17291322 loops.
   fork Thread 9 completed 5 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 5 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 9 loops.
   forktoomuch Thread 14 completed 8 loops.
   lock Thread 21 completed 1648 loops.
   lock Thread 22 completed 1274 loops.
   lock Thread 23 completed 975 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 2 loops.
   read Thread 1 completed 6 loops.
   read Thread 2 completed 3 loops.
   nxread Thread 3 completed 7 loops.
   nxread Thread 4 completed 4 loops.
   nxread Thread 5 completed 7 loops.
   tryexcept Thread 6 completed 16955552 loops.
   tryexcept Thread 7 completed 27781696 loops.
   tryexcept Thread 8 completed 16151561 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 3 loops.
   fork Thread 11 completed 2 loops.
   forktoomuch Thread 12 completed 7 loops.
   forktoomuch Thread 13 completed 7 loops.
   forktoomuch Thread 14 completed 7 loops.
   lock Thread 21 completed 2148 loops.
   lock Thread 22 completed 2179 loops.
   lock Thread 23 completed 1804 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 7 loops.
   read Thread 1 completed 5 loops.
   read Thread 2 completed 4 loops.
   nxread Thread 3 completed 9 loops.
   nxread Thread 4 completed 6 loops.
   nxread Thread 5 completed 5 loops.
   tryexcept Thread 6 completed 14537433 loops.
   tryexcept Thread 7 completed 24043303 loops.
   tryexcept Thread 8 completed 14258976 loops.
   fork Thread 9 completed 6 loops.
   fork Thread 10 completed 7 loops.
   fork Thread 11 completed 6 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 8 loops.
   forktoomuch Thread 14 completed 8 loops.
   lock Thread 21 completed 6504 loops.
   lock Thread 22 completed 2290 loops.
   lock Thread 23 completed 7696 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 5 loops.
   read Thread 1 completed 6 loops.
   read Thread 2 completed 2 loops.
   nxread Thread 3 completed 4 loops.
   nxread Thread 4 completed 1 loops.
   nxread Thread 5 completed 3 loops.
   tryexcept Thread 6 completed 17349384 loops.
   tryexcept Thread 7 completed 29845941 loops.
   tryexcept Thread 8 completed 17792587 loops.
   fork Thread 9 completed 5 loops.
   fork Thread 10 completed 5 loops.
   fork Thread 11 completed 6 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 9 loops.
   forktoomuch Thread 14 completed 9 loops.
   lock Thread 21 completed 2692 loops.
   lock Thread 22 completed 4498 loops.
   lock Thread 23 completed 3600 loops.
All tests complete.  Congratulations.

C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>

Regards,
Randy Coleburn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110316/5aece318/attachment-0002.html>

From rcolebur at SCIRES.COM  Wed Mar 16 19:54:37 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Wed, 16 Mar 2011 14:54:37 -0400
Subject: [M3devel] another thread test run on NT386 32-bit using HEAD branch
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E603418BDB06@atlex02-srv>

Here are results from the following platform:
IBM G40, Windows XP Professional, 32-bit
Using current HEAD branch of CM3

Both of the runs below use @M3paranoidgc

Note on the second run using alloc and creat tests that I get an error about a thread trying to join twice.

C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lock @M3paranoidgc
Writing file...done
Creating read threads...
   read=0
   read=1
   read=2
done
Creating nxread threads...
   nxread=3
   nxread=4
   nxread=5
done
Creating tryexcept threads...
   tryexcept=6
   tryexcept=7
   tryexcept=8
done
Creating fork threads...
   fork=9
   fork=0
   fork=11
done
Creating forktoomuch threads...
   forktoomuch=12
   forktoomuch=13
   forktoomuch=14
done
Creating lock threads...
   lock=21
   lock=22
   lock=23
done
running...printing oldest/median age/newest
....

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0x4086a0 = Init + 0x79 in ..\src\rw\FileRd.m3
***

.Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x107feb8   0x44536b  SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m3
0x107ff00   0x4086a0  Init + 0x79 in ..\src\rw\FileRd.m3
0x107ff2c   0x40861d  Open + 0x4d in ..\src\rw\FileRd.m3
0x107ff78   0x40173e  NApply + 0x124 in ..\src\Main.m3
0x107ffb4   0x42b56f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
.........  .........  ... more frames ...



C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests alloc,creat @M3paranoidgc
Writing file...done
Creating alloc threads...
   alloc=15
   alloc=16
   alloc=17
done
Creating creat threads...
   creat=18
   creat=19
   creat=20
done
running...printing oldest/median age/newest
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 11125 loops.
   alloc Thread 16 completed 10472 loops.
   alloc Thread 17 completed 9722 loops.
   creat Thread 18 completed 84 loops.
   creat Thread 19 completed 98 loops.
   creat Thread 20 completed 96 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 14258 loops.
   alloc Thread 16 completed 10791 loops.
   alloc Thread 17 completed 11403 loops.
   creat Thread 18 completed 111 loops.
   creat Thread 19 completed 115 loops.
   creat Thread 20 completed 121 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 13954 loops.
   alloc Thread 16 completed 9547 loops.
   alloc Thread 17 completed 10561 loops.
   creat Thread 18 completed 115 loops.
   creat Thread 19 completed 121 loops.
   creat Thread 20 completed 125 loops.
.

***
*** runtime error:
***    Thread client error: attempt to join with thread twice
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 688
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x127fedc   0x42c3ee  Die + 0x2a in ..\src\thread\WIN32\ThreadWin32.m3
0x127ff10   0x42b882  XJoin + 0x3c in ..\src\thread\WIN32\ThreadWin32.m3
0x127ff38   0x42ba06  Join + 0x46 in ..\src\thread\WIN32\ThreadWin32.m3
0x127ff78   0x402777  CApply + 0x12d in ..\src\Main.m3
0x127ffb4   0x42b56f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
.........  .........  ... more frames ...


Regards,
Randy Coleburn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110316/9a242093/attachment-0002.html>

From dabenavidesd at yahoo.es  Wed Mar 16 22:11:06 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 16 Mar 2011 21:11:06 +0000 (GMT)
Subject: [M3devel] thread tests on NT386 32-bit circa 2008,
	not good so far
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BDAF8@atlex02-srv>
Message-ID: <654158.70885.qm@web29702.mail.ird.yahoo.com>

Hi all:
I would be not surprised if its results were wrong crashes but because of the system threading.
Certainly we? would need to discard why the user threads are working so far and system threads are not working, i.e why CVsup is not working there are several idiomatic differences between system threads, each system indeed has its own behavior different from user threads, it certainly makes things portable in that sense to me.
But when ever we have access to one SPIN installation, I guess the program would be no trouble in running, as I think you could even debug it with a dynamic race condition detector, as I read somewhere, they did a catch somewhere in C client libraries linked against RT or better than that to use SPIN m3gdb specially modified for that purpose of remote debugging.
Even with the user threads implementation is not difficult but because of those libraries get into that debugging I believe.
Also we can annotate sources to debug later with ESC, at least its syntax, later more.
The other thing is that we then must need LL pragma which I still don't how to use, so any documentation on that is most welcome.
Yet another option would be catch the system threads in a stack trace able platform like there were before, perhaps this is the most feasible 
Thanks in advance

?

--- El mi?, 16/3/11, Coleburn, Randy <rcolebur at SCIRES.COM> escribi?:

De: Coleburn, Randy <rcolebur at SCIRES.COM>
Asunto: [M3devel] thread tests on NT386 32-bit circa 2008, not good so far
Para: "m3devel" <m3devel at elegosoft.com>
Fecha: mi?rcoles, 16 de marzo, 2011 13:42

I?ve gone back to a CM3 built on June 21, 2008.Platform is IBM ThinkPad T60, Windows XP Professional, 32-bit. ?If I try to put the ?@M3paranoidgc? option on the command line, the thread test program always crashes, even before it reports anything about creating the threads. ??read?, ?nxread?, ?tryexcept?, ?fork?, ?forktoomuch?, and ?lock? tests seem to succeed. ??creat? and ?alloc? seem to hang the program on the first iteration.? I see one ?.? printed and nothing else.? Have to CTRL-C abort.BUT, if you run them with ?@M3nogc? they will run until we run out of memory.? Tony, does this give any hint as to what may be wrong? ?Output of the various runs is shown below: ? ?C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read @M3paranoidgc ?****** runtime error:***??? Attempt to reference an illegal memory location.***??? pc = 0x42fb8c = AllocTraced + 0x3e in
 ..\src\runtime\common\RTCollector.m3*** ?****** runtime error:***??? <*ASSERT*> failed.***??? file "..\src\thread\WIN32\ThreadWin32.m3", line 845*** ?****** runtime error:***??? <*ASSERT*> failed.***??? file "..\src\thread\WIN32\ThreadWin32.m3", line 845*** ? ?C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests allocWriting file...doneCreating alloc threads...?? alloc=15?? alloc=16?? alloc=17donerunning...printing oldest/median age/newest.^C ?C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests creatWriting file...doneCreating creat threads...?? creat=18?? creat=19?? creat=20donerunning...printing oldest/median age/newest.^C ? ?C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests creat,alloc @M3nogcWriting file...doneCreating alloc threads...?? alloc=15?? alloc=16?? alloc=17doneCreating creat threads...?? creat=18??
 creat=19?? creat=20donerunning...printing oldest/median age/newest..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)?? alloc Thread 15 completed 29204 loops.?? alloc Thread 16 completed 38868 loops.?? alloc Thread 17 completed 29118 loops.?? creat Thread 18 completed 111114 loops.?? creat Thread 19 completed 114913 loops.?? creat Thread 20 completed 108555 loops...........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)?? alloc Thread 15 completed 6968 loops.?? alloc Thread 16 completed 6747 loops.?? alloc Thread 17 completed 6331 loops.?? creat Thread 18 completed 40626 loops.?? creat Thread 19 completed 46526 loops.?? creat Thread 20 completed 43511 loops...........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)?? alloc Thread 15 completed 4857 loops.?? alloc Thread 16 completed 5409 loops.?? alloc Thread 17 completed 4601 loops.?? creat Thread 18 completed 50836 loops.?? creat
 Thread 19 completed 50108 loops.?? creat Thread 20 completed 53645 loops...........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)?? alloc Thread 15 completed 6249 loops.?? alloc Thread 16 completed 7252 loops.?? alloc Thread 17 completed 6770 loops.?? creat Thread 18 completed 62606 loops.?? creat Thread 19 completed 66036 loops.?? creat Thread 20 completed 62561 loops...........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)?? alloc Thread 15 completed 7000 loops.?? alloc Thread 16 completed 7559 loops.?? alloc Thread 17 completed 7389 loops.?? creat Thread 18 completed 66873 loops.?? creat Thread 19 completed 81612 loops.?? creat Thread 20 completed 62607 loops...........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)?? alloc Thread 15 completed 6666 loops.?? alloc Thread 16 completed 7579 loops.?? alloc Thread 17 completed 6964 loops.?? creat Thread 18 completed 89667 loops.?? creat
 Thread 19 completed 90794 loops.?? creat Thread 20 completed 90528 loops...... ?****** runtime error:***??? NEW() was unable to allocate more memory.***??? file "..\src\runtime\common\RTCollector.m3", line 1545*** ?Stack trace:?? FP???????? PC????? Procedure---------? ---------? -------------------------------0x4e7fe34?? 0x430197? LongAlloc + 0x89 in ..\src\runtime\common\RTCollector.m30x4e7fe90?? 0x42fd06? AllocTraced + 0x1b8 in ..\src\runtime\common\RTCollector.m30x4e7fed4?? 0x427ea9? GetOpenArray + 0x80 in ..\src\runtime\common\RTAllocator.m30x4e7fef8?? 0x427738? AllocateOpenArray + 0x19 in ..\src\runtime\common\RTAllocator.m30x4e7ff50?? 0x402293? AApply + 0x109 in ..\src\Main.m30x4e7ff88?? 0x42a34a? RunThread + 0x1f6 in ..\src\thread\WIN32\ThreadWin32.m30x4e7ffb4?? 0x42a0e3? ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3.........? .........? ... more frames ... ?
 ?C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lockWriting file...doneCreating read threads...?? read=0?? read=1?? read=2doneCreating nxread threads...?? nxread=3?? nxread=4?? nxread=5doneCreating tryexcept threads...?? tryexcept=6?? tryexcept=7?? tryexcept=8doneCreating fork threads...?? fork=9?? fork=0?? fork=11doneCreating forktoomuch threads...?? forktoomuch=12?? forktoomuch=13?? forktoomuch=14doneCreating lock threads...?? lock=21?? lock=22?? lock=23donerunning...printing oldest/median age/newest..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 2 loops.?? read Thread 1 completed 6 loops.?? read Thread 2 completed 4 loops.?? nxread Thread 3 completed 3 loops.?? nxread Thread 4 completed 1 loops.?? nxread Thread 5 completed 3
 loops.?? tryexcept Thread 6 completed 14293296 loops.?? tryexcept Thread 7 completed 23332343 loops.?? tryexcept Thread 8 completed 14563267 loops.?? fork Thread 9 completed 4 loops.?? fork Thread 10 completed 4 loops.?? fork Thread 11 completed 5 loops.?? forktoomuch Thread 12 completed 6 loops.?? forktoomuch Thread 13 completed 7 loops.?? forktoomuch Thread 14 completed 6 loops.?? lock Thread 21 completed 1395 loops.?? lock Thread 22 completed 1613 loops.?? lock Thread 23 completed 2354 loops...........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 6 loops.?? read Thread 1 completed 13 loops.?? read Thread 2 completed 5 loops.?? nxread Thread 3 completed 8 loops.?? nxread Thread 4 completed 7 loops.?? nxread Thread 5 completed 10 loops.?? tryexcept Thread 6 completed 15350367 loops.?? tryexcept Thread 7 completed 22864059
 loops.?? tryexcept Thread 8 completed 14516795 loops.?? fork Thread 9 completed 6 loops.?? fork Thread 10 completed 7 loops.?? fork Thread 11 completed 6 loops.?? forktoomuch Thread 12 completed 8 loops.?? forktoomuch Thread 13 completed 9 loops.?? forktoomuch Thread 14 completed 8 loops.?? lock Thread 21 completed 3742 loops.?? lock Thread 22 completed 2342 loops.?? lock Thread 23 completed 3827 loops...........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 5 loops.?? read Thread 1 completed 10 loops.?? read Thread 2 completed 4 loops.?? nxread Thread 3 completed 5 loops.?? nxread Thread 4 completed 3 loops.?? nxread Thread 5 completed 4 loops.?? tryexcept Thread 6 completed 14205335 loops.?? tryexcept Thread 7 completed 23955466 loops.?? tryexcept Thread 8 completed 14597334 loops.?? fork Thread 9 completed 7 loops.??
 fork Thread 10 completed 6 loops.?? fork Thread 11 completed 7 loops.?? forktoomuch Thread 12 completed 8 loops.?? forktoomuch Thread 13 completed 9 loops.?? forktoomuch Thread 14 completed 8 loops.?? lock Thread 21 completed 1384 loops.?? lock Thread 22 completed 3801 loops.?? lock Thread 23 completed 4735 loops...........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 5 loops.?? read Thread 1 completed 9 loops.?? read Thread 2 completed 6 loops.?? nxread Thread 3 completed 5 loops.?? nxread Thread 4 completed 4 loops.?? nxread Thread 5 completed 9 loops.?? tryexcept Thread 6 completed 13962901 loops.?? tryexcept Thread 7 completed 22999610 loops.?? tryexcept Thread 8 completed 14123517 loops.?? fork Thread 9 completed 6 loops.?? fork Thread 10 completed 6 loops.?? fork Thread 11 completed 5 loops.?? forktoomuch Thread 12
 completed 7 loops.?? forktoomuch Thread 13 completed 8 loops.?? forktoomuch Thread 14 completed 8 loops.?? lock Thread 21 completed 1744 loops.?? lock Thread 22 completed 2095 loops.?? lock Thread 23 completed 1503 loops...........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 2 loops.?? read Thread 1 completed 6 loops.?? read Thread 2 completed 2 loops.?? nxread Thread 3 completed 3 loops.?? nxread Thread 4 completed 3 loops.? ?nxread Thread 5 completed 3 loops.?? tryexcept Thread 6 completed 15715885 loops.?? tryexcept Thread 7 completed 24769727 loops.?? tryexcept Thread 8 completed 15414675 loops.?? fork Thread 9 completed 7 loops.?? fork Thread 10 completed 6 loops.?? fork Thread 11 completed 7 loops.?? forktoomuch Thread 12 completed 8 loops.?? forktoomuch Thread 13 completed 8 loops.?? forktoomuch Thread 14 completed
 9 loops.?? lock Thread 21 completed 1523 loops.?? lock Thread 22 completed 1922 loops.?? lock Thread 23 completed 1204 loops...........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 5 loops.?? read Thread 1 completed 9 loops.?? read Thread 2 completed 6 loops.?? nxread Thread 3 completed 4 loops.?? nxread Thread 4 completed 2 loops.?? nxread Thread 5 completed 8 loops.?? tryexcept Thread 6 completed 14688224 loops.?? tryexcept Thread 7 completed 23710577 loops.?? tryexcept Thread 8 completed 15355622 loops.?? fork Thread 9 completed 6 loops.?? fork Thread 10 completed 7 loops.?? fork Thread 11 completed 6 loops.?? forktoomuch Thread 12 completed 8 loops.?? forktoomuch Thread 13 completed 9 loops.?? forktoomuch Thread 14 completed 7 loops.?? lock Thread 21 completed 9427 loops.?? lock Thread 22 completed 3941 loops.?? lock
 Thread 23 completed 4421 loops...........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 9 loops.?? read Thread 1 completed 11 loops.?? read Thread 2 completed 6 loops.?? nxread Thread 3 completed 7 loops.?? nxread Thread 4 completed 5 loops.?? nxread Thread 5 completed 9 loops.?? tryexcept Thread 6 completed 16315690 loops.?? tryexcept Thread 7 completed 25110147 loops.?? tryexcept Thread 8 completed 17291322 loops.?? fork Thread 9 completed 5 loops.?? fork Thread 10 completed 4 loops.?? fork Thread 11 completed 5 loops.? ?forktoomuch Thread 12 completed 8 loops.?? forktoomuch Thread 13 completed 9 loops.?? forktoomuch Thread 14 completed 8 loops.?? lock Thread 21 completed 1648 loops.?? lock Thread 22 completed 1274 loops.?? lock Thread 23 completed 975 loops...........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0
 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 2 loops.?? read Thread 1 completed 6 loops.?? read Thread 2 completed 3 loops.?? nxread Thread 3 completed 7 loops.?? nxread Thread 4 completed 4 loops.?? nxread Thread 5 completed 7 loops.?? tryexcept Thread 6 completed 16955552 loops.?? tryexcept Thread 7 completed 27781696 loops.?? tryexcept Thread 8 completed 16151561 loops.?? fork Thread 9 completed 4 loops.?? fork Thread 10 completed 3 loops.?? fork Thread 11 completed 2 loops.?? forktoomuch Thread 12 completed 7 loops.?? forktoomuch Thread 13 completed 7 loops.?? forktoomuch Thread 14 completed 7 loops.?? lock Thread 21 completed 2148 loops.?? lock Thread 22 completed 2179 loops.?? lock Thread 23 completed 1804 loops...........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 7 loops.??
 read Thread 1 completed 5 loops.?? read Thread 2 completed 4 loops.?? nxread Thread 3 completed 9 loops.?? nxread Thread 4 completed 6 loops.?? nxread Thread 5 completed 5 loops.?? tryexcept Thread 6 completed 14537433 loops.?? tryexcept Thread 7 completed 24043303 loops.?? tryexcept Thread 8 completed 14258976 loops.?? fork Thread 9 completed 6 loops.?? fork Thread 10 completed 7 loops.?? fork Thread 11 completed 6 loops.?? forktoomuch Thread 12 completed 8 loops.?? forktoomuch Thread 13 completed 8 loops.?? forktoomuch Thread 14 completed 8 loops.?? lock Thread 21 completed 6504 loops.?? lock Thread 22 completed 2290 loops.?? lock Thread 23 completed 7696 loops...........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)?? read Thread 0 completed 5 loops.?? read Thread 1 completed 6 loops.?? read Thread 2 completed 2 loops.?? nxread Thread 3 completed
 4 loops.?? nxread Thread 4 completed 1 loops.?? nxread Thread 5 completed 3 loops.?? tryexcept Thread 6 completed 17349384 loops.?? tryexcept Thread 7 completed 29845941 loops.?? tryexcept Thread 8 completed 17792587 loops.?? fork Thread 9 completed 5 loops.?? fork Thread 10 completed 5 loops.?? fork Thread 11 completed 6 loops.? ?forktoomuch Thread 12 completed 8 loops.?? forktoomuch Thread 13 completed 9 loops.?? forktoomuch Thread 14 completed 9 loops.?? lock Thread 21 completed 2692 loops.?? lock Thread 22 completed 4498 loops.?? lock Thread 23 completed 3600 loops.All tests complete.? Congratulations. ?C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386> ?Regards,Randy Coleburn ?


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

From hosking at cs.purdue.edu  Wed Mar 16 22:22:38 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 16 Mar 2011 17:22:38 -0400
Subject: [M3devel] another thread test run on NT386 32-bit using HEAD
	branch
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BDB06@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BDB06@atlex02-srv>
Message-ID: <0BEFC896-66CC-4441-8271-360FD0E3F59B@cs.purdue.edu>

Badness both places.  Not sure I see anything obvious from these dumps.

On Mar 16, 2011, at 2:54 PM, Coleburn, Randy wrote:

> Here are results from the following platform:
> IBM G40, Windows XP Professional, 32-bit
> Using current HEAD branch of CM3
>  
> Both of the runs below use @M3paranoidgc
>  
> Note on the second run using alloc and creat tests that I get an error about a thread trying to join twice.
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lock @M3paranoidgc
> Writing file...done
> Creating read threads...
>    read=0
>    read=1
>    read=2
> done
> Creating nxread threads...
>    nxread=3
>    nxread=4
>    nxread=5
> done
> Creating tryexcept threads...
>    tryexcept=6
>    tryexcept=7
>    tryexcept=8
> done
> Creating fork threads...
>    fork=9
>    fork=0
>    fork=11
> done
> Creating forktoomuch threads...
>    forktoomuch=12
>    forktoomuch=13
>    forktoomuch=14
> done
> Creating lock threads...
>    lock=21
>    lock=22
>    lock=23
> done
> running...printing oldest/median age/newest
> ....
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
> ***    pc = 0x4086a0 = Init + 0x79 in ..\src\rw\FileRd.m3
> ***
>  
> .Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0x107feb8   0x44536b  SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m3
> 0x107ff00   0x4086a0  Init + 0x79 in ..\src\rw\FileRd.m3
> 0x107ff2c   0x40861d  Open + 0x4d in ..\src\rw\FileRd.m3
> 0x107ff78   0x40173e  NApply + 0x124 in ..\src\Main.m3
> 0x107ffb4   0x42b56f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
> .........  .........  ... more frames ...
>  
>  
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests alloc,creat @M3paranoidgc
> Writing file...done
> Creating alloc threads...
>    alloc=15
>    alloc=16
>    alloc=17
> done
> Creating creat threads...
>    creat=18
>    creat=19
>    creat=20
> done
> running...printing oldest/median age/newest
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 11125 loops.
>    alloc Thread 16 completed 10472 loops.
>    alloc Thread 17 completed 9722 loops.
>    creat Thread 18 completed 84 loops.
>    creat Thread 19 completed 98 loops.
>    creat Thread 20 completed 96 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 14258 loops.
>    alloc Thread 16 completed 10791 loops.
>    alloc Thread 17 completed 11403 loops.
>    creat Thread 18 completed 111 loops.
>    creat Thread 19 completed 115 loops.
>    creat Thread 20 completed 121 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 13954 loops.
>    alloc Thread 16 completed 9547 loops.
>    alloc Thread 17 completed 10561 loops.
>    creat Thread 18 completed 115 loops.
>    creat Thread 19 completed 121 loops.
>    creat Thread 20 completed 125 loops.
> .
>  
> ***
> *** runtime error:
> ***    Thread client error: attempt to join with thread twice
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 688
> ***
>  
> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0x127fedc   0x42c3ee  Die + 0x2a in ..\src\thread\WIN32\ThreadWin32.m3
> 0x127ff10   0x42b882  XJoin + 0x3c in ..\src\thread\WIN32\ThreadWin32.m3
> 0x127ff38   0x42ba06  Join + 0x46 in ..\src\thread\WIN32\ThreadWin32.m3
> 0x127ff78   0x402777  CApply + 0x12d in ..\src\Main.m3
> 0x127ffb4   0x42b56f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
> .........  .........  ... more frames ...
>  
>  
> Regards,
> Randy Coleburn
>  

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

From hosking at cs.purdue.edu  Wed Mar 16 22:25:25 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 16 Mar 2011 17:25:25 -0400
Subject: [M3devel] thread tests on NT386 32-bit circa 2008,
	not good so far
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BDAF8@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BDAF8@atlex02-srv>
Message-ID: <B579D06A-BA7D-4739-9954-3B8A4E358AAD@cs.purdue.edu>

I don't remember how stable the collector was at that point.  Running them with @M3nogc indicates there were problems with it.
Now, what happens with the current trunk head when run with @M3nogc?

On Mar 16, 2011, at 2:42 PM, Coleburn, Randy wrote:

> I?ve gone back to a CM3 built on June 21, 2008.
> Platform is IBM ThinkPad T60, Windows XP Professional, 32-bit.
>  
> If I try to put the ?@M3paranoidgc? option on the command line, the thread test program always crashes, even before it reports anything about creating the threads.
>  
> ?read?, ?nxread?, ?tryexcept?, ?fork?, ?forktoomuch?, and ?lock? tests seem to succeed.
>  
> ?creat? and ?alloc? seem to hang the program on the first iteration.  I see one ?.? printed and nothing else.  Have to CTRL-C abort.
> BUT, if you run them with ?@M3nogc? they will run until we run out of memory.  Tony, does this give any hint as to what may be wrong?
>  
> Output of the various runs is shown below:
>  
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read @M3paranoidgc
>  
> ***
> *** runtime error:
> ***    Attempt to reference an illegal memory location.
> ***    pc = 0x42fb8c = AllocTraced + 0x3e in ..\src\runtime\common\RTCollector.m3
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 845
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 845
> ***
>  
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests alloc
> Writing file...done
> Creating alloc threads...
>    alloc=15
>    alloc=16
>    alloc=17
> done
> running...printing oldest/median age/newest
> .^C
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests creat
> Writing file...done
> Creating creat threads...
>    creat=18
>    creat=19
>    creat=20
> done
> running...printing oldest/median age/newest
> .^C
>  
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests creat,alloc @M3nogc
> Writing file...done
> Creating alloc threads...
>    alloc=15
>    alloc=16
>    alloc=17
> done
> Creating creat threads...
>    creat=18
>    creat=19
>    creat=20
> done
> running...printing oldest/median age/newest
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 29204 loops.
>    alloc Thread 16 completed 38868 loops.
>    alloc Thread 17 completed 29118 loops.
>    creat Thread 18 completed 111114 loops.
>    creat Thread 19 completed 114913 loops.
>    creat Thread 20 completed 108555 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 6968 loops.
>    alloc Thread 16 completed 6747 loops.
>    alloc Thread 17 completed 6331 loops.
>    creat Thread 18 completed 40626 loops.
>    creat Thread 19 completed 46526 loops.
>    creat Thread 20 completed 43511 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 4857 loops.
>    alloc Thread 16 completed 5409 loops.
>    alloc Thread 17 completed 4601 loops.
>    creat Thread 18 completed 50836 loops.
>    creat Thread 19 completed 50108 loops.
>    creat Thread 20 completed 53645 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 6249 loops.
>    alloc Thread 16 completed 7252 loops.
>    alloc Thread 17 completed 6770 loops.
>    creat Thread 18 completed 62606 loops.
>    creat Thread 19 completed 66036 loops.
>    creat Thread 20 completed 62561 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 7000 loops.
>    alloc Thread 16 completed 7559 loops.
>    alloc Thread 17 completed 7389 loops.
>    creat Thread 18 completed 66873 loops.
>    creat Thread 19 completed 81612 loops.
>    creat Thread 20 completed 62607 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 6666 loops.
>    alloc Thread 16 completed 7579 loops.
>    alloc Thread 17 completed 6964 loops.
>    creat Thread 18 completed 89667 loops.
>    creat Thread 19 completed 90794 loops.
>    creat Thread 20 completed 90528 loops.
> .....
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
> ***    file "..\src\runtime\common\RTCollector.m3", line 1545
> ***
>  
> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0x4e7fe34   0x430197  LongAlloc + 0x89 in ..\src\runtime\common\RTCollector.m3
> 0x4e7fe90   0x42fd06  AllocTraced + 0x1b8 in ..\src\runtime\common\RTCollector.m3
> 0x4e7fed4   0x427ea9  GetOpenArray + 0x80 in ..\src\runtime\common\RTAllocator.m3
> 0x4e7fef8   0x427738  AllocateOpenArray + 0x19 in ..\src\runtime\common\RTAllocator.m3
> 0x4e7ff50   0x402293  AApply + 0x109 in ..\src\Main.m3
> 0x4e7ff88   0x42a34a  RunThread + 0x1f6 in ..\src\thread\WIN32\ThreadWin32.m3
> 0x4e7ffb4   0x42a0e3  ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3
> .........  .........  ... more frames ...
>  
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lock
> Writing file...done
> Creating read threads...
>    read=0
>    read=1
>    read=2
> done
> Creating nxread threads...
>    nxread=3
>    nxread=4
>    nxread=5
> done
> Creating tryexcept threads...
>    tryexcept=6
>    tryexcept=7
>    tryexcept=8
> done
> Creating fork threads...
>    fork=9
>    fork=0
>    fork=11
> done
> Creating forktoomuch threads...
>    forktoomuch=12
>    forktoomuch=13
>    forktoomuch=14
> done
> Creating lock threads...
>    lock=21
>    lock=22
>    lock=23
> done
> running...printing oldest/median age/newest
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 2 loops.
>    read Thread 1 completed 6 loops.
>    read Thread 2 completed 4 loops.
>    nxread Thread 3 completed 3 loops.
>    nxread Thread 4 completed 1 loops.
>    nxread Thread 5 completed 3 loops.
>    tryexcept Thread 6 completed 14293296 loops.
>    tryexcept Thread 7 completed 23332343 loops.
>    tryexcept Thread 8 completed 14563267 loops.
>    fork Thread 9 completed 4 loops.
>    fork Thread 10 completed 4 loops.
>    fork Thread 11 completed 5 loops.
>    forktoomuch Thread 12 completed 6 loops.
>    forktoomuch Thread 13 completed 7 loops.
>    forktoomuch Thread 14 completed 6 loops.
>    lock Thread 21 completed 1395 loops.
>    lock Thread 22 completed 1613 loops.
>    lock Thread 23 completed 2354 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 6 loops.
>    read Thread 1 completed 13 loops.
>    read Thread 2 completed 5 loops.
>    nxread Thread 3 completed 8 loops.
>    nxread Thread 4 completed 7 loops.
>    nxread Thread 5 completed 10 loops.
>    tryexcept Thread 6 completed 15350367 loops.
>    tryexcept Thread 7 completed 22864059 loops.
>    tryexcept Thread 8 completed 14516795 loops.
>    fork Thread 9 completed 6 loops.
>    fork Thread 10 completed 7 loops.
>    fork Thread 11 completed 6 loops.
>    forktoomuch Thread 12 completed 8 loops.
>    forktoomuch Thread 13 completed 9 loops.
>    forktoomuch Thread 14 completed 8 loops.
>    lock Thread 21 completed 3742 loops.
>    lock Thread 22 completed 2342 loops.
>    lock Thread 23 completed 3827 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 5 loops.
>    read Thread 1 completed 10 loops.
>    read Thread 2 completed 4 loops.
>    nxread Thread 3 completed 5 loops.
>    nxread Thread 4 completed 3 loops.
>    nxread Thread 5 completed 4 loops.
>    tryexcept Thread 6 completed 14205335 loops.
>    tryexcept Thread 7 completed 23955466 loops.
>    tryexcept Thread 8 completed 14597334 loops.
>    fork Thread 9 completed 7 loops.
>    fork Thread 10 completed 6 loops.
>    fork Thread 11 completed 7 loops.
>    forktoomuch Thread 12 completed 8 loops.
>    forktoomuch Thread 13 completed 9 loops.
>    forktoomuch Thread 14 completed 8 loops.
>    lock Thread 21 completed 1384 loops.
>    lock Thread 22 completed 3801 loops.
>    lock Thread 23 completed 4735 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 5 loops.
>    read Thread 1 completed 9 loops.
>    read Thread 2 completed 6 loops.
>    nxread Thread 3 completed 5 loops.
>    nxread Thread 4 completed 4 loops.
>    nxread Thread 5 completed 9 loops.
>    tryexcept Thread 6 completed 13962901 loops.
>    tryexcept Thread 7 completed 22999610 loops.
>    tryexcept Thread 8 completed 14123517 loops.
>    fork Thread 9 completed 6 loops.
>    fork Thread 10 completed 6 loops.
>    fork Thread 11 completed 5 loops.
>    forktoomuch Thread 12 completed 7 loops.
>    forktoomuch Thread 13 completed 8 loops.
>    forktoomuch Thread 14 completed 8 loops.
>    lock Thread 21 completed 1744 loops.
>    lock Thread 22 completed 2095 loops.
>    lock Thread 23 completed 1503 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 2 loops.
>    read Thread 1 completed 6 loops.
>    read Thread 2 completed 2 loops.
>    nxread Thread 3 completed 3 loops.
>    nxread Thread 4 completed 3 loops.
>    nxread Thread 5 completed 3 loops.
>    tryexcept Thread 6 completed 15715885 loops.
>    tryexcept Thread 7 completed 24769727 loops.
>    tryexcept Thread 8 completed 15414675 loops.
>    fork Thread 9 completed 7 loops.
>    fork Thread 10 completed 6 loops.
>    fork Thread 11 completed 7 loops.
>    forktoomuch Thread 12 completed 8 loops.
>    forktoomuch Thread 13 completed 8 loops.
>    forktoomuch Thread 14 completed 9 loops.
>    lock Thread 21 completed 1523 loops.
>    lock Thread 22 completed 1922 loops.
>    lock Thread 23 completed 1204 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 5 loops.
>    read Thread 1 completed 9 loops.
>    read Thread 2 completed 6 loops.
>    nxread Thread 3 completed 4 loops.
>    nxread Thread 4 completed 2 loops.
>    nxread Thread 5 completed 8 loops.
>    tryexcept Thread 6 completed 14688224 loops.
>    tryexcept Thread 7 completed 23710577 loops.
>    tryexcept Thread 8 completed 15355622 loops.
>    fork Thread 9 completed 6 loops.
>    fork Thread 10 completed 7 loops.
>    fork Thread 11 completed 6 loops.
>    forktoomuch Thread 12 completed 8 loops.
>    forktoomuch Thread 13 completed 9 loops.
>    forktoomuch Thread 14 completed 7 loops.
>    lock Thread 21 completed 9427 loops.
>    lock Thread 22 completed 3941 loops.
>    lock Thread 23 completed 4421 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 9 loops.
>    read Thread 1 completed 11 loops.
>    read Thread 2 completed 6 loops.
>    nxread Thread 3 completed 7 loops.
>    nxread Thread 4 completed 5 loops.
>    nxread Thread 5 completed 9 loops.
>    tryexcept Thread 6 completed 16315690 loops.
>    tryexcept Thread 7 completed 25110147 loops.
>    tryexcept Thread 8 completed 17291322 loops.
>    fork Thread 9 completed 5 loops.
>    fork Thread 10 completed 4 loops.
>    fork Thread 11 completed 5 loops.
>    forktoomuch Thread 12 completed 8 loops.
>    forktoomuch Thread 13 completed 9 loops.
>    forktoomuch Thread 14 completed 8 loops.
>    lock Thread 21 completed 1648 loops.
>    lock Thread 22 completed 1274 loops.
>    lock Thread 23 completed 975 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 2 loops.
>    read Thread 1 completed 6 loops.
>    read Thread 2 completed 3 loops.
>    nxread Thread 3 completed 7 loops.
>    nxread Thread 4 completed 4 loops.
>    nxread Thread 5 completed 7 loops.
>    tryexcept Thread 6 completed 16955552 loops.
>    tryexcept Thread 7 completed 27781696 loops.
>    tryexcept Thread 8 completed 16151561 loops.
>    fork Thread 9 completed 4 loops.
>    fork Thread 10 completed 3 loops.
>    fork Thread 11 completed 2 loops.
>    forktoomuch Thread 12 completed 7 loops.
>    forktoomuch Thread 13 completed 7 loops.
>    forktoomuch Thread 14 completed 7 loops.
>    lock Thread 21 completed 2148 loops.
>    lock Thread 22 completed 2179 loops.
>    lock Thread 23 completed 1804 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 7 loops.
>    read Thread 1 completed 5 loops.
>    read Thread 2 completed 4 loops.
>    nxread Thread 3 completed 9 loops.
>    nxread Thread 4 completed 6 loops.
>    nxread Thread 5 completed 5 loops.
>    tryexcept Thread 6 completed 14537433 loops.
>    tryexcept Thread 7 completed 24043303 loops.
>    tryexcept Thread 8 completed 14258976 loops.
>    fork Thread 9 completed 6 loops.
>    fork Thread 10 completed 7 loops.
>    fork Thread 11 completed 6 loops.
>    forktoomuch Thread 12 completed 8 loops.
>    forktoomuch Thread 13 completed 8 loops.
>    forktoomuch Thread 14 completed 8 loops.
>    lock Thread 21 completed 6504 loops.
>    lock Thread 22 completed 2290 loops.
>    lock Thread 23 completed 7696 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 5 loops.
>    read Thread 1 completed 6 loops.
>    read Thread 2 completed 2 loops.
>    nxread Thread 3 completed 4 loops.
>    nxread Thread 4 completed 1 loops.
>    nxread Thread 5 completed 3 loops.
>    tryexcept Thread 6 completed 17349384 loops.
>    tryexcept Thread 7 completed 29845941 loops.
>    tryexcept Thread 8 completed 17792587 loops.
>    fork Thread 9 completed 5 loops.
>    fork Thread 10 completed 5 loops.
>    fork Thread 11 completed 6 loops.
>    forktoomuch Thread 12 completed 8 loops.
>    forktoomuch Thread 13 completed 9 loops.
>    forktoomuch Thread 14 completed 9 loops.
>    lock Thread 21 completed 2692 loops.
>    lock Thread 22 completed 4498 loops.
>    lock Thread 23 completed 3600 loops.
> All tests complete.  Congratulations.
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>
>  
> Regards,
> Randy Coleburn
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110316/6a0a5098/attachment-0002.html>

From rcolebur at SCIRES.COM  Wed Mar 16 23:34:53 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Wed, 16 Mar 2011 18:34:53 -0400
Subject: [M3devel] thread tests on NT386 32-bt
In-Reply-To: <B579D06A-BA7D-4739-9954-3B8A4E358AAD@cs.purdue.edu>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BDAF8@atlex02-srv>
	<B579D06A-BA7D-4739-9954-3B8A4E358AAD@cs.purdue.edu>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E603418BDB96@atlex02-srv>

Tony asked:
I don't remember how stable the collector was at that point.  Running them with @M3nogc indicates there were problems with it.
Now, what happens with the current trunk head when run with @M3nogc?
Here you go:

The alloc & create tests ran 9 iterations before running out of memory.

The other tests ran to completion.

See below (these tests run on IBM G40, XP Pro, 32-bit, against current HEAD branch):

C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests alloc,creat @M3nogc
Writing file...done
Creating alloc threads...
   alloc=15
   alloc=16
   alloc=17
done
Creating creat threads...
   creat=18
   creat=19
   creat=20
done
running...printing oldest/median age/newest
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 32400 loops.
   alloc Thread 16 completed 48840 loops.
   alloc Thread 17 completed 36525 loops.
   creat Thread 18 completed 25 loops.
   creat Thread 19 completed 28 loops.
   creat Thread 20 completed 27 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 5850 loops.
   alloc Thread 16 completed 8310 loops.
   alloc Thread 17 completed 8910 loops.
   creat Thread 18 completed 19 loops.
   creat Thread 19 completed 20 loops.
   creat Thread 20 completed 21 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 8505 loops.
   alloc Thread 16 completed 11805 loops.
   alloc Thread 17 completed 13170 loops.
   creat Thread 18 completed 27 loops.
   creat Thread 19 completed 26 loops.
   creat Thread 20 completed 27 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 7035 loops.
   alloc Thread 16 completed 13080 loops.
   alloc Thread 17 completed 5010 loops.
   creat Thread 18 completed 19 loops.
   creat Thread 19 completed 21 loops.
   creat Thread 20 completed 19 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 10260 loops.
   alloc Thread 16 completed 5445 loops.
  alloc Thread 17 completed 6390 loops.
   creat Thread 18 completed 21 loops.
   creat Thread 19 completed 23 loops.
   creat Thread 20 completed 23 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 3240 loops.
   alloc Thread 16 completed 12405 loops.
   alloc Thread 17 completed 6975 loops.
   creat Thread 18 completed 24 loops.
   creat Thread 19 completed 25 loops.
   creat Thread 20 completed 23 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 7410 loops.
   alloc Thread 16 completed 6090 loops.
   alloc Thread 17 completed 8670 loops.
   creat Thread 18 completed 17 loops.
   creat Thread 19 completed 17 loops.
   creat Thread 20 completed 17 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 6105 loops.
   alloc Thread 16 completed 7425 loops.
   alloc Thread 17 completed 10155 loops.
   creat Thread 18 completed 14 loops.
   creat Thread 19 completed 17 loops.
   creat Thread 20 completed 17 loops.
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 17160 loops.
   alloc Thread 16 completed 13365 loops.
   alloc Thread 17 completed 13785 loops.
   creat Thread 18 completed 17 loops.
   creat Thread 19 completed 16 loops.
   creat Thread 20 completed 17 loops.
......

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.
***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***
.
***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0xf7fefc   0x44c572  Raise + 0x3f in ..\src\runtime\common\RuntimeError.m3
0xf7ff1c   0x428712  AllocateOpenArray + 0x33 in ..\src\runtime\common\RTAllocator.m3
0xf7ff78   0x402430  AApply + 0x128 in ..\src\Main.m3
0xf7ffb4   0x42b56f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
.........  .........  ... more frames ...



C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lock @M3nogc
Writing file...done
Creating read threads...
   read=0
   read=1
   read=2
done
Creating nxread threads...
   nxread=3
   nxread=4
   nxread=5
done
Creating tryexcept threads...
   tryexcept=6
   tryexcept=7
   tryexcept=8
done
Creating fork threads...
   fork=9
   fork=0
   fork=11
done
Creating forktoomuch threads...
   forktoomuch=12
   forktoomuch=13
   forktoomuch=14
done
Creating lock threads...
   lock=21
   lock=22
   lock=23
done
running...printing oldest/median age/newest
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 98 loops.
   read Thread 1 completed 101 loops.
   read Thread 2 completed 98 loops.
   nxread Thread 3 completed 63 loops.
   nxread Thread 4 completed 64 loops.
   nxread Thread 5 completed 64 loops.
   tryexcept Thread 6 completed 1106827 loops.
   tryexcept Thread 7 completed 1056963 loops.
   tryexcept Thread 8 completed 1124363 loops.
   fork Thread 9 completed 3 loops.
   fork Thread 10 completed 3 loops.
   fork Thread 11 completed 3 loops.
   forktoomuch Thread 12 completed 5 loops.
   forktoomuch Thread 13 completed 5 loops.
   forktoomuch Thread 14 completed 4 loops.
   lock Thread 21 completed 902314 loops.
   lock Thread 22 completed 873503 loops.
   lock Thread 23 completed 946840 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 108 loops.
   read Thread 1 completed 105 loops.
   read Thread 2 completed 108 loops.
   nxread Thread 3 completed 68 loops.
   nxread Thread 4 completed 70 loops.
   nxread Thread 5 completed 67 loops.
   tryexcept Thread 6 completed 1197135 loops.
   tryexcept Thread 7 completed 1248635 loops.
   tryexcept Thread 8 completed 1263743 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 4 loops.
   forktoomuch Thread 12 completed 6 loops.
   forktoomuch Thread 13 completed 7 loops.
   forktoomuch Thread 14 completed 7 loops.
   lock Thread 21 completed 1156474 loops.
   lock Thread 22 completed 1007509 loops.
   lock Thread 23 completed 1072164 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 91 loops.
   read Thread 1 completed 101 loops.
   read Thread 2 completed 99 loops.
   nxread Thread 3 completed 67 loops.
   nxread Thread 4 completed 63 loops.
   nxread Thread 5 completed 64 loops.
   tryexcept Thread 6 completed 1212286 loops.
   tryexcept Thread 7 completed 1115613 loops.
   tryexcept Thread 8 completed 1124737 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 5 loops.
   fork Thread 11 completed 4 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 8 loops.
   forktoomuch Thread 14 completed 7 loops.
   lock Thread 21 completed 1058176 loops.
   lock Thread 22 completed 979426 loops.
   lock Thread 23 completed 1068972 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 103 loops.
   read Thread 1 completed 105 loops.
   read Thread 2 completed 105 loops.
   nxread Thread 3 completed 63 loops.
   nxread Thread 4 completed 63 loops.
   nxread Thread 5 completed 61 loops.
   tryexcept Thread 6 completed 1132672 loops.
   tryexcept Thread 7 completed 1186707 loops.
   tryexcept Thread 8 completed 1136861 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 4 loops.
   forktoomuch Thread 12 completed 6 loops.
   forktoomuch Thread 13 completed 6 loops.
   forktoomuch Thread 14 completed 7 loops.
   lock Thread 21 completed 794204 loops.
   lock Thread 22 completed 1171670 loops.
   lock Thread 23 completed 992164 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 88 loops.
   read Thread 1 completed 93 loops.
   read Thread 2 completed 105 loops.
   nxread Thread 3 completed 60 loops.
   nxread Thread 4 completed 63 loops.
   nxread Thread 5 completed 64 loops.
   tryexcept Thread 6 completed 1213622 loops.
   tryexcept Thread 7 completed 1169506 loops.
   tryexcept Thread 8 completed 1220576 loops.
   fork Thread 9 completed 3 loops.
   fork Thread 10 completed 3 loops.
   fork Thread 11 completed 3 loops.
   forktoomuch Thread 12 completed 5 loops.
   forktoomuch Thread 13 completed 6 loops.
   forktoomuch Thread 14 completed 6 loops.
   lock Thread 21 completed 947532 loops.
   lock Thread 22 completed 1046220 loops.
   lock Thread 23 completed 886815 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 104 loops.
   read Thread 1 completed 104 loops.
   read Thread 2 completed 104 loops.
   nxread Thread 3 completed 69 loops.
   nxread Thread 4 completed 68 loops.
   nxread Thread 5 completed 68 loops.
   tryexcept Thread 6 completed 1225537 loops.
   tryexcept Thread 7 completed 1158824 loops.
   tryexcept Thread 8 completed 1185900 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 5 loops.
   fork Thread 11 completed 4 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 7 loops.
   forktoomuch Thread 14 completed 6 loops.
   lock Thread 21 completed 1116802 loops.
   lock Thread 22 completed 1028306 loops.
   lock Thread 23 completed 1130454 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 107 loops.
   read Thread 1 completed 110 loops.
   read Thread 2 completed 112 loops.
   nxread Thread 3 completed 63 loops.
   nxread Thread 4 completed 63 loops.
   nxread Thread 5 completed 63 loops.
   tryexcept Thread 6 completed 1156252 loops.
   tryexcept Thread 7 completed 1094847 loops.
   tryexcept Thread 8 completed 1199661 loops.
   fork Thread 9 completed 3 loops.
   fork Thread 10 completed 3 loops.
   fork Thread 11 completed 4 loops.
   forktoomuch Thread 12 completed 7 loops.
   forktoomuch Thread 13 completed 7 loops.
   forktoomuch Thread 14 completed 7 loops.
   lock Thread 21 completed 746279 loops.
   lock Thread 22 completed 1069667 loops.
   lock Thread 23 completed 1045028 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 98 loops.
   read Thread 1 completed 99 loops.
   read Thread 2 completed 96 loops.
   nxread Thread 3 completed 64 loops.
   nxread Thread 4 completed 60 loops.
   nxread Thread 5 completed 63 loops.
   tryexcept Thread 6 completed 1185205 loops.
   tryexcept Thread 7 completed 1175381 loops.
   tryexcept Thread 8 completed 1114031 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 5 loops.
   fork Thread 11 completed 4 loops.
   forktoomuch Thread 12 completed 6 loops.
   forktoomuch Thread 13 completed 7 loops.
   forktoomuch Thread 14 completed 6 loops.
   lock Thread 21 completed 1053691 loops.
   lock Thread 22 completed 1009143 loops.
   lock Thread 23 completed 966082 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 111 loops.
   read Thread 1 completed 110 loops.
   read Thread 2 completed 101 loops.
   nxread Thread 3 completed 64 loops.
   nxread Thread 4 completed 65 loops.
   nxread Thread 5 completed 64 loops.
   tryexcept Thread 6 completed 1130609 loops.
   tryexcept Thread 7 completed 1160042 loops.
   tryexcept Thread 8 completed 1110365 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 5 loops.
   forktoomuch Thread 12 completed 7 loops.
   forktoomuch Thread 13 completed 7 loops.
   forktoomuch Thread 14 completed 7 loops.
   lock Thread 21 completed 682298 loops.
   lock Thread 22 completed 1124977 loops.
   lock Thread 23 completed 960154 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 62 loops.
   read Thread 1 completed 65 loops.
   read Thread 2 completed 62 loops.
   nxread Thread 3 completed 45 loops.
   nxread Thread 4 completed 42 loops.
   nxread Thread 5 completed 42 loops.
   tryexcept Thread 6 completed 1569234 loops.
   tryexcept Thread 7 completed 1553679 loops.
   tryexcept Thread 8 completed 1511503 loops.
   fork Thread 9 completed 1 loops.
   fork Thread 10 completed 2 loops.
   fork Thread 11 completed 2 loops.
   forktoomuch Thread 12 completed 4 loops.
   forktoomuch Thread 13 completed 4 loops.
   forktoomuch Thread 14 completed 4 loops.
   lock Thread 21 completed 1311441 loops.
   lock Thread 22 completed 1309196 loops.
   lock Thread 23 completed 1418347 loops.
All tests complete.  Congratulations.

C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>

Regards,
Randy Coleburn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110316/7fb37fc9/attachment-0002.html>

From rcolebur at SCIRES.COM  Wed Mar 16 23:50:55 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Wed, 16 Mar 2011 18:50:55 -0400
Subject: [M3devel] thread test results on Win7 64-bit
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E603418BDB9C@atlex02-srv>

Here are thread test results for Dell Latitude E6510, Windows 7, 64-bit, against current HEAD branch.
I ran each set 3 times:  no @M3 directive, @M3paranoidgc, and @M3nogc
Note 3rd run where the fork thread shows being starved during first iteration, but test did run to completion using @M3nogc.


C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lock
Writing file...done
Creating read threads...
   read=0
   read=1
   read=2
done
Creating nxread threads...
   nxread=3
   nxread=4
   nxread=5
done
Creating tryexcept threads...
   tryexcept=6
   tryexcept=7
   tryexcept=8
done
Creating fork threads...
   fork=9
   fork=0
   fork=11
done
Creating forktoomuch threads...
   forktoomuch=12
   forktoomuch=13
   forktoomuch=14
done
Creating lock threads...
   lock=21
   lock=22
   lock=23
done
running...printing oldest/median age/newest
.

***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\rw\FileRd.m3", line 83
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0xaafa68  0x1198d68  Seek + 0x454 in ..\src\rw\FileRd.m3
0xaafa94  0x119a836  FastEOF + 0xc9 in ..\src\rw\Rd.m3
0xaafabc  0x119a72c  EOF + 0x48 in ..\src\rw\Rd.m3
0xaafb08  0x119176e  NApply + 0x154 in ..\src\Main.m3
0xaafb44  0x11bb56f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
0xaafb50  0x75c53677  <???>
0xaafb90  0x77e39f02  <???>
.........  .........  ... more frames ...


C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lock @M3paranoidgc
Writing file...done
Creating read threads...
   read=0
   read=1
   read=2
done
Creating nxread threads...
   nxread=3
   nxread=4
   nxread=5
done
Creating tryexcept threads...
   tryexcept=6
   tryexcept=7
   tryexcept=8
done
Creating fork threads...
   fork=9
   fork=0
   fork=11
done
Creating forktoomuch threads...
   forktoomuch=12
   forktoomuch=13
   forktoomuch=14
done
Creating lock threads...
   lock=21
   lock=22
   lock=23
done
running...printing oldest/median age/newest
.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0x11986a0 = Init + 0x79 in ..\src\rw\FileRd.m3
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x84fb48  0x11d537b  SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m3
0x84fb90  0x11986a0  Init + 0x79 in ..\src\rw\FileRd.m3
0x84fbbc  0x119861d  Open + 0x4d in ..\src\rw\FileRd.m3
0x84fcf4  0x1191360  RApply + 0x160 in ..\src\Main.m3
0x84fd30  0x11bb56f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
0x84fd3c  0x75c53677  <???>
0x84fd7c  0x77e39f02  <???>
.........  .........  ... more frames ...


C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lock @M3nogc
Writing file...done
Creating read threads...
   read=0
   read=1
   read=2
done
Creating nxread threads...
   nxread=3
   nxread=4
   nxread=5
done
Creating tryexcept threads...
   tryexcept=6
   tryexcept=7
   tryexcept=8
done
Creating fork threads...
   fork=9
   fork=0
   fork=11
done
Creating forktoomuch threads...
   forktoomuch=12
   forktoomuch=13
   forktoomuch=14
done
Creating lock threads...
   lock=21
   lock=22
   lock=23
done
running...printing oldest/median age/newest
..........laziest thread is 0/0/-2 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork -2/-2/-2 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 113 loops.
   read Thread 1 completed 45 loops.
   read Thread 2 completed 56 loops.
   nxread Thread 3 completed 48 loops.
   nxread Thread 4 completed 50 loops.
   nxread Thread 5 completed 41 loops.
   tryexcept Thread 6 completed 19499179 loops.
   tryexcept Thread 7 completed 15275763 loops.
   tryexcept Thread 8 completed 22671986 loops.
fork Thread 9 appears starved or deadlocked !!!
fork Thread 10 appears starved or deadlocked !!!
fork Thread 11 appears starved or deadlocked !!!
   forktoomuch Thread 12 completed 5 loops.
   forktoomuch Thread 13 completed 5 loops.
   forktoomuch Thread 14 completed 5 loops.
   lock Thread 21 completed 9512206 loops.
   lock Thread 22 completed 6619988 loops.
   lock Thread 23 completed 7547029 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 81 loops.
   read Thread 1 completed 71 loops.
   read Thread 2 completed 89 loops.
   nxread Thread 3 completed 66 loops.
   nxread Thread 4 completed 40 loops.
   nxread Thread 5 completed 36 loops.
   tryexcept Thread 6 completed 19628784 loops.
   tryexcept Thread 7 completed 22393679 loops.
   tryexcept Thread 8 completed 19328247 loops.
   fork Thread 9 completed 3 loops.
   fork Thread 10 completed 2 loops.
   fork Thread 11 completed 1 loops.
   forktoomuch Thread 12 completed 5 loops.
   forktoomuch Thread 13 completed 6 loops.
   forktoomuch Thread 14 completed 5 loops.
   lock Thread 21 completed 10152547 loops.
   lock Thread 22 completed 7780818 loops.
   lock Thread 23 completed 8156000 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 151 loops.
   read Thread 1 completed 114 loops.
   read Thread 2 completed 198 loops.
   nxread Thread 3 completed 81 loops.
   nxread Thread 4 completed 102 loops.
   nxread Thread 5 completed 65 loops.
   tryexcept Thread 6 completed 16242018 loops.
   tryexcept Thread 7 completed 18541779 loops.
   tryexcept Thread 8 completed 23687938 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 5 loops.
   fork Thread 11 completed 4 loops.
   forktoomuch Thread 12 completed 7 loops.
   forktoomuch Thread 13 completed 8 loops.
   forktoomuch Thread 14 completed 7 loops.
   lock Thread 21 completed 6189375 loops.
   lock Thread 22 completed 12637746 loops.
   lock Thread 23 completed 6191441 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 158 loops.
   read Thread 1 completed 111 loops.
   read Thread 2 completed 210 loops.
   nxread Thread 3 completed 80 loops.
   nxread Thread 4 completed 107 loops.
   nxread Thread 5 completed 77 loops.
   tryexcept Thread 6 completed 27811791 loops.
   tryexcept Thread 7 completed 14614651 loops.
   tryexcept Thread 8 completed 14962432 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 5 loops.
   forktoomuch Thread 12 completed 9 loops.
   forktoomuch Thread 13 completed 8 loops.
   forktoomuch Thread 14 completed 9 loops.
   lock Thread 21 completed 6021783 loops.
   lock Thread 22 completed 11487180 loops.
   lock Thread 23 completed 6730226 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 85 loops.
   read Thread 1 completed 75 loops.
   read Thread 2 completed 85 loops.
   nxread Thread 3 completed 50 loops.
   nxread Thread 4 completed 58 loops.
   nxread Thread 5 completed 67 loops.
   tryexcept Thread 6 completed 28345540 loops.
   tryexcept Thread 7 completed 14693468 loops.
   tryexcept Thread 8 completed 17065423 loops.
   fork Thread 9 completed 5 loops.
   fork Thread 10 completed 6 loops.
   fork Thread 11 completed 5 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 9 loops.
   forktoomuch Thread 14 completed 8 loops.
   lock Thread 21 completed 6621257 loops.
   lock Thread 22 completed 10815327 loops.
   lock Thread 23 completed 8437962 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 174 loops.
   read Thread 1 completed 133 loops.
   read Thread 2 completed 202 loops.
   nxread Thread 3 completed 85 loops.
   nxread Thread 4 completed 110 loops.
   nxread Thread 5 completed 72 loops.
   tryexcept Thread 6 completed 23348157 loops.
   tryexcept Thread 7 completed 14374032 loops.
   tryexcept Thread 8 completed 19940269 loops.
   fork Thread 9 completed 5 loops.
   fork Thread 10 completed 5 loops.
   fork Thread 11 completed 5 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 8 loops.
   forktoomuch Thread 14 completed 8 loops.
   lock Thread 21 completed 7341139 loops.
   lock Thread 22 completed 10330530 loops.
   lock Thread 23 completed 6812041 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 26 loops.
   read Thread 1 completed 32 loops.
   read Thread 2 completed 36 loops.
   nxread Thread 3 completed 38 loops.
   nxread Thread 4 completed 24 loops.
   nxread Thread 5 completed 27 loops.
   tryexcept Thread 6 completed 17115144 loops.
   tryexcept Thread 7 completed 19179208 loops.
   tryexcept Thread 8 completed 25222246 loops.
   fork Thread 9 completed 5 loops.
   fork Thread 10 completed 6 loops.
   fork Thread 11 completed 5 loops.
   forktoomuch Thread 12 completed 8 loops.
   forktoomuch Thread 13 completed 9 loops.
   forktoomuch Thread 14 completed 9 loops.
   lock Thread 21 completed 10391588 loops.
   lock Thread 22 completed 7466890 loops.
   lock Thread 23 completed 8045330 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 68 loops.
   read Thread 1 completed 78 loops.
   read Thread 2 completed 87 loops.
   nxread Thread 3 completed 55 loops.
   nxread Thread 4 completed 49 loops.
   nxread Thread 5 completed 49 loops.
   tryexcept Thread 6 completed 23843674 loops.
   tryexcept Thread 7 completed 23476782 loops.
   tryexcept Thread 8 completed 15668116 loops.
   fork Thread 9 completed 5 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 5 loops.
   forktoomuch Thread 12 completed 9 loops.
   forktoomuch Thread 13 completed 8 loops.
   forktoomuch Thread 14 completed 9 loops.
   lock Thread 21 completed 7504169 loops.
   lock Thread 22 completed 9868443 loops.
  lock Thread 23 completed 8893786 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 191 loops.
   read Thread 1 completed 181 loops.
   read Thread 2 completed 256 loops.
   nxread Thread 3 completed 100 loops.
   nxread Thread 4 completed 116 loops.
   nxread Thread 5 completed 110 loops.
   tryexcept Thread 6 completed 25424753 loops.
   tryexcept Thread 7 completed 16145782 loops.
   tryexcept Thread 8 completed 18178878 loops.
   fork Thread 9 completed 5 loops.
   fork Thread 10 completed 5 loops.
   fork Thread 11 completed 4 loops.
   forktoomuch Thread 12 completed 9 loops.
   forktoomuch Thread 13 completed 9 loops.
   forktoomuch Thread 14 completed 8 loops.
   lock Thread 21 completed 8276088 loops.
   lock Thread 22 completed 8386980 loops.
   lock Thread 23 completed 9006728 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
   read Thread 0 completed 100 loops.
   read Thread 1 completed 126 loops.
   read Thread 2 completed 180 loops.
   nxread Thread 3 completed 80 loops.
   nxread Thread 4 completed 63 loops.
   nxread Thread 5 completed 96 loops.
   tryexcept Thread 6 completed 24009428 loops.
   tryexcept Thread 7 completed 18997565 loops.
   tryexcept Thread 8 completed 17752747 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 4 loops.
   forktoomuch Thread 12 completed 7 loops.
   forktoomuch Thread 13 completed 8 loops.
   forktoomuch Thread 14 completed 9 loops.
   lock Thread 21 completed 8760970 loops.
   lock Thread 22 completed 6987943 loops.
   lock Thread 23 completed 10012968 loops.
All tests complete.  Congratulations.


C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests alloc,creat
Writing file...done
Creating alloc threads...
   alloc=15
   alloc=16
   alloc=17
done
Creating creat threads...
   creat=18
   creat=19
   creat=20
done
running...printing oldest/median age/newest
.....

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0xdee37d = Move + 0x50 in ..\src\runtime\common\RTCollector.m3
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

^C


C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests alloc,creat @M3paranoidgc
Writing file...done
Creating alloc threads...
   alloc=15
   alloc=16
   alloc=17
done
Creating creat threads...
   creat=18
   creat=19
   creat=20
done
running...printing oldest/median age/newest
..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
   alloc Thread 15 completed 15465 loops.
   alloc Thread 16 completed 26927 loops.
   alloc Thread 17 completed 32052 loops.
   creat Thread 18 completed 248 loops.
   creat Thread 19 completed 432 loops.
   creat Thread 20 completed 260 loops.
..

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 841
***

^C


C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests alloc,creat @M3nogc
Writing file...done
Creating alloc threads...
   alloc=15
   alloc=16
   alloc=17
done
Creating creat threads...
   creat=18
   creat=19
   creat=20
done
running...printing oldest/median age/newest
...

NEW() was unable to al***ate more memory. was unable to allocate more memory.

NEW() was unable to al***ate more memory.

NEW() was unable to al***ate more memory. was unable to allocate more memory.

***
*** runtime error:
***    NEW() was unable to allocate more memory.
***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

***    file "..\src\runtime\common\RuntimeError.m3", line 63
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0xa5fa48   0xeac5a2  Raise + 0x3f in ..\src\runtime\common\RuntimeError.m3
0xa5fa68   0xe88712  AllocateOpenArray + 0x33 in ..\src\runtime\common\RTAllocator.m3
0xa5fac4   0xe62430  AApply + 0x128 in ..\src\Main.m3
0xa5fb00   0xe8b56f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
0xa5fb0c  0x75c53677  <???>
0xa5fb4c  0x77e39f02  <???>
.........  .........  ... more frames ...

C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>

Regards,
Randy Coleburn

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

From hosking at cs.purdue.edu  Thu Mar 17 01:13:34 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 16 Mar 2011 20:13:34 -0400
Subject: [M3devel] thread test results on Win7 64-bit
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BDB9C@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BDB9C@atlex02-srv>
Message-ID: <8A030252-DB8E-4505-BA29-70B28329577F@cs.purdue.edu>

This is the offending line:

On Mar 16, 2011, at 6:50 PM, Coleburn, Randy wrote:

> ***
> *** runtime error:
> ***    An array subscript was out of range.
> ***    file "..\src\rw\FileRd.m3", line 83
> ***

      n := rd.sourceH.read(
             SUBARRAY(LOOPHOLE(ADR(rd.buff[0]), ByteArrayPtr)^, 0,
                      MIN (NUMBER(rd.buff^), BIG)), mayBlock := NOT dontBlock)

I am very suspicious about this...  anyone have any insights?

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

From hosking at cs.purdue.edu  Thu Mar 17 01:13:47 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 16 Mar 2011 20:13:47 -0400
Subject: [M3devel] thread tests on NT386 32-bt
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BDB96@atlex02-srv>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BDAF8@atlex02-srv>
	<B579D06A-BA7D-4739-9954-3B8A4E358AAD@cs.purdue.edu>
	<D67F02DDC62F7545A6B84C285F88F3E603418BDB96@atlex02-srv>
Message-ID: <1D3141BB-DB5F-46C9-ACB1-A3B9A95B74AE@cs.purdue.edu>

OK, good.  So I think this is definitely a threads/GC interaction.  Should be diagnosable from here out.

On Mar 16, 2011, at 6:34 PM, Coleburn, Randy wrote:

> Tony asked:
> I don't remember how stable the collector was at that point.  Running them with @M3nogc indicates there were problems with it.
> Now, what happens with the current trunk head when run with @M3nogc?
> 
> Here you go:
>  
> The alloc & create tests ran 9 iterations before running out of memory.
>  
> The other tests ran to completion.
>  
> See below (these tests run on IBM G40, XP Pro, 32-bit, against current HEAD branch):
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests alloc,creat @M3nogc
> Writing file...done
> Creating alloc threads...
>    alloc=15
>    alloc=16
>    alloc=17
> done
> Creating creat threads...
>    creat=18
>    creat=19
>    creat=20
> done
> running...printing oldest/median age/newest
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 32400 loops.
>    alloc Thread 16 completed 48840 loops.
>    alloc Thread 17 completed 36525 loops.
>    creat Thread 18 completed 25 loops.
>    creat Thread 19 completed 28 loops.
>    creat Thread 20 completed 27 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 5850 loops.
>    alloc Thread 16 completed 8310 loops.
>    alloc Thread 17 completed 8910 loops.
>    creat Thread 18 completed 19 loops.
>    creat Thread 19 completed 20 loops.
>    creat Thread 20 completed 21 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 8505 loops.
>    alloc Thread 16 completed 11805 loops.
>    alloc Thread 17 completed 13170 loops.
>    creat Thread 18 completed 27 loops.
>    creat Thread 19 completed 26 loops.
>    creat Thread 20 completed 27 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 7035 loops.
>    alloc Thread 16 completed 13080 loops.
>    alloc Thread 17 completed 5010 loops.
>    creat Thread 18 completed 19 loops.
>    creat Thread 19 completed 21 loops.
>    creat Thread 20 completed 19 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 10260 loops.
>    alloc Thread 16 completed 5445 loops.
>   alloc Thread 17 completed 6390 loops.
>    creat Thread 18 completed 21 loops.
>    creat Thread 19 completed 23 loops.
>    creat Thread 20 completed 23 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 3240 loops.
>    alloc Thread 16 completed 12405 loops.
>    alloc Thread 17 completed 6975 loops.
>    creat Thread 18 completed 24 loops.
>    creat Thread 19 completed 25 loops.
>    creat Thread 20 completed 23 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 7410 loops.
>    alloc Thread 16 completed 6090 loops.
>    alloc Thread 17 completed 8670 loops.
>    creat Thread 18 completed 17 loops.
>    creat Thread 19 completed 17 loops.
>    creat Thread 20 completed 17 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 6105 loops.
>    alloc Thread 16 completed 7425 loops.
>    alloc Thread 17 completed 10155 loops.
>    creat Thread 18 completed 14 loops.
>    creat Thread 19 completed 17 loops.
>    creat Thread 20 completed 17 loops.
> ..........laziest thread is 0/0/0 (tests: alloc 0/0/0 creat 0/0/0)
>    alloc Thread 15 completed 17160 loops.
>    alloc Thread 16 completed 13365 loops.
>    alloc Thread 17 completed 13785 loops.
>    creat Thread 18 completed 17 loops.
>    creat Thread 19 completed 16 loops.
>    creat Thread 20 completed 17 loops.
> ......
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
>  
> ***
> *** runtime error:
> ***    NEW() was unable to allocate more memory.
> ***    file "..\src\runtime\common\RuntimeError.m3", line 63
> ***
>  
> ***    file "..\src\runtime\common\RuntimeError.m3", line 63
> ***
> .
> ***    file "..\src\runtime\common\RuntimeError.m3", line 63
> ***
>  
> ***    file "..\src\runtime\common\RuntimeError.m3", line 63
> ***
>  
> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0xf7fefc   0x44c572  Raise + 0x3f in ..\src\runtime\common\RuntimeError.m3
> 0xf7ff1c   0x428712  AllocateOpenArray + 0x33 in ..\src\runtime\common\RTAllocator.m3
> 0xf7ff78   0x402430  AApply + 0x128 in ..\src\Main.m3
> 0xf7ffb4   0x42b56f  ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWin32.m3
> .........  .........  ... more frames ...
>  
>  
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>threadtest.exe -verbose -tests read,nxread,tryexcept,fork,forktoomuch,lock @M3nogc
> Writing file...done
> Creating read threads...
>    read=0
>    read=1
>    read=2
> done
> Creating nxread threads...
>    nxread=3
>    nxread=4
>    nxread=5
> done
> Creating tryexcept threads...
>    tryexcept=6
>    tryexcept=7
>    tryexcept=8
> done
> Creating fork threads...
>    fork=9
>    fork=0
>    fork=11
> done
> Creating forktoomuch threads...
>    forktoomuch=12
>    forktoomuch=13
>    forktoomuch=14
> done
> Creating lock threads...
>    lock=21
>    lock=22
>    lock=23
> done
> running...printing oldest/median age/newest
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 98 loops.
>    read Thread 1 completed 101 loops.
>    read Thread 2 completed 98 loops.
>    nxread Thread 3 completed 63 loops.
>    nxread Thread 4 completed 64 loops.
>    nxread Thread 5 completed 64 loops.
>    tryexcept Thread 6 completed 1106827 loops.
>    tryexcept Thread 7 completed 1056963 loops.
>    tryexcept Thread 8 completed 1124363 loops.
>    fork Thread 9 completed 3 loops.
>    fork Thread 10 completed 3 loops.
>    fork Thread 11 completed 3 loops.
>    forktoomuch Thread 12 completed 5 loops.
>    forktoomuch Thread 13 completed 5 loops.
>    forktoomuch Thread 14 completed 4 loops.
>    lock Thread 21 completed 902314 loops.
>    lock Thread 22 completed 873503 loops.
>    lock Thread 23 completed 946840 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 108 loops.
>    read Thread 1 completed 105 loops.
>    read Thread 2 completed 108 loops.
>    nxread Thread 3 completed 68 loops.
>    nxread Thread 4 completed 70 loops.
>    nxread Thread 5 completed 67 loops.
>    tryexcept Thread 6 completed 1197135 loops.
>    tryexcept Thread 7 completed 1248635 loops.
>    tryexcept Thread 8 completed 1263743 loops.
>    fork Thread 9 completed 4 loops.
>    fork Thread 10 completed 4 loops.
>    fork Thread 11 completed 4 loops.
>    forktoomuch Thread 12 completed 6 loops.
>    forktoomuch Thread 13 completed 7 loops.
>    forktoomuch Thread 14 completed 7 loops.
>    lock Thread 21 completed 1156474 loops.
>    lock Thread 22 completed 1007509 loops.
>    lock Thread 23 completed 1072164 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 91 loops.
>    read Thread 1 completed 101 loops.
>    read Thread 2 completed 99 loops.
>    nxread Thread 3 completed 67 loops.
>    nxread Thread 4 completed 63 loops.
>    nxread Thread 5 completed 64 loops.
>    tryexcept Thread 6 completed 1212286 loops.
>    tryexcept Thread 7 completed 1115613 loops.
>    tryexcept Thread 8 completed 1124737 loops.
>    fork Thread 9 completed 4 loops.
>    fork Thread 10 completed 5 loops.
>    fork Thread 11 completed 4 loops.
>    forktoomuch Thread 12 completed 8 loops.
>    forktoomuch Thread 13 completed 8 loops.
>    forktoomuch Thread 14 completed 7 loops.
>    lock Thread 21 completed 1058176 loops.
>    lock Thread 22 completed 979426 loops.
>    lock Thread 23 completed 1068972 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 103 loops.
>    read Thread 1 completed 105 loops.
>    read Thread 2 completed 105 loops.
>    nxread Thread 3 completed 63 loops.
>    nxread Thread 4 completed 63 loops.
>    nxread Thread 5 completed 61 loops.
>    tryexcept Thread 6 completed 1132672 loops.
>    tryexcept Thread 7 completed 1186707 loops.
>    tryexcept Thread 8 completed 1136861 loops.
>    fork Thread 9 completed 4 loops.
>    fork Thread 10 completed 4 loops.
>    fork Thread 11 completed 4 loops.
>    forktoomuch Thread 12 completed 6 loops.
>    forktoomuch Thread 13 completed 6 loops.
>    forktoomuch Thread 14 completed 7 loops.
>    lock Thread 21 completed 794204 loops.
>    lock Thread 22 completed 1171670 loops.
>    lock Thread 23 completed 992164 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 88 loops.
>    read Thread 1 completed 93 loops.
>    read Thread 2 completed 105 loops.
>    nxread Thread 3 completed 60 loops.
>    nxread Thread 4 completed 63 loops.
>    nxread Thread 5 completed 64 loops.
>    tryexcept Thread 6 completed 1213622 loops.
>    tryexcept Thread 7 completed 1169506 loops.
>    tryexcept Thread 8 completed 1220576 loops.
>    fork Thread 9 completed 3 loops.
>    fork Thread 10 completed 3 loops.
>    fork Thread 11 completed 3 loops.
>    forktoomuch Thread 12 completed 5 loops.
>    forktoomuch Thread 13 completed 6 loops.
>    forktoomuch Thread 14 completed 6 loops.
>    lock Thread 21 completed 947532 loops.
>    lock Thread 22 completed 1046220 loops.
>    lock Thread 23 completed 886815 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 104 loops.
>    read Thread 1 completed 104 loops.
>    read Thread 2 completed 104 loops.
>    nxread Thread 3 completed 69 loops.
>    nxread Thread 4 completed 68 loops.
>    nxread Thread 5 completed 68 loops.
>    tryexcept Thread 6 completed 1225537 loops.
>    tryexcept Thread 7 completed 1158824 loops.
>    tryexcept Thread 8 completed 1185900 loops.
>    fork Thread 9 completed 4 loops.
>    fork Thread 10 completed 5 loops.
>    fork Thread 11 completed 4 loops.
>    forktoomuch Thread 12 completed 8 loops.
>    forktoomuch Thread 13 completed 7 loops.
>    forktoomuch Thread 14 completed 6 loops.
>    lock Thread 21 completed 1116802 loops.
>    lock Thread 22 completed 1028306 loops.
>    lock Thread 23 completed 1130454 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 107 loops.
>    read Thread 1 completed 110 loops.
>    read Thread 2 completed 112 loops.
>    nxread Thread 3 completed 63 loops.
>    nxread Thread 4 completed 63 loops.
>    nxread Thread 5 completed 63 loops.
>    tryexcept Thread 6 completed 1156252 loops.
>    tryexcept Thread 7 completed 1094847 loops.
>    tryexcept Thread 8 completed 1199661 loops.
>    fork Thread 9 completed 3 loops.
>    fork Thread 10 completed 3 loops.
>    fork Thread 11 completed 4 loops.
>    forktoomuch Thread 12 completed 7 loops.
>    forktoomuch Thread 13 completed 7 loops.
>    forktoomuch Thread 14 completed 7 loops.
>    lock Thread 21 completed 746279 loops.
>    lock Thread 22 completed 1069667 loops.
>    lock Thread 23 completed 1045028 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 98 loops.
>    read Thread 1 completed 99 loops.
>    read Thread 2 completed 96 loops.
>    nxread Thread 3 completed 64 loops.
>    nxread Thread 4 completed 60 loops.
>    nxread Thread 5 completed 63 loops.
>    tryexcept Thread 6 completed 1185205 loops.
>    tryexcept Thread 7 completed 1175381 loops.
>    tryexcept Thread 8 completed 1114031 loops.
>    fork Thread 9 completed 4 loops.
>    fork Thread 10 completed 5 loops.
>    fork Thread 11 completed 4 loops.
>    forktoomuch Thread 12 completed 6 loops.
>    forktoomuch Thread 13 completed 7 loops.
>    forktoomuch Thread 14 completed 6 loops.
>    lock Thread 21 completed 1053691 loops.
>    lock Thread 22 completed 1009143 loops.
>    lock Thread 23 completed 966082 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 111 loops.
>    read Thread 1 completed 110 loops.
>    read Thread 2 completed 101 loops.
>    nxread Thread 3 completed 64 loops.
>    nxread Thread 4 completed 65 loops.
>    nxread Thread 5 completed 64 loops.
>    tryexcept Thread 6 completed 1130609 loops.
>    tryexcept Thread 7 completed 1160042 loops.
>    tryexcept Thread 8 completed 1110365 loops.
>    fork Thread 9 completed 4 loops.
>    fork Thread 10 completed 4 loops.
>    fork Thread 11 completed 5 loops.
>    forktoomuch Thread 12 completed 7 loops.
>    forktoomuch Thread 13 completed 7 loops.
>    forktoomuch Thread 14 completed 7 loops.
>    lock Thread 21 completed 682298 loops.
>    lock Thread 22 completed 1124977 loops.
>    lock Thread 23 completed 960154 loops.
> ..........laziest thread is 0/0/0 (tests: read 0/0/0 nxread 0/0/0 tryexcept 0/0/0 fork 0/0/0 forktoomuch 0/0/0 lock 0/0/0)
>    read Thread 0 completed 62 loops.
>    read Thread 1 completed 65 loops.
>    read Thread 2 completed 62 loops.
>    nxread Thread 3 completed 45 loops.
>    nxread Thread 4 completed 42 loops.
>    nxread Thread 5 completed 42 loops.
>    tryexcept Thread 6 completed 1569234 loops.
>    tryexcept Thread 7 completed 1553679 loops.
>    tryexcept Thread 8 completed 1511503 loops.
>    fork Thread 9 completed 1 loops.
>    fork Thread 10 completed 2 loops.
>    fork Thread 11 completed 2 loops.
>    forktoomuch Thread 12 completed 4 loops.
>    forktoomuch Thread 13 completed 4 loops.
>    forktoomuch Thread 14 completed 4 loops.
>    lock Thread 21 completed 1311441 loops.
>    lock Thread 22 completed 1309196 loops.
>    lock Thread 23 completed 1418347 loops.
> All tests complete.  Congratulations.
>  
> C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread\NT386>
>  
> Regards,
> Randy Coleburn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110316/40c031b5/attachment-0002.html>

From rcolebur at SCIRES.COM  Thu Mar 17 20:46:00 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 17 Mar 2011 15:46:00 -0400
Subject: [M3devel] thread test results on Win7 64-bit
In-Reply-To: <8A030252-DB8E-4505-BA29-70B28329577F@cs.purdue.edu>
References: <D67F02DDC62F7545A6B84C285F88F3E603418BDB9C@atlex02-srv>
	<8A030252-DB8E-4505-BA29-70B28329577F@cs.purdue.edu>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E603418BDDEC@atlex02-srv>

Tony et al:

On the surface, it would seem this convoluted code is doing the following:

1.       Making rd.buff appear as an "ARRAY OF Byte", vice an "ARRAY OF CHAR, so as to meet the requirements of the File.T.read interface.

2.       Limiting the buffer to be the smaller of "BIG", or the actual number of elements in rd.buff

Now, re #2, the code in FileRd seems to allocate buffers in 4096-char arrays, and BIG is 16M, so I don't quite see why the need to ensure the buffer is limited to no more than BIG, as it should never be more than 4096.

All that aside, are you concerned that the GC could be relocating rd.buff after its address is obtained and fed to the File.T.read (rd.sourceH.read) procedure?

If indeed this movement can occur, this code definitely needs to change.

How can we force the GC not to move rd.buff, or is there another "safe" way to make rd.buff appear as an "ARRAY OF Byte" to satisfy the File.T.read interface?

Buffers are allocated in line #45 as a traced reference to an ARRAY OF CHAR via:
      rd.buff := NEW(CharBuffer, BufferSize);
Yet, the ByteArrayPtr in FileRd.m3 (line 25) is an untraced reference (to an array of Byte).

Should we be allocating buffers (rd.buff) as untraced refs instead, and then explicitly freeing?  Or, is there a way to keep them as traced refs, but avoid collection/movement while being used in an unsafe manner?

Finally, there are multiple statements in the FileRd.m3 module similar to line #83 that must be dealt with (e.g., 114, 119).

Regards,
Randy Coleburn

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Wednesday, March 16, 2011 8:14 PM
To: Coleburn, Randy
Cc: m3devel
Subject: Re: [M3devel] thread test results on Win7 64-bit

This is the offending line:
On Mar 16, 2011, at 6:50 PM, Coleburn, Randy wrote:

***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\rw\FileRd.m3", line 83
***

      n := rd.sourceH.read(
             SUBARRAY(LOOPHOLE(ADR(rd.buff[0]), ByteArrayPtr)^, 0,
                      MIN (NUMBER(rd.buff^), BIG)), mayBlock := NOT dontBlock)

I am very suspicious about this...  anyone have any insights?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110317/006cbf1a/attachment-0002.html>

From dabenavidesd at yahoo.es  Fri Mar 18 01:31:35 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Fri, 18 Mar 2011 00:31:35 +0000 (GMT)
Subject: [M3devel] thread test results on Win7 64-bit
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E603418BDDEC@atlex02-srv>
Message-ID: <46694.52575.qm@web29710.mail.ird.yahoo.com>

Hi all:
reading through the green book chapter on IO streams, p160, it seems, there should not be such a range violation cause its actually allowed to be NIL (see? ftp://gatekeeper.research.compaq.com/pub/DEC/SRC/research-reports/abstracts/src-rr-053.html
p 30 and above) so this must be related to the fact there is some missing a conditional if so as it is unsafely checked by the compiler, but it might not be necessarily that, I mean unsafe perse, but in that case just for that may get a RT error unneeded to argue for that (i.e it might not), indeed most of the crashes might come by this classes, but as I read TextWr seek method style was to raise an unlisted exception which is by itself a RT error as a policy, however subclasses of Rd.T must be aware of their obligations that is, they have invariants so we could? check for those I believe they are there in safe MODULES (as I think is checked already) and manner that is even as one could argue in UNSAFE modules they hold (if they don't hold just the first case), we could if this is really broken get it in safe modules to check for them in an ESC, actually first RW lib was absolutely according to their comments unsafe for speed performance but after
 crashed many times decided to made safe interfaces to look for those kind of errors. So it might be need a middle layer not UNSAFE module of FileRd INTERFACE to look for those errors closely, e.g implement that method failing (FileRd.seek) and related safely and check them by ESC.
Specifically from the three invariants the most feasible mentioned in RdClass interface which might be not be satisfied and should be checked in a debugger is the first of the three (because would cause same RT error shown there):
rd is valid if =>
[rd.lo .. rd.hi-i] 
where i can be 0 and so buff=NIL, 
so its possible though would need confirmation a breakpoint there in line FileRd.m3:83 to see rd.buff
the others that come after this, 
cur(rd) = MIN(rd.cur,? len(rd))
from what
rd.cur>len(rd) or rd.cur = len(rd)
and third:
NOT (rd.intermittent AND rd.seekable)
That said I would recommend the latter method a mechanic debugger meanwhile, tough if positive we would follow the guideline of Greg and the gang to specify it in a safe module, at least the method. Then in an automatic debugger might help to proof that for us too if so.
Indeed there are more classes of invariants there for declare clean and also private invariants too. Will check for that too.  
Thanks in advance

--- El jue, 17/3/11, Coleburn, Randy <rcolebur at SCIRES.COM> escribi?:

De: Coleburn, Randy <rcolebur at SCIRES.COM>
Asunto: Re: [M3devel] thread test results on Win7 64-bit
Para: "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 17 de marzo, 2011 14:46

Tony et al: ?On the surface, it would seem this convoluted code is doing the following:1.?????? Making rd.buff appear as an ?ARRAY OF Byte?, vice an ?ARRAY OF CHAR, so as to meet the requirements of the File.T.read interface.2.?????? Limiting the buffer to be the smaller of ?BIG?, or the actual number of elements in rd.buff ?Now, re #2, the code in FileRd seems to allocate buffers in 4096-char arrays, and BIG is 16M, so I don?t quite see why the need to ensure the buffer is limited to no more than BIG, as it should never be more than 4096. ?All that aside, are you concerned that the GC could be relocating rd.buff after its address is obtained and fed to the File.T.read (rd.sourceH.read) procedure? ?If indeed this movement can occur, this code definitely needs to change. ?How can we force the GC not to move rd.buff, or is there another ?safe? way to make rd.buff appear as an ?ARRAY OF Byte? to satisfy the File.T.read
 interface? ?Buffers are allocated in line #45 as a traced reference to an ARRAY OF CHAR via:????? rd.buff := NEW(CharBuffer, BufferSize);Yet, the ByteArrayPtr in FileRd.m3 (line 25) is an untraced reference (to an array of Byte). ?Should we be allocating buffers (rd.buff) as untraced refs instead, and then explicitly freeing?? Or, is there a way to keep them as traced refs, but avoid collection/movement while being used in an unsafe manner? ?Finally, there are multiple statements in the FileRd.m3 module similar to line #83 that must be dealt with (e.g., 114, 119). ?Regards,Randy Coleburn ?From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
Sent: Wednesday, March 16, 2011 8:14 PM
To: Coleburn, Randy
Cc: m3devel
Subject: Re: [M3devel] thread test results on Win7 64-bit ?This is the offending line:On Mar 16, 2011, at 6:50 PM, Coleburn, Randy wrote: ?****** runtime error:***??? An array subscript was out of range.***??? file "..\src\rw\FileRd.m3", line 83*** ??? ? ?n := rd.sourceH.read(?? ? ? ? ? ? SUBARRAY(LOOPHOLE(ADR(rd.buff[0]), ByteArrayPtr)^, 0,?? ? ? ? ? ? ? ? ? ? ?MIN (NUMBER(rd.buff^), BIG)), mayBlock := NOT dontBlock) ?I am very suspicious about this... ?anyone have any insights? ?


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110318/0138ec00/attachment-0002.html>

From jay.krell at cornell.edu  Sun Mar 20 22:08:46 2011
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 20 Mar 2011 21:08:46 +0000
Subject: [M3devel] runaway hudson/pgm
Message-ID: <COL101-W63D86DE03E6E0EF01D5ABEE6B20@phx.gbl>


Some "pgm" (a common name for test cases) running as Hudson was eating CPU and laptop was noticably hot/slow, so I killed it.

 - Jay




 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110320/71efb57d/attachment-0002.html>

From rodney_bates at lcwb.coop  Tue Mar 22 19:45:28 2011
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Tue, 22 Mar 2011 13:45:28 -0500
Subject: [M3devel] thread test results on Win7 64-bit
Message-ID: <4D88EE48.70608@lcwb.coop>



The only subscript operation in this line is rd.buff[0].
 From the declaration of buff in RdClass.i3:32, buff has
type REF ARRAY OF CHAR.  If buff were NIL, it should give
a different runtime error (probably segfault).  With the
subscript being statically zero, the only way this could
happen is if buff was allocated with a zero NUMBER.  I
didn't go looking for that, but it seems unlikely.

Otherwise, it would have to be a corrupted heap object or
maybe miscompiled code.  Or the runtime error message is
wrong.  From this shallow reasoning, I would put my bet on
the corrupted object.

On 03/16/2011 07:13 PM, Tony Hosking wrote:
> This is the offending line:
>
> On Mar 16, 2011, at 6:50 PM, Coleburn, Randy wrote:
>
>> ***
>> *** runtime error:
>> *** An array subscript was out of range.
>> *** file "..\src\rw\FileRd.m3", line 83
>> ***
>
> n := rd.sourceH.read(
> SUBARRAY(LOOPHOLE(ADR(rd.buff[0]), ByteArrayPtr)^, 0,
> MIN (NUMBER(rd.buff^), BIG)), mayBlock := NOT dontBlock)
>
> I am very suspicious about this... anyone have any insights?
>



From dabenavidesd at yahoo.es  Thu Mar 24 00:41:35 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 23 Mar 2011 23:41:35 +0000 (GMT)
Subject: [M3devel] thread test results on Win7 64-bit
Message-ID: <634095.3089.qm@web29701.mail.ird.yahoo.com>

Hi all:
that is correct, it could be not NIL and still be wrong if V1 doesn't hold the characters of src are not those of buff mentione cin green book, page 160 or p 37 of:
ftp://apotheca.hpl.hp.com/pub/dec/SRC/research-reports/SRC-053.pdf

rd.buff[rd.st + i - rd.lo] = src(rd)[i]

The other thing is that as WrRep module section 6.8 in green book, page 151 says is needed or in SRC-RR-053, p 21 sec 8, collector is not relocating, does it hold this?


Aside, does a procedure type hold ADDRESS and its values are valid, as we could trace untraced objects, records, procedures in an unmovable heap and change them absolutely but in terms of an unsafe RT, that is to communicate better its abstraction low level in the RT, or high level like with traced ones.

Thanks in advance


--- El mar, 22/3/11, Rodney M. Bates <rodney_bates at lcwb.coop> escribi?:

> De: Rodney M. Bates <rodney_bates at lcwb.coop>
> Asunto: Re: [M3devel] thread test results on Win7 64-bit
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: martes, 22 de marzo, 2011 13:45
> 
> 
> The only subscript operation in this line is rd.buff[0].
>  From the declaration of buff in RdClass.i3:32, buff has
> type REF ARRAY OF CHAR.  If buff were NIL, it should
> give
> a different runtime error (probably segfault).  With
> the
> subscript being statically zero, the only way this could
> happen is if buff was allocated with a zero NUMBER. 
> I
> didn't go looking for that, but it seems unlikely.
> 
> Otherwise, it would have to be a corrupted heap object or
> maybe miscompiled code.  Or the runtime error message
> is
> wrong.  From this shallow reasoning, I would put my
> bet on
> the corrupted object.
> 
> On 03/16/2011 07:13 PM, Tony Hosking wrote:
> > This is the offending line:
> >
> > On Mar 16, 2011, at 6:50 PM, Coleburn, Randy wrote:
> >
> >> ***
> >> *** runtime error:
> >> *** An array subscript was out of range.
> >> *** file "..\src\rw\FileRd.m3", line 83
> >> ***
> >
> > n := rd.sourceH.read(
> > SUBARRAY(LOOPHOLE(ADR(rd.buff[0]), ByteArrayPtr)^, 0,
> > MIN (NUMBER(rd.buff^), BIG)), mayBlock := NOT
> dontBlock)
> >
> > I am very suspicious about this... anyone have any
> insights?
> >
> 
>



      


From rodney_bates at lcwb.coop  Mon Mar 28 18:16:23 2011
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Mon, 28 Mar 2011 11:16:23 -0500
Subject: [M3devel] How to install cm3 at a nonstandard location
Message-ID: <4D90B457.90305@lcwb.coop>

I tried to build cm3 head and install at /usr/local/cm3-head.
 From the installation notes, I set environment variable
CM3_INSTALL to this path.  After fixing several failures
involving merges by cvs, I discovered it had been putting
things into /usr/local/cm3, where I have the latest cm3
release, giving me a mixture of stuff from the head and
the release, which I certainly don't trust.

I was building instead of using cminstall, like the the install
notes were referring to.  However, before I started, I found
code in scripts/sysinfo.sh setting up CM3_INSTALL to the default,
unless already set, which I took to mean this was the way to
do it when building too.

I did double and triple check my spelling and value of
CM3_INSTALL, before and after the failed builds.

So how do I get this to work?

This was on LINUXLIBC6.

Rodney Bates




From mika at async.caltech.edu  Mon Mar 28 18:51:33 2011
From: mika at async.caltech.edu (Mika Nystrom)
Date: Mon, 28 Mar 2011 09:51:33 -0700
Subject: [M3devel] How to install cm3 at a nonstandard location
In-Reply-To: <4D90B457.90305@lcwb.coop> 
References: <4D90B457.90305@lcwb.coop>
Message-ID: <20110328165133.7504B1A2078@async.async.caltech.edu>

I think I pass the target directory to cminstall on the cmd. line, something like:

./cminstall /path/to/installation/root

"Rodney M. Bates" writes:
>I tried to build cm3 head and install at /usr/local/cm3-head.
> From the installation notes, I set environment variable
>CM3_INSTALL to this path.  After fixing several failures
>involving merges by cvs, I discovered it had been putting
>things into /usr/local/cm3, where I have the latest cm3
>release, giving me a mixture of stuff from the head and
>the release, which I certainly don't trust.
>
>I was building instead of using cminstall, like the the install
>notes were referring to.  However, before I started, I found
>code in scripts/sysinfo.sh setting up CM3_INSTALL to the default,
>unless already set, which I took to mean this was the way to
>do it when building too.
>
>I did double and triple check my spelling and value of
>CM3_INSTALL, before and after the failed builds.
>
>So how do I get this to work?
>
>This was on LINUXLIBC6.
>
>Rodney Bates
>


From dabenavidesd at yahoo.es  Mon Mar 28 21:24:52 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 28 Mar 2011 20:24:52 +0100 (BST)
Subject: [M3devel] About Simplify build script platforms and cm3ide service
Message-ID: <402597.44437.qm@web29712.mail.ird.yahoo.com>

Hi all:
I was wondering as I remember Simplify has a component to show IO (not sure for input) web page to show results or the theorems being proved and their proof and some test suites contain test compliant test suites, it seems we surely will have to display that for other clients than us, so it might be useful to put this tests or runs in the cm3ide server, as it allows to show a centralized approach rather than running simplify from old binary versions. It is also an opportunity to show an application of it, Modula-3 and of an application itself and by the way make cm3 improved performance for long runs of it since this is really an used tool, thus we can show how the compiler can take and how much can be optimized for every platform (perhaps to rethink a build script for it and perhaps to add optimization backend support port of  DS3100 burs based? or full 64 bit support in Win2k, xp, 2003, Server, Vista, 7, etc platforms, perhaps better to make an
 improvement over current Win*nix Platforms?
There are some tools which might use that, I know from two sources test suites mentioned coming from ESC in Modula-3, Java and later versions
Originally from the ESC/Modula-3 VCG:
http://portal.acm.org/citation.cfm?id=1066102&dl=guide&coll=GUIDE

(In section Source Materials, the second tab, inside simplify_benchmarks hyperlink and see simplify_benchmarks/format.txt for thge big and small suites or download directly from:
http://delivery.acm.org/10.1145/1070000/1066102/supp/simplify_benchmarks.tar.gz?key1=1066102&key2=3798331031&coll=DL&dl=ACM&CFID=15503308&CFTOKEN=88865083 

)

later modification of ESC/Java VCG relevant originally in:
http://replay.waybackmachine.org/20090422004503/http://nemerle.org/~malekith/smt/benchmarks/
Even other systems like JVM based Whiley, and or so any ESC/JVM itself, etc.
  
Thanks in advance


From jay.krell at cornell.edu  Tue Mar 29 02:03:03 2011
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 29 Mar 2011 00:03:03 +0000
Subject: [M3devel] How to install cm3 at a nonstandard location
In-Reply-To: <20110328165133.7504B1A2078@async.async.caltech.edu>
References: <4D90B457.90305@lcwb.coop>,
	<20110328165133.7504B1A2078@async.async.caltech.edu>
Message-ID: <COL101-W63008765882635E26EA9B1E6BD0@phx.gbl>


Another approach is to copy a few things to the new location, e.g. config files, cm3, cm3cg, and then use those to build/ship.
That is how make-dist.py works, for example.
And be sure the config files use path() to find themselves, instead of hardcoding their location.

 - Jay

> To: rodney_bates at lcwb.coop
> Date: Mon, 28 Mar 2011 09:51:33 -0700
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] How to install cm3 at a nonstandard location
> 
> I think I pass the target directory to cminstall on the cmd. line, something like:
> 
> ./cminstall /path/to/installation/root
> 
> "Rodney M. Bates" writes:
> >I tried to build cm3 head and install at /usr/local/cm3-head.
> > From the installation notes, I set environment variable
> >CM3_INSTALL to this path.  After fixing several failures
> >involving merges by cvs, I discovered it had been putting
> >things into /usr/local/cm3, where I have the latest cm3
> >release, giving me a mixture of stuff from the head and
> >the release, which I certainly don't trust.
> >
> >I was building instead of using cminstall, like the the install
> >notes were referring to.  However, before I started, I found
> >code in scripts/sysinfo.sh setting up CM3_INSTALL to the default,
> >unless already set, which I took to mean this was the way to
> >do it when building too.
> >
> >I did double and triple check my spelling and value of
> >CM3_INSTALL, before and after the failed builds.
> >
> >So how do I get this to work?
> >
> >This was on LINUXLIBC6.
> >
> >Rodney Bates
> >
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110329/c26447fc/attachment-0002.html>

From dabenavidesd at yahoo.es  Tue Mar 29 01:57:23 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 29 Mar 2011 00:57:23 +0100 (BST)
Subject: [M3devel] About CM3_IDE_UsersGuide format if so
Message-ID: <667386.49334.qm@web29719.mail.ird.yahoo.com>

Hi all:
I wanted to know whether you agree on reformat the CM3_IDE_UserGuide doc file into a standard linear one, like of the doc tools used in cm3 and pm3 repository are based on either tex, html (and back and forth see belo ) or even gnuinfo files, although there some small ones of mtex that I don't know much about and also the noweb files (literate programming like native burs backend is coded or ldb, where still is to be seeing whether generic files are post processed as expected by cm3) that are also plain text files.
I was thinking in make some docs more widely available specifically some improvement over Net Object collector information, since there are two formal proofs of that I believe one is current there (Birrell's collection scheme) and "new" one distributed cyclic garbage collection.
This would allows us to alter proof them by formal and automatic mechanical checking and such gain some more interest in the platform and its collection algorithms:
http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-116.pdf

And subsequent work:
http://kar.kent.ac.uk/21327/

http://www.cs.kent.ac.uk/pubs/1998/926/index.html

and last but not least:
http://www.cs.kent.ac.uk/pubs/2003/1650/

With mechanism such as of the pm3 sgml-obliq it could be shown to convert from ps (with see doi:10.1109/ICDAR.1997.619868 [1]) to html to tex and so on keep improving the situation with respect of lack of annotation information with the current papers, as of anybody who wants to write informally knowledge about it let him do it freely.

Well, just in case you don't mind I will try to add extra converted this docs to lyx, from where it could be later compiled to tex or displayed directly in any other format if so.

Thanks in advance

[1] B. Poirier and M. Dagenais, ?An interactive system to extract structured text from a geometrical representation,? in Document Analysis and Recognition, 1997., Proceedings of the Fourth International Conference on, 1997, vol. 1, pp. 342-346 vol.1.


From jay.krell at cornell.edu  Tue Mar 29 02:04:00 2011
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 29 Mar 2011 00:04:00 +0000
Subject: [M3devel] FW: GCC 4.6.0 Released
In-Reply-To: <20110328072557.GG11563@sunsite.ms.mff.cuni.cz>
References: <20110328072557.GG11563@sunsite.ms.mff.cuni.cz>
Message-ID: <COL101-W2D287BFCAEBA44A26313CE6BD0@phx.gbl>


for us to consider..


> Date: Mon, 28 Mar 2011 09:25:57 +0200
> From: jakub at redhat.com
> To: gcc-announce at gcc.gnu.org
> CC: gcc at gcc.gnu.org
> Subject: GCC 4.6.0 Released
> 
> The GNU Compiler Collection version 4.6.0 has been released.
> 
> GCC 4.6.0 is a major release, containing substantial new functionality
> not available in GCC 4.5.x or previous GCC releases.
> 
> The "link-time optimization" framework introduced in GCC 4.5.0 has been
> significantly improved in this release, it is now possible to compile
> very large applications like Mozilla or GCC itself with LTO.
> GCC can now partially inline functions, inlining just hot short path
> to exit and keeping the rest of the function out of line.
> Support for the upcoming C++0x standard has been notably improved,
> Fortran 2003 and 2008 has been greatly extended and many other frontends
> undergone substantial changes as well.
> Many other improvements have been added and more than thousand of bugs
> have been fixed in various parts of the compiler collection.
> 
> See:
> 
>   http://gcc.gnu.org/gcc-4.6/changes.html
> 
> for more information about changes in GCC 4.6.0.
> 
> This release is available from the FTP servers listed here:
> 
>   http://www.gnu.org/order/ftp.html
> 
> The release is in gcc/gcc-4.6.0/ subdirectory.
> 
> If you encounter difficulties using GCC 4.6, please do not contact me
> directly.  Instead, please visit http://gcc.gnu.org for information
> about getting help.
> 
> As always, a vast number of people contributed to this GCC releases --
> far too many to thank individually!
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110329/eb0cebe0/attachment-0002.html>

From hosking at cs.purdue.edu  Tue Mar 29 04:38:00 2011
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 28 Mar 2011 22:38:00 -0400
Subject: [M3devel] FW: GCC 4.6.0 Released
In-Reply-To: <COL101-W2D287BFCAEBA44A26313CE6BD0@phx.gbl>
References: <20110328072557.GG11563@sunsite.ms.mff.cuni.cz>
	<COL101-W2D287BFCAEBA44A26313CE6BD0@phx.gbl>
Message-ID: <4D4B822F-1820-4E91-8543-AA35097A3766@cs.purdue.edu>

Are you volunteering?  ;-)


On Mar 28, 2011, at 8:04 PM, Jay K wrote:

> for us to consider..
> 
> 
> > Date: Mon, 28 Mar 2011 09:25:57 +0200
> > From: jakub at redhat.com
> > To: gcc-announce at gcc.gnu.org
> > CC: gcc at gcc.gnu.org
> > Subject: GCC 4.6.0 Released
> > 
> > The GNU Compiler Collection version 4.6.0 has been released.
> > 
> > GCC 4.6.0 is a major release, containing substantial new functionality
> > not available in GCC 4.5.x or previous GCC releases.
> > 
> > The "link-time optimization" framework introduced in GCC 4.5.0 has been
> > significantly improved in this release, it is now possible to compile
> > very large applications like Mozilla or GCC itself with LTO.
> > GCC can now partially inline functions, inlining just hot short path
> > to exit and keeping the rest of the function out of line.
> > Support for the upcoming C++0x standard has been notably improved,
> > Fortran 2003 and 2008 has been greatly extended and many other frontends
> > undergone substantial changes as well.
> > Many other improvements have been added and more than thousand of bugs
> > have been fixed in various parts of the compiler collection.
> > 
> > See:
> > 
> > http://gcc.gnu.org/gcc-4.6/changes.html
> > 
> > for more information about changes in GCC 4.6.0.
> > 
> > This release is available from the FTP servers listed here:
> > 
> > http://www.gnu.org/order/ftp.html
> > 
> > The release is in gcc/gcc-4.6.0/ subdirectory.
> > 
> > If you encounter difficulties using GCC 4.6, please do not contact me
> > directly. Instead, please visit http://gcc.gnu.org for information
> > about getting help.
> > 
> > As always, a vast number of people contributed to this GCC releases --
> > far too many to thank individually!

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

From dabenavidesd at yahoo.es  Tue Mar 29 05:07:56 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 29 Mar 2011 04:07:56 +0100 (BST)
Subject: [M3devel] About Simplify build script platforms and cm3ide
	service
In-Reply-To: <402597.44437.qm@web29712.mail.ird.yahoo.com>
Message-ID: <428050.39604.qm@web29720.mail.ird.yahoo.com>

Hi all:
some refs I didn't mention where it came from, here:
http://www.cs.nyu.edu/pipermail/smt-lib/2007/000149.html

And further for same knowledge and software theories improvement [1] in:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.22.4306

[2] in:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.28.6492

and realized retrospectively on [3], and a newer one [4]

[1] U. Nestmann, H. H?ttel, J. Kleist, and M. Merro, ?Aliasing Models for Mobile Objects,? Information and Computation, vol. 175, no. 1, pp. 3-33, May. 2002.

[2] M. Merro, J. Kleist, and U. Nestmann, ?Mobile Objects as Mobile Processes,? Information and Computation, vol. 177, no. 2, pp. 195-241, Sep. 2002.

[3] D. Caromel and L. Henrio, A Theory of Distributed Objects, 1st ed. Springer, 2005.

[4] M. Hennessy, A Distributed Pi-Calculus, 1st ed. Cambridge University Press, 2007.

Again, this would useful for such an application extension of DCVS like mercurial, perforce and git rewrite from scratch but in something rely fast and reliable for really distributed computations, don't you think? :)
 
Thanks in advance

--- El lun, 28/3/11, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:

> De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
> Asunto: [M3devel] About Simplify build script platforms and cm3ide service
> Para: m3devel at elegosoft.com
> Fecha: lunes, 28 de marzo, 2011 14:24
> Hi all:
> I was wondering as I remember Simplify has a component to
> show IO (not sure for input) web page to show results or the
> theorems being proved and their proof and some test suites
> contain test compliant test suites, it seems we surely will
> have to display that for other clients than us, so it might
> be useful to put this tests or runs in the cm3ide server, as
> it allows to show a centralized approach rather than running
> simplify from old binary versions. It is also an opportunity
> to show an application of it, Modula-3 and of an application
> itself and by the way make cm3 improved performance for long
> runs of it since this is really an used tool, thus we can
> show how the compiler can take and how much can be optimized
> for every platform (perhaps to rethink a build script for it
> and perhaps to add optimization backend support port
> of  DS3100 burs based? or full 64 bit support in Win2k,
> xp, 2003, Server, Vista, 7, etc platforms, perhaps better to
> make an
>  improvement over current Win*nix Platforms?
> There are some tools which might use that, I know from two
> sources test suites mentioned coming from ESC in Modula-3,
> Java and later versions
> Originally from the ESC/Modula-3 VCG:
> http://portal.acm.org/citation.cfm?id=1066102&dl=guide&coll=GUIDE
> 
> (In section Source Materials, the second tab, inside
> simplify_benchmarks hyperlink and see
> simplify_benchmarks/format.txt for thge big and small suites
> or download directly from:
> http://delivery.acm.org/10.1145/1070000/1066102/supp/simplify_benchmarks.tar.gz?key1=1066102&key2=3798331031&coll=DL&dl=ACM&CFID=15503308&CFTOKEN=88865083
> 
> 
> )
> 
> later modification of ESC/Java VCG relevant originally in:
> http://replay.waybackmachine.org/20090422004503/http://nemerle.org/~malekith/smt/benchmarks/
> Even other systems like JVM based Whiley, and or so any
> ESC/JVM itself, etc.
>   
> Thanks in advance
> 


From wagner at elegosoft.com  Tue Mar 29 09:18:52 2011
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 29 Mar 2011 09:18:52 +0200
Subject: [M3devel] How to install cm3 at a nonstandard location
In-Reply-To: <4D90B457.90305@lcwb.coop>
References: <4D90B457.90305@lcwb.coop>
Message-ID: <20110329091852.sdnxriui04s880go@mail.elegosoft.com>

Quoting "Rodney M. Bates" <rodney_bates at lcwb.coop>:

> I tried to build cm3 head and install at /usr/local/cm3-head.
> From the installation notes, I set environment variable
> CM3_INSTALL to this path.  After fixing several failures
> involving merges by cvs, I discovered it had been putting
> things into /usr/local/cm3, where I have the latest cm3
> release, giving me a mixture of stuff from the head and
> the release, which I certainly don't trust.
>
> I was building instead of using cminstall, like the the install
> notes were referring to.  However, before I started, I found
> code in scripts/sysinfo.sh setting up CM3_INSTALL to the default,
> unless already set, which I took to mean this was the way to
> do it when building too.
>
> I did double and triple check my spelling and value of
> CM3_INSTALL, before and after the failed builds.
>
> So how do I get this to work?
>
> This was on LINUXLIBC6.

It certainly used to work, but scripts have changed much in recent
years, and some people rather use python or Windows' cmd scripts etc.

I always need to make sure myself when I try something like that again.
The main thing to look for is the central configuration file or
the set of configuration files that the builder reads. These are
quake scripts of course, and I think there's INSTALL_ROOT.

The current cm3.cfg seems to use a combination of CM3_INSTALL and
INSATLL_ROOT:

1.1       jkrell     14: proc CM3SetInstallRoot() is
                      15:     if defined("INSTALL_ROOT")
                      16:         return
                      17:     end
                      18:     if not equal ($CM3_INSTALL, "")
                      19:         INSTALL_ROOT = $CM3_INSTALL
                      20:         return
                      21:     end
                      22:     INSTALL_ROOT = (path() & SL & "..")
                      23: end

Of course this file may look completely different if you've got an
older installed version of cm3...

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Tue Mar 29 10:07:08 2011
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 29 Mar 2011 08:07:08 +0000
Subject: [M3devel] FW: GCC 4.6.0 Released
In-Reply-To: <4D4B822F-1820-4E91-8543-AA35097A3766@cs.purdue.edu>
References: <20110328072557.GG11563@sunsite.ms.mff.cuni.cz>,
	<COL101-W2D287BFCAEBA44A26313CE6BD0@phx.gbl>,
	<4D4B822F-1820-4E91-8543-AA35097A3766@cs.purdue.edu>
Message-ID: <COL101-W26BEC4765D7A10521AAA4FE6BD0@phx.gbl>


I assume we want it and yeah I might get to it.
I'd like to continue to avoid the gmp/mpfr/mpc dependencies, as well as not bothering with LTO for the forseable future.

 - Jay

From: hosking at cs.purdue.edu
Date: Mon, 28 Mar 2011 22:38:00 -0400
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] FW: GCC 4.6.0 Released



Are you volunteering?  ;-)


On Mar 28, 2011, at 8:04 PM, Jay K wrote:for us to consider..


> Date: Mon, 28 Mar 2011 09:25:57 +0200
> From: jakub at redhat.com
> To: gcc-announce at gcc.gnu.org
> CC: gcc at gcc.gnu.org
> Subject: GCC 4.6.0 Released
> 
> The GNU Compiler Collection version 4.6.0 has been released.
> 
> GCC 4.6.0 is a major release, containing substantial new functionality
> not available in GCC 4.5.x or previous GCC releases.
> 
> The "link-time optimization" framework introduced in GCC 4.5.0 has been
> significantly improved in this release, it is now possible to compile
> very large applications like Mozilla or GCC itself with LTO.
> GCC can now partially inline functions, inlining just hot short path
> to exit and keeping the rest of the function out of line.
> Support for the upcoming C++0x standard has been notably improved,
> Fortran 2003 and 2008 has been greatly extended and many other frontends
> undergone substantial changes as well.
> Many other improvements have been added and more than thousand of bugs
> have been fixed in various parts of the compiler collection.
> 
> See:
> 
> http://gcc.gnu.org/gcc-4.6/changes.html
> 
> for more information about changes in GCC 4.6.0.
> 
> This release is available from the FTP servers listed here:
> 
> http://www.gnu.org/order/ftp.html
> 
> The release is in gcc/gcc-4.6.0/ subdirectory.
> 
> If you encounter difficulties using GCC 4.6, please do not contact me
> directly. Instead, please visit http://gcc.gnu.org for information
> about getting help.
> 
> As always, a vast number of people contributed to this GCC releases --
> far too many to thank individually!

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110329/2599da1f/attachment-0002.html>

From rcolebur at SCIRES.COM  Tue Mar 29 21:40:16 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Tue, 29 Mar 2011 15:40:16 -0400
Subject: [M3devel] About CM3_IDE_UsersGuide format if so
In-Reply-To: <667386.49334.qm@web29719.mail.ird.yahoo.com>
References: <667386.49334.qm@web29719.mail.ird.yahoo.com>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E60341B189BC@atlex02-srv>

Daniel:

I am ok with you or anyone else providing the user guide in additional formats.
I simply provided it in the formats readily available to me at the time.

Regards,
Randy Coleburn

-----Original Message-----
From: Daniel Alejandro Benavides D. [mailto:dabenavidesd at yahoo.es] 
Sent: Monday, March 28, 2011 7:57 PM
To: m3devel at elegosoft.com
Subject: [M3devel] About CM3_IDE_UsersGuide format if so

Hi all:
I wanted to know whether you agree on reformat the CM3_IDE_UserGuide doc file into a standard linear one, like of the doc tools used in cm3 and pm3 repository are based on either tex, html (and back and forth see belo ) or even gnuinfo files, although there some small ones of mtex that I don't know much about and also the noweb files (literate programming like native burs backend is coded or ldb, where still is to be seeing whether generic files are post processed as expected by cm3) that are also plain text files.
I was thinking in make some docs more widely available specifically some improvement over Net Object collector information, since there are two formal proofs of that I believe one is current there (Birrell's collection scheme) and "new" one distributed cyclic garbage collection.
This would allows us to alter proof them by formal and automatic mechanical checking and such gain some more interest in the platform and its collection algorithms:
http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-116.pdf

And subsequent work:
http://kar.kent.ac.uk/21327/

http://www.cs.kent.ac.uk/pubs/1998/926/index.html

and last but not least:
http://www.cs.kent.ac.uk/pubs/2003/1650/

With mechanism such as of the pm3 sgml-obliq it could be shown to convert from ps (with see doi:10.1109/ICDAR.1997.619868 [1]) to html to tex and so on keep improving the situation with respect of lack of annotation information with the current papers, as of anybody who wants to write informally knowledge about it let him do it freely.

Well, just in case you don't mind I will try to add extra converted this docs to lyx, from where it could be later compiled to tex or displayed directly in any other format if so.

Thanks in advance

[1] B. Poirier and M. Dagenais, ?An interactive system to extract structured text from a geometrical representation,? in Document Analysis and Recognition, 1997., Proceedings of the Fourth International Conference on, 1997, vol. 1, pp. 342-346 vol.1.

From dabenavidesd at yahoo.es  Tue Mar 29 22:36:42 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 29 Mar 2011 21:36:42 +0100 (BST)
Subject: [M3devel] About CM3_IDE_UsersGuide format if so
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E60341B189BC@atlex02-srv>
Message-ID: <630972.93901.qm@web29718.mail.ird.yahoo.com>

Hi all:
yes, thanks for the info, would be nice to see some level of integration between the ESC and Modula-3 in cm3ide as I said it shall be pretty easy to deploy network management display of test sessions with the cm3ide tool with Simplify too, so is nice to have documentation on it about that. I guess it would be possible to handle that too in any format, if hosts are kind enough for that, as our hosts allows us to do so, if I am right. Also a good and nice option is for Mobile sessions, to keep an eye on each task, for instance I know you can use some editor for showing error messages, I guess one would be able to reproduce that behavior with ESC errors right, i.e cm3 errors displays line an hyperlinks a editor on line. Thus for instance you can get a report on error messages from the web server and so display a line in the code directly to modify it and run again, I believe.
This is something really useful if we have such an automation of tasks one could think in programming or getting the marked line via twits for instance :) if such agreement is allowed too.
Thanks in advance


--- El mar, 29/3/11, Coleburn, Randy <rcolebur at SCIRES.COM> escribi?:

> De: Coleburn, Randy <rcolebur at SCIRES.COM>
> Asunto: RE: [M3devel] About CM3_IDE_UsersGuide format if so
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>, "m3devel at elegosoft.com" <m3devel at elegosoft.com>
> Fecha: martes, 29 de marzo, 2011 14:40
> Daniel:
> 
> I am ok with you or anyone else providing the user guide in
> additional formats.
> I simply provided it in the formats readily available to me
> at the time.
> 
> Regards,
> Randy Coleburn
> 
> -----Original Message-----
> From: Daniel Alejandro Benavides D. [mailto:dabenavidesd at yahoo.es]
> 
> Sent: Monday, March 28, 2011 7:57 PM
> To: m3devel at elegosoft.com
> Subject: [M3devel] About CM3_IDE_UsersGuide format if so
> 
> Hi all:
> I wanted to know whether you agree on reformat the
> CM3_IDE_UserGuide doc file into a standard linear one, like
> of the doc tools used in cm3 and pm3 repository are based on
> either tex, html (and back and forth see belo ) or even
> gnuinfo files, although there some small ones of mtex that I
> don't know much about and also the noweb files (literate
> programming like native burs backend is coded or ldb, where
> still is to be seeing whether generic files are post
> processed as expected by cm3) that are also plain text
> files.
> I was thinking in make some docs more widely available
> specifically some improvement over Net Object collector
> information, since there are two formal proofs of that I
> believe one is current there (Birrell's collection scheme)
> and "new" one distributed cyclic garbage collection.
> This would allows us to alter proof them by formal and
> automatic mechanical checking and such gain some more
> interest in the platform and its collection algorithms:
> http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-116.pdf

> 
> And subsequent work:
> http://kar.kent.ac.uk/21327/

> 
> http://www.cs.kent.ac.uk/pubs/1998/926/index.html

> 
> and last but not least:
> http://www.cs.kent.ac.uk/pubs/2003/1650/

> 
> With mechanism such as of the pm3 sgml-obliq it could be
> shown to convert from ps (with see
> doi:10.1109/ICDAR.1997.619868 [1]) to html to tex and so on
> keep improving the situation with respect of lack of
> annotation information with the current papers, as of
> anybody who wants to write informally knowledge about it let
> him do it freely.
> 
> Well, just in case you don't mind I will try to add extra
> converted this docs to lyx, from where it could be later
> compiled to tex or displayed directly in any other format if
> so.
> 
> Thanks in advance
> 
> [1] B. Poirier and M. Dagenais, ?An interactive system to
> extract structured text from a geometrical
> representation,? in Document Analysis and Recognition,
> 1997., Proceedings of the Fourth International Conference
> on, 1997, vol. 1, pp. 342-346 vol.1.
> 


From rcolebur at SCIRES.COM  Tue Mar 29 23:26:19 2011
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Tue, 29 Mar 2011 17:26:19 -0400
Subject: [M3devel] About CM3_IDE_UsersGuide format if so
In-Reply-To: <630972.93901.qm@web29718.mail.ird.yahoo.com>
References: <D67F02DDC62F7545A6B84C285F88F3E60341B189BC@atlex02-srv>
	<630972.93901.qm@web29718.mail.ird.yahoo.com>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E60341B18A02@atlex02-srv>

Daniel:

I'm sorry, but I'm not sure I follow your entire train of thought.

If you use CM3IDE to invoke the CM3 builder, any errors during the compilation/build process will be displayed in the browser with a hyperlink to invoke your editor and jump to the line identified as the source of the problem.

The CM3IDE configuration page allows you to specify the editor to be invoked, among other options.

Regards,
Randy Coleburn

-----Original Message-----
From: Daniel Alejandro Benavides D. [mailto:dabenavidesd at yahoo.es] 
Sent: Tuesday, March 29, 2011 4:37 PM
To: m3devel at elegosoft.com; Coleburn, Randy
Subject: RE: [M3devel] About CM3_IDE_UsersGuide format if so

Hi all:
yes, thanks for the info, would be nice to see some level of integration between the ESC and Modula-3 in cm3ide as I said it shall be pretty easy to deploy network management display of test sessions with the cm3ide tool with Simplify too, so is nice to have documentation on it about that. I guess it would be possible to handle that too in any format, if hosts are kind enough for that, as our hosts allows us to do so, if I am right. Also a good and nice option is for Mobile sessions, to keep an eye on each task, for instance I know you can use some editor for showing error messages, I guess one would be able to reproduce that behavior with ESC errors right, i.e cm3 errors displays line an hyperlinks a editor on line. Thus for instance you can get a report on error messages from the web server and so display a line in the code directly to modify it and run again, I believe.
This is something really useful if we have such an automation of tasks one could think in programming or getting the marked line via twits for instance :) if such agreement is allowed too.
Thanks in advance


--- El mar, 29/3/11, Coleburn, Randy <rcolebur at SCIRES.COM> escribi?:

> De: Coleburn, Randy <rcolebur at SCIRES.COM>
> Asunto: RE: [M3devel] About CM3_IDE_UsersGuide format if so
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>, "m3devel at elegosoft.com" <m3devel at elegosoft.com>
> Fecha: martes, 29 de marzo, 2011 14:40
> Daniel:
> 
> I am ok with you or anyone else providing the user guide in
> additional formats.
> I simply provided it in the formats readily available to me
> at the time.
> 
> Regards,
> Randy Coleburn
> 
> -----Original Message-----
> From: Daniel Alejandro Benavides D. [mailto:dabenavidesd at yahoo.es]
> 
> Sent: Monday, March 28, 2011 7:57 PM
> To: m3devel at elegosoft.com
> Subject: [M3devel] About CM3_IDE_UsersGuide format if so
> 
> Hi all:
> I wanted to know whether you agree on reformat the
> CM3_IDE_UserGuide doc file into a standard linear one, like
> of the doc tools used in cm3 and pm3 repository are based on
> either tex, html (and back and forth see belo ) or even
> gnuinfo files, although there some small ones of mtex that I
> don't know much about and also the noweb files (literate
> programming like native burs backend is coded or ldb, where
> still is to be seeing whether generic files are post
> processed as expected by cm3) that are also plain text
> files.
> I was thinking in make some docs more widely available
> specifically some improvement over Net Object collector
> information, since there are two formal proofs of that I
> believe one is current there (Birrell's collection scheme)
> and "new" one distributed cyclic garbage collection.
> This would allows us to alter proof them by formal and
> automatic mechanical checking and such gain some more
> interest in the platform and its collection algorithms:
> http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-116.pdf

> 
> And subsequent work:
> http://kar.kent.ac.uk/21327/

> 
> http://www.cs.kent.ac.uk/pubs/1998/926/index.html

> 
> and last but not least:
> http://www.cs.kent.ac.uk/pubs/2003/1650/

> 
> With mechanism such as of the pm3 sgml-obliq it could be
> shown to convert from ps (with see
> doi:10.1109/ICDAR.1997.619868 [1]) to html to tex and so on
> keep improving the situation with respect of lack of
> annotation information with the current papers, as of
> anybody who wants to write informally knowledge about it let
> him do it freely.
> 
> Well, just in case you don't mind I will try to add extra
> converted this docs to lyx, from where it could be later
> compiled to tex or displayed directly in any other format if
> so.
> 
> Thanks in advance
> 
> [1] B. Poirier and M. Dagenais, ?An interactive system to
> extract structured text from a geometrical
> representation,? in Document Analysis and Recognition,
> 1997., Proceedings of the Fourth International Conference
> on, 1997, vol. 1, pp. 342-346 vol.1.
> 

From dabenavidesd at yahoo.es  Wed Mar 30 02:21:44 2011
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 30 Mar 2011 01:21:44 +0100 (BST)
Subject: [M3devel] About CM3_IDE_UsersGuide format if so
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E60341B18A02@atlex02-srv>
Message-ID: <242549.67696.qm@web29703.mail.ird.yahoo.com>

Hi all:
thanks for your message, and it's Ok, indeed I'm very sorry about that; now the idea behind is that we can invoke "m3build" process (aka cm3) to ESC via esc() quake directive and so subsequently it will call Simplify theorem prover as many times as needed.
As Simplify is able to display its output via ESC command line input parameter and then call the output of it and postprocessed it in ESC to show a source code line number error, e.g array index out of bounds line number xyz, nil deref attempt, unchecked exception, deadlock, etc, so we can get a line number from it and then pass it trough cm3ide to its web output (if Verification Condition VC is correctly generated in ESC that is, Simplify's input and if implied results are positive for source code "errors" at least by its conservatism or formal proof, as also it might be silent in absence of errors either by possible insufficient or too much rigorousness in VCs or if not pass it back to ESC if so to get an error message because of theorem proof is not true or if it doesn't find it, again conservatively speaking), we surely may get this passed through from ESC back to cm3ide to show a similar message hyperlink and "error" line number.
Now in behalf of us we don't have any time to waste we could continue our duties and get a editor call or a twit a message with line and error and enter or twit back the intended solution if so in that line whenever that happens.
As the the Simplify output has html output support for VC falsity, etc, and ESC I still wonder how it will communicate its results, we could adjust that for us in the cm3ide to make that display for us too and show its line number and warning message. Perhaps another cm3ide object method might do that as well, as this "errors" are not fatal, still, it can be shown as warnings (as they really are), then does CM3IDE warning messages come too in same way cm3 errors are shown? If so perhaps this is the way to go. We could select whether to stop compilation process if so if there are selected warnings to do so or if it's asked to continue to do so and don't halt until another instruction is given or it finishes its process. 
As ESC is concerned it would take same time parsing and compiling as cm3 but then another equivalent or more time to check it in VCs theorem proving   meanwhile it might be useful to have that view or display, if for instance it is not happy or unable to prove a given formula to display its VC, in case of false alarm say, or if they are successful steps as they are PROCEDURE by PROCEDURE as ESC goes along each MODULE, so in the end it would take slower time to compile and then recompile it if so as any given module might have a failed proof in a procedure before it checks everything of it. 
Main issue here is that parse trees are different so we can't share their time to type check (assuming we both want to compile and statically check), at least as Verification condition generation is concerned, besides dependency order is determined by cm3 driver and I don't know how it might be get it by m3tk independently if so, so it will for now wait for its type checking and then redo type inference and so and continue to proof so best case scenario both systems will have that to do same type checking and inference to produce a parse tree that will give us a proof that must be verified and if it doesn't satisfy its condition return as an ESC "error" or warning, or finish without complaints if it really does.   
Thanks in advance

--- El mar, 29/3/11, Coleburn, Randy <rcolebur at SCIRES.COM> escribi?:

> De: Coleburn, Randy <rcolebur at SCIRES.COM>
> Asunto: RE: [M3devel] About CM3_IDE_UsersGuide format if so
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>, "m3devel at elegosoft.com" <m3devel at elegosoft.com>
> Fecha: martes, 29 de marzo, 2011 16:26
> Daniel:
> 
> I'm sorry, but I'm not sure I follow your entire train of
> thought.
> 
> If you use CM3IDE to invoke the CM3 builder, any errors
> during the compilation/build process will be displayed in
> the browser with a hyperlink to invoke your editor and jump
> to the line identified as the source of the problem.
> 
> The CM3IDE configuration page allows you to specify the
> editor to be invoked, among other options.
> 
> Regards,
> Randy Coleburn
> 
> -----Original Message-----
> From: Daniel Alejandro Benavides D. [mailto:dabenavidesd at yahoo.es]
> 
> Sent: Tuesday, March 29, 2011 4:37 PM
> To: m3devel at elegosoft.com;
> Coleburn, Randy
> Subject: RE: [M3devel] About CM3_IDE_UsersGuide format if
> so
> 
> Hi all:
> yes, thanks for the info, would be nice to see some level
> of integration between the ESC and Modula-3 in cm3ide as I
> said it shall be pretty easy to deploy network management
> display of test sessions with the cm3ide tool with Simplify
> too, so is nice to have documentation on it about that. I
> guess it would be possible to handle that too in any format,
> if hosts are kind enough for that, as our hosts allows us to
> do so, if I am right. Also a good and nice option is for
> Mobile sessions, to keep an eye on each task, for instance I
> know you can use some editor for showing error messages, I
> guess one would be able to reproduce that behavior with ESC
> errors right, i.e cm3 errors displays line an hyperlinks a
> editor on line. Thus for instance you can get a report on
> error messages from the web server and so display a line in
> the code directly to modify it and run again, I believe.
> This is something really useful if we have such an
> automation of tasks one could think in programming or
> getting the marked line via twits for instance :) if such
> agreement is allowed too.
> Thanks in advance
> 
> 
> --- El mar, 29/3/11, Coleburn, Randy <rcolebur at SCIRES.COM>
> escribi?:
> 
> > De: Coleburn, Randy <rcolebur at SCIRES.COM>
> > Asunto: RE: [M3devel] About CM3_IDE_UsersGuide format
> if so
> > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>,
> "m3devel at elegosoft.com"
> <m3devel at elegosoft.com>
> > Fecha: martes, 29 de marzo, 2011 14:40
> > Daniel:
> > 
> > I am ok with you or anyone else providing the user
> guide in
> > additional formats.
> > I simply provided it in the formats readily available
> to me
> > at the time.
> > 
> > Regards,
> > Randy Coleburn
> > 
> > -----Original Message-----
> > From: Daniel Alejandro Benavides D. [mailto:dabenavidesd at yahoo.es]
> > 
> > Sent: Monday, March 28, 2011 7:57 PM
> > To: m3devel at elegosoft.com
> > Subject: [M3devel] About CM3_IDE_UsersGuide format if
> so
> > 
> > Hi all:
> > I wanted to know whether you agree on reformat the
> > CM3_IDE_UserGuide doc file into a standard linear one,
> like
> > of the doc tools used in cm3 and pm3 repository are
> based on
> > either tex, html (and back and forth see belo ) or
> even
> > gnuinfo files, although there some small ones of mtex
> that I
> > don't know much about and also the noweb files
> (literate
> > programming like native burs backend is coded or ldb,
> where
> > still is to be seeing whether generic files are post
> > processed as expected by cm3) that are also plain
> text
> > files.
> > I was thinking in make some docs more widely
> available
> > specifically some improvement over Net Object
> collector
> > information, since there are two formal proofs of that
> I
> > believe one is current there (Birrell's collection
> scheme)
> > and "new" one distributed cyclic garbage collection.
> > This would allows us to alter proof them by formal
> and
> > automatic mechanical checking and such gain some more
> > interest in the platform and its collection
> algorithms:
> > http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-116.pdf

> 
> > 
> > And subsequent work:
> > http://kar.kent.ac.uk/21327/

> 
> > 
> > http://www.cs.kent.ac.uk/pubs/1998/926/index.html

> 
> > 
> > and last but not least:
> > http://www.cs.kent.ac.uk/pubs/2003/1650/

> 
> > 
> > With mechanism such as of the pm3 sgml-obliq it could
> be
> > shown to convert from ps (with see
> > doi:10.1109/ICDAR.1997.619868 [1]) to html to tex and
> so on
> > keep improving the situation with respect of lack of
> > annotation information with the current papers, as of
> > anybody who wants to write informally knowledge about
> it let
> > him do it freely.
> > 
> > Well, just in case you don't mind I will try to add
> extra
> > converted this docs to lyx, from where it could be
> later
> > compiled to tex or displayed directly in any other
> format if
> > so.
> > 
> > Thanks in advance
> > 
> > [1] B. Poirier and M. Dagenais, ?An interactive
> system to
> > extract structured text from a geometrical
> > representation,? in Document Analysis and
> Recognition,
> > 1997., Proceedings of the Fourth International
> Conference
> > on, 1997, vol. 1, pp. 342-346 vol.1.
> > 
>