[M3devel] draft new edition of thread test program

[Tony Hosking]

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

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

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

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