Mercury Bugs - mercury | |||||
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 |
Reporter | obo | ||||
---|---|---|---|---|---|
Assigned To | |||||
Priority | normal | Severity | crash | Reproducibility | always |
Status | closed | Resolution | duplicate | ||
Platform | OS | OS Version | |||
Product Version | |||||
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, Ondrej. | ||||
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 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. | ||||
Tags | No tags attached. | ||||
Relationships | |||||
Attached Files | standalone.BUG.20080805-1042303618463.tgz (354,051) 2008-08-05 22:56 https://bugs.mercurylang.org/file_download.php?file_id=58&type=bug treedecode.m (91,169) 2008-08-06 00:31 https://bugs.mercurylang.org/file_download.php?file_id=59&type=bug recombstack.m (9,102) 2008-08-06 00:31 https://bugs.mercurylang.org/file_download.php?file_id=60&type=bug |
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 |