[M3devel] CM3 crashing

[Tony Hosking]

On Jan 12, 2014, at 7:25 PM, 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).

Interesting.  Needs exploration.  This should be filed as a bug.  The workaround is to wrap the builtin calls (Word.Xor, etc.) in a local procedure so that you have an addressable procedure.

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

Yes, they are inlined, but there *is* an implementation in Word.m3 (generated from GenWord.mg).

> 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?

It must be the threads implementation, since the same collector is used with both pthreads and user threads, and I believe that user threads don’t suffer from this problem.  My intuition is that it may be a problem with getting stack roots on particular platforms, probably because the stack bounds are not being computed correctly for a given architecture, or perhaps because reference alignment is not being observed correctly.  For example, is it possible on x86_64 to have references stored in the stack aligned on 32-bit instead of 64-bit boundaries?

I notice that RTThread.i3 says the pointer alignment is BYTESIZE(ADDRESS) on all platforms.  Once upon a time the alignment was platform-dependent, so I wonder if we lost something somewhere with all the backend and porting work.  It may be that the backend needs to be instructed to align all references appropriately in the stacks.

One way to test all this might be to see if the thread stress tester causes things to break on older 32-bit platforms, where I expect all pointers will be aligned properly.

Also, I’ve not inspected the code in ThreadPThreadC.c recently (it’s changed since I last looked), but I wonder if the stack bounds are being computed correctly so that the collector can find all the stack roots.

I’d really like to get to the bottom of this problem.

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