Dear all,
I am sure I am missing something but I don't know what.
After a quite long debugging session, I have the following
fragment in my C++ code:
prolog_term x = p2p_new();
if (is_var(x) == FALSE)
abort(); // This statement does not get executed.
if (c2p_list(x) == FALSE)
abort(); // This statement does not get executed.
// Hey, how can `x' still be a variable?
if (is_var(x) == TRUE)
abort(); // This statement IS executed.
`x' is initialized to a fresh variable (so that the first
call to abort() is not executed), then the call to c2p_list()
is successful (so that the second call to abort() is not executed),
but afterwards `x' is still bound to a variable (and the third
call to abort() is executed).
Any idea why that happens?
All the best
Roberto
P.S. I am using XSB 2.5
$ xsb
[xsb_configuration loaded]
[sysinitrc loaded]
[packaging loaded]
XSB Version 2.5 (Okocim) of March 11, 2002
[i686-pc-linux-gnu; mode: optimal; engine: slg-wam; gc: indirection; scheduling: local]
| ?-
--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara@cs.unipr.it
Dear all,
thanks for the workaround. The patch below allowed me to get around
the XSB bug I reported some time ago. I can thus continue developing
an XSB interface for the Parma Polyhedra Library (http://www.cs.unipr.it/ppl/).
All the best
Roberto
Luis Fernando Pias de Castro wrote:
> Hi,
>
> well, it seems both Kostis and David were right. ;)
>
> The problem is due to a use of numbervars *inside* the singleton
> checks. The patch below seems to eliminate the segfault in this case,
> even though it has the side-effect of missing the warning. Any
> suggestions of how to deal with this better? Or should I commit this?
>
> Thanks,
> -Luis
>
> ===================================================================
> RCS file: /cvsroot/xsb/XSB/cmplib/singlton.P,v
> retrieving revision 1.3
> diff -c -r1.3 singlton.P
> *** singlton.P 18 Aug 1999 22:05:23 -0000 1.3
> --- singlton.P 22 Jul 2002 20:33:20 -0000
> ***************
> *** 78,83 ****
> --- 78,85 ----
> arg(NewN, Term, Arg), % We cannot use ll_arg/3 here (Term may be a list)
> ( Arg = '$VAR'(Number) ->
> ( integer(Number) ->
> + Number > 0,
> + Number =< Arity,
> ll_arg(Number, Occurences, OccCount),
> ( var(OccCount) -> OccCount = found(_)
> ; OccCount = found(Times) ->
>
>
> Kostis Sagonas <kostis(a)csd.uu.se> writes:
>
>
>>David wrote:
>>
>> > Yup, it's a bug. I'm quite sure it arises because the compiler is
>> > using numbervars, and gets confused about your use of $VAR(0) and its
>> > use of $VAR(0) for the variable A.
>>
>>Not quite. Just in case it was not clear from my previous message,
>>the problem is due to the singleton check pass of the XSB compiler,
>>not the use of numbervars.
>>
>>I bet that in XSB a similar problem can be observed in compiling
>>something like:
>>
>> p :- A = '$VAR'(87456).
>>
>>Or using some other big number. NOT related to numbervars!
>>
>>Kostis.
--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara@cs.unipr.it
