How do i resolve stack overflow errors?

This comes up in the normal course of running a complex but not unreasonable computation. The SWI window is using 1GB memory, but there’s no reason it couldn’t use a lot more. Also of note, if I (without terminating my program) request to run the computation a second time it succeeds. I would like to never get stack_overflow so long as my computer has memory.

error(resource_error(stack),stack_overflow{choicepoints:11,depth:2782,environments:28,globalused:453669,localused:4,stack:[frame(2782,assoc:insert(t,t/4,x,t/5,_44502558),[]),frame(2781,assoc:insert(<,t/5,t/4,x,_44502596,_44502598),[]),frame(2779,assoc:insert(<,t/5,t/4,x,_44502636,_44502638),[]),frame(2777,assoc:insert(<,t/5,t/4,x,_44502676,_44502678),[]),frame(2775,assoc:insert(<,t/5,t/4,x,_44502716,_44502718),[])],stack_limit:1048576,trailused:262141})ERROR: FAILED REQUEST (replay_system)

Calling garbage_collect before the computation did not fix it.

You can call set_prolog_flag(stack_limit, <some large number>) to increase the space.

Also see for more options.

The memory use is very far below 1Gb if I read this correctly. Possibly you hit a bug that was solved Jul 25 (212560dddbd7eea1af19f54b5dc381580245cf04):

FIXED: Possible execution path that does not perform a stack shift while this
is still possible, running out of stack while this is not needed.

I don’t know which version you are using, but recent versions have quite a few enhancements to garbage collection and shift scheduling that both avoid unnecessary out-of-stack and various scenarios where most of the time is spent on garbage collection.

I’ve been on 8.0.3, installed July 26, but note I have experienced this on previous versions, it just hasn’t been a major issue until now. 1GB is the process size.

8.0.3 last commit was Jun 19, so the above patch is not in there. It indeed patches a very old bug that triggers pretty rarely.

You mean at the time of the overflow according to the OS? The exception claims a local stack with 28 environments and 11 choicepoints (that is small) and a global stack with 453669 bytes. Seems it is building an assoc. That is a strange moment to run out of 1Gb stack space. Running out of space while the stacks are small can practically only happen with a large findall/3 (and derived bagof/setof). They collect the answers outside the stacks, but as eventually they need to be copied to the stack it verifies there is enough space to do so while collecting answers. There are some more big allocations: sort/2 verifies there is enough space for copying the list before starting, etc. None of that seems to apply here.

The code at issue is almost certainly CHR, the stuff that builds the hashmap to lookup objects in their database during queries. I will get 8.0.3-1 (why not called 8.0.4?) and try it.

8.0.3-1 is 8.0.3. CPack insists on a -N at the end. 8.0.4 doesn’t exist and is not in the pipeline anytime soon. 8.1.X is your own option (except for grabbing the source and assembling your own version). 8.1.X is very stable as long as you stay away from the latest tabling developments. All development happens there, but this is completely isolated from the non-tabled execution.

Then I’m confused. How do I get the fix?

If you are on windows you can just download the development release from here:

On Ubuntu you can add the PPA, see here:

On arch you get from AUR:

1 Like

Good news: The problem has not recurred since getting the devel build.

thanks for the feedback. Apparently everything still works as well :slight_smile: If you don’t like regression, just stick with that version of the devel series until you experience another problem or the next stable is released and you should be fine,