<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>ok, I augmented the test a bit and commited it to CVS and I can see it fail now.<BR>Does the test make sense to people?<BR> <BR>Thanks,<BR> - Jay<br><br> <BR><div><hr id="stopSpelling">From: jay.krell@cornell.edu<br>To: peter.mckinna@gmail.com; mika@async.caltech.edu<br>Date: Wed, 15 Jan 2014 05:01:16 +0000<br>CC: m3devel@elegosoft.com<br>Subject: Re: [M3devel] CM3 crashing<br><br>
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr">Here is my failed attempt to demonstrate the wow64 bug.<br>Make sense?<br>Repros for anyone? I only tried Windows 8 so far.<br> <br> <br>#undef NDEBUG<br>#include <assert.h><br>#include <stddef.h><br>#include <windows.h><br>void* _AddressOfReturnAddress(void);<br>volatile size_t expected;<br>#define PAGE 4096<br>__declspec(noinline) void X(void)<br>{<br> expected = (size_t)_AddressOfReturnAddress();<br> Sleep(1);<br> expected = 0;<br>}<br>__declspec(noinline) void F1(void) { volatile char a[PAGE * 8]; X(); }<br>__declspec(noinline) void F2(void) { volatile char a[PAGE * 4]; X(); }<br>__declspec(noinline) unsigned long __stdcall Thread(PVOID parameter)<br>{<br> while (1)<br> {<br> F1();<br> F2();<br> }<br> return 0;<br>}<br>int __cdecl wmain()<br>{<br> unsigned __int64 count = 0;<br> HANDLE thread = CreateThread(0, 0, Thread, 0, 0, 0);<br> CONTEXT context;<br> ZeroMemory(&context, sizeof(context));<br> context.ContextFlags = CONTEXT_CONTROL;<br> //while (count++ < 1000000)<br> while (1)<br> {<br> SuspendThread(thread);<br> GetThreadContext(thread, &context);<br> assert(expected == 0 || (context.Esp && context.Esp < expected));<br> ResumeThread(thread);<br> }<br>}<br><br> - Jay<br><br><br> <br><div><hr id="ecxstopSpelling">Date: Mon, 13 Jan 2014 14:54:08 +1100<br>From: peter.mckinna@gmail.com<br>To: mika@async.caltech.edu<br>CC: m3devel@elegosoft.com<br>Subject: Re: [M3devel] CM3 crashing<br><br><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="ecxgmail_extra"><br>
<br><div class="ecxgmail_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="ecxgmail_quote" style="padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">
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="ecxim"><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="ecxim">><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="ecxHOEnZb"><div class="h5">>University<br>
>305 N. University Street | West Lafayette | IN 47907 | USA<br>
>Mobile <a target="_blank">+1 765 427 5484</a><br>
><br>
><br>
><br>
><br>
</div></div></blockquote></div><br></div></div> </div></div> </div></body>
</html>