[M3devel] CM3 crashing

Mon Jan 13 20:16:41 CET 2014

Tony et al:

The thread test program fails for me on 64-bit Windows 7.

I've listed output from a couple of runs below:

C:\cm3\Sandbox>cm3 --version
Critical Mass Modula-3 version d5.9.0
  last updated: 2010-07-21
  compiled: 2014-01-07 06:55:14
  configuration: C:\cm3\bin\cm3.cfg
  host: NT386
  target: NT386

FIRST RUN:

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:
***    <*ASSERT*> failed.
***    file "..\src\runtime\common\RTCollector.m3", line 418
***

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

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

               ...this last assertion repeats until you press CTRL-C to abort the program...

SECOND RUN:

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

***
*** runtime error:
***    Attempt to reference an illegal memory location.
***    pc = 0x776f22d2
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0xa6f9a8   0xc6afeb  SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m3
0xa6f9d0  0x776f22d2  <???>
0xa6f9e8   0xc4a39b  LockMutex + 0x4f in ..\src\thread\WIN32\ThreadWin32.m3
0xa6fa10   0xc299f8  GetChar + 0x28 in ..\src\rw\Rd.m3
0xa6fb48   0xc213a8  RApply + 0x1b8 in ..\src\Main.m3
0xa6fb84   0xc4b71b  ThreadBase + 0x255 in ..\src\thread\WIN32\ThreadWin32.m3
0xa6fb90  0x76db336a  <???>
0xa6fbd0  0x7770bf32  <???>
.........  .........  ... more frames ...

Maybe this info will be useful in tracking down the problem.

--Randy

Randy C. Coleburn, CISSP-ISSEP, GCED
Corporate Information Security Officer (CISO)
Scientific Research Corporation
2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339
voice: (770) 989-9464, email: RColeburn at SciRes.com<mailto:RColeburn at SciRes.com>, fax: (770) 989-9497

[logo_SRC]
"Technology Driven-Customer Focused"

Quality Policy:  "SRC is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements."

CONFIDENTIALITY NOTICE:  This email constitutes an electronic communication within the meaning of the Electronic Communications Privacy Act, 18 U.S.C. 2510, and its disclosure is strictly limited to the named recipient(s) intended by the sender of this message.  This email, and any attachments, may contain confidential and/or proprietary information of Scientific Research Corporation.  If you are not a named recipient, any copying, using, disclosing or distributing to others the information in this email and attachments is STRICTLY PROHIBITED.  If you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts or hard copies of the email and attachments.

EXPORT COMPLIANCE NOTICE:  This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR).  Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer.  In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization.  By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements.

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Monday, January 13, 2014 11:04 AM
To: Peter McKinna
Cc: m3devel
Subject: EXT:Re: [M3devel] CM3 crashing

Let us assume that the user-level threads are functioning properly w.r.to GC (can someone confirm?).
In which case, it would be good to have as many eyes as possible take a look at the differences between ThreadPosixC.c (ProcessContext) and ThreadPThreadC.c (ProcessLive) to see if we can spot a problem.

As I understand it, the crash occurs even for non-concurrent (@M3noincremental) and non-generational (@M3nogenerational) GC.  Combined with my assumption that user threads work fine, it would seem to point the finger at stack scanning.  Can someone confirm?

If the failure is *only* with concurrent or generational collection then we might suspect unsafe code (perhaps newly introduced?) messing with heap references without keeping the collector informed.

On Jan 12, 2014, at 10:54 PM, Peter McKinna <peter.mckinna at gmail.com<mailto:peter.mckinna at gmail.com>> wrote:

Hey,
  I was trying to get a handle on that problem last year. The threadtest program is really a stress tester of the collector/allocator with pthreads. If you run it with just the tests read and alloc you pretty much always get a crash. If you run them with paranoidgc it will crash in the heap checker. Tony thought it was a clear cut  problem of the roots of some ref not being found on a thread stack. I mucked around with code to get some output and the stacks looked ok to me but I could be wrong. All stacks are checked whilst the threads are blocked in a signal handler, the design of which looks fine as far as I can tell. This test is characterised by some slow threads (the read threads) and a bunch of fast threads (the alloc threads). Even if you modify the test to have only one read thread the problem occurs. I have had misgivings about mixing signals and threads having been bitten many years ago, but really this is the only way the collector can get its raw refs to check.
My guess is its a subtle timing or lock problem maybe a lurking bug in the collector itself. One thing I noticed is that in ThreadPThread__ProcessStopped  the second call to   p(context, ((char *)context) + sizeof(ucontext_t)); according to the comment is to process the registers. But the registers should already be on the stack and anyway this call is a partial duplicate of the previous one.
It would be good to raise the priority on this problem. Trust in the collector has always been at the heart of m3 programs.
Regards Peter

On Mon, Jan 13, 2014 at 11:25 AM, <mika at async.caltech.edu<mailto:mika at async.caltech.edu>> wrote:
Yes it works in PM3 (still, since I use PM3 on FreeBSD4, never saw a reason to switch to CM3).

I figured there aren't actually implementations of Word.Xor, Word.Or,
and Word.And as procedures but they get inlined somehow?

BTW, any idea about what's wrong with pthreads?  Do you think the issue
is with the garbage collector or with the threads, off the top of your
head?

Tony Hosking writes:
>Are you saying passing these used to work in PM3?
>Sounds like a front-end bug.  I=92m curious what changed to break it.
>
>On Jan 12, 2014, at 12:58 PM, mika at async.caltech.edu<mailto:mika at async.caltech.edu> wrote:
>
>>=20
>> The code is:
>>=20
>>              HIntExpr.Xor =3D> RETURN NewConst(CBitwise(av, bv, =
>Word.Xor), ab)
>>            |
>>              HIntExpr.Bor =3D> RETURN NewConst(CBitwise(av, bv, =
>Word.Or), ab)
>>            |
>>              HIntExpr.Band =3D> RETURN NewConst(CBitwise(av, bv, =
>Word.And), ab)
>>=20
>> I guess it doesn't like passing Word.Xor, Word.Or, and Word.And ...=20
>
>
>
>Antony Hosking | Associate Professor | Computer Science | Purdue =
>University
>305 N. University Street | West Lafayette | IN 47907 | USA
>Mobile +1 765 427 5484<tel:%2B1%20765%20427%205484>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140113/49ca426d/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 11339 bytes
Desc: image002.jpg
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140113/49ca426d/attachment-0002.jpg>