#175 Memory violation occurred during evaluation

Compiler (23)
Martin Halama

Dear All,

I am playing a little with thenew version of XSB 3.2 and I have found the following issue (probably with write/1 predicate):

e :- f_err([226,38,250]).

f_err(Ind) :- (phrase(ezz(X,E),Ind,_) -> true ; true), X=x, writeln(E).

ezz(_,_) --> {fail}.

The example does not make sense because I tried to found the issue as close as possible. Goal ?- e. leads to:

Partial Forward Continuation...
... l_write/3
... l_write/3
... _$call/1
... call_query/1
... call_expose/1
... catch/3
... interpreter/0
... ll_code_call/3
... call_expose/1
... catch/3

++Memory violation occurred during evaluation.
++Please report this problem using the XSB bug tracking system accessible from
++ http://sourceforge.net/projects/xsb
++Please supply the steps necessary to reproduce the bug.

Exiting XSB abnormally...

I am running 64-bit Kubuntu. uname -a gives: Linux rakosnicek 2.6.27-11-generic #1 SMP Wed Apr 1 20:53:41 UTC 2009 x86_64 GNU/Linux

I have compiled the XSB with default ./configure with only ODBC support.

best regards,

Martin Halama


  • I first thought this would be related to phrase/*, but now I think it isn't. Here is a smaller program
    that shows problems:

    e1 :-
    (foo(ezz(Y)) ->

    e2 :-
    (foo(ezz(X,Y)) ->
    X = x,

    foo(_) :- fail.

    Try queries ?- e1. % which gives the wrong output
    and ?- e2. % which segfaults as the original program.

    My guess: register allocation/initialization problem.

    BTW, changing the -> into a ! givs the same result.


    Bart Demoen

    • labels: 100887 --> Compiler
    • assigned_to: nobody --> dwarren
  • This is a compiler bug. The compiler is generating a putdval instruction to load the argument E to writeln after which it deallocates and executes writeln, whereas it should use a putuval. I'll try to figure out why.

    • status: open --> closed-fixed
  • Modified the compiler to check when the initial occurrence of a variable not at the top-level is in a conditional (ifthenelse, or or), and in that case does *not* consider the variable safe.