The fac_dcg.pl code I'm attaching is buggy (it's very much work-in-progress/experimenting) and isn't something I'd normally show to anyone but I thought you'd like the crash report. The crash occurs with both 3.4.0 and the latest 3.5.0.
I think the problem is an errant table declaration (the crash goes away when I remove all the table declarations) and maybe it's nothing more than a table exploding. Or it could be some strange interaction with when/2 and tables. Anyway, here it is.
Attached is a tar file with 3 files:
fac_dcg.pl
s_domain.pl
crash-xsb-log.txt
The .txt file shows what happens when I did:
$ xsb
[fac_dcg].
interp(passthru_plus(Z)), s_domain:domains_as_items([Z]), writeln(z=Z), fail.
In addition, if I uncommented line 73 of interp.pl (:- table interp/1), the same query would put XSB into some kind of infinite loop.
And another program got a crash (segfault) in table_dump from a similar program (attached with log). My simple "read_table1" did work but table_dump exploded.
With a small variation in the code, I got:
++Error[XSB/Runtime/P]: [Representation (Arity needed for return template is not less than MAX_ARITY)] in arg 4 of predicate trie_intern/4 or other tabling routine
Is there anything I can do to get more information for debugging this?
And, with another small variation (what debug info do you want?)
Not interned (wrongly GC-ed?): trie 2: '0x10193e688',D≈
Not interned (wrongly GC-ed?): trie 2: '0x10193e688',D≈
Partial Forward Continuation...
... interp_list/1 From /Users/pludemann/src/larch/tmp/plus_delayed.xwam
... interp/1 From /Users/pludemann/src/larch/tmp/plus_delayed.xwam
... $interp_list/1 From /Users/pludemann/src/larch/tmp/plus_delayed.xwam
... $interp_list/1 From /Users/pludemann/src/larch/tmp/plus_delayed.xwam
... interp_list/1 From /Users/pludemann/src/larch/tmp/plus_delayed.xwam
(skipping several dozen repeats of the above)
++Error[XSB]: [Runtime/C]
++Memory violation occurred during evaluation.
Hi Peter
I'm currently in Vienna, vacationing for a couple of days after a conference, and David is probably returning from the same conference. I'll download your files so I can try to debug them on the plane ride back (Saturday).
Here is my guess. You tabled an answer and/or call with more than 255 variables. The core tabling algorithms handle it, but calling get_returns tries to put the result in a ret/N structure with N over 255. Probably not too hard to fix, but at the very least we should have an error message that makes sense to someone who is not a developer.
Hi Terry: that makes sense (I'm probably creating a list of more than 255 items, each with a different "when" attribute, which is actually what I'm trying to avoid).
For the "not less than MAX_ARITY" error, I've attached the problem program (very much work-in-progress; please don't think that this is my normal programming style; etc. etc.)
And this (one-line change) is the program that caused the "Not interned" errors.