2024-06-21 20:32 AEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000270mercuryBugpublic2012-12-31 00:22
Assigned Tojuliensf 
PlatformPC Intel Core I7 2.8GHz, 2.9GB mOSUbuntu Linux OS Version10.04
Product Version 
Target VersionFixed in Version 
Summary0000270: When one uses fact_table, the mercury compiler crashes if there is an error in the fact_table.
DescriptionHere is a small program without errors:

% dic.m
wrd("cat", "catus").
wrd("dog", "canis").
wrd("horse", "equus").
wrd("person","homo sapiens").

% bug.m
:- module bug.

:- interface.
:- import_module io.
:- pred main(io::di, io::uo) is cc_multi.

:- implementation.
:- import_module string, list, char.
:- pred wrd( string::in, string::out) is nondet.
:- pragma fact_table( wrd/2, "dic.m").

main(!IO) :-
   ( wrd("horse", X) ->
     print(X,!IO), nl(!IO)
   ; true ).

The command below compiles the above program flawlessly:

> mmc --infer-all --use-subdirs --rebuild bug

However, If I introduce an error in the fact_table, the compiler freezes. For example, let us forget the comma between "horses" and "equus":

% dic.m
wrd("cat", "catus").
wrd("dog", "canis").
wrd("horse" "equus").
wrd("person","homo sapiens").

Now, instead of reporting the error, the compiler freezes.
Steps To ReproduceIn the description of the bug, you will find the steps to reproduce the bug. I tried it in different machines, and I always was able to reproduce the freezing of the compiler. Since I am writing large programs that requires fact_tables I would like that the compiler report errors, instead of crashing or freezing.

% Correct fact_table
% dic.m
wrd("cat", "catus").
wrd("dog", "canis").
wrd("horse", "equus").
wrd("person","homo sapiens").

% Fact_table that freezes the compiler
% dic.m
wrd("cat", "catus").
wrd("dog", "canis").
wrd("horse" "equus").
wrd("person","homo sapiens").
TagsNo tags attached.
Attached Files
  • ? file icon bug.m (317 bytes) 2012-12-30 05:58




juliensf (administrator)

Have you tried compiling the program as without the fact table pragma? Recent versions of the compiler should be able to generate as efficient code for predicates like wrd/2 without the fact_table/1 pragma.
(IIRC the only difference is that without the fact_table pragma the compiler may not be able to type check
that predicate as quickly.)


juliensf (administrator)

The problem is that when building the fact table, the compiler tries to keep going when it encounters
an error in one of the facts. With verbose output enabled:

% Reading short interface for module `Mercury/int2s/rtti_implementation.int2'... successful parse.
% Module qualifying items...
% done.
% Expanding equivalence types...
% done.
% Converting parse tree to hlds...
% Read fact 0
dic.m:003: Syntax error at string "equus": expected `,', `)', or operator
% Invoking system command `cat >>Mercury/cs/dic.m.c, ...

It is the invocation of cat after something as gone wrong that is causing the compiler to freeze.


edu500ac (reporter)

juliensf said: "Recent versions of the compiler should be able to generate as efficient code for predicates like wrd/2 without the fact_table/1 pragma." Mauro and Junia wrote a vastly simplified program to demonstrate the bug. The actual program generates user guides and manuals for electronic goods. The generated text can be in many language, like Swahili, Spanish, French and Portuguese, and Guarany. The program builds fact tables from dictionaries and model texts. The fact tables are huge. The arity ranges from 10 to 8. The modes vary from module to module. For example, a mode could be xword(out, out, in, out, in, in, out, out, in, out). The program may consult a chain of 8 nondet dictionaries before making a decision.

My question is: Can Mercury compiler handle such fact-tables without the pragma declaration? If it can, I think that Mauro and Junia should use standard predicates instead, since their Common Lisp PPCRE programs that generate the fact tables often make mistakes, that confuse the Mercury compiler. Another solution would be to fix the Common Lisp programs to make sure that they don't make mistakes, when allocating a generated fact to a given table. However, I am not sure whether this allocation would be easy, since the decision is made by a neural network.

-Issue History
Date Modified Username Field Change
2012-12-30 05:58 maurojh New Issue
2012-12-30 05:58 maurojh File Added: bug.m
2012-12-30 13:47 juliensf Note Added: 0000487
2012-12-30 13:47 juliensf Assigned To => juliensf
2012-12-30 13:47 juliensf Status new => feedback
2012-12-30 13:58 juliensf Note Added: 0000488
2012-12-30 13:58 juliensf Status feedback => confirmed
2012-12-31 00:22 edu500ac Note Added: 0000489
+Issue History