[mercury-users] Stack overflow detection?

[obo at ruk.cuni.cz]

On Wed, 12 May 2004, Zoltan Somogyi wrote:
> At the moment, we catch stack overflow using one of two mechanisms in the low
> level C backend.
>
> The preferred mechanism is a "redzone", a zone at the end of each stack where
> no access is allowed, an attempted access to which causes a SIGSEGV that
> can be caught. The other mechanism is a probe at the time of allocation of
> a stack frame to see if the stack has room for that stack frame.

The redzone mechanism is preferred because such code is faster if there is
still enough space on the stack? From the theoretical point of view and
from the notes you gave, the allocation-probe should be preferred.

> The high level backends use the native stack of the operating system;
> if it isn't extended automatically as needed, the mechanisms to fix that fact
> are operating system-dependent and outside our "jurisdiction".

Currently, I'm using asm_fast.gc but without any reason, in fact. I do not
understand the differences between grades, I just choose the grade that
got successfully compiled here. (Btw., I'm using rotd-2003-09-13).

> > (Generally speaking, it would be better to redesign the code and run into
> > the plain memory exhausted error later, but this is not worth the effort
> > for my task, where I can simply reject all unnice examples.)

Having raised the stack sizes, I ran into the plain out of memory
directly:

GC Warning: Out of Memory!  Returning NIL!

*** Mercury runtime: caught segmentation violation ***
PC at signal: 135373675 (811a36b)
address involved: (nil)
This may have been caused by a stack overflow, due to unbounded recursion.
exiting from signal handler

... so no redesign is necessary, in fact. :-)

> More information about exactly what you want to do would be useful in
answering
> your question.

I'm using Mercury in compulational linguistics to do some corpus work. I
need to read and analyse around 5 million of Czech sentences, select
"simple ones" and collect some information from these. The selection is
performed in Mercury, every word is represented as a feature structure and
the selection is a set of reductions and filters based on regular
expressions over feature structures, ie. over the words. I use
nondeterministic search to find a match for a given regular expression.
Depending on the length and complexity of the input, the nondeterministic
search sometimes fills up the stack. (It is guaranteed that there is no
infinite loop in application of the regular expressions; the reductions
are in general applied in a loop but all non-shortening reductions have a
counter to stop after specific number of iterations.) It is perfectly
correct to simply reject an input sentence on the basis of "memory
exhaustion", such a sentence is definitely not one of the "simple ones"
I'm selecting. In other words: the whole system is quite complicated,
written solely in Mercury and it relies heavily on Mercury.

Naturally, I could use a script wrapper and restart my code
after it segfaults. But shell scripts are always quite randomly
nondeterministic... I just wish to stay in Mercury to handle this situation.

I'd be very grateful for any wrapper predicate, such as the try/2,
promise_only_solution/1 and others are. I know my C experience and
knowledge of Mercury internals is not sufficient for writing anything of
the kind.

Thank you, O.

>
> Zoltan.
> --------------------------------------------------------------------------
> mercury-users mailing list
> post:  mercury-users at cs.mu.oz.au
> administrative address: owner-mercury-users at cs.mu.oz.au
> unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
> subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
> --------------------------------------------------------------------------
>

--
Ondrej Bojar (mailto:obo at cuni.cz)
http://www.cuni.cz/~obo


--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------