[M3devel] results of threadtest program on Windows7

[Tony Hosking]

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>