UWN

SICStus and SWI. For SICStus, you have to `ulimit -v` memory first (under Linux), otherwise you get roughly the behavior you describe. For SWI, there is a relatively small default...

You cannot `ulimit -v` Go. Another way to (partially) address this problem is to provide some mechanism to limit the number of inferences. This helps, at least for the typical...

Here is a case where this limit is not respected: ``` ulrich@p0:/opt/gupu/ichiban-prolog$ go version go version go1.20.4 linux/amd64 ulrich@p0:/opt/gupu/ichiban-prolog$ GOMEMLIMIT=1MiB $(go env GOPATH)/bin/1pl Top level for ichiban/prolog v1.1.0 This is...

There is no need to have very precise overflow detection. It could be performed every nth inference only.

Why is there now this unexpected instantiation error: ``` ?- current_prolog_flag(max_integer, Max). Max = 9223372036854775807; ?- succ(9223372036854775807, S). 2023/08/11 08:13:54 error(evaluation_error(int_overflow),succ/2) ?- current_prolog_flag(max_integer, Max), succ(Max, S). 2023/08/11 08:14:20 error(instantiation_error,succ/2), unexpected.

@jfmc , as long as this is not fixed (and this cannot be very complex), further issues do not make much sense.

But on the other hand you permit interrupts which should be similarly difficult to handle...

Just out of curiosity: How do you know that an overflow happened (and not a real bug)? In above case, it seems you do know that the heap overflowed. But...

Now: ``` ?- test(E,direct). % CPU time: 0.000s E = 2^18 ; % CPU time: 0.000s E = 2^19 ; % CPU time: 0.000s E = 2^20 ; % CPU...

This has reappeared: ``` ?- test(E,call). % CPU time: 0.327s, -19 inference (exception?) E = 2^18 ; % CPU time: 0.656s, 54 inferences E = 2^19 ; % CPU time:...