[M3devel] CM3 crashing

[Jay K]

Here is my failed attempt to demonstrate the wow64  bug.
Make sense?
Repros for anyone? I only tried Windows 8 so far.
 
 
#undef NDEBUG
#include <assert.h>
#include <stddef.h>
#include <windows.h>
void* _AddressOfReturnAddress(void);
volatile size_t expected;
#define PAGE 4096
__declspec(noinline) void X(void)
{
  expected = (size_t)_AddressOfReturnAddress();
  Sleep(1);
  expected = 0;
}
__declspec(noinline) void F1(void) { volatile char a[PAGE * 8]; X(); }
__declspec(noinline) void F2(void) { volatile char a[PAGE * 4]; X(); }
__declspec(noinline) unsigned long __stdcall Thread(PVOID parameter)
{
  while (1)
  {
    F1();
    F2();
  }
  return 0;
}
int __cdecl wmain()
{
  unsigned __int64 count = 0;
  HANDLE thread = CreateThread(0, 0, Thread, 0, 0, 0);
  CONTEXT context;
  ZeroMemory(&context, sizeof(context));
  context.ContextFlags = CONTEXT_CONTROL;
  //while (count++ < 1000000)
  while (1)
  {
    SuspendThread(thread);
    GetThreadContext(thread, &context);
    assert(expected == 0 || (context.Esp && context.Esp < expected));
    ResumeThread(thread);
  }
}

 - Jay


 
Date: Mon, 13 Jan 2014 14:54:08 +1100
From: peter.mckinna at gmail.com
To: mika at async.caltech.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] CM3 crashing

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/20140115/7fcd3a4f/attachment-0002.html>