How to reproduce the bug:

- use rotd-2008-08-03
- on a 64bit machine (all works fine on i686)

Type 'make'. This will compile the executable, run it, creating a logfile
called 'test'.

The very end of ./test says:


   ...keeping both histories
Printing H0 at treedecode.m:2063
  H0: h(0, 0.0, '<<foreign>>', sol([]), [], 0, fixed(0), [opened_position(0, ...
   Source of H29H: "H26H"
   VAL: delta(h(26, -0.8609579495780626, '<<foreign>>', sol([delta(h(25, -0.8...
*** Mercury runtime: caught segmentation violation ***
cause: bad permissions for mapped object
address involved: 0x2aaaab59a0f0
This may have been caused by a stack overflow, due to unbounded recursion.
exiting from signal handler


The most interesting part is the comparison of:

H0: h(0, ...

with

VAL: delta(h(26, ...  h(0, ...

The system constructs hypotheses h(...), numbered with increasing integers.
Every new hypothesis contains a list of its predecessors. So H26 contains H0
(further down the chain).

The bug is that H0 gets suddenly garbled.

While dump_h0/0 prints "Fixed H0: ..." and the contents of H0 correctly on line
2063, H0 is garbled in the next (trace) goal when printed as part of the Source
of H29.

My guess is that it is primarily the type info (or program code?) that gets
malformed, because the type h/2 should contain oc_segments in the 9th field:

h( 
  0,
  0.0,
  '<<foreign>>',
  sol([]),
  [],
  0,
  fixed(0),
  [opened_position(0, "--root--")],
  oc_segments(config(inited(no_lm, no_lm)), ...
  ...

(see any occurrence of "h(0" in the log, except for the very last)

but it appears to contain a term of type h/2 after the memory changes:

  VAL: ... sol([delta(h(
    0,
    0.0,
    '<<foreign>>',
    sol([]),
    [],
    0,
    fixed(0),
    [opened_position(0, "--root--")],
    h(46912546371265, 2.31778775968724e-31, '<<foreign>>', sol(


I do not claim it is necessarily Mercury runtime, who is writing somewhere
randomly in the memory. It could be myself. Unfortunately, I'm failing to find
the part of the code that is actually damaging the memory. Even valgrind does
not suggest any problematic spot.

Thanks, Ondrej.
