Prolog - SWI-Prolog : Out Of Local Stack

Author

SWI-Prolog : Out Of Local Stack

roschler

2006-09-17, 9:59 pm

I have a DCG predicate that gets a "out of local stack" error when I
try to trace it in the graphical debugger, but works properly when I'm
not in debugging. I read in the manual that can happen because last
call optimization is turned off in the graphical debugger.

It appears to happen due to a dynamically built predicate call. If I
surround that dynamically built predicate call with call/1, then the
graphical debugger works fine. I have no problem using call/1, but if
there are any issues I need to be concerned with by using call/1, then
please let me know. If there's a good page that discusses the issues
between using call/1 and not using it, just point me to it.

There's something about the naked PredCall that causes the DCG
predicate 'C' to have problems when running in the graphical debugger.

x(WordlistFunctor) -->
% Try taking a three words and testing them as a single atom against
the desired predicate.
[W1, W2, W3],
{ concat_all([W1, W2, W3], Matched) ,
PredCall =.. [WordlistFunctor, Matched],
% PredCall, - this will cause an "out of local stack" error with the
graphical debugger.
call(PredCall) % this is OK
},
!.

Jan Wielemaker

2006-09-18, 4:00 am

On 2006-09-17, roschler <robert.oschler@gmail.com> wrote:
> I have a DCG predicate that gets a "out of local stack" error when I
> try to trace it in the graphical debugger, but works properly when I'm
> not in debugging. I read in the manual that can happen because last
> call optimization is turned off in the graphical debugger.
>
> It appears to happen due to a dynamically built predicate call. If I
> surround that dynamically built predicate call with call/1, then the
> graphical debugger works fine. I have no problem using call/1, but if
> there are any issues I need to be concerned with by using call/1, then
> please let me know. If there's a good page that discusses the issues
> between using call/1 and not using it, just point me to it.
>
> There's something about the naked PredCall that causes the DCG
> predicate 'C' to have problems when running in the graphical debugger.
>
> x(WordlistFunctor) -->
> % Try taking a three words and testing them as a single atom against
> the desired predicate.
> [W1, W2, W3],
> { concat_all([W1, W2, W3], Matched) ,
> PredCall =.. [WordlistFunctor, Matched],
> % PredCall, - this will cause an "out of local stack" error with the
> graphical debugger.
> call(PredCall) % this is OK
> },
> !.

call(PredCall) is certainly not better than simply PredCall. Looks like
a bug in the debugger. Please report, preferably to the SWI-Prolog
bugzilla system. Include a *complete* program, not just a snippet. Also
include the version, as there have been some recent changes to the
debugger.

--- Jan

roschler

2006-09-20, 7:00 pm

Jan Wielemaker wrote:
> On 2006-09-17, roschler <robert.oschler@gmail.com> wrote:

>
> call(PredCall) is certainly not better than simply PredCall. Looks like
> a bug in the debugger. Please report, preferably to the SWI-Prolog
> bugzilla system. Include a *complete* program, not just a snippet. Also
> include the version, as there have been some recent changes to the
> debugger.
>
> --- Jan

Jan,

I have entered a bug report with a complete test program into
SWI-Prolog BugZilla; just follow the reported steps.

In the meantime, is the main liability in using call/1 simply speed,
since it's an interpretive call and not compiled?

Also, is there a way to tell from Prolog code if the code is currently
being traced in the GUI debugger? If there is, and it's not too
ridiculous, I could create a call like:

safe_call(Goal) :-
is_gui_tracing_active,
!,
call(Goal).
safe_call(Goal) :-
\+ is_gui_tracing_active,
!,
Goal.

Too silly?

Thanks,
Robert

Jan Wielemaker

2006-09-20, 7:00 pm

On 2006-09-20, roschler <robert.oschler@gmail.com> wrote:
> Jan Wielemaker wrote:
>
>
> Jan,
>
> I have entered a bug report with a complete test program into
> SWI-Prolog BugZilla; just follow the reported steps.

Fixed. See updated bug report (and mail if all went as it should).

> In the meantime, is the main liability in using call/1 simply speed,
> since it's an interpretive call and not compiled?

call(X) and X are the same. The current version simply defines

call(X) :- X.

> Also, is there a way to tell from Prolog code if the code is currently
> being traced in the GUI debugger? If there is, and it's not too
> ridiculous, I could create a call like:
>
> safe_call(Goal) :-
> is_gui_tracing_active,
> !,
> call(Goal).
> safe_call(Goal) :-
> \+ is_gui_tracing_active,
> !,
> Goal.
>
> Too silly?

Bugs should be fixed at the right place. You can check whether the
tracer is active using tracing/0 and the gui tracer using
current_prolog_flag(gui_tracer, true). Very exceptional cases
aside, never use this in your application.

Thanks for reporting --- Jan

Sponsored Links