2024-11-24 13:10 AEDT
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000117mercuryBugpublic2009-11-28 02:362015-10-31 19:04
Reporterpjrm 
Assigned Tojuliensf 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
Product Version 
Target VersionFixed in Version 
Summary0000117: No error message for false non_empty_list declaration; runtime segfault
Description(The available "Severity" values aren't quite right for a compiler. I chose "minor" on the grounds that it affects only incorrect programs, though it's among the more serious of this class, in that it still compiles, but the resulting executable segfaults.)

I have a program where a function's output variable's mode is declared as out(non_empty_list), but where in fact the result can be empty. The program compiles with no warnings (whether with --debug or --grade=hlc.gc), but segfaults when it generates an empty list for a caller that assumes non-emptiness. (I have a feeling that in some cases the executable silently produces wrong results rather than segfaulting, though I'm not certain.)

I haven't yet made a minimal example, but can do so on request.

Tested with rotd-2009-02-26 and a 2007 version.
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0000220

wangp (developer)

2009-12-01 01:53

 Can you post a test case?

~0000222

pjrm (reporter)

2009-12-01 03:13

 I've attached two files, nonempty12.m and call_nonempty12.m. The first is the one of interest, in that it compiles without error. The second is the obvious corresponding `main' predicate that segfaults when trying to access the first element of the list.

The test case is remarkably simple, not at all the highly specific circumstances I'd usually have for a Mercury compiler bug; I suppose then that it must be related to one of the several already-known limitations in the current mode system implementation.

I've tested with rotd-2009-02-26 on i686-pc-linux-gnu (Debian), with mgnuc=gcc-3.4.6, with both
`mmc --make --debug call_nonempty12 && ./call_nonempty12' and
`mmc --make --grade=hlc.gc call_nonempty12 && ./call_nonempty12'.
(Also tested with rotd-2007-12-16, so it's fairly long-standing.)

~0000223

wangp (developer)

2009-12-01 21:35

 The problem is the following XXX.

inst_matches_final_3(ground(UniqA, HOInstInfoA), bound(UniqB, ListB),
        MaybeType, !Info) :-
    ModuleInfo = !.Info ^ imi_module_info,
    \+ ho_inst_info_is_nonstandard_func_mode(ModuleInfo, HOInstInfoA),
    unique_matches_final(UniqA, UniqB),
    bound_inst_list_is_ground(ListB, MaybeType, ModuleInfo),
    uniq_matches_bound_inst_list(UniqA, ListB, ModuleInfo),
    (
        MaybeType = yes(Type),
        % We can only do this check if the type is known.
        bound_inst_list_is_complete_for_type(set.init, ModuleInfo, ListB, Type)
    ;
        true
        % XXX enabling the check for bound_inst_list_is_complete
        % for type makes the mode checker too conservative in
        % the absence of alias tracking, so we currently always
        % succeed, even if this check fails.
    ).

~0000858

juliensf (administrator)

2015-10-31 19:04

 This was fixed in commit 491bb0a.
(I have added a test case for it.)
+Notes

-Issue History
Date Modified Username Field Change
2009-11-28 02:36 pjrm New Issue
2009-12-01 01:53 wangp Note Added: 0000220
2009-12-01 03:02 pjrm File Added: nonempty12.m
2009-12-01 03:03 pjrm File Added: call_nonempty12.m
2009-12-01 03:13 pjrm Note Added: 0000222
2009-12-01 21:35 wangp Note Added: 0000223
2009-12-11 06:47 juliensf Status new => confirmed
2015-10-31 19:04 juliensf Note Added: 0000858
2015-10-31 19:04 juliensf Status confirmed => resolved
2015-10-31 19:04 juliensf Resolution open => fixed
2015-10-31 19:04 juliensf Assigned To => juliensf
+Issue History