GLOBALSZ leak issue?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

GLOBALSZ leak issue?

emacstheviking
I downloaded and built a fresh binary from here:


I then loaded this code:

gtest :-
    statistics,
    gtest.

It looks like it would run forever as the values didn't change.

Then I ran this code:

gtest :-
    statistics(global_stack, GS),
    gtest.

Fatal Error: trail stack overflow (size: 16384 Kb, reached: 16384 Kb, environment variable used: TRAILSZ)

TRAILSZ is used for, AIUI, "variable bindings to undo", so that's understandable;  I am creating GS on each pass and then calling myself so it's stashing the current value of GS jut in case we ever came back.

gtest :-
    statistics(global_stack, _),
    gtest.

This still causes TRAILSZ to exhaust, which I expected because it is still a binding that has to be stashed I guess.

Continuing... 

gtest :-
        statistics(global_stack, _),
        !,
gtest.

Same again, TRAILSZ exhausted. From my obviously incorrect understanding of prolog, only fail/0 would cause any memory allocation to be released at this point?

SO... how does one use tail-recursion to keep an application running without running out of stack space? This really feels like "worrying about consing" when you first learn Lisp. Ultimately, unless you are out for performance the runtime will do it for you etc. BUT for Prolog, which is still new to me, I am now completely at a loss as to how to proceed.

Paulo, we've spoken briefly in the past and I keep meaning to use LogTalk but would that allow me to use my custom "gprolog" binary with my SDL extensions? It ought to I guess.

Firstly, I will try Lindsey-s advice and better my understanding of DCG productions as state transformers but I can't help feeling a little bemused and stuck at the moment as I have failed so far to understand the nature of the problem i.e. why is it apparently so  hard to be able to use gprolog for a long-running application?

Many thanks chaps for your time so far!

All the best,
Sean.





_______________________________________________
Users-prolog mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/users-prolog
Reply | Threaded
Open this post in threaded view
|

Re: GLOBALSZ leak issue?

Paulo Moura-2

> On 06/08/2015, at 18:18, emacstheviking <[hidden email]> wrote:
>
> I downloaded and built a fresh binary from here:
>
> git://git.code.sf.net/p/gprolog/code <http://git.code.sf.net/p/gprolog/code> master
>
> I then loaded this code:
>
> gtest :-
>     statistics,
>     gtest.
>
> It looks like it would run forever as the values didn't change.
>
> Then I ran this code:
>
> gtest :-
>     statistics(global_stack, GS),
>     gtest.
>
> Fatal Error: trail stack overflow (size: 16384 Kb, reached: 16384 Kb, environment variable used: TRAILSZ)
>
> TRAILSZ is used for, AIUI, "variable bindings to undo", so that's understandable;  I am creating GS on each pass and then calling myself so it's stashing the current value of GS jut in case we ever came back.
>
> gtest :-
>     statistics(global_stack, _),
>     gtest.
>
> This still causes TRAILSZ to exhaust, which I expected because it is still a binding that has to be stashed I guess.
>
> Continuing...
>
> gtest :-
>         statistics(global_stack, _),
>         !,
> gtest.
>
> Same again, TRAILSZ exhausted. From my obviously incorrect understanding of prolog, only fail/0 would cause any memory allocation to be released at this point?
>
> SO... how does one use tail-recursion to keep an application running without running out of stack space?

How about:

gtest :-
    statistics(global_stack, GS),
    fail.
gtest :-
    gtest.

> This really feels like "worrying about consing" when you first learn Lisp. Ultimately, unless you are out for performance the runtime will do it for you etc. BUT for Prolog, which is still new to me, I am now completely at a loss as to how to proceed.
>
> Paulo, we've spoken briefly in the past and I keep meaning to use LogTalk but would that allow me to use my custom "gprolog" binary with my SDL extensions? It ought to I guess.

Logtalk, not LogTalk :-) You can easily embed Logtalk and a Logtalk application in a GNU Prolog executable. See:

https://github.com/LogtalkDotOrg/logtalk3/wiki/Embedding-Logtalk

Just make sure you use the latest Logtalk git or stable version (as I added a workaround a few days ago for a gplc bug triggered when embedding Logtalk).

> Firstly, I will try Lindsey-s advice and better my understanding of DCG productions as state transformers but I can't help feeling a little bemused and stuck at the moment as I have failed so far to understand the nature of the problem i.e. why is it apparently so  hard to be able to use gprolog for a long-running application?
>
> Many thanks chaps for your time so far!

You're welcome. Cheers,

Paulo

-----------------------------------------------------------------
Paulo Moura
Logtalk developer

Email: <mailto:[hidden email]>
Web:   <http://logtalk.org/>
-----------------------------------------------------------------





_______________________________________________
Users-prolog mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/users-prolog