[MLton] osx compiles again in x86_64 branch

[Wesley W. Terpstra]

On May 23, 2006, at 10:52 PM, Matthew Fluet wrote:
>> The problem is now that compiled programs segfault! :-)
>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>> Reason: KERN_INVALID_ADDRESS at address: 0x00514e24
>> 0x00140d3c in performGC ()
>> (gdb) bt
>> #0  0x00140d3c in performGC ()
>> #1  0x00142d98 in GC_collect ()
>> #2  0x00013848 in Chunk25 ()
>> #3  0x001396a4 in main ()
>>
>> I'll look into this in more detail shortly.
>
> If you haven't tried it already, I'd recommend doing a 'make clean'  
> in the x86_64 sources and bootstrap with mlton-20051205.  There  
> were a couple of times when I got segfaults with the C-codegen on  
> linux, but I couldn't reproduce them when I rebuilt from clean  
> sources.  (I suspect the underlying issue is that the Makefiles  
> don't accurately reflect all of the real dependencies, and  
> sometimes you can introduce inconsistencies when hacking on the  
> runtime.)

I don't trust MLton's makefiles at all. :-) I always rebuild from  
clean source, which rather defeats the point of having a makefile, I  
grant, but the current Makefiles have bit me too many times. However,  
I've been using MLton 20051109. Is this deficient in some way?

Anyways, the problem persists, but I have more information. At some  
point, the stack is getting corrupted. The stack was normally a very  
large number, then after some point it ends up pointing to 0x1d16b0.  
This is valid.

> (gdb) print getStackCurrent(s)
> $55 = (struct GC_stack *) 0x1d16b0
> (gdb) print *getStackCurrent(s)
> $56 = {
>   markTop = 0x0,
>   markIndex = 0,
>   reserved = 536,
>   used = 124
> }

Things start going wrong after an attempt to remapHeap fails (because  
on osx HAS_REMAP is FALSE). I imagine this is why you don't have the  
problem on linux. It then enters (from gc/heap.c:306) releaseHeap. At  
this point, the stack is still fine. Then, this happens:

> Breakpoint 10, growHeap (s=0xcadc0, desiredSize=243552,  
> minSize=30444) at gc/heap.c:306
> 306         releaseHeap (s, curHeapp);
> (gdb) print *getStackCurrent(s)
> $81 = {
>   markTop = 0x0,
>   markIndex = 0,
>   reserved = 536,
>   used = 124
> }
> (gdb) print getStackCurrent(s)
> $82 = (struct GC_stack *) 0x1d16b0
> (gdb) s
>
> Breakpoint 8, releaseHeap (s=0xcadc0, h=0xcb008) at gc/heap.c:110
> 110       if (NULL == h->start)
> (gdb) s
> 112       if (DEBUG or s->controls.messages)
> (gdb)
> 116       GC_release (h->start, h->size);
> (gdb)
>
> Breakpoint 9, GC_release (base=0x1ce000, length=28672) at platform/ 
> use-mmap.c:8
> 8               munmap_safe (base, length);

... I trust you see the problem? :-)