[mercury-users] Crash on MacOS X

Peter Ross pro at missioncriticalit.com
Fri Nov 7 12:37:07 AEDT 2008

On Thu, Nov 6, 2008 at 11:21 PM, Michael Day <mikeday at yeslogic.com> wrote:
>> I'll test again with the latest release of the day and see how it goes.
> Slightly different error with the latest rotd:
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0xbf7fffcc
> 0x00355bc2 in mercury__builtin__compare_3_p_0 (ti=28447408, res=0x0, x=0x0,
> y=0x0) at mercury_ho_call.c:214
> 214     mercury_ho_call.c: No such file or directory.
>        in mercury_ho_call.c
> (gdb) bt
> #0  0x00355bc2 in mercury__builtin__compare_3_p_0 (ti=28447408, res=0x0,
> x=0x0, y=0x0) at mercury_ho_call.c:214
> Cannot access memory at address 0xbf7fffdc
> Cannot access memory at address 0xbf7fffe0
> However, it's still basically a NULL pointer dereference, occurring in the
> middle of pure Mercury code with no C code or low-level hackery in sight, so
> it's a bit frustrating.
> I'll try and narrow down the test case, but it's difficult to even know
> where to begin.
We had a similar problem at MC.  Our problem was that some memory was
being prematurely collected and as a by-product of that process being
zero'd.  Hence the null pointer exceptions.

For us the problem was that we were using the expat C library, but
telling it to use boehmgc to manage memory.  Anyway it was incorrectly
calling GC_free at some points and this was somehow confusing the gc.
So instead we passed to expat a no-op function for freeing memory, and
allowed boehmgc to decide itself when to free the memory.

Maybe you have a similar problem?

We found it by compiling with GC_ASSERTION as a #define.

mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au

More information about the users mailing list