[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Help-smalltalk] Re: [call for testing] intel mac crashes
From: |
Stephen Compall |
Subject: |
[Help-smalltalk] Re: [call for testing] intel mac crashes |
Date: |
Thu, 03 May 2007 02:48:00 -0500 |
User-agent: |
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1 |
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.
- [Help-smalltalk] Re: [call for testing] intel mac crashes,
Stephen Compall <=