|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000073||mercury||Bug||public||2008-08-05 22:56||2008-08-07 14:56|
|Target Version||Fixed in Version|
|Summary||0000073: garbled memory|
|Description||An object (of a discriminated union type) suddenly changes. It's 9th field which is supposed to be of the type OC (oc_segments.oc_segments/0 in this particular case suddenly appears as of type treedecode.h/2. The contents of the field are garbled and it leads to a segfault in asm_fast.gc and to an infinite loop in hlc.gc.|
Quite possibly, it's me, who is garbling the memory. What's weird though is that the actual change in memory contents happens when I'm not doing anything, except a set.to_sorted_list call.
I'd be grateful for any suggestions,
|Additional Information||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
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, ...
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
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:
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(
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.
|Tags||No tags attached.|
|Please close this bug. I have created a reduced version and posted it separately as bug 0000074.|
|See bug 0000074.|
|2008-08-05 22:56||obo||New Issue|
|2008-08-05 22:57||obo||File Added: standalone.BUG.20080805-1042303618463.tgz|
|2008-08-06 00:26||obo||Note Added: 0000113|
|2008-08-06 00:30||obo||Note Edited: 0000113|
|2008-08-06 00:31||obo||File Added: treedecode.m|
|2008-08-06 00:31||obo||File Added: recombstack.m|
|2008-08-07 02:33||obo||Note Added: 0000114|
|2008-08-07 02:33||obo||Note Deleted: 0000113|
|2008-08-07 14:56||juliensf||Status||new => closed|
|2008-08-07 14:56||juliensf||Note Added: 0000116|
|2008-08-07 14:56||juliensf||Resolution||open => duplicate|