intel mac crashes

Par of the failure should be fixed by the following
patchlet.  However, 
there is another subsequent failure after applying this.

Thanks,

--- orig/libgst/md-config.h
+++ mod/libgst/md-config.h
 -87,7
+87,7 
  # define REG_AVAILABILITY 0
  # define __DECL_REG1 __asm("%esi")
  # define __DECL_REG2 __asm("%edi")
-# ifdef PIC
+# if defined __PIC__ || defined __pic__
  #  define __DECL_REG3 __asm("%edx")   /* Don't
conflict with GOT 
pointer... */
  # else
  #  define __DECL_REG3 __asm("%ebx")   /* ...but
prefer a callee-save 
reg.  */

Paolo


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

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.no
candysw.com/blog **
Failure to imagine vast possibilities usually stems from a
lack of
imagination, not a lack of possibility.


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

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

Ok, let's commit this as a start.

> 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.  ???

i.e. to access the allocated memory...

Paolo


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Tue, 2007-05-08 at 02:59 -0500, Stephen Compall wrote:
> Okay, I *wasn't* suspicious of _gst_mem_protect, and
OH.
> 
> _gst_mem_protect (addr=0x600e000, len=4096, prot=1)
> 
> (where arg 3 is PROT_READ)

Played with debugging a bit, figured out the sigsegv handler
is never
called, remembered that one of the announcements in
libsigsegv 2.3 was
support for Darwin/x86.  Upgraded to 2.4 install on local
machine;
problem solved.

FAIL: floatmath.st
FAIL: mutate.st

I'll post failure diffs later.

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

_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

> Played with debugging a bit, figured out the sigsegv
handler is never
> called, remembered that one of the announcements in
libsigsegv 2.3 was
> support for Darwin/x86.  Upgraded to 2.4 install on
local machine;
> problem solved.

Cool!

Thanks.

Paolo


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

Stephen Compall wrote:
> On Tue, 2007-05-08 at 02:59 -0500, Stephen Compall
wrote:
>> Okay, I *wasn't* suspicious of _gst_mem_protect,
and OH.
>>
>> _gst_mem_protect (addr=0x600e000, len=4096,
prot=1)
>>
>> (where arg 3 is PROT_READ)
> 
> Played with debugging a bit, figured out the sigsegv
handler is never
> called, remembered that one of the announcements in
libsigsegv 2.3 was
> support for Darwin/x86.  Upgraded to 2.4 install on
local machine;
> problem solved.

I merged 2.4 into the arch repository (should expect no
failures for the 
stable repo, mutate.st for the development repo).

Paolo


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk