[M3devel] results of threadtest program on Windows7
Tony Hosking
hosking at cs.purdue.edu
Thu Mar 3 16:39:07 CET 2011
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>
More information about the M3devel
mailing list