[mercury-users] Mercury runtime problem on Windows

Julien Fischer juliensf at csse.unimelb.edu.au
Fri Aug 14 12:46:26 AEST 2009

On Fri, 14 Aug 2009, Paul Bone wrote:

> On Thu, Aug 13, 2009 at 10:28:42PM +1000, Michael Day wrote:
>> Hi Paul,
>>> AIUI this is for the detection and slightly-more-graceful handling of memory
>>> access errors.  In some places in the runtime we use mprotect() to ensure that
>>> reads or writes to that memory are caught as errors, I forget exactly what this
>>> is for but perhaps to catch stack overruns, this may be related to our SIGSERV
>>> handler.
>> In this case it seems that the signal handler is only necessary to give
>> a suitable error message for runtime or program errors. Since in this
>> case it is actually causing a serious error, and is not required for
>> correct program operation, it would be nice if it were optional.
>> Can this be done? It seems to be simply a matter of ignoring the return
>> value, or perhaps printing a message or aborting only in debug grades?
> I'm not convinced that this is a good idea.  We need to determine if the signal
> hander is required by our use of mprotect().  We also need to determine the
> cause of this behaviour, we're still just guessing.

The signal handler is not required to use mprotect(); it just prints out
a nice error message.

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