[Help-smalltalk] Re: [call for testing] intel mac crashes

[Stephen Compall]

I can verify that the patch seems to work, and that the REGISTER macro 
is pretty wild.

Also it is not nice that "heap" means a different thing in most of the 
system (_gst_mem_new_heap heaps) than in heap.c and morecore 
(_gst_heap_create heaps).  I will chalk this up to evil genius.

Unrelated bug: All the users of _gst_osmem_commit expect =>0 --> 
failure.  However, anon_mmap_commit answers mmap's result directly, 
which is -1 for failure.  Adding

return UNCOMMON(result == MAP_FAILED) ? NULL : result;

to anon_mmap_commit presumably fixes this, not that I've ever had mmap fail.

I've followed the execution down to watching the call to mmap that 
should map the address that later fails complete successfully.  I traced 
heap_primitive_free and _gst_osmem_free (aka decommit) and they were 
never called.

Okay.  The failure address is 0x600e018, 24 bytes after 0x600e000, which 
is the value of blk.  By my count, that is an attempt to access the 
unused long double data[1] field.  ???

--
;;; Stephen Compall ** http://scompall.nocandysw.com/blog **
Failure to imagine vast possibilities usually stems from a lack of
imagination, not a lack of possibility.