Stacks not removed from memory?

Marty Knapp martyknappster at
Fri May 14 13:48:54 EDT 2021

In my case it's not a name conflict. Lets say I have a main stack "XYZ" and then I query a separate Preference stack:

put the cpCustomProperty of stack "full_path_to_pref_stack" into tPref
close stack "pref_stack"

(my preference stack has destroyStack set to true)

Now thinking that I'm back in my main stack "XYZ" I do something like:
put tPref into fld "123" of this stack

This worked fine for me for years. In LC 9.6.2 rc 5, it would fail most of the time. Curious, I inserted code to find out what LC thought was "this stack" only to discover that *sometimes* it's the preference stack that I just closed.

Then after closing the preference stack, I tried "go stack "XYZ" and "set the default stack to "XYZ" But "this stack" would still (most of the time) report my supposedly closed preference stack.

So now I'm having to query for revLoadedStacks and if my preference stack is listed then I delete it from memory.

I did file a bug report (#23194 ) but as it does not always happen I have not provided a test stack.


> On May 14, 2021, at 10:05 AM, Richard Gaskin via use-livecode <use-livecode at> wrote:
> Devin Asay wrote:
> > I have seen what you’re describing on all of the recent releases—9.5 -
> > 9.6.x; i.e., a stack with destroyStack set to true, then closed, is
> > not always removed from memory. Sometimes this has caused an infinite
> > loop with the Save - Purge - Cancel dialog. I would report it, but I
> > haven’t been able to come up with a reliable recipe. It’s a problem
> > that I would like to nail down and squash.
> Is this to avoid stack name conflicts, or is there some other reason to use this feature?
> Because if it's just the stack name conflict thang, I'd rather we solve that at the root by being done with that IDE-imposed limitation that doesn't actually exist in the engine:
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> ____________________________________________________________________
> Ambassador at      

More information about the use-livecode mailing list