<div dir="ltr"><div><div><div>Hey,<br><br></div>  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. <br>
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.<br>
</div>It would be good to raise the priority on this problem. Trust in the collector has always been at the heart of m3 programs. <br><br></div>Regards Peter<br><div><div><br></div></div></div><div class="gmail_extra"><br>
<br><div class="gmail_quote">On Mon, Jan 13, 2014 at 11:25 AM,  <span dir="ltr"><<a href="mailto:mika@async.caltech.edu" target="_blank">mika@async.caltech.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yes it works in PM3 (still, since I use PM3 on FreeBSD4, never saw a reason to switch to CM3).<br>
<br>
I figured there aren't actually implementations of Word.Xor, Word.Or,<br>
and Word.And as procedures but they get inlined somehow?<br>
<br>
BTW, any idea about what's wrong with pthreads?  Do you think the issue<br>
is with the garbage collector or with the threads, off the top of your<br>
head?<br>
<div class="im"><br>
Tony Hosking writes:<br>
>Are you saying passing these used to work in PM3?<br>
</div>>Sounds like a front-end bug.  I=92m curious what changed to break it.<br>
<div class="im">><br>
>On Jan 12, 2014, at 12:58 PM, <a href="mailto:mika@async.caltech.edu">mika@async.caltech.edu</a> wrote:<br>
><br>
</div>>>=20<br>
>> The code is:<br>
>>=20<br>
>>              HIntExpr.Xor =3D> RETURN NewConst(CBitwise(av, bv, =<br>
>Word.Xor), ab)<br>
>>            |<br>
>>              HIntExpr.Bor =3D> RETURN NewConst(CBitwise(av, bv, =<br>
>Word.Or), ab)<br>
>>            |<br>
>>              HIntExpr.Band =3D> RETURN NewConst(CBitwise(av, bv, =<br>
>Word.And), ab)<br>
>>=20<br>
>> I guess it doesn't like passing Word.Xor, Word.Or, and Word.And ...=20<br>
><br>
><br>
><br>
>Antony Hosking | Associate Professor | Computer Science | Purdue =<br>
<div class="HOEnZb"><div class="h5">>University<br>
>305 N. University Street | West Lafayette | IN 47907 | USA<br>
>Mobile <a href="tel:%2B1%20765%20427%205484" value="+17654275484">+1 765 427 5484</a><br>
><br>
><br>
><br>
><br>
</div></div></blockquote></div><br></div>