2024-11-21 23:30 AEDT
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000073mercuryBugpublic2008-08-05 22:562008-08-07 14:56
Reporterobo 
Assigned To 
PrioritynormalSeveritycrashReproducibilityalways
StatusclosedResolutionduplicate 
Product Version 
Target VersionFixed in Version 
Summary0000073: garbled memory
DescriptionAn 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,
  Ondrej.
Additional InformationHow 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.
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0000114

obo (reporter)

2008-08-07 02:33

 Please close this bug. I have created a reduced version and posted it separately as bug 0000074.

~0000116

juliensf (administrator)

2008-08-07 14:56

 See bug 0000074.
+Notes

-Issue History
Date Modified Username Field Change
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
+Issue History