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={}) at ../src/vbt/VBTRep.m3:82 #10 0x00ee2b5c in Palette__ResolveCursor (st=0xb7db6ae4, curs={}) 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: , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , <20110227231125.3DC611A2078@async.async.caltech.edu> Message-ID: 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: 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: References: , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, Message-ID: 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: 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: References: , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, 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 > > > > > > >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
Writing file...done
Creating read threads...= >done
Creating fork threads...done
Creating alloc threads...done
Cr= >eating lock threads...done
running...printing oldest/median age/newestr>.

Are we guranteed forward progress in suspending all threads?
= >
I do see it fail usually on Darwin. e.g.:
........pthread_mutex_dest= >roy:EBUSY
pthread_mutex_destroy:EBUSY
..laziest thread is 0/0/0 (test= >s: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
...

***
*** r= >untime error:
*** =3B =3B =3B An array subscript was out of = >range.
*** =3B =3B =3B file "../src/runtime/common/RTCollect= >or.m3"=2C line 418
***

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

Mika are your machin= >es all multiprocessors?
I do wonder if that helps increase the stress an= >d if I should be sure to use multiprocessors.

I'm also considering t= >aking the time to try various historical versions=2C either releases or dat= >es in CVS.

 =3B- Jay


From: jay.kr= >ell at cornell.edu
To: mika at async.caltech.edu=3B rcolebur at scires.com
Dat= >e: 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 du= >al processor virtual machines.
Randy=2C has it failed many times for you= >?

 =3B- Jay

>=3B To: rcolebur at SCIRES.COM
>=3B Date= >: Sun=2C 27 Feb 2011 15:11:25 -0800
>=3B From: mika at async.caltech.edu<= >br>>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] result= >s of threadtest program on Windows7
>=3B
>=3B Ah=2C it just does= >n't check command-line arguments that carefully.
>=3B
>=3B I thi= >nk what you did is equivalent to "-tests STD".
>=3B
>=3B Mi= >ka
>=3B
>=3B "Coleburn=2C Randy" writes:
>=3B >=3BMika:r>>=3B >=3B
>=3B >=3BNo change with "-tests POSIX".
>=3B &g= >t=3B
>=3B >=3BInteresting twist: On Windows 7=2C I thought I'd see = >what the command line o=3D
>=3B >=3Bptions are=2C and I typed "threa= >dtest -help" rather than reading the code.
>=3B >=3B
>=3B >= >=3BFirst time=2C it produced what appears to be a NIL deref crash. Then=2C= > I trie=3D
>=3B >=3Bd it again and it ran to completion. Something = >seems non-deterministic her=3D
>=3B >=3Be. See below.
>=3B >= >=3B
>=3B >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>=3Bt= >hreadtest.exe -help
>=3B >=3BWriting file...done
>=3B >=3BCre= >ating read threads...done
>=3B >=3BCreating fork threads...done
&= >gt=3B >=3BCreating alloc threads...done
>=3B >=3BCreating lock thr= >eads...done
>=3B >=3Brunning...printing oldest/median age/newest
= >>=3B >=3B.
>=3B >=3B
>=3B >=3B***
>=3B >=3B*** run= >time error:
>=3B >=3B*** Attempt to reference an illegal memory l= >ocation.
>=3B >=3B*** pc =3D3D 0x77762262
>=3B >=3B***
= >>=3B >=3B
>=3B >=3BStack trace:
>=3B >=3B FP PC= > Procedure
>=3B >=3B--------- --------- ---------------------= >----------
>=3B >=3B 0xcdf998 0x130351b SystemError + 0x64 in ..\s= >rc\runtime\NT386\RTSignal.m=3D
>=3B >=3B3
>=3B >=3B 0xcdf9c0 = > 0x77762262 <=3B???>=3B
>=3B >=3B 0xcdf9d8 0x12e83b7 LockMute= >x + 0x4f in ..\src\thread\WIN32\ThreadWin32.m=3D
>=3B >=3B3
>= >=3B >=3B 0xcdfa00 0x12c7b08 GetChar + 0x28 in ..\src\rw\Rd.m3
>=3B= > >=3B 0xcdfb38 0x12c12e3 RApply + 0xd3 in ..\src\Main.m3
>=3B >= >=3B 0xcdfb74 0x12e971f ThreadBase + 0x254 in ..\src\thread\WIN32\ThreadWi= >n32=3D
>=3B >=3B.m3
>=3B >=3B 0xcdfb80 0x76543677 <=3B???= >>=3B
>=3B >=3B 0xcdfbc0 0x77779f02 <=3B???>=3B
>=3B >= >=3B......... ......... ... more frames ...
>=3B >=3B
>=3B >= >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>=3Bthreadtest.exe -he= >lp
>=3B >=3BWriting file...done
>=3B >=3BCreating read thread= >s...done
>=3B >=3BCreating fork threads...done
>=3B >=3BCreat= >ing alloc threads...done
>=3B >=3BCreating lock threads...done
&g= >t=3B >=3Brunning...printing oldest/median age/newest
>=3B >=3B....= >......laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=3D<= >br>>=3B >=3B lock 0/0/0)
>=3B >=3B..........laziest thread is 0/= >0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=3D
>=3B >=3B lock 0/0/= >0)
>=3B >=3B..........laziest thread is 0/0/0 (tests: read 0/0/0 for= >k 0/0/0 alloc 0/0/0=3D
>=3B >=3B lock 0/0/0)
>=3B >=3B.......= >...laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=3D
= >>=3B >=3B lock 0/0/0)
>=3B >=3B..........laziest thread is 0/0/0= > (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=3D
>=3B >=3B lock 0/0/0)<= >br>>=3B >=3B..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0= >/0/0 alloc 0/0/0=3D
>=3B >=3B lock 0/0/0)
>=3B >=3B..........= >laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=3D
>= >=3B >=3B lock 0/0/0)
>=3B >=3B..........laziest thread is 0/0/0 (t= ests: read 0/0/0 fork 0/0/0 alloc 0/0/0=3D
>=3B >=3B lock 0/0/0)
= >>=3B >=3B..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/= >0 alloc 0/0/0=3D
>=3B >=3B lock 0/0/0)
>=3B >=3B..........laz= >iest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0=3D
>=3B= > >=3B lock 0/0/0)
>=3B >=3BAll tests complete. Congratulations.r>>=3B >=3B
>=3B >=3BRegards=2C
>=3B >=3BRandy Coleburnr>>=3B >=3B
>=3B >=3B-----Original Message-----
>=3B >=3B= >From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
>=3B >=3BSen= >t: Sunday=2C February 27=2C 2011 3:30 PM
>=3B >=3BTo: Coleburn=2C Ra= >ndy
>=3B >=3BCc: m3devel at elegosoft.com
>=3B >=3BSubject: Re: = >[M3devel] results of threadtest program on Windows7=3D20
>=3B >=3Br>>=3B >=3BHi Randy=2C
>=3B >=3B
>=3B >=3BYou can try it = >with -tests POSIX as well.
>=3B >=3B
>=3B >=3BI find on user = >threads it runs very slowly (but it does run) because of how=3D
>=3B &= >gt=3B unfair
>=3B >=3Bthe thread scheduler is.
>=3B >=3B
&= >gt=3B >=3BNext step might be to whittle down the tests and see if you can= > get a failu=3D
>=3B >=3Bre with
>=3B >=3Ba single test runni= >ng and -n 2. That would likely be the simplest scenario=3D
>=3B >= >=3B to
>=3B >=3Bstart further debugging from.
>=3B >=3B
&g= >t=3B >=3B Mika
>=3B >=3B
>=3B >=3B"Coleburn=2C Randy" w= >rites:
>=3B >=3B>=3BMika et al:
>=3B >=3B>=3B
>=3B &= >gt=3B>=3BThought I would try something else.
>=3B >=3B>=3B
&g= >t=3B >=3B>=3BI took the sources of your thread test program to an older= > XP machine that=3D
>=3B >=3B =3D3D
>=3B >=3B>=3Bhas CM3 ci= >rca August 2008. This is the machine and implementation I used =3D
>= >=3B >=3Bw=3D3D
>=3B >=3B>=3Bhen building a major project I did a= > couple years back.
>=3B >=3B>=3B
>=3B >=3B>=3BThe thread= > test program does indeed build on this old system=2C but when I r=3D
&g= >t=3B >=3Bu=3D3D
>=3B >=3B>=3Bn it=2C I get different results tha= >n with the latest HEAD branch code. =3D3D20
>=3B >=3B>=3B
>= >=3B >=3B>=3BAfter it prints "running...printing oldest/median age/newes= >t"=2C on the next=3D
>=3B >=3B =3D3D
>=3B >=3B>=3Bline I ge= >t two periods ".." and now the program seems hung. I'll let it "=3D
>= >=3B >=3Br=3D3D
>=3B >=3B>=3Bun" for a few more minutes to see if= > anything else happens before killing =3D
>=3B >=3Bi=3D3D
>=3B = >>=3B>=3Bt.
>=3B >=3B>=3B
>=3B >=3B>=3BAt least we don= >'t get the subscript and assertion failures on this older C=3D
>=3B &g= >t=3BM=3D3D
>=3B >=3B>=3B3 platform.
>=3B >=3B>=3B
>= >=3B >=3B>=3BRegards=2C
>=3B >=3B>=3BRandy Coleburn
>=3B &= >gt=3B>=3B
>=3B >=3B>=3B
>=3B >=3B>=3B-----Original Mess= >age-----
>=3B >=3B>=3BFrom: Coleburn=2C Randy=3D3D20
>=3B >= >=3B>=3BSent: Sunday=2C February 27=2C 2011 2:09 PM
>=3B >=3B>=3B= >To: m3devel at elegosoft.com
>=3B >=3B>=3BSubject: Re: [M3devel] resu= >lts of threadtest program on Windows7
>=3B >=3B>=3B
>=3B >= >=3B>=3BMika:
>=3B >=3B>=3B
>=3B >=3B>=3BOk=2C I've upda= >ted to latest HEAD and I've also built Jay's m3sleep program.
>=3B >= >=3B>=3B
>=3B >=3B>=3BHere is what happens now when I run your th= >readtest program on Windows 7.
>=3B >=3B>=3B
>=3B >=3B>= >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>=3Bthreadtest -tests = >ALL=2C-fo=3D
>=3B >=3Br=3D3D
>=3B >=3B>=3Bk
>=3B >= >=3B>=3BWriting file...done
>=3B >=3B>=3BCreating read threads...= >done
>=3B >=3B>=3BCreating nxread threads...done
>=3B >=3B&= >gt=3BCreating tryexcept threads...done
>=3B >=3B>=3BCreating forkt= >oomuch threads...done
>=3B >=3B>=3BCreating alloc threads...doner>>=3B >=3B>=3BCreating creat threads...done
>=3B >=3B>=3BCr= >eating lock threads...done
>=3B >=3B>=3Brunning...printing oldest/= >median age/newest
>=3B >=3B>=3B
>=3B >=3B>=3B
>=3B &= >gt=3B>=3B***
>=3B >=3B>=3B*** runtime error:
>=3B >=3B>= >=3B*** An array subscript was out of range.
>=3B >=3B>=3B*** = > file "..\src\runtime\common\RTCollector.m3"=2C line 418
>=3B >=3B&g= >t=3B***
>=3B >=3B>=3B
>=3B >=3B>=3B
>=3B >=3B>= >=3B
>=3B >=3B>=3B***
>=3B >=3B>=3B*** runtime error:
&= >gt=3B >=3B>=3B*** <=3B*ASSERT*>=3B failed.
>=3B >=3B>= >=3B*** file "..\src\thread\WIN32\ThreadWin32.m3"=2C line 841
>=3B &= >gt=3B>=3B***
>=3B >=3B>=3B
>=3B >=3B>=3BThe last error = >repeats ad infinitum until I press CNTRL-C to abort.
>=3B >=3B>=3B= >
>=3B >=3B>=3BI'll send more info on the Windows install of Modula= >3 in a subsequent post=3D
>=3B >=3B.
>=3B >=3B>=3B
>= >=3B >=3B>=3BRegards=2C
>=3B >=3B>=3BRandy Coleburn
>=3B &= >gt=3B>=3B
>=3B >=3B>=3B-----Original Message-----
>=3B >= >=3B>=3BFrom: Mika Nystrom [mailto:mika at async.caltech.edu]=3D3D20
>= >=3B >=3B>=3BSent: Saturday=2C February 26=2C 2011 12:55 PM
>=3B &g= >t=3B>=3BTo: Coleburn=2C Randy
>=3B >=3B>=3BCc: m3devel at elegosoft= >.com
>=3B >=3B>=3BSubject: Re: [M3devel] results of threadtest pro= >gram on Windows7=3D3D20
>=3B >=3B>=3B
>=3B >=3B>=3BHi Ran= >dy=2C
>=3B >=3B>=3B
>=3B >=3B>=3BHm yes it looks like my = >Windows programming skills leave something
>=3B >=3B>=3Bto be desi= >red.
>=3B >=3B>=3B
>=3B >=3B>=3BYou can run the thread te= >ster while skipping a test as follows
>=3B >=3B>=3B
>=3B >= >=3B>=3B threadtest -tests ALL=2C-fork
>=3B >=3B>=3B
>=3B = >>=3B>=3B(for instance)
>=3B >=3B>=3B
>=3B >=3B>=3Bif = >you just run=3D3D20
>=3B >=3B>=3B
>=3B >=3B>=3B threadt= >est -sadfassdaf
>=3B >=3B>=3B
>=3B >=3B>=3Bit'll print th= >e tests that are available.
>=3B >=3B>=3B
>=3B >=3B>=3BAs= > it happens=2C I just had to upgrade my windows 2000 system to windows 7.r>>=3B >=3B>=3BCan you give me a very brief description of what you d= >id to install Modula=3D
>=3B >=3B-=3D3D
>=3B >=3B>=3B3
&= >gt=3B >=3B>=3Bon this system?
>=3B >=3B>=3B
>=3B >=3B&g= >t=3B Mika
>=3B >=3B>=3B
>=3B >=3B>=3B"Coleburn=2C Ran= >dy" writes:
>=3B >=3B>=3B>=3B--_000_D67F02DDC62F7545A6B84C285F88= >F3E6EE25C849atlex02srv_
>=3B >=3B>=3B>=3BContent-Type: text/plai= >n=3B charset=3D3D3D"us-ascii"
>=3B >=3B>=3B>=3BContent-Transfer-= >Encoding: quoted-printable
>=3B >=3B>=3B>=3B
>=3B >=3B>= >=3B>=3BMika:
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B>=3BI'v= >e finally managed to get cm3 rebuilt on Windows 7 again.
>=3B >=3B&g= >t=3B>=3B
>=3B >=3B>=3B>=3BSo=2C I ran your threadtest program.= >
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B>=3BHere are the resu= >lts. Note the "..." is where I cut out a bunch of the r=3D
>=3B >= >=3Be=3D3D
>=3B >=3B>=3Bp=3D3D3D
>=3B >=3B>=3B>=3Beating= > "ERROR FApply" messages.
>=3B >=3B>=3B>=3B
>=3B >=3B>= >=3B>=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>=3Bthreadtest.e= >xe
>=3B >=3B>=3B>=3BWriting file...done
>=3B >=3B>=3B&g= >t=3BCreating read threads...done
>=3B >=3B>=3B>=3BCreating fork = >threads...done
>=3B >=3B>=3B>=3BCreating alloc threads...done>>=3B >=3B>=3B>=3BCreating lock threads...done
>=3B >=3B>= >=3B>=3Brunning...printing oldest/median age/newest
>=3B >=3B>=3B= >>=3BERROR FApply: OSError.E: ErrorCode=3D3D3D3D2: The system cannot find= > the f=3D
>=3B >=3Bile=3D3D
>=3B >=3B>=3B sp=3D3D3D
>= >=3B >=3B>=3B>=3Becified.
>=3B >=3B>=3B>=3BERROR FApply: OS= >Error.E: ErrorCode=3D3D3D3D2: The system cannot find the f=3D
>=3B &g= >t=3Bile=3D3D
>=3B >=3B>=3B sp=3D3D3D
>=3B >=3B>=3B>=3Be= >cified.
>=3B >=3B>=3B>=3BERROR FApply: OSError.E: ErrorCode=3D3= >D3D3D2: The system cannot find the f=3D
>=3B >=3Bile=3D3D
>=3B = >>=3B>=3B sp=3D3D3D
>=3B >=3B>=3B>=3Becified.
>=3B >= >=3B>=3B>=3B.
>=3B >=3B>=3B>=3B.
>=3B >=3B>=3B>=3B= >.
>=3B >=3B>=3B>=3B***
>=3B >=3B>=3B>=3B*** runtime e= >rror:
>=3B >=3B>=3B>=3B*** An enumeration or subrange value w= >as out of range.
>=3B >=3B>=3B>=3B*** file "..\src\Main.m3"= >=2C line 340
>=3B >=3B>=3B>=3B***
>=3B >=3B>=3B>=3Br>>=3B >=3B>=3B>=3Blaziest thread is 0/0/ERROR FApply: OSError.E: = >ErrorCode=3D3D3D3D2: The sy=3D
>=3B >=3Bste=3D3D
>=3B >=3B>= >=3Bm c=3D3D3D
>=3B >=3B>=3B>=3Bannot find the file specified.>>=3B >=3B>=3B>=3BERROR FApply: OSError.E: ErrorCode=3D3D3D3D2: Th= >e system cannot find the f=3D
>=3B >=3Bile=3D3D
>=3B >=3B>= >=3B sp=3D3D3D
>=3B >=3B>=3B>=3Becified.
>=3B >=3B>=3B&g= >t=3BERROR FApply: OSError.E: ErrorCode=3D3D3D3D2: The system cannot find t= >he f=3D
>=3B >=3Bile=3D3D
>=3B >=3B>=3B sp=3D3D3D
>=3B= > >=3B>=3B>=3Becified.
>=3B >=3B>=3B>=3BERROR FApply: OSErr= >or.E: ErrorCode=3D3D3D3D2: The system cannot find the f=3D
>=3B >= >=3Bile=3D3D
>=3B >=3B>=3B sp=3D3D3D
>=3B >=3B>=3B>=3Bec= >ified.
>=3B >=3B>=3B>=3B.
>=3B >=3B>=3B>=3B.
>= >=3B >=3B>=3B>=3B.
>=3B >=3B>=3B>=3Blaziest thread is 0/0/E= >RROR FApply: OSError.E: ErrorCode=3D3D3D3D2: The sy=3D
>=3B >=3Bste= >=3D3D
>=3B >=3B>=3Bm c=3D3D3D
>=3B >=3B>=3B>=3Bannot fi= >nd the file specified.
>=3B >=3B>=3B>=3BERROR FApply: OSError.E:= > ErrorCode=3D3D3D3D2: The system cannot find the f=3D
>=3B >=3Bile= >=3D3D
>=3B >=3B>=3B sp=3D3D3D
>=3B >=3B>=3B>=3Becified.= >
>=3B >=3B>=3B>=3BERROR FApply: OSError.E: ErrorCode=3D3D3D3D2:= > The system cannot find the f=3D
>=3B >=3Bile=3D3D
>=3B >=3B&= >gt=3B sp=3D3D3D
>=3B >=3B>=3B>=3Becified.
>=3B >=3B>=3B= >>=3BERROR FApply: OSError.E: ErrorCode=3D3D3D3D2: The system cannot find= > the f=3D
>=3B >=3Bile=3D3D
>=3B >=3B>=3B sp=3D3D3D
>= >=3B >=3B>=3B>=3Becified.
>=3B >=3B>=3B>=3B.
>=3B >= >=3B>=3B>=3B.
>=3B >=3B>=3B>=3B.
>=3B >=3B>=3B>=3B= >ERROR FApply: OSError.E: ErrorCode=3D3D3D3D2: The system cannot find the f= >=3D
>=3B >=3Bile=3D3D
>=3B >=3B>=3B sp=3D3D3D
>=3B >= >=3B>=3B>=3Becified.
>=3B >=3B>=3B>=3BERROR FApply: OSError.E= >: ErrorCode=3D3D3D3D2: The system cannot find the f=3D
>=3B >=3Bile= >=3D3D
>=3B >=3B>=3B sp=3D3D3D
>=3B >=3B>=3B>=3Becified.= >
>=3B >=3B>=3B>=3BStack trace:
>=3B >=3B>=3B>=3B FP= > PC Procedure
>=3B >=3B>=3B>=3B--------- ---------= > -------------------------------
>=3B >=3B>=3B>=3B0x30fbd0 0x1= >27218a PutStats + 0x1a3 in ..\src\Main.m3
>=3B >=3B>=3B>=3B0x30= >fcc0 0x1273825 Main_M3 + 0x11db(!) in ..\src\Main.m3
>=3B >=3B>= >=3B>=3B
>=3B >=3B>=3B>=3BRegards=2C
>=3B >=3B>=3B>= >=3BRandy Coleburn
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B>=3B= >--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
>=3B >=3B= >>=3B>=3BContent-Type: text/html=3B charset=3D3D3D"us-ascii"
>=3B &= >gt=3B>=3B>=3BContent-Transfer-Encoding: quoted-printable
>=3B >= >=3B>=3B>=3B
>= > >--_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 escribi?: > De: Mika Nystrom > Asunto: Re: [M3devel] results of threadtest program on Windows7 > Para: "Jay K" > 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 > > > > > > > > > > > > > >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
Writing > file...done
Creating read threads...= > >done
Creating fork > threads...done
Creating alloc > threads...done
Cr= > >eating lock threads...done
running...printing > oldest/median age/newest >r>.

Are we guranteed forward > progress in suspending all threads?
= > >
I do see it fail usually on Darwin. > e.g.:
........pthread_mutex_dest= > >roy:EBUSY
pthread_mutex_destroy:EBUSY
..laziest > thread is 0/0/0 (test= > >s: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock > 0/0/0)
...

***
*** r= > >untime > error:
*** =3B =3B =3B An > array subscript was out of = > >range.
*** =3B =3B =3B > file "../src/runtime/common/RTCollect= > >or.m3"=2C line 418
***

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

Mika are your machin= > >es all multiprocessors?
I do wonder if that > helps increase the stress an= > >d if I should be sure to use > multiprocessors.

I'm also considering t= > >aking the time to try various historical versions=2C > either releases or dat= > >es in CVS.

 =3B- > Jay


From: > jay.kr= > >ell at cornell.edu
To: > mika at async.caltech.edu=3B > rcolebur at scires.com
Dat= > >e: Tue=2C 1 Mar 2011 10:59:29 +0000
CC: m3devel at elegosoft.com
Subject= > >: Re: [M3devel] results of threadtest program on > Windows7

> > > > content=3D"text/html=3B charset=3Dunicode= > >"> > > SafeHTML"> > > > > > > > >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 du= > >al processor virtual machines.
Randy=2C has it > failed many times for you= > >?

 =3B- > Jay

>=3B To: rcolebur at SCIRES.COM
>=3B > Date= > >: Sun=2C 27 Feb 2011 15:11:25 -0800
>=3B > From: mika at async.caltech.edu<= > >br>>=3B CC: m3devel at elegosoft.com
>=3B > Subject: Re: [M3devel] result= > >s of threadtest program on Windows7
>=3B >
>=3B Ah=2C it just does= > >n't check command-line arguments that > carefully.
>=3B
>=3B I thi= > >nk what you did is equivalent to "-tests > STD".
>=3B
>=3B > Mi= > >ka
>=3B
>=3B > "Coleburn=2C Randy" writes:
>=3B > >=3BMika: >r>>=3B >=3B
>=3B > >=3BNo change with "-tests POSIX".
>=3B > &g= > >t=3B
>=3B >=3BInteresting > twist: On Windows 7=2C I thought I'd see = > >what the command line o=3D
>=3B > >=3Bptions are=2C and I typed "threa= > >dtest -help" rather than reading the > code.
>=3B >=3B
>=3B > >= > >=3BFirst time=2C it produced what appears to be a NIL > deref crash. Then=2C= > > I trie=3D
>=3B >=3Bd it again and > it ran to completion. Something = > >seems non-deterministic her=3D
>=3B > >=3Be. See below.
>=3B >= > >=3B
>=3B > >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>=3Bt= > >hreadtest.exe -help
>=3B > >=3BWriting file...done
>=3B > >=3BCre= > >ating read threads...done
>=3B > >=3BCreating fork threads...done
&= > >gt=3B >=3BCreating alloc > threads...done
>=3B >=3BCreating lock > thr= > >eads...done
>=3B > >=3Brunning...printing oldest/median > age/newest
= > >>=3B >=3B.
>=3B > >=3B
>=3B > >=3B***
>=3B >=3B*** run= > >time error:
>=3B >=3B*** > Attempt to reference an illegal memory l= > >ocation.
>=3B >=3B*** > pc =3D3D 0x77762262
>=3B > >=3B***
= > >>=3B >=3B
>=3B > >=3BStack trace:
>=3B > >=3B FP > PC= > > Procedure
>=3B > >=3B--------- --------- > ---------------------= > >----------
>=3B >=3B > 0xcdf998 0x130351b SystemError + 0x64 in ..\s= > >rc\runtime\NT386\RTSignal.m=3D
>=3B > >=3B3
>=3B >=3B 0xcdf9c0 = > > 0x77762262 > <=3B???>=3B
>=3B >=3B > 0xcdf9d8 0x12e83b7 LockMute= > >x + 0x4f in > ..\src\thread\WIN32\ThreadWin32.m=3D
>=3B > >=3B3
>= > >=3B >=3B 0xcdfa00 0x12c7b08 GetChar + > 0x28 in ..\src\rw\Rd.m3
>=3B= > > >=3B 0xcdfb38 0x12c12e3 RApply + > 0xd3 in ..\src\Main.m3
>=3B >= > >=3B 0xcdfb74 0x12e971f ThreadBase + 0x254 > in ..\src\thread\WIN32\ThreadWi= > >n32=3D
>=3B > >=3B.m3
>=3B >=3B 0xcdfb80 > 0x76543677 <=3B???= > >>=3B
>=3B >=3B > 0xcdfbc0 0x77779f02 > <=3B???>=3B
>=3B >= > >=3B......... ......... ... more frames > ...
>=3B >=3B
>=3B > >= > >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>=3Bthreadtest.exe > -he= > >lp
>=3B >=3BWriting > file...done
>=3B >=3BCreating read > thread= > >s...done
>=3B >=3BCreating fork > threads...done
>=3B >=3BCreat= > >ing alloc threads...done
>=3B > >=3BCreating lock threads...done
&g= > >t=3B >=3Brunning...printing oldest/median > age/newest
>=3B >=3B....= > >......laziest thread is 0/0/0 (tests: read 0/0/0 fork > 0/0/0 alloc 0/0/0=3D<= > >br>>=3B >=3B lock > 0/0/0)
>=3B >=3B..........laziest > thread is 0/= > >0/0 (tests: read 0/0/0 fork 0/0/0 alloc > 0/0/0=3D
>=3B >=3B lock 0/0/= > >0)
>=3B >=3B..........laziest > thread is 0/0/0 (tests: read 0/0/0 for= > >k 0/0/0 alloc 0/0/0=3D
>=3B >=3B > lock 0/0/0)
>=3B >=3B.......= > >...laziest thread is 0/0/0 (tests: read 0/0/0 fork > 0/0/0 alloc 0/0/0=3D
= > >>=3B >=3B lock 0/0/0)
>=3B > >=3B..........laziest thread is 0/0/0= > > (tests: read 0/0/0 fork 0/0/0 alloc > 0/0/0=3D
>=3B >=3B lock 0/0/0)<= > >br>>=3B >=3B..........laziest thread is > 0/0/0 (tests: read 0/0/0 fork 0= > >/0/0 alloc 0/0/0=3D
>=3B >=3B lock > 0/0/0)
>=3B >=3B..........= > >laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 > alloc 0/0/0=3D
>= > >=3B >=3B lock 0/0/0)
>=3B > >=3B..........laziest thread is 0/0/0 (t= > ests: read 0/0/0 fork 0/0/0 alloc > 0/0/0=3D
>=3B >=3B lock > 0/0/0)
= > >>=3B >=3B..........laziest thread is 0/0/0 > (tests: read 0/0/0 fork 0/0/= > >0 alloc 0/0/0=3D
>=3B >=3B lock > 0/0/0)
>=3B >=3B..........laz= > >iest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 > alloc 0/0/0=3D
>=3B= > > >=3B lock 0/0/0)
>=3B > >=3BAll tests complete. Congratulations. >r>>=3B >=3B
>=3B > >=3BRegards=2C
>=3B >=3BRandy > Coleburn >r>>=3B >=3B
>=3B > >=3B-----Original Message-----
>=3B > >=3B= > >From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
>=3B > >=3BSen= > >t: Sunday=2C February 27=2C 2011 3:30 > PM
>=3B >=3BTo: Coleburn=2C Ra= > >ndy
>=3B >=3BCc: m3devel at elegosoft.com
>=3B > >=3BSubject: Re: = > >[M3devel] results of threadtest program on > Windows7=3D20
>=3B >=3B >r>>=3B >=3BHi > Randy=2C
>=3B >=3B
>=3B > >=3BYou can try it = > >with -tests POSIX as well.
>=3B > >=3B
>=3B >=3BI find on user = > >threads it runs very slowly (but it does run) because > of how=3D
>=3B &= > >gt=3B unfair
>=3B >=3Bthe thread > scheduler is.
>=3B > >=3B
&= > >gt=3B >=3BNext step might be to whittle down the > tests and see if you can= > > get a failu=3D
>=3B >=3Bre > with
>=3B >=3Ba single test runni= > >ng and -n 2. That would likely be the simplest > scenario=3D
>=3B >= > >=3B to
>=3B >=3Bstart further > debugging from.
>=3B > >=3B
&g= > >t=3B >=3B > Mika
>=3B > >=3B
>=3B >=3B"Coleburn=2C Randy" > w= > >rites:
>=3B >=3B>=3BMika et > al:
>=3B > >=3B>=3B
>=3B &= > >gt=3B>=3BThought I would try something > else.
>=3B > >=3B>=3B
&g= > >t=3B >=3B>=3BI took the sources of your > thread test program to an older= > > XP machine that=3D
>=3B >=3B > =3D3D
>=3B >=3B>=3Bhas CM3 ci= > >rca August 2008. This is the machine and > implementation I used =3D
>= > >=3B >=3Bw=3D3D
>=3B > >=3B>=3Bhen building a major project I did a= > > couple years back.
>=3B > >=3B>=3B
>=3B > >=3B>=3BThe thread= > > test program does indeed build on this old system=2C > but when I r=3D
&g= > >t=3B >=3Bu=3D3D
>=3B > >=3B>=3Bn it=2C I get different results tha= > >n with the latest HEAD branch code. > =3D3D20
>=3B > >=3B>=3B
>= > >=3B >=3B>=3BAfter it prints > "running...printing oldest/median age/newes= > >t"=2C on the next=3D
>=3B >=3B > =3D3D
>=3B >=3B>=3Bline I ge= > >t two periods ".." and now the program seems > hung. I'll let it "=3D
>= > >=3B >=3Br=3D3D
>=3B > >=3B>=3Bun" for a few more minutes to see if= > > anything else happens before killing > =3D
>=3B >=3Bi=3D3D
>=3B > = > >>=3B>=3Bt.
>=3B > >=3B>=3B
>=3B > >=3B>=3BAt least we don= > >'t get the subscript and assertion failures on this > older C=3D
>=3B &g= > >t=3BM=3D3D
>=3B >=3B>=3B3 > platform.
>=3B > >=3B>=3B
>= > >=3B >=3B>=3BRegards=2C
>=3B > >=3B>=3BRandy Coleburn
>=3B > &= > >gt=3B>=3B
>=3B > >=3B>=3B
>=3B > >=3B>=3B-----Original Mess= > >age-----
>=3B >=3B>=3BFrom: > Coleburn=2C Randy=3D3D20
>=3B >= > >=3B>=3BSent: Sunday=2C February 27=2C 2011 2:09 > PM
>=3B >=3B>=3B= > >To: m3devel at elegosoft.com
>=3B > >=3B>=3BSubject: Re: [M3devel] resu= > >lts of threadtest program on > Windows7
>=3B > >=3B>=3B
>=3B >= > >=3B>=3BMika:
>=3B > >=3B>=3B
>=3B > >=3B>=3BOk=2C I've upda= > >ted to latest HEAD and I've also built Jay's m3sleep > program.
>=3B >= > >=3B>=3B
>=3B > >=3B>=3BHere is what happens now when I run your > th= > >readtest program on Windows 7.
>=3B > >=3B>=3B
>=3B >=3B>= > >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>=3Bthreadtest > -tests = > >ALL=2C-fo=3D
>=3B > >=3Br=3D3D
>=3B > >=3B>=3Bk
>=3B >= > >=3B>=3BWriting file...done
>=3B > >=3B>=3BCreating read threads...= > >done
>=3B >=3B>=3BCreating > nxread threads...done
>=3B >=3B&= > >gt=3BCreating tryexcept > threads...done
>=3B > >=3B>=3BCreating forkt= > >oomuch threads...done
>=3B > >=3B>=3BCreating alloc threads...done >r>>=3B >=3B>=3BCreating creat > threads...done
>=3B >=3B>=3BCr= > >eating lock threads...done
>=3B > >=3B>=3Brunning...printing oldest/= > >median age/newest
>=3B > >=3B>=3B
>=3B > >=3B>=3B
>=3B &= > >gt=3B>=3B***
>=3B > >=3B>=3B*** runtime error:
>=3B > >=3B>= > >=3B*** An array subscript was out of > range.
>=3B > >=3B>=3B*** = > > file "..\src\runtime\common\RTCollector.m3"=2C line > 418
>=3B >=3B&g= > >t=3B***
>=3B > >=3B>=3B
>=3B > >=3B>=3B
>=3B >=3B>= > >=3B
>=3B > >=3B>=3B***
>=3B > >=3B>=3B*** runtime error:
&= > >gt=3B >=3B>=3B*** > <=3B*ASSERT*>=3B failed.
>=3B > >=3B>= > >=3B*** file > "..\src\thread\WIN32\ThreadWin32.m3"=2C line > 841
>=3B &= > >gt=3B>=3B***
>=3B > >=3B>=3B
>=3B > >=3B>=3BThe last error = > >repeats ad infinitum until I press CNTRL-C to > abort.
>=3B >=3B>=3B= > >
>=3B >=3B>=3BI'll send more > info on the Windows install of Modula= > >3 in a subsequent post=3D
>=3B > >=3B.
>=3B > >=3B>=3B
>= > >=3B >=3B>=3BRegards=2C
>=3B > >=3B>=3BRandy Coleburn
>=3B > &= > >gt=3B>=3B
>=3B > >=3B>=3B-----Original > Message-----
>=3B >= > >=3B>=3BFrom: Mika Nystrom [mailto:mika at async.caltech.edu]=3D3D20
>= > >=3B >=3B>=3BSent: Saturday=2C February > 26=2C 2011 12:55 PM
>=3B &g= > >t=3B>=3BTo: Coleburn=2C Randy
>=3B > >=3B>=3BCc: m3devel at elegosoft= > >.com
>=3B >=3B>=3BSubject: > Re: [M3devel] results of threadtest pro= > >gram on Windows7=3D3D20
>=3B > >=3B>=3B
>=3B > >=3B>=3BHi Ran= > >dy=2C
>=3B > >=3B>=3B
>=3B > >=3B>=3BHm yes it looks like my = > >Windows programming skills leave > something
>=3B >=3B>=3Bto be > desi= > >red.
>=3B > >=3B>=3B
>=3B > >=3B>=3BYou can run the thread te= > >ster while skipping a test as > follows
>=3B > >=3B>=3B
>=3B >= > >=3B>=3B threadtest -tests > ALL=2C-fork
>=3B > >=3B>=3B
>=3B = > >>=3B>=3B(for instance)
>=3B > >=3B>=3B
>=3B > >=3B>=3Bif = > >you just run=3D3D20
>=3B > >=3B>=3B
>=3B > >=3B>=3B threadt= > >est -sadfassdaf
>=3B > >=3B>=3B
>=3B > >=3B>=3Bit'll print th= > >e tests that are available.
>=3B > >=3B>=3B
>=3B > >=3B>=3BAs= > > it happens=2C I just had to upgrade my windows 2000 > system to windows 7. >r>>=3B >=3B>=3BCan you give me a > very brief description of what you d= > >id to install Modula=3D
>=3B > >=3B-=3D3D
>=3B > >=3B>=3B3
&= > >gt=3B >=3B>=3Bon this > system?
>=3B > >=3B>=3B
>=3B >=3B&g= > >t=3B Mika
>=3B > >=3B>=3B
>=3B > >=3B>=3B"Coleburn=2C Ran= > >dy" writes:
>=3B > >=3B>=3B>=3B--_000_D67F02DDC62F7545A6B84C285F88= > >F3E6EE25C849atlex02srv_
>=3B > >=3B>=3B>=3BContent-Type: text/plai= > >n=3B charset=3D3D3D"us-ascii"
>=3B > >=3B>=3B>=3BContent-Transfer-= > >Encoding: quoted-printable
>=3B > >=3B>=3B>=3B
>=3B > >=3B>= > >=3B>=3BMika:
>=3B > >=3B>=3B>=3B
>=3B > >=3B>=3B>=3BI'v= > >e finally managed to get cm3 rebuilt on Windows 7 > again.
>=3B >=3B&g= > >t=3B>=3B
>=3B > >=3B>=3B>=3BSo=2C I ran your threadtest > program.= > >
>=3B > >=3B>=3B>=3B
>=3B > >=3B>=3B>=3BHere are the resu= > >lts. Note the "..." is where I cut out a bunch of > the r=3D
>=3B >= > >=3Be=3D3D
>=3B > >=3B>=3Bp=3D3D3D
>=3B > >=3B>=3B>=3Beating= > > "ERROR FApply" messages.
>=3B > >=3B>=3B>=3B
>=3B > >=3B>= > >=3B>=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>=3Bthreadtest.e= > >xe
>=3B > >=3B>=3B>=3BWriting > file...done
>=3B >=3B>=3B&g= > >t=3BCreating read threads...done
>=3B > >=3B>=3B>=3BCreating fork = > >threads...done
>=3B > >=3B>=3B>=3BCreating alloc > threads...done >>>=3B >=3B>=3B>=3BCreating > lock threads...done
>=3B >=3B>= > >=3B>=3Brunning...printing oldest/median > age/newest
>=3B >=3B>=3B= > >>=3BERROR FApply: OSError.E: > ErrorCode=3D3D3D3D2: The system cannot find= > > the f=3D
>=3B > >=3Bile=3D3D
>=3B >=3B>=3B > sp=3D3D3D
>= > >=3B > >=3B>=3B>=3Becified.
>=3B > >=3B>=3B>=3BERROR FApply: OS= > >Error.E: ErrorCode=3D3D3D3D2: The system cannot > find the f=3D
>=3B &g= > >t=3Bile=3D3D
>=3B >=3B>=3B > sp=3D3D3D
>=3B > >=3B>=3B>=3Be= > >cified.
>=3B > >=3B>=3B>=3BERROR FApply: OSError.E: > ErrorCode=3D3= > >D3D3D2: The system cannot find the > f=3D
>=3B > >=3Bile=3D3D
>=3B = > >>=3B>=3B sp=3D3D3D
>=3B > >=3B>=3B>=3Becified.
>=3B > >= > >=3B>=3B>=3B.
>=3B > >=3B>=3B>=3B.
>=3B > >=3B>=3B>=3B= > >.
>=3B > >=3B>=3B>=3B***
>=3B > >=3B>=3B>=3B*** runtime e= > >rror:
>=3B > >=3B>=3B>=3B*** An > enumeration or subrange value w= > >as out of range.
>=3B > >=3B>=3B>=3B*** file > "..\src\Main.m3"= > >=2C line 340
>=3B > >=3B>=3B>=3B***
>=3B > >=3B>=3B>=3B >r>>=3B >=3B>=3B>=3Blaziest > thread is 0/0/ERROR FApply: OSError.E: = > >ErrorCode=3D3D3D3D2: The sy=3D
>=3B > >=3Bste=3D3D
>=3B >=3B>= > >=3Bm c=3D3D3D
>=3B > >=3B>=3B>=3Bannot find the file > specified. >>>=3B >=3B>=3B>=3BERROR > FApply: OSError.E: ErrorCode=3D3D3D3D2: Th= > >e system cannot find the f=3D
>=3B > >=3Bile=3D3D
>=3B >=3B>= > >=3B sp=3D3D3D
>=3B > >=3B>=3B>=3Becified.
>=3B > >=3B>=3B&g= > >t=3BERROR FApply: OSError.E: ErrorCode=3D3D3D3D2: > The system cannot find t= > >he f=3D
>=3B > >=3Bile=3D3D
>=3B >=3B>=3B > sp=3D3D3D
>=3B= > > > >=3B>=3B>=3Becified.
>=3B > >=3B>=3B>=3BERROR FApply: OSErr= > >or.E: ErrorCode=3D3D3D3D2: The system cannot find > the f=3D
>=3B >= > >=3Bile=3D3D
>=3B >=3B>=3B > sp=3D3D3D
>=3B > >=3B>=3B>=3Bec= > >ified.
>=3B > >=3B>=3B>=3B.
>=3B > >=3B>=3B>=3B.
>= > >=3B >=3B>=3B>=3B.
>=3B > >=3B>=3B>=3Blaziest thread is 0/0/E= > >RROR FApply: OSError.E: ErrorCode=3D3D3D3D2: The > sy=3D
>=3B >=3Bste= > >=3D3D
>=3B >=3B>=3Bm > c=3D3D3D
>=3B > >=3B>=3B>=3Bannot fi= > >nd the file specified.
>=3B > >=3B>=3B>=3BERROR FApply: OSError.E:= > > ErrorCode=3D3D3D3D2: The system cannot find the > f=3D
>=3B >=3Bile= > >=3D3D
>=3B >=3B>=3B > sp=3D3D3D
>=3B > >=3B>=3B>=3Becified.= > >
>=3B > >=3B>=3B>=3BERROR FApply: OSError.E: > ErrorCode=3D3D3D3D2:= > > The system cannot find the f=3D
>=3B > >=3Bile=3D3D
>=3B >=3B&= > >gt=3B sp=3D3D3D
>=3B > >=3B>=3B>=3Becified.
>=3B > >=3B>=3B= > >>=3BERROR FApply: OSError.E: > ErrorCode=3D3D3D3D2: The system cannot find= > > the f=3D
>=3B > >=3Bile=3D3D
>=3B >=3B>=3B > sp=3D3D3D
>= > >=3B > >=3B>=3B>=3Becified.
>=3B > >=3B>=3B>=3B.
>=3B > >= > >=3B>=3B>=3B.
>=3B > >=3B>=3B>=3B.
>=3B > >=3B>=3B>=3B= > >ERROR FApply: OSError.E: ErrorCode=3D3D3D3D2: The > system cannot find the f= > >=3D
>=3B > >=3Bile=3D3D
>=3B >=3B>=3B > sp=3D3D3D
>=3B >= > >=3B>=3B>=3Becified.
>=3B > >=3B>=3B>=3BERROR FApply: OSError.E= > >: ErrorCode=3D3D3D3D2: The system cannot find the > f=3D
>=3B >=3Bile= > >=3D3D
>=3B >=3B>=3B > sp=3D3D3D
>=3B > >=3B>=3B>=3Becified.= > >
>=3B > >=3B>=3B>=3BStack > trace:
>=3B > >=3B>=3B>=3B FP= > > PC > Procedure
>=3B > >=3B>=3B>=3B--------- ---------= > > > -------------------------------
>=3B > >=3B>=3B>=3B0x30fbd0 0x1= > >27218a PutStats + 0x1a3 in > ..\src\Main.m3
>=3B > >=3B>=3B>=3B0x30= > >fcc0 0x1273825 Main_M3 + 0x11db(!) in > ..\src\Main.m3
>=3B >=3B>= > >=3B>=3B
>=3B > >=3B>=3B>=3BRegards=2C
>=3B > >=3B>=3B>= > >=3BRandy Coleburn
>=3B > >=3B>=3B>=3B
>=3B > >=3B>=3B>=3B= > >--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
>=3B > >=3B= > >>=3B>=3BContent-Type: text/html=3B > charset=3D3D3D"us-ascii"
>=3B &= > >gt=3B>=3B>=3BContent-Transfer-Encoding: > quoted-printable
>=3B >= > >=3B>=3B>=3B
> > > > >= > > > >--_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: 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 escribi?: > > > De: Mika Nystrom > > Asunto: Re: [M3devel] results of threadtest program on Windows7 > > Para: "Jay K" > > 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 > > > > > > > > > > > > > > > > > > > > >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
Writing > > file...done
Creating read threads...= > > >done
Creating fork > > threads...done
Creating alloc > > threads...done
Cr= > > >eating lock threads...done
running...printing > > oldest/median age/newest > >r>.

Are we guranteed forward > > progress in suspending all threads?
= > > >
I do see it fail usually on Darwin. > > e.g.:
........pthread_mutex_dest= > > >roy:EBUSY
pthread_mutex_destroy:EBUSY
..laziest > > thread is 0/0/0 (test= > > >s: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock > > 0/0/0)
...

***
*** r= > > >untime > > error:
*** =3B =3B =3B An > > array subscript was out of = > > >range.
*** =3B =3B =3B > > file "../src/runtime/common/RTCollect= > > >or.m3"=2C line 418
***

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

Mika are your machin= > > >es all multiprocessors?
I do wonder if that > > helps increase the stress an= > > >d if I should be sure to use > > multiprocessors.

I'm also considering t= > > >aking the time to try various historical versions=2C > > either releases or dat= > > >es in CVS.

 =3B- > > Jay


From: > > jay.kr= > > >ell at cornell.edu
To: > > mika at async.caltech.edu=3B > > rcolebur at scires.com
Dat= > > >e: Tue=2C 1 Mar 2011 10:59:29 +0000
CC: m3devel at elegosoft.com
Subject= > > >: Re: [M3devel] results of threadtest program on > > Windows7

> > > > > > > content=3D"text/html=3B charset=3Dunicode= > > >"> > > > > SafeHTML"> > > > > > > > > > > > >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 du= > > >al processor virtual machines.
Randy=2C has it > > failed many times for you= > > >?

 =3B- > > Jay

>=3B To: rcolebur at SCIRES.COM
>=3B > > Date= > > >: Sun=2C 27 Feb 2011 15:11:25 -0800
>=3B > > From: mika at async.caltech.edu<= > > >br>>=3B CC: m3devel at elegosoft.com
>=3B > > Subject: Re: [M3devel] result= > > >s of threadtest program on Windows7
>=3B > >
>=3B Ah=2C it just does= > > >n't check command-line arguments that > > carefully.
>=3B
>=3B I thi= > > >nk what you did is equivalent to "-tests > > STD".
>=3B
>=3B > > Mi= > > >ka
>=3B
>=3B > > "Coleburn=2C Randy" writes:
>=3B > > >=3BMika: > >r>>=3B >=3B
>=3B > > >=3BNo change with "-tests POSIX".
>=3B > > &g= > > >t=3B
>=3B >=3BInteresting > > twist: On Windows 7=2C I thought I'd see = > > >what the command line o=3D
>=3B > > >=3Bptions are=2C and I typed "threa= > > >dtest -help" rather than reading the > > code.
>=3B >=3B
>=3B > > >= > > >=3BFirst time=2C it produced what appears to be a NIL > > deref crash. Then=2C= > > > I trie=3D
>=3B >=3Bd it again and > > it ran to completion. Something = > > >seems non-deterministic her=3D
>=3B > > >=3Be. See below.
>=3B >= > > >=3B
>=3B > > >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>=3Bt= > > >hreadtest.exe -help
>=3B > > >=3BWriting file...done
>=3B > > >=3BCre= > > >ating read threads...done
>=3B > > >=3BCreating fork threads...done
&= > > >gt=3B >=3BCreating alloc > > threads...done
>=3B >=3BCreating lock > > thr= > > >eads...done
>=3B > > >=3Brunning...printing oldest/median > > age/newest
= > > >>=3B >=3B.
>=3B > > >=3B
>=3B > > >=3B***
>=3B >=3B*** run= > > >time error:
>=3B >=3B*** > > Attempt to reference an illegal memory l= > > >ocation.
>=3B >=3B*** > > pc =3D3D 0x77762262
>=3B > > >=3B***
= > > >>=3B >=3B
>=3B > > >=3BStack trace:
>=3B > > >=3B FP > > PC= > > > Procedure
>=3B > > >=3B--------- --------- > > ---------------------= > > >----------
>=3B >=3B > > 0xcdf998 0x130351b SystemError + 0x64 in ..\s= > > >rc\runtime\NT386\RTSignal.m=3D
>=3B > > >=3B3
>=3B >=3B 0xcdf9c0 = > > > 0x77762262 > > <=3B???>=3B
>=3B >=3B > > 0xcdf9d8 0x12e83b7 LockMute= > > >x + 0x4f in > > ..\src\thread\WIN32\ThreadWin32.m=3D
>=3B > > >=3B3
>= > > >=3B >=3B 0xcdfa00 0x12c7b08 GetChar + > > 0x28 in ..\src\rw\Rd.m3
>=3B= > > > >=3B 0xcdfb38 0x12c12e3 RApply + > > 0xd3 in ..\src\Main.m3
>=3B >= > > >=3B 0xcdfb74 0x12e971f ThreadBase + 0x254 > > in ..\src\thread\WIN32\ThreadWi= > > >n32=3D
>=3B > > >=3B.m3
>=3B >=3B 0xcdfb80 > > 0x76543677 <=3B???= > > >>=3B
>=3B >=3B > > 0xcdfbc0 0x77779f02 > > <=3B???>=3B
>=3B >= > > >=3B......... ......... ... more frames > > ...
>=3B >=3B
>=3B > > >= > > >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>=3Bthreadtest.exe > > -he= > > >lp
>=3B >=3BWriting > > file...done
>=3B >=3BCreating read > > thread= > > >s...done
>=3B >=3BCreating fork > > threads...done
>=3B >=3BCreat= > > >ing alloc threads...done
>=3B > > >=3BCreating lock threads...done
&g= > > >t=3B >=3Brunning...printing oldest/median > > age/newest
>=3B >=3B....= > > >......laziest thread is 0/0/0 (tests: read 0/0/0 fork > > 0/0/0 alloc 0/0/0=3D<= > > >br>>=3B >=3B lock > > 0/0/0)
>=3B >=3B..........laziest > > thread is 0/= > > >0/0 (tests: read 0/0/0 fork 0/0/0 alloc > > 0/0/0=3D
>=3B >=3B lock 0/0/= > > >0)
>=3B >=3B..........laziest > > thread is 0/0/0 (tests: read 0/0/0 for= > > >k 0/0/0 alloc 0/0/0=3D
>=3B >=3B > > lock 0/0/0)
>=3B >=3B.......= > > >...laziest thread is 0/0/0 (tests: read 0/0/0 fork > > 0/0/0 alloc 0/0/0=3D
= > > >>=3B >=3B lock 0/0/0)
>=3B > > >=3B..........laziest thread is 0/0/0= > > > (tests: read 0/0/0 fork 0/0/0 alloc > > 0/0/0=3D
>=3B >=3B lock 0/0/0)<= > > >br>>=3B >=3B..........laziest thread is > > 0/0/0 (tests: read 0/0/0 fork 0= > > >/0/0 alloc 0/0/0=3D
>=3B >=3B lock > > 0/0/0)
>=3B >=3B..........= > > >laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 > > alloc 0/0/0=3D
>= > > >=3B >=3B lock 0/0/0)
>=3B > > >=3B..........laziest thread is 0/0/0 (t= > > ests: read 0/0/0 fork 0/0/0 alloc > > 0/0/0=3D
>=3B >=3B lock > > 0/0/0)
= > > >>=3B >=3B..........laziest thread is 0/0/0 > > (tests: read 0/0/0 fork 0/0/= > > >0 alloc 0/0/0=3D
>=3B >=3B lock > > 0/0/0)
>=3B >=3B..........laz= > > >iest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 > > alloc 0/0/0=3D
>=3B= > > > >=3B lock 0/0/0)
>=3B > > >=3BAll tests complete. Congratulations. > >r>>=3B >=3B
>=3B > > >=3BRegards=2C
>=3B >=3BRandy > > Coleburn > >r>>=3B >=3B
>=3B > > >=3B-----Original Message-----
>=3B > > >=3B= > > >From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
>=3B > > >=3BSen= > > >t: Sunday=2C February 27=2C 2011 3:30 > > PM
>=3B >=3BTo: Coleburn=2C Ra= > > >ndy
>=3B >=3BCc: m3devel at elegosoft.com
>=3B > > >=3BSubject: Re: = > > >[M3devel] results of threadtest program on > > Windows7=3D20
>=3B >=3B > >r>>=3B >=3BHi > > Randy=2C
>=3B >=3B
>=3B > > >=3BYou can try it = > > >with -tests POSIX as well.
>=3B > > >=3B
>=3B >=3BI find on user = > > >threads it runs very slowly (but it does run) because > > of how=3D
>=3B &= > > >gt=3B unfair
>=3B >=3Bthe thread > > scheduler is.
>=3B > > >=3B
&= > > >gt=3B >=3BNext step might be to whittle down the > > tests and see if you can= > > > get a failu=3D
>=3B >=3Bre > > with
>=3B >=3Ba single test runni= > > >ng and -n 2. That would likely be the simplest > > scenario=3D
>=3B >= > > >=3B to
>=3B >=3Bstart further > > debugging from.
>=3B > > >=3B
&g= > > >t=3B >=3B > > Mika
>=3B > > >=3B
>=3B >=3B"Coleburn=2C Randy" > > w= > > >rites:
>=3B >=3B>=3BMika et > > al:
>=3B > > >=3B>=3B
>=3B &= > > >gt=3B>=3BThought I would try something > > else.
>=3B > > >=3B>=3B
&g= > > >t=3B >=3B>=3BI took the sources of your > > thread test program to an older= > > > XP machine that=3D
>=3B >=3B > > =3D3D
>=3B >=3B>=3Bhas CM3 ci= > > >rca August 2008. This is the machine and > > implementation I used =3D
>= > > >=3B >=3Bw=3D3D
>=3B > > >=3B>=3Bhen building a major project I did a= > > > couple years back.
>=3B > > >=3B>=3B
>=3B > > >=3B>=3BThe thread= > > > test program does indeed build on this old system=2C > > but when I r=3D
&g= > > >t=3B >=3Bu=3D3D
>=3B > > >=3B>=3Bn it=2C I get different results tha= > > >n with the latest HEAD branch code. > > =3D3D20
>=3B > > >=3B>=3B
>= > > >=3B >=3B>=3BAfter it prints > > "running...printing oldest/median age/newes= > > >t"=2C on the next=3D
>=3B >=3B > > =3D3D
>=3B >=3B>=3Bline I ge= > > >t two periods ".." and now the program seems > > hung. I'll let it "=3D
>= > > >=3B >=3Br=3D3D
>=3B > > >=3B>=3Bun" for a few more minutes to see if= > > > anything else happens before killing > > =3D
>=3B >=3Bi=3D3D
>=3B > > = > > >>=3B>=3Bt.
>=3B > > >=3B>=3B
>=3B > > >=3B>=3BAt least we don= > > >'t get the subscript and assertion failures on this > > older C=3D
>=3B &g= > > >t=3BM=3D3D
>=3B >=3B>=3B3 > > platform.
>=3B > > >=3B>=3B
>= > > >=3B >=3B>=3BRegards=2C
>=3B > > >=3B>=3BRandy Coleburn
>=3B > > &= > > >gt=3B>=3B
>=3B > > >=3B>=3B
>=3B > > >=3B>=3B-----Original Mess= > > >age-----
>=3B >=3B>=3BFrom: > > Coleburn=2C Randy=3D3D20
>=3B >= > > >=3B>=3BSent: Sunday=2C February 27=2C 2011 2:09 > > PM
>=3B >=3B>=3B= > > >To: m3devel at elegosoft.com
>=3B > > >=3B>=3BSubject: Re: [M3devel] resu= > > >lts of threadtest program on > > Windows7
>=3B > > >=3B>=3B
>=3B >= > > >=3B>=3BMika:
>=3B > > >=3B>=3B
>=3B > > >=3B>=3BOk=2C I've upda= > > >ted to latest HEAD and I've also built Jay's m3sleep > > program.
>=3B >= > > >=3B>=3B
>=3B > > >=3B>=3BHere is what happens now when I run your > > th= > > >readtest program on Windows 7.
>=3B > > >=3B>=3B
>=3B >=3B>= > > >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>=3Bthreadtest > > -tests = > > >ALL=2C-fo=3D
>=3B > > >=3Br=3D3D
>=3B > > >=3B>=3Bk
>=3B >= > > >=3B>=3BWriting file...done
>=3B > > >=3B>=3BCreating read threads...= > > >done
>=3B >=3B>=3BCreating > > nxread threads...done
>=3B >=3B&= > > >gt=3BCreating tryexcept > > threads...done
>=3B > > >=3B>=3BCreating forkt= > > >oomuch threads...done
>=3B > > >=3B>=3BCreating alloc threads...done > >r>>=3B >=3B>=3BCreating creat > > threads...done
>=3B >=3B>=3BCr= > > >eating lock threads...done
>=3B > > >=3B>=3Brunning...printing oldest/= > > >median age/newest
>=3B > > >=3B>=3B
>=3B > > >=3B>=3B
>=3B &= > > >gt=3B>=3B***
>=3B > > >=3B>=3B*** runtime error:
>=3B > > >=3B>= > > >=3B*** An array subscript was out of > > range.
>=3B > > >=3B>=3B*** = > > > file "..\src\runtime\common\RTCollector.m3"=2C line > > 418
>=3B >=3B&g= > > >t=3B***
>=3B > > >=3B>=3B
>=3B > > >=3B>=3B
>=3B >=3B>= > > >=3B
>=3B > > >=3B>=3B***
>=3B > > >=3B>=3B*** runtime error:
&= > > >gt=3B >=3B>=3B*** > > <=3B*ASSERT*>=3B failed.
>=3B > > >=3B>= > > >=3B*** file > > "..\src\thread\WIN32\ThreadWin32.m3"=2C line > > 841
>=3B &= > > >gt=3B>=3B***
>=3B > > >=3B>=3B
>=3B > > >=3B>=3BThe last error = > > >repeats ad infinitum until I press CNTRL-C to > > abort.
>=3B >=3B>=3B= > > >
>=3B >=3B>=3BI'll send more > > info on the Windows install of Modula= > > >3 in a subsequent post=3D
>=3B > > >=3B.
>=3B > > >=3B>=3B
>= > > >=3B >=3B>=3BRegards=2C
>=3B > > >=3B>=3BRandy Coleburn
>=3B > > &= > > >gt=3B>=3B
>=3B > > >=3B>=3B-----Original > > Message-----
>=3B >= > > >=3B>=3BFrom: Mika Nystrom [mailto:mika at async.caltech.edu]=3D3D20
>= > > >=3B >=3B>=3BSent: Saturday=2C February > > 26=2C 2011 12:55 PM
>=3B &g= > > >t=3B>=3BTo: Coleburn=2C Randy
>=3B > > >=3B>=3BCc: m3devel at elegosoft= > > >.com
>=3B >=3B>=3BSubject: > > Re: [M3devel] results of threadtest pro= > > >gram on Windows7=3D3D20
>=3B > > >=3B>=3B
>=3B > > >=3B>=3BHi Ran= > > >dy=2C
>=3B > > >=3B>=3B
>=3B > > >=3B>=3BHm yes it looks like my = > > >Windows programming skills leave > > something
>=3B >=3B>=3Bto be > > desi= > > >red.
>=3B > > >=3B>=3B
>=3B > > >=3B>=3BYou can run the thread te= > > >ster while skipping a test as > > follows
>=3B > > >=3B>=3B
>=3B >= > > >=3B>=3B threadtest -tests > > ALL=2C-fork
>=3B > > >=3B>=3B
>=3B = > > >>=3B>=3B(for instance)
>=3B > > >=3B>=3B
>=3B > > >=3B>=3Bif = > > >you just run=3D3D20
>=3B > > >=3B>=3B
>=3B > > >=3B>=3B threadt= > > >est -sadfassdaf
>=3B > > >=3B>=3B
>=3B > > >=3B>=3Bit'll print th= > > >e tests that are available.
>=3B > > >=3B>=3B
>=3B > > >=3B>=3BAs= > > > it happens=2C I just had to upgrade my windows 2000 > > system to windows 7. > >r>>=3B >=3B>=3BCan you give me a > > very brief description of what you d= > > >id to install Modula=3D
>=3B > > >=3B-=3D3D
>=3B > > >=3B>=3B3
&= > > >gt=3B >=3B>=3Bon this > > system?
>=3B > > >=3B>=3B
>=3B >=3B&g= > > >t=3B Mika
>=3B > > >=3B>=3B
>=3B > > >=3B>=3B"Coleburn=2C Ran= > > >dy" writes:
>=3B > > >=3B>=3B>=3B--_000_D67F02DDC62F7545A6B84C285F88= > > >F3E6EE25C849atlex02srv_
>=3B > > >=3B>=3B>=3BContent-Type: text/plai= > > >n=3B charset=3D3D3D"us-ascii"
>=3B > > >=3B>=3B>=3BContent-Transfer-= > > >Encoding: quoted-printable
>=3B > > >=3B>=3B>=3B
>=3B > > >=3B>= > > >=3B>=3BMika:
>=3B > > >=3B>=3B>=3B
>=3B > > >=3B>=3B>=3BI'v= > > >e finally managed to get cm3 rebuilt on Windows 7 > > again.
>=3B >=3B&g= > > >t=3B>=3B
>=3B > > >=3B>=3B>=3BSo=2C I ran your threadtest > > program.= > > >
>=3B > > >=3B>=3B>=3B
>=3B > > >=3B>=3B>=3BHere are the resu= > > >lts. Note the "..." is where I cut out a bunch of > > the r=3D
>=3B >= > > >=3Be=3D3D
>=3B > > >=3B>=3Bp=3D3D3D
>=3B > > >=3B>=3B>=3Beating= > > > "ERROR FApply" messages.
>=3B > > >=3B>=3B>=3B
>=3B > > >=3B>= > > >=3B>=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>=3Bthreadtest.e= > > >xe
>=3B > > >=3B>=3B>=3BWriting > > file...done
>=3B >=3B>=3B&g= > > >t=3BCreating read threads...done
>=3B > > >=3B>=3B>=3BCreating fork = > > >threads...done
>=3B > > >=3B>=3B>=3BCreating alloc > > threads...done > >>>=3B >=3B>=3B>=3BCreating > > lock threads...done
>=3B >=3B>= > > >=3B>=3Brunning...printing oldest/median > > age/newest
>=3B >=3B>=3B= > > >>=3BERROR FApply: OSError.E: > > ErrorCode=3D3D3D3D2: The system cannot find= > > > the f=3D
>=3B > > >=3Bile=3D3D
>=3B >=3B>=3B > > sp=3D3D3D
>= > > >=3B > > >=3B>=3B>=3Becified.
>=3B > > >=3B>=3B>=3BERROR FApply: OS= > > >Error.E: ErrorCode=3D3D3D3D2: The system cannot > > find the f=3D
>=3B &g= > > >t=3Bile=3D3D
>=3B >=3B>=3B > > sp=3D3D3D
>=3B > > >=3B>=3B>=3Be= > > >cified.
>=3B > > >=3B>=3B>=3BERROR FApply: OSError.E: > > ErrorCode=3D3= > > >D3D3D2: The system cannot find the > > f=3D
>=3B > > >=3Bile=3D3D
>=3B = > > >>=3B>=3B sp=3D3D3D
>=3B > > >=3B>=3B>=3Becified.
>=3B > > >= > > >=3B>=3B>=3B.
>=3B > > >=3B>=3B>=3B.
>=3B > > >=3B>=3B>=3B= > > >.
>=3B > > >=3B>=3B>=3B***
>=3B > > >=3B>=3B>=3B*** runtime e= > > >rror:
>=3B > > >=3B>=3B>=3B*** An > > enumeration or subrange value w= > > >as out of range.
>=3B > > >=3B>=3B>=3B*** file > > "..\src\Main.m3"= > > >=2C line 340
>=3B > > >=3B>=3B>=3B***
>=3B > > >=3B>=3B>=3B > >r>>=3B >=3B>=3B>=3Blaziest > > thread is 0/0/ERROR FApply: OSError.E: = > > >ErrorCode=3D3D3D3D2: The sy=3D
>=3B > > >=3Bste=3D3D
>=3B >=3B>= > > >=3Bm c=3D3D3D
>=3B > > >=3B>=3B>=3Bannot find the file > > specified. > >>>=3B >=3B>=3B>=3BERROR > > FApply: OSError.E: ErrorCode=3D3D3D3D2: Th= > > >e system cannot find the f=3D
>=3B > > >=3Bile=3D3D
>=3B >=3B>= > > >=3B sp=3D3D3D
>=3B > > >=3B>=3B>=3Becified.
>=3B > > >=3B>=3B&g= > > >t=3BERROR FApply: OSError.E: ErrorCode=3D3D3D3D2: > > The system cannot find t= > > >he f=3D
>=3B > > >=3Bile=3D3D
>=3B >=3B>=3B > > sp=3D3D3D
>=3B= > > > > > >=3B>=3B>=3Becified.
>=3B > > >=3B>=3B>=3BERROR FApply: OSErr= > > >or.E: ErrorCode=3D3D3D3D2: The system cannot find > > the f=3D
>=3B >= > > >=3Bile=3D3D
>=3B >=3B>=3B > > sp=3D3D3D
>=3B > > >=3B>=3B>=3Bec= > > >ified.
>=3B > > >=3B>=3B>=3B.
>=3B > > >=3B>=3B>=3B.
>= > > >=3B >=3B>=3B>=3B.
>=3B > > >=3B>=3B>=3Blaziest thread is 0/0/E= > > >RROR FApply: OSError.E: ErrorCode=3D3D3D3D2: The > > sy=3D
>=3B >=3Bste= > > >=3D3D
>=3B >=3B>=3Bm > > c=3D3D3D
>=3B > > >=3B>=3B>=3Bannot fi= > > >nd the file specified.
>=3B > > >=3B>=3B>=3BERROR FApply: OSError.E:= > > > ErrorCode=3D3D3D3D2: The system cannot find the > > f=3D
>=3B >=3Bile= > > >=3D3D
>=3B >=3B>=3B > > sp=3D3D3D
>=3B > > >=3B>=3B>=3Becified.= > > >
>=3B > > >=3B>=3B>=3BERROR FApply: OSError.E: > > ErrorCode=3D3D3D3D2:= > > > The system cannot find the f=3D
>=3B > > >=3Bile=3D3D
>=3B >=3B&= > > >gt=3B sp=3D3D3D
>=3B > > >=3B>=3B>=3Becified.
>=3B > > >=3B>=3B= > > >>=3BERROR FApply: OSError.E: > > ErrorCode=3D3D3D3D2: The system cannot find= > > > the f=3D
>=3B > > >=3Bile=3D3D
>=3B >=3B>=3B > > sp=3D3D3D
>= > > >=3B > > >=3B>=3B>=3Becified.
>=3B > > >=3B>=3B>=3B.
>=3B > > >= > > >=3B>=3B>=3B.
>=3B > > >=3B>=3B>=3B.
>=3B > > >=3B>=3B>=3B= > > >ERROR FApply: OSError.E: ErrorCode=3D3D3D3D2: The > > system cannot find the f= > > >=3D
>=3B > > >=3Bile=3D3D
>=3B >=3B>=3B > > sp=3D3D3D
>=3B >= > > >=3B>=3B>=3Becified.
>=3B > > >=3B>=3B>=3BERROR FApply: OSError.E= > > >: ErrorCode=3D3D3D3D2: The system cannot find the > > f=3D
>=3B >=3Bile= > > >=3D3D
>=3B >=3B>=3B > > sp=3D3D3D
>=3B > > >=3B>=3B>=3Becified.= > > >
>=3B > > >=3B>=3B>=3BStack > > trace:
>=3B > > >=3B>=3B>=3B FP= > > > PC > > Procedure
>=3B > > >=3B>=3B>=3B--------- ---------= > > > > > -------------------------------
>=3B > > >=3B>=3B>=3B0x30fbd0 0x1= > > >27218a PutStats + 0x1a3 in > > ..\src\Main.m3
>=3B > > >=3B>=3B>=3B0x30= > > >fcc0 0x1273825 Main_M3 + 0x11db(!) in > > ..\src\Main.m3
>=3B >=3B>= > > >=3B>=3B
>=3B > > >=3B>=3B>=3BRegards=2C
>=3B > > >=3B>=3B>= > > >=3BRandy Coleburn
>=3B > > >=3B>=3B>=3B
>=3B > > >=3B>=3B>=3B= > > >--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
>=3B > > >=3B= > > >>=3B>=3BContent-Type: text/html=3B > > charset=3D3D3D"us-ascii"
>=3B &= > > >gt=3B>=3B>=3BContent-Transfer-Encoding: > > quoted-printable
>=3B >= > > >=3B>=3B>=3B
> > > > > > > > >= > > > > > >--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_-- > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: <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: , , <20110301181718.12EFC1A2078@async.async.caltech.edu>, <20110302033945.GC32641@topoi.pooq.com> Message-ID: > 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: 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: References: <20110301181718.12EFC1A2078@async.async.caltech.edu>, <452042.5906.qm@web29706.mail.ird.yahoo.com> Message-ID: '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: 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: 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 escribi?: De: Jay K Asunto: RE: [M3devel] results of threadtest program on Windows7 Para: dabenavidesd at yahoo.es, "Mika Nystrom" CC: "m3devel" 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 escribi?: > > > De: Mika Nystrom > > Asunto: Re: [M3devel] results of threadtest program on Windows7 > > Para: "Jay K" > > 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 > > > > > > > > > > > > > > > > > > > > >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
Writing > > file...done
Creating read threads...= > > >done
Creating fork > > threads...done
Creating alloc > > threads...done
Cr= > > >eating lock threads...done
running...printing > > oldest/median age/newest > >r>.

Are we guranteed forward > > progress in suspending all threads?
= > > >
I do see it fail usually on Darwin. > > e.g.:
........pthread_mutex_dest= > > >roy:EBUSY
pthread_mutex_destroy:EBUSY
..laziest > > thread is 0/0/0 (test= > > >s: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock > > 0/0/0)
...

***
*** r= > > >untime > > error:
*** =3B =3B =3B An > > array subscript was out of = > > >range.
*** =3B =3B =3B > > file "../src/runtime/common/RTCollect= > > >or.m3"=2C line 418
***

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

Mika are your machin= > > >es all multiprocessors?
I do wonder if that > > helps increase the stress an= > > >d if I should be sure to use > > multiprocessors.

I'm also considering t= > > >aking the time to try various historical versions=2C > > either releases or dat= > > >es in CVS.

 =3B- > > Jay


From: > > jay.kr= > > >ell at cornell.edu
To: > > mika at async.caltech.edu=3B > > rcolebur at scires.com
Dat= > > >e: Tue=2C 1 Mar 2011 10:59:29 +0000
CC: m3devel at elegosoft.com
Subject= > > >: Re: [M3devel] results of threadtest program on > > Windows7

> > > > > > > content=3D"text/html=3B charset=3Dunicode= > > >"> > > > > SafeHTML"> > > > > > > > > > > > >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 du= > > >al processor virtual machines.
Randy=2C has it > > failed many times for you= > > >?

 =3B- > > Jay

>=3B To: rcolebur at SCIRES.COM
>=3B > > Date= > > >: Sun=2C 27 Feb 2011 15:11:25 -0800
>=3B > > From: mika at async.caltech.edu<= > > >br>>=3B CC: m3devel at elegosoft.com
>=3B > > Subject: Re: [M3devel] result= > > >s of threadtest program on Windows7
>=3B > >
>=3B Ah=2C it just does= > > >n't check command-line arguments that > > carefully.
>=3B
>=3B I thi= > > >nk what you did is equivalent to "-tests > > STD".
>=3B
>=3B > > Mi= > > >ka
>=3B
>=3B > > "Coleburn=2C Randy" writes:
>=3B > > >=3BMika: > >r>>=3B >=3B
>=3B > > >=3BNo change with "-tests POSIX".
>=3B > > &g= > > >t=3B
>=3B >=3BInteresting > > twist: On Windows 7=2C I thought I'd see = > > >what the command line o=3D
>=3B > > >=3Bptions are=2C and I typed "threa= > > >dtest -help" rather than reading the > > code.
>=3B >=3B
>=3B > > >= > > >=3BFirst time=2C it produced what appears to be a NIL > > deref crash. Then=2C= > > > I trie=3D
>=3B >=3Bd it again and > > it ran to completion. Something = > > >seems non-deterministic her=3D
>=3B > > >=3Be. See below.
>=3B >= > > >=3B
>=3B > > >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>=3Bt= > > >hreadtest.exe -help
>=3B > > >=3BWriting file...done
>=3B > > >=3BCre= > > >ating read threads...done
>=3B > > >=3BCreating fork threads...done
&= > > >gt=3B >=3BCreating alloc > > threads...done
>=3B >=3BCreating lock > > thr= > > >eads...done
>=3B > > >=3Brunning...printing oldest/median > > age/newest
= > > >>=3B >=3B.
>=3B > > >=3B
>=3B > > >=3B***
>=3B >=3B*** run= > > >time error:
>=3B >=3B*** > > Attempt to reference an illegal memory l= > > >ocation.
>=3B >=3B*** > > pc =3D3D 0x77762262
>=3B > > >=3B***
= > > >>=3B >=3B
>=3B > > >=3BStack trace:
>=3B > > >=3B FP > > PC= > > > Procedure
>=3B > > >=3B--------- --------- > > ---------------------= > > >----------
>=3B >=3B > > 0xcdf998 0x130351b SystemError + 0x64 in ..\s= > > >rc\runtime\NT386\RTSignal.m=3D
>=3B > > >=3B3
>=3B >=3B 0xcdf9c0 = > > > 0x77762262 > > <=3B???>=3B
>=3B >=3B > > 0xcdf9d8 0x12e83b7 LockMute= > > >x + 0x4f in > > ..\src\thread\WIN32\ThreadWin32.m=3D
>=3B > > >=3B3
>= > > >=3B >=3B 0xcdfa00 0x12c7b08 GetChar + > > 0x28 in ..\src\rw\Rd.m3
>=3B= > > > >=3B 0xcdfb38 0x12c12e3 RApply + > > 0xd3 in ..\src\Main.m3
>=3B >= > > >=3B 0xcdfb74 0x12e971f ThreadBase + 0x254 > > in ..\src\thread\WIN32\ThreadWi= > > >n32=3D
>=3B > > >=3B.m3
>=3B >=3B 0xcdfb80 > > 0x76543677 <=3B???= > > >>=3B
>=3B >=3B > > 0xcdfbc0 0x77779f02 > > <=3B???>=3B
>=3B >= > > >=3B......... ......... ... more frames > > ...
>=3B >=3B
>=3B > > >= > > >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>=3Bthreadtest.exe > > -he= > > >lp
>=3B >=3BWriting > > file...done
>=3B >=3BCreating read > > thread= > > >s...done
>=3B >=3BCreating fork > > threads...done
>=3B >=3BCreat= > > >ing alloc threads...done
>=3B > > >=3BCreating lock threads...done
&g= > > >t=3B >=3Brunning...printing oldest/median > > age/newest
>=3B >=3B....= > > >......laziest thread is 0/0/0 (tests: read 0/0/0 fork > > 0/0/0 alloc 0/0/0=3D<= > > >br>>=3B >=3B lock > > 0/0/0)
>=3B >=3B..........laziest > > thread is 0/= > > >0/0 (tests: read 0/0/0 fork 0/0/0 alloc > > 0/0/0=3D
>=3B >=3B lock 0/0/= > > >0)
>=3B >=3B..........laziest > > thread is 0/0/0 (tests: read 0/0/0 for= > > >k 0/0/0 alloc 0/0/0=3D
>=3B >=3B > > lock 0/0/0)
>=3B >=3B.......= > > >...laziest thread is 0/0/0 (tests: read 0/0/0 fork > > 0/0/0 alloc 0/0/0=3D
= > > >>=3B >=3B lock 0/0/0)
>=3B > > >=3B..........laziest thread is 0/0/0= > > > (tests: read 0/0/0 fork 0/0/0 alloc > > 0/0/0=3D
>=3B >=3B lock 0/0/0)<= > > >br>>=3B >=3B..........laziest thread is > > 0/0/0 (tests: read 0/0/0 fork 0= > > >/0/0 alloc 0/0/0=3D
>=3B >=3B lock > > 0/0/0)
>=3B >=3B..........= > > >laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 > > alloc 0/0/0=3D
>= > > >=3B >=3B lock 0/0/0)
>=3B > > >=3B..........laziest thread is 0/0/0 (t= > > ests: read 0/0/0 fork 0/0/0 alloc > > 0/0/0=3D
>=3B >=3B lock > > 0/0/0)
= > > >>=3B >=3B..........laziest thread is 0/0/0 > > (tests: read 0/0/0 fork 0/0/= > > >0 alloc 0/0/0=3D
>=3B >=3B lock > > 0/0/0)
>=3B >=3B..........laz= > > >iest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 > > alloc 0/0/0=3D
>=3B= > > > >=3B lock 0/0/0)
>=3B > > >=3BAll tests complete. Congratulations. > >r>>=3B >=3B
>=3B > > >=3BRegards=2C
>=3B >=3BRandy > > Coleburn > >r>>=3B >=3B
>=3B > > >=3B-----Original Message-----
>=3B > > >=3B= > > >From: Mika Nystrom [mailto:mika at async.caltech.edu]=3D20
>=3B > > >=3BSen= > > >t: Sunday=2C February 27=2C 2011 3:30 > > PM
>=3B >=3BTo: Coleburn=2C Ra= > > >ndy
>=3B >=3BCc: m3devel at elegosoft.com
>=3B > > >=3BSubject: Re: = > > >[M3devel] results of threadtest program on > > Windows7=3D20
>=3B >=3B > >r>>=3B >=3BHi > > Randy=2C
>=3B >=3B
>=3B > > >=3BYou can try it = > > >with -tests POSIX as well.
>=3B > > >=3B
>=3B >=3BI find on user = > > >threads it runs very slowly (but it does run) because > > of how=3D
>=3B &= > > >gt=3B unfair
>=3B >=3Bthe thread > > scheduler is.
>=3B > > >=3B
&= > > >gt=3B >=3BNext step might be to whittle down the > > tests and see if you can= > > > get a failu=3D
>=3B >=3Bre > > with
>=3B >=3Ba single test runni= > > >ng and -n 2. That would likely be the simplest > > scenario=3D
>=3B >= > > >=3B to
>=3B >=3Bstart further > > debugging from.
>=3B > > >=3B
&g= > > >t=3B >=3B > > Mika
>=3B > > >=3B
>=3B >=3B"Coleburn=2C Randy" > > w= > > >rites:
>=3B >=3B>=3BMika et > > al:
>=3B > > >=3B>=3B
>=3B &= > > >gt=3B>=3BThought I would try something > > else.
>=3B > > >=3B>=3B
&g= > > >t=3B >=3B>=3BI took the sources of your > > thread test program to an older= > > > XP machine that=3D
>=3B >=3B > > =3D3D
>=3B >=3B>=3Bhas CM3 ci= > > >rca August 2008. This is the machine and > > implementation I used =3D
>= > > >=3B >=3Bw=3D3D
>=3B > > >=3B>=3Bhen building a major project I did a= > > > couple years back.
>=3B > > >=3B>=3B
>=3B > > >=3B>=3BThe thread= > > > test program does indeed build on this old system=2C > > but when I r=3D
&g= > > >t=3B >=3Bu=3D3D
>=3B > > >=3B>=3Bn it=2C I get different results tha= > > >n with the latest HEAD branch code. > > =3D3D20
>=3B > > >=3B>=3B
>= > > >=3B >=3B>=3BAfter it prints > > "running...printing oldest/median age/newes= > > >t"=2C on the next=3D
>=3B >=3B > > =3D3D
>=3B >=3B>=3Bline I ge= > > >t two periods ".." and now the program seems > > hung. I'll let it "=3D
>= > > >=3B >=3Br=3D3D
>=3B > > >=3B>=3Bun" for a few more minutes to see if= > > > anything else happens before killing > > =3D
>=3B >=3Bi=3D3D
>=3B > > = > > >>=3B>=3Bt.
>=3B > > >=3B>=3B
>=3B > > >=3B>=3BAt least we don= > > >'t get the subscript and assertion failures on this > > older C=3D
>=3B &g= > > >t=3BM=3D3D
>=3B >=3B>=3B3 > > platform.
>=3B > > >=3B>=3B
>= > > >=3B >=3B>=3BRegards=2C
>=3B > > >=3B>=3BRandy Coleburn
>=3B > > &= > > >gt=3B>=3B
>=3B > > >=3B>=3B
>=3B > > >=3B>=3B-----Original Mess= > > >age-----
>=3B >=3B>=3BFrom: > > Coleburn=2C Randy=3D3D20
>=3B >= > > >=3B>=3BSent: Sunday=2C February 27=2C 2011 2:09 > > PM
>=3B >=3B>=3B= > > >To: m3devel at elegosoft.com
>=3B > > >=3B>=3BSubject: Re: [M3devel] resu= > > >lts of threadtest program on > > Windows7
>=3B > > >=3B>=3B
>=3B >= > > >=3B>=3BMika:
>=3B > > >=3B>=3B
>=3B > > >=3B>=3BOk=2C I've upda= > > >ted to latest HEAD and I've also built Jay's m3sleep > > program.
>=3B >= > > >=3B>=3B
>=3B > > >=3B>=3BHere is what happens now when I run your > > th= > > >readtest program on Windows 7.
>=3B > > >=3B>=3B
>=3B >=3B>= > > >=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>=3Bthreadtest > > -tests = > > >ALL=2C-fo=3D
>=3B > > >=3Br=3D3D
>=3B > > >=3B>=3Bk
>=3B >= > > >=3B>=3BWriting file...done
>=3B > > >=3B>=3BCreating read threads...= > > >done
>=3B >=3B>=3BCreating > > nxread threads...done
>=3B >=3B&= > > >gt=3BCreating tryexcept > > threads...done
>=3B > > >=3B>=3BCreating forkt= > > >oomuch threads...done
>=3B > > >=3B>=3BCreating alloc threads...done > >r>>=3B >=3B>=3BCreating creat > > threads...done
>=3B >=3B>=3BCr= > > >eating lock threads...done
>=3B > > >=3B>=3Brunning...printing oldest/= > > >median age/newest
>=3B > > >=3B>=3B
>=3B > > >=3B>=3B
>=3B &= > > >gt=3B>=3B***
>=3B > > >=3B>=3B*** runtime error:
>=3B > > >=3B>= > > >=3B*** An array subscript was out of > > range.
>=3B > > >=3B>=3B*** = > > > file "..\src\runtime\common\RTCollector.m3"=2C line > > 418
>=3B >=3B&g= > > >t=3B***
>=3B > > >=3B>=3B
>=3B > > >=3B>=3B
>=3B >=3B>= > > >=3B
>=3B > > >=3B>=3B***
>=3B > > >=3B>=3B*** runtime error:
&= > > >gt=3B >=3B>=3B*** > > <=3B*ASSERT*>=3B failed.
>=3B > > >=3B>= > > >=3B*** file > > "..\src\thread\WIN32\ThreadWin32.m3"=2C line > > 841
>=3B &= > > >gt=3B>=3B***
>=3B > > >=3B>=3B
>=3B > > >=3B>=3BThe last error = > > >repeats ad infinitum until I press CNTRL-C to > > abort.
>=3B >=3B>=3B= > > >
>=3B >=3B>=3BI'll send more > > info on the Windows install of Modula= > > >3 in a subsequent post=3D
>=3B > > >=3B.
>=3B > > >=3B>=3B
>= > > >=3B >=3B>=3BRegards=2C
>=3B > > >=3B>=3BRandy Coleburn
>=3B > > &= > > >gt=3B>=3B
>=3B > > >=3B>=3B-----Original > > Message-----
>=3B >= > > >=3B>=3BFrom: Mika Nystrom [mailto:mika at async.caltech.edu]=3D3D20
>= > > >=3B >=3B>=3BSent: Saturday=2C February > > 26=2C 2011 12:55 PM
>=3B &g= > > >t=3B>=3BTo: Coleburn=2C Randy
>=3B > > >=3B>=3BCc: m3devel at elegosoft= > > >.com
>=3B >=3B>=3BSubject: > > Re: [M3devel] results of threadtest pro= > > >gram on Windows7=3D3D20
>=3B > > >=3B>=3B
>=3B > > >=3B>=3BHi Ran= > > >dy=2C
>=3B > > >=3B>=3B
>=3B > > >=3B>=3BHm yes it looks like my = > > >Windows programming skills leave > > something
>=3B >=3B>=3Bto be > > desi= > > >red.
>=3B > > >=3B>=3B
>=3B > > >=3B>=3BYou can run the thread te= > > >ster while skipping a test as > > follows
>=3B > > >=3B>=3B
>=3B >= > > >=3B>=3B threadtest -tests > > ALL=2C-fork
>=3B > > >=3B>=3B
>=3B = > > >>=3B>=3B(for instance)
>=3B > > >=3B>=3B
>=3B > > >=3B>=3Bif = > > >you just run=3D3D20
>=3B > > >=3B>=3B
>=3B > > >=3B>=3B threadt= > > >est -sadfassdaf
>=3B > > >=3B>=3B
>=3B > > >=3B>=3Bit'll print th= > > >e tests that are available.
>=3B > > >=3B>=3B
>=3B > > >=3B>=3BAs= > > > it happens=2C I just had to upgrade my windows 2000 > > system to windows 7. > >r>>=3B >=3B>=3BCan you give me a > > very brief description of what you d= > > >id to install Modula=3D
>=3B > > >=3B-=3D3D
>=3B > > >=3B>=3B3
&= > > >gt=3B >=3B>=3Bon this > > system?
>=3B > > >=3B>=3B
>=3B >=3B&g= > > >t=3B Mika
>=3B > > >=3B>=3B
>=3B > > >=3B>=3B"Coleburn=2C Ran= > > >dy" writes:
>=3B > > >=3B>=3B>=3B--_000_D67F02DDC62F7545A6B84C285F88= > > >F3E6EE25C849atlex02srv_
>=3B > > >=3B>=3B>=3BContent-Type: text/plai= > > >n=3B charset=3D3D3D"us-ascii"
>=3B > > >=3B>=3B>=3BContent-Transfer-= > > >Encoding: quoted-printable
>=3B > > >=3B>=3B>=3B
>=3B > > >=3B>= > > >=3B>=3BMika:
>=3B > > >=3B>=3B>=3B
>=3B > > >=3B>=3B>=3BI'v= > > >e finally managed to get cm3 rebuilt on Windows 7 > > again.
>=3B >=3B&g= > > >t=3B>=3B
>=3B > > >=3B>=3B>=3BSo=2C I ran your threadtest > > program.= > > >
>=3B > > >=3B>=3B>=3B
>=3B > > >=3B>=3B>=3BHere are the resu= > > >lts. Note the "..." is where I cut out a bunch of > > the r=3D
>=3B >= > > >=3Be=3D3D
>=3B > > >=3B>=3Bp=3D3D3D
>=3B > > >=3B>=3B>=3Beating= > > > "ERROR FApply" messages.
>=3B > > >=3B>=3B>=3B
>=3B > > >=3B>= > > >=3B>=3BC:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>=3Bthreadtest.e= > > >xe
>=3B > > >=3B>=3B>=3BWriting > > file...done
>=3B >=3B>=3B&g= > > >t=3BCreating read threads...done
>=3B > > >=3B>=3B>=3BCreating fork = > > >threads...done
>=3B > > >=3B>=3B>=3BCreating alloc > > threads...done > >>>=3B >=3B>=3B>=3BCreating > > lock threads...done
>=3B >=3B>= > > >=3B>=3Brunning...printing oldest/median > > age/newest
>=3B >=3B>=3B= > > >>=3BERROR FApply: OSError.E: > > ErrorCode=3D3D3D3D2: The system cannot find= > > > the f=3D
>=3B > > >=3Bile=3D3D
>=3B >=3B>=3B > > sp=3D3D3D
>= > > >=3B > > >=3B>=3B>=3Becified.
>=3B > > >=3B>=3B>=3BERROR FApply: OS= > > >Error.E: ErrorCode=3D3D3D3D2: The system cannot > > find the f=3D
>=3B &g= > > >t=3Bile=3D3D
>=3B >=3B>=3B > > sp=3D3D3D
>=3B > > >=3B>=3B>=3Be= > > >cified.
>=3B > > >=3B>=3B>=3BERROR FApply: OSError.E: > > ErrorCode=3D3= > > >D3D3D2: The system cannot find the > > f=3D
>=3B > > >=3Bile=3D3D
>=3B = > > >>=3B>=3B sp=3D3D3D
>=3B > > >=3B>=3B>=3Becified.
>=3B > > >= > > >=3B>=3B>=3B.
>=3B > > >=3B>=3B>=3B.
>=3B > > >=3B>=3B>=3B= > > >.
>=3B > > >=3B>=3B>=3B***
>=3B > > >=3B>=3B>=3B*** runtime e= > > >rror:
>=3B > > >=3B>=3B>=3B*** An > > enumeration or subrange value w= > > >as out of range.
>=3B > > >=3B>=3B>=3B*** file > > "..\src\Main.m3"= > > >=2C line 340
>=3B > > >=3B>=3B>=3B***
>=3B > > >=3B>=3B>=3B > >r>>=3B >=3B>=3B>=3Blaziest > > thread is 0/0/ERROR FApply: OSError.E: = > > >ErrorCode=3D3D3D3D2: The sy=3D
>=3B > > >=3Bste=3D3D
>=3B >=3B>= > > >=3Bm c=3D3D3D
>=3B > > >=3B>=3B>=3Bannot find the file > > specified. > >>>=3B >=3B>=3B>=3BERROR > > FApply: OSError.E: ErrorCode=3D3D3D3D2: Th= > > >e system cannot find the f=3D
>=3B > > >=3Bile=3D3D
>=3B >=3B>= > > >=3B sp=3D3D3D
>=3B > > >=3B>=3B>=3Becified.
>=3B > > >=3B>=3B&g= > > >t=3BERROR FApply: OSError.E: ErrorCode=3D3D3D3D2: > > The system cannot find t= > > >he f=3D
>=3B > > >=3Bile=3D3D
>=3B >=3B>=3B > > sp=3D3D3D
>=3B= > > > > > >=3B>=3B>=3Becified.
>=3B > > >=3B>=3B>=3BERROR FApply: OSErr= > > >or.E: ErrorCode=3D3D3D3D2: The system cannot find > > the f=3D
>=3B >= > > >=3Bile=3D3D
>=3B >=3B>=3B > > sp=3D3D3D
>=3B > > >=3B>=3B>=3Bec= > > >ified.
>=3B > > >=3B>=3B>=3B.
>=3B > > >=3B>=3B>=3B.
>= > > >=3B >=3B>=3B>=3B.
>=3B > > >=3B>=3B>=3Blaziest thread is 0/0/E= > > >RROR FApply: OSError.E: ErrorCode=3D3D3D3D2: The > > sy=3D
>=3B >=3Bste= > > >=3D3D
>=3B >=3B>=3Bm > > c=3D3D3D
>=3B > > >=3B>=3B>=3Bannot fi= > > >nd the file specified.
>=3B > > >=3B>=3B>=3BERROR FApply: OSError.E:= > > > ErrorCode=3D3D3D3D2: The system cannot find the > > f=3D
>=3B >=3Bile= > > >=3D3D
>=3B >=3B>=3B > > sp=3D3D3D
>=3B > > >=3B>=3B>=3Becified.= > > >
>=3B > > >=3B>=3B>=3BERROR FApply: OSError.E: > > ErrorCode=3D3D3D3D2:= > > > The system cannot find the f=3D
>=3B > > >=3Bile=3D3D
>=3B >=3B&= > > >gt=3B sp=3D3D3D
>=3B > > >=3B>=3B>=3Becified.
>=3B > > >=3B>=3B= > > >>=3BERROR FApply: OSError.E: > > ErrorCode=3D3D3D3D2: The system cannot find= > > > the f=3D
>=3B > > >=3Bile=3D3D
>=3B >=3B>=3B > > sp=3D3D3D
>= > > >=3B > > >=3B>=3B>=3Becified.
>=3B > > >=3B>=3B>=3B.
>=3B > > >= > > >=3B>=3B>=3B.
>=3B > > >=3B>=3B>=3B.
>=3B > > >=3B>=3B>=3B= > > >ERROR FApply: OSError.E: ErrorCode=3D3D3D3D2: The > > system cannot find the f= > > >=3D
>=3B > > >=3Bile=3D3D
>=3B >=3B>=3B > > sp=3D3D3D
>=3B >= > > >=3B>=3B>=3Becified.
>=3B > > >=3B>=3B>=3BERROR FApply: OSError.E= > > >: ErrorCode=3D3D3D3D2: The system cannot find the > > f=3D
>=3B >=3Bile= > > >=3D3D
>=3B >=3B>=3B > > sp=3D3D3D
>=3B > > >=3B>=3B>=3Becified.= > > >
>=3B > > >=3B>=3B>=3BStack > > trace:
>=3B > > >=3B>=3B>=3B FP= > > > PC > > Procedure
>=3B > > >=3B>=3B>=3B--------- ---------= > > > > > -------------------------------
>=3B > > >=3B>=3B>=3B0x30fbd0 0x1= > > >27218a PutStats + 0x1a3 in > > ..\src\Main.m3
>=3B > > >=3B>=3B>=3B0x30= > > >fcc0 0x1273825 Main_M3 + 0x11db(!) in > > ..\src\Main.m3
>=3B >=3B>= > > >=3B>=3B
>=3B > > >=3B>=3B>=3BRegards=2C
>=3B > > >=3B>=3B>= > > >=3BRandy Coleburn
>=3B > > >=3B>=3B>=3B
>=3B > > >=3B>=3B>=3B= > > >--_000_D67F02DDC62F7545A6B84C285F88F3E6EE25C849atlex02srv_
>=3B > > >=3B= > > >>=3B>=3BContent-Type: text/html=3B > > charset=3D3D3D"us-ascii"
>=3B &= > > >gt=3B>=3B>=3BContent-Transfer-Encoding: > > quoted-printable
>=3B >= > > >=3B>=3B>=3B
> > > > > > > > >= > > > > > >--_93dad88e-7ca3-48ac-a7dc-f4777a03b794_-- > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , <20110227231125.3DC611A2078@async.async.caltech.edu> Message-ID: 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: 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: References: , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, , Message-ID: 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: 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: References: , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, , Message-ID: 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: 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: 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 escribi?: De: Jay K Asunto: Re: [M3devel] results of threadtest program on Windows7 Para: rcolebur at scires.com, "m3devel" 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: 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: , <974355.12644.qm@web29717.mail.ird.yahoo.com> Message-ID: 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 escribi?: De: Jay K Asunto: Re: [M3devel] results of threadtest program on Windows7 Para: rcolebur at scires.com, "m3devel" 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: 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: References: , <974355.12644.qm@web29717.mail.ird.yahoo.com>, Message-ID: 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 escribi?: De: Jay K Asunto: Re: [M3devel] results of threadtest program on Windows7 Para: rcolebur at scires.com, "m3devel" 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: 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: References: , <974355.12644.qm@web29717.mail.ird.yahoo.com>, , Message-ID: 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 escribi?: De: Jay K Asunto: Re: [M3devel] results of threadtest program on Windows7 Para: rcolebur at scires.com, "m3devel" 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: 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: References: , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, , 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: 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: References: , <974355.12644.qm@web29717.mail.ird.yahoo.com> 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 escribi?: > > De: Jay K > Asunto: Re: [M3devel] results of threadtest program on Windows7 > Para: rcolebur at scires.com, "m3devel" > 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: 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: References: , <974355.12644.qm@web29717.mail.ird.yahoo.com>, , 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 escribi?: > > De: Jay K > Asunto: Re: [M3devel] results of threadtest program on Windows7 > Para: rcolebur at scires.com, "m3devel" > 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: 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: References: , <974355.12644.qm@web29717.mail.ird.yahoo.com>, Message-ID: 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 escribi?: > > De: Jay K > Asunto: Re: [M3devel] results of threadtest program on Windows7 > Para: rcolebur at scires.com, "m3devel" > 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: 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: , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu> Message-ID: 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: 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: References: , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu> 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: References: , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu> 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: 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: <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 escribi?: > > De: Jay K > Asunto: RE: [M3devel] results of threadtest program on Windows7 > Para: dabenavidesd at yahoo.es, "Mika Nystrom" > CC: "m3devel" > 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: , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu> <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu> Message-ID: 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] 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: 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: References: , ,,<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,,, ,,, ,,<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,,, , , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , , , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, Message-ID: 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: 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: 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: References: <20110305200630.F26711A2078@async.async.caltech.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: References: , ,,<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,,, ,,, ,,<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,,, , , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , , , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, Message-ID: 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: 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 escribi=F3: > >> De: Mika Nystrom >> Asunto: Re: [M3devel] MODULEs in .M3IMPTAB >> Para: "Tony Hosking" >> 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 escribi?: > De: Mika Nystrom > Asunto: Re: [M3devel] MODULEs in .M3IMPTAB > Para: "Tony Hosking" > 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> <20110305225351.2A2AD1A2078@async.async.caltech.edu> Message-ID: m3browser? Sent from my iPhone On Mar 5, 2011, at 5:53 PM, Mika Nystrom 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: References: <20110305200630.F26711A2078@async.async.caltech.edu> <20110305225351.2A2AD1A2078@async.async.caltech.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 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: References: , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , , , , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, ,,, , , , , , , , , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , , <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, , , , Message-ID: 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: 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: References: , , , ,,<20110226175511.3F7D21A2078@async.async.caltech.edu>, , , ,,, , , ,,, , , ,,<20110227202950.46F3B1A2078@async.async.caltech.edu>, , , ,,, , ,,, <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , , , , , ,,, ,,, ,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, ,,, ,,<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, , , , , , , , Message-ID: 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: 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: References: , , ,,,,<20110226175511.3F7D21A2078@async.async.caltech.edu>, , ,,,,, , ,,,,, , ,,,,<20110227202950.46F3B1A2078@async.async.caltech.edu>, , ,,,,, , ,,,,<20110227231125.3DC611A2078@async.async.caltech.edu>, , , ,,, , ,,, , , , , , , , , , , , , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , , , , , , <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, , , , , ,,, , , , , , Message-ID: 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: 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: References: , ,,,,,,<20110226175511.3F7D21A2078@async.async.caltech.edu>, ,,,,,,, ,,,,,,, ,,,,,,<20110227202950.46F3B1A2078@async.async.caltech.edu>, ,,,,,,, ,,,,,,<20110227231125.3DC611A2078@async.async.caltech.edu>, , ,,,,, , ,,,,, , , ,,, , , ,,, , , ,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , ,,, , , ,,<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, , ,,, , , , , , , , , , , , , , , Message-ID: 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: 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: References: , , , , , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , , , , , , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, ,,,,,,, ,,,,,,, , ,,,,, , ,,,,, , ,,,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , ,,,,, , ,,,,<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, , ,,,,, , , ,,, , ,,, ,,, , , , , , , , Message-ID: 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: 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: References: , , , , , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , , , , , , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , , ,,,,,,, ,,,,,,, ,,,,,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, ,,,,,,, ,,,,,,<44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, ,,,,,,, , ,,,,, , ,,,,,,, , , , , , , , , , , Message-ID: 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: 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: References: , , , , , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , , , , , , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , , , , , , , , , , , , , , <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, , , , , , , , , ,,,,,,, , , , , , , , , , , , , , , , , , , , , , Message-ID: 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: 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: References: , , , , , , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , , , , , , , , ,,, , , , , ,,, , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, ,,, , , , , , , , , , , , , , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , ,,, , , , , , , , , ,,, , , , , ,,, , , , , , , , , ,,, , , , , ,,, , , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , ,,, , , , , ,,, , , , , , <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>,,, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,,, , , , , , , , , , Message-ID: 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: 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: References: , , , , , , , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , , , , ,,, , ,,, , , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , , , ,,,,<20110227231125.3DC611A2078@async.async.caltech.edu>, , , , ,,, , ,,, , , , , , , , , , , , , , , , , , ,,, , , , , , , , , , , , , , , , , , ,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , ,,, , , ,,, ,,, , , , , , , <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, , , , , , , , , , , , , , , , , , ,,, , ,,, , , , , , , , , ,,, , , , ,,,,,,, , , ,,, ,,, , , , , , Message-ID: 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: 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: References: , , , ,,, , , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , , , , , , ,,, , , , , , ,,,,,,<20110227231125.3DC611A2078@async.async.caltech.edu>, , , , ,,, ,,,,, , , , , ,,, , , , , , , , , ,,, , ,,, , , , , ,,, , , , , , , , , ,,, ,,,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , ,,, , , , , , , , , , , , , , , , , <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, , , , , , , , , , , ,,, , , , , , ,,,,, , ,,, , , , ,,, , , , ,,, ,,, ,,,,,,,,, , , , , , , , , , , , , , , , , , , , , Message-ID: 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: 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: References: , , , , , , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , , , , , , , , ,,, , , , , ,,, , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, ,,, , , , , , , , , , , , , , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , ,,, , , , , , , , , ,,, , , , , ,,, , , , , , , , , ,,, , , , , ,,, , , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , ,,, , , , , ,,, , , , , , <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>,,, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,,, , , , , , , , , , Message-ID: 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: 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: References: , , , , , , , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , , , , , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , , , , , , , , , , , , , , , , , , <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, ! , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Message-ID: 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: 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: 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 escribi?: De: Tony Hosking Asunto: Re: [M3devel] results of threadtest program on Windows7 Para: "Jay K" CC: "m3devel" 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: 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: References: , , , , , , , , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , , , , , , , , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , , ,,, , , , , , , , , , , , , , , , ,,, , , , , , , , , , , , , , , , , , , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , ,,, , , , , , , , , , , , , , , , , , , <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, !, , , , , , , , , , , , , , , , , , , , , , , , , , , , ,,, , , , , ,,, , , , , , , , , ,,, , , ,,, , ,,, , ,,, , ,,, , , , , , , Message-ID: 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: 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: References: , , , , , , , , , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , , , , , , , , , , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , , , , , , ,,, , , , , , ,,, , , , , , , , , , , , , , ,,, , ,,, , , , , , , , , , , , , , , , , , , ,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , ,,, , , , , , , , , , , , , , , , , , , , , <44BAC21C-4375-478B-9FDF-27181181D765@cs.purdue.edu>, !, , , , , , , , , , , , , , , , , , , , , , ,,, , , , , , ,,, ,,, , , ,,, , , ,,, , , , ,,,,, , ,,,,, ,,,,, ,,,,, , , , , , , , , , , , , , Message-ID: 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: 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: References: , , , , , , , , , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , , , , , , , , , , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , , , , , , , , , , , , , , , , , , , , , , , <44BAC21C-4375-478B-9FDF-27181181D7! 65@cs.purdue.edu>, !, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , 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: 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: , , , , , , , , , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , , , , , , , , , , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , , , , , , ,,, , , , , , ,,, , , , , , , , , , , , , , ,,, , ,,, , , , , , , , , , , , , , , , , , , ,,<8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , ,,, , , , , , , , , , , , , , , , , , , , , <44BAC21C-4375-478B-9FDF-27181181D7!, 65@cs.purdue.edu>, !, , , , , , , , , , , , , , , , , , , , , , ,,, , , , , , ,,, ,,, , , ,,, , , ,,, , , , ,,,,, , ,,,,, ,,,,, ,,,,, , , , , , , , , , , , , , , <8972478C-50D2-41D1-8DEB-57323B1D3580@cs.purdue.edu> Message-ID: 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: 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: References: , , , , , , , , , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , , , , , , , , , , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , , , , , , , , , , , , , , , , , , , , , , , <44BAC21C-4375-478B-9FDF-27181181D7! !, 65@cs.purdue.edu>, !, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , <8972478C-50D2-41D1-8DEB-57323B1D3580@cs.purdue.edu> 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: 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 escribi?: De: Tony Hosking Asunto: Re: [M3devel] results of threadtest program on Windows7 Para: "Jay K" CC: "m3devel" 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: 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. escribi?: De: Daniel Alejandro Benavides D. Asunto: Re: [M3devel] results of threadtest program on Windows7 Para: "Jay K" , "Tony Hosking" CC: "m3devel" 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 escribi?: De: Tony Hosking Asunto: Re: [M3devel] results of threadtest program on Windows7 Para: "Jay K" CC: "m3devel" 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: 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: , , , , , , , , , , , , , <20110226175511.3F7D21A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,,, , , , , , , , <20110227202950.46F3B1A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , <20110227231125.3DC611A2078@async.async.caltech.edu>, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , <8532EBC7-7795-4218-8F99-F8B9EF655394@cs.purdue.edu>, , , , , , , , , , , , , , , , , , , , , , , , , , , , <44BAC21C-4375-478B-9FDF-27181181D7!, !, 65@cs.purdue.edu>, !, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,,, , , , , , , ,,, , , , ,,, , , , ,,, , , , ,,, , , ,,, , , , , , , , , , , , <8972478C-50D2-41D1-8DEB-57323B1D3580@cs.purdue.edu>, , <685C8B05-23D1-4BE8-93BB-3B11FFD28AFF@cs.purdue.edu> Message-ID: 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: 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: 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: 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: References: <224092.3263.qm@web29710.mail.ird.yahoo.com> Message-ID: <20110314212514.edcnep7i8wk8gwkc@mail.elegosoft.com> Quoting Jay K : > > 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 escribi?: > De: Olaf Wagner > 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 : > > > > > 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: 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: 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: References: 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: 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: , <82BC458A-AEC4-4148-B65D-D6B4B0692CDD@cs.purdue.edu> Message-ID: - 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: 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: 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: 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: References: Message-ID: 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: 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: 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 escribi?: De: Jay K Asunto: Re: [M3devel] question on use of Time.Now in thread test program Para: rcolebur at scires.com, "m3devel" 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: 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: , <569254.84801.qm@web29712.mail.ird.yahoo.com> Message-ID: 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 escribi?: De: Jay K Asunto: Re: [M3devel] question on use of Time.Now in thread test program Para: rcolebur at scires.com, "m3devel" 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: 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: References: , <82BC458A-AEC4-4148-B65D-D6B4B0692CDD@cs.purdue.edu> Message-ID: 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: 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: References: , <82BC458A-AEC4-4148-B65D-D6B4B0692CDD@cs.purdue.edu> 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: 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: 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: Main.m3 Type: application/octet-stream Size: 18584 bytes Desc: Main.m3 URL: 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: References: Message-ID: 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: 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 > >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"" xmlns=3D"http://www.w3.org/TR/REC-html40">v=3DContent-Type content=3D"text/html; charset=3Dus-ascii">erator content=3D"Microsoft Word 12 (filtered medium)">nk=3Dpurple>

Mika et al:= >

 

I = >didn’t want to check in a modified version of your program without ev= >eryone agreeing my modifications are desired.

ormal> 

Attached is my modified sou= >rce 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, l= >et me know.

 

s=3DMsoNormal>Basically, I’ve done 2 things:

class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 lf= >o1'>1.ont:7.0pt "Times New Roman"'>       span>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 separat= >e 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.)

<= >o:p>

ist:l0 level1 lfo1'>2.= >     = >  Added “–verbose” co= >mmand line option.  If you choose this option, extra information is pr= >inted, namely:  as threads are created, their “id” is prin= >ted and then for each iteration, the number of times each thread executed i= >ts main loop is printed.  Also, if a thread doesn’t make any pro= >gress on an iteration, a notice that the thread may be starved or deadlocke= >d is printed.

 

ass=3DMsoNormal>Unless you use –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.  For example,

lass=3DMsoNormal style=3D'margin-left:.5in'>rier New"'>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtest.e= >xe -tests read lock

in-left:.5in'>ParseParams: parame= >ter 4 =3D "lock" extraneous or misplaced.

class=3DMsoNormal style=3D'margin-left:.5in'>ourier New"'> 

in-left:.5in'>*** Couldnt parse c= >md-line args.

 p>

Now, running on Windows 7 (64-bit), I still get non-= >deterministic behavior and some crashes.  For example:

<= >p class=3DMsoNormal style=3D'margin-left:.5in'>Courier New"'>C:\cm3\Sandbox\m3-libs\m3core\tests\thread\NT386>threadtes= >t.exe -verbose -tests read,lock

tyle=3D'margin-left:.5in'>Writing= > file...done

:.5in'>Creating read threads...:p>

tyle=3D'font-family:"Courier New"'>   read=3D0<= >/p>

ly:"Courier New"'>   read=3D1

Normal style=3D'margin-left:.5in'>>   read=3D2

argin-left:.5in'>done<= >/span>

nt-family:"Courier New"'>Creating lock threads...

lass=3DMsoNormal style=3D'margin-left:.5in'>rier New"'>   lock=3D21

style=3D'margin-left:.5in'> = >;  lock=3D22

-left:.5in'>   lock=3D2= >3

n style=3D'font-family:"Courier New"'>done

MsoNormal style=3D'margin-left:.5in'>w"'>running...printing oldest/median age/newest

ss=3DMsoNormal style=3D'margin-left:.5in'>er New"'>..........laziest thread is 0/0/0 (tests: read 0/0/0 lock 0/0/0):p>

tyle=3D'font-family:"Courier New"'>   read Thread 0 completed 167= >0 loops.

n'>   read Thread 1 com= >pleted 1692 loops.

n-left:.5in'>   read Th= >read 2 completed 1849 loops.

e=3D'margin-left:.5in'> &nbs= >p; lock Thread 21 completed 11788253 loops.

=3DMsoNormal style=3D'margin-left:.5in'> New"'>   lock Thread 22 completed 9448889 loops.n>

amily:"Courier New"'>   lock Thread 23 completed 9480853 loops.:p>

tyle=3D'font-family:"Courier New"'>..........laziest thread is 0/0/0 (tests= >: read 0/0/0 lock 0/0/0)

'margin-left:.5in'>   r= >ead Thread 0 completed 2148 loops.

l style=3D'margin-left:.5in'>&nbs= >p;  read Thread 1 completed 2113 loops.

=3DMsoNormal style=3D'margin-left:.5in'> New"'>   read Thread 2 completed 2343 loops.p>

y:"Courier New"'>   lock Thread 21 completed 13326765 loops.= >

e=3D'font-family:"Courier New"'>   lock Thread 22 completed 11327= >588 loops.

5in'>   lock Thread 23 = >completed 12743882 loops.

=3D'margin-left:.5in'>.......>

le=3D'font-family:"Courier New"'> 

Normal style=3D'margin-left:.5in'>>***

<= >span style=3D'font-family:"Courier New"'>*** runtime error:n>

amily:"Courier New"'>***    Attempt to reference an illegal = >memory location.

left:.5in'> n>

amily:"Courier New"'>***

'margin-left:.5in'>*** runtime er= >ror:

<= >span style=3D'font-family:"Courier New"'>***    Attempt to r= >eference an illegal memory location.

mal style=3D'margin-left:.5in'>:p> 

<= >span style=3D'font-family:"Courier New"'>***

=3DMsoNormal style=3D'margin-left:.5in'> New"'>*** runtime error:

=3D'margin-left:.5in'>*** &n= >bsp;  Attempt to reference an illegal memory location.n>

amily:"Courier New"'>***    pc =3D 0x126e37d =3D Move + 0x50= > in ..\src\runtime\common\RTCollector.m3

oNormal style=3D'margin-left:.5in'>'>***

= > 

ass=3DMsoNormal style=3D'margin-left:.5in'>ier New"'>***

t:.5in'>*** runtime error:o:p>

=3D'font-family:"Courier New"'>***    <*ASSERT*> faile= >d.

an style=3D'font-family:"Courier New"'>***    file "..\= >src\thread\WIN32\ThreadWin32.m3", line 841

ss=3DMsoNormal style=3D'margin-left:.5in'>er New"'>***

:.5in'> p>

y:"Courier New"'>***

gin-left:.5in'>*** runtime error:= >

style=3D'font-family:"Courier New"'>***    <*ASSERT*>= > failed.

n'>***    file &qu= >ot;..\src\thread\WIN32\ThreadWin32.m3", line 841

= >

"Courier New"'>***

n-left:.5in'> pan>

-family:"Courier New"'>***

=3D'margin-left:.5in'>*** runtime= > error:

'>***    <*ASSE= >RT*> failed.

eft:.5in'>***    f= >ile "..\src\thread\WIN32\ThreadWin32.m3", line 841an>

family:"Courier New"'>***

&n= >bsp;

I’ll try on 32-bit XP soon and rep= >ort.

 

Normal>Regards,

Randy Coleburn>

 

= > >--_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: 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: 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: 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: 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: 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 escribi?: De: Coleburn, Randy Asunto: [M3devel] thread tests on NT386 32-bit circa 2008, not good so far Para: "m3devel" 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 Threa