[M3devel] CM3 crashing
Tony Hosking
hosking at cs.purdue.edu
Mon Jan 13 21:02:57 CET 2014
Is this from the head of source?
Also, please run with @M3paranoidgc flag.
On Jan 13, 2014, at 2:55 PM, Coleburn, Randy <rcolebur at SCIRES.COM> wrote:
> I’ve also tested on 32-bit Windows XP and the thread test program crashes there also.
>
> C:\cm3\Sandbox\cm3\m3-libs>set CM3_TARGET=NT386
>
> C:\cm3\Sandbox\cm3\m3-libs>cm3 --version
> Critical Mass Modula-3 version d5.9.0
> last updated: 2010-07-21
> compiled: 2013-12-17 17:28:52
> configuration: C:\cm3\bin\cm3.cfg
> host: NT386
> target: NT386
>
> Here is the output:
>
> C:\cm3\Sandbox\cm3\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 = 0x42e34a = Move + 0x50 in ..\src\runtime\common\RTCollector.m3
> ***
>
> ***
> *** 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 assert repeats indefinitely until you press CTRL-C.
>
> --Randy
>
>
> From: Coleburn, Randy
> Sent: Monday, January 13, 2014 2:17 PM
> To: Tony Hosking; Peter McKinna
> Cc: m3devel
> Subject: Re: [M3devel] CM3 crashing
>
> 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:
> *** 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.
>
> ***
> *** 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
>
>
> 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> 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> 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 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
> >
> >
> >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140113/c56a7e47/attachment-0002.html>
More information about the M3devel
mailing list