[mercury-users] Re: problems

[Fergus Henderson]

On 22-Sep-1998, Thomas Charles CONWAY <conway at cs.mu.OZ.AU> wrote:
> Tomas By, you write:
> > | Mercury runtime: memory zone detstack#0 overflowed
> > | PC at signal: -277789040 (ef714690)
> > | You can get a stack dump by using grade debug
> > 
> > The machine is a Sun with 256MB running Solaris 2.6.
> > 
> > Since I can't add any printing anywhere I don't quite know where
> > to start.

In extras/trailed_update/unsafe.m there is a procedure called
`unsafe_perform_io' which can be used to add debugging print
statements for debugging this kind of thing.

> > What kind of information is it that there was too much
> > of? (Call frames? / local data structures? / both?)

Call frames and/or local variables for procedures whose
determinism is neither `nondet' nor `multi'.

> > Do you have
> > any suggestions for how to approach this?

1. As Tom said, try enlarging the det stack using the
   MERCURY_OPTIONS environment variable.
   See the Mercury user's guide and/or set MERCURY_OPTIONS
   to `-h' for help.

2. Use `unsafe_perform_io' to add debugging print statements.

3. Download a very recent ROTD version of the Mercury distribution,
   compile your program with `--debug', run it with `mdb'
   and trace through your program's execution to see where/why
   it is using so much stack space.

4. Compile your program with termination analysis enabled.
   This may help you spot infinite loops (or even performance
   problems -- the procedures for which termination analysis
   can't prove termination may well be the ones using up the
   stack space, even if they do eventually terminate).

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.