Mercury Bugs - mercury
View Issue Details
0000048mercuryBugpublic2008-02-28 02:552008-03-26 15:32
Assigned Tomark 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000048: compiler abort in .decldebug grade
DescriptionCompiling compiler/analysis.m in asm_fast.gc.decldebug on pluto (linux-x86_64) results in

Uncaught Mercury exception:
Software Error: map.lookup: key not found
Key Type: term.var(parse_tree.prog_data.prog_var_type)
Key Value: var(160)
Value Type: ll_backend.var_locn.var_state

This Mercury compiler used was rotd-2008-02-27.
Compiling the affected module with -O0 makes the problem go away.
TagsNo tags attached.
Attached Files? DIFF.55_65 (11,818) 2008-02-28 16:27

2008-02-28 03:03   
I've added the workaround for this to compiler/Mercury.options and committed it.
2008-02-28 11:45   
--common-struct seems to be triggering the problem. The bug does not occur with
2008-02-28 16:33   
The problem is caused by one or more bugs in common.m, as shown by the attached diff between the HLDS dumps at level 55 and 65. The diff shows that common.m finds and eliminates several common structures, most of which are type_infos or type_ctor_infos, and one of which is an ordinary field of the analysis_info structure. I have visually examined the diff and I think all these changes in the code are fine.

The problems lie in the changes to the rtti var maps. The diff shows some updates to type_class_info maps that I don't think should be there. It does NOT show updates to type_info maps that SHOULD be there. Common.m eliminates several type_info variables, replacing them with references to other, identical type_info variables, but does not update the rtti_var_maps. (common.m was written BEFORE we added rtti_var_maps.) I believe these dangling references that cause the bug symptom.
2008-02-28 17:13   
For reference, this is r1.2 of compiler/analysis.m.
2008-03-26 12:51   
I've committed one fix to some dangling references left by common.m
(26/3/2008). This allows compilation of analysis.m to complete.
However, similar segfaults have been reported in the G12 project,
so I'll leave this bug open and investigate further.
2008-03-26 15:32   
The other failures were caused by a different bug,
which I have reported as bug 0000054

Issue History
2008-02-28 02:55juliensfNew Issue
2008-02-28 03:03juliensfNote Added: 0000080
2008-02-28 11:45juliensfNote Added: 0000081
2008-02-28 16:27zsFile Added: DIFF.55_65
2008-02-28 16:33zsNote Added: 0000082
2008-02-28 17:10juliensfStatusnew => assigned
2008-02-28 17:10juliensfAssigned To => mark
2008-02-28 17:13juliensfNote Added: 0000083
2008-03-26 12:51markNote Added: 0000091
2008-03-26 15:32markNote Added: 0000092
2008-03-26 15:32markStatusassigned => resolved
2008-03-26 15:32markResolutionopen => fixed