The [apn-apply-bug](https://core.tcl-lang.org/tcl/timeline?r=apn-apply-bug) branch contains a demonstration and proposed fix for the bug.

The bug is triggered when the apply command is passed a "lambda" argument which is is a two element list (i.e. not yet shimmered to the `lambdaType` internal representation) but the second element of the list (the lambda body) is unshared **and** already has a internal `tclByteCodeType` representation.

The test command [testapplylambda](https://core.tcl-lang.org/tcl/artifact?name=f0202c540752a8dc&ln=8127) is an example of the above.

Analysis:

When `TclNRApplyObjCmd` is called with an argument that is a list of two strings, it first [converts](https://core.tcl-lang.org/tcl/artifact?name=37dbfa89bf70d3f9&ln=2683) the argument to the internal `lambdaType` in `procPtr`. It then compiles the second element of the argument, the body, by calling [TclPushProcCallFrame](https://core.tcl-lang.org/tcl/artifact?name=37dbfa89bf70d3f9&ln=2720). Crucially, this compilation updates the `procPtr->numCompiledLocals` field with the number of locals used in the body.

The next time `TclNRApplyObjCmd` is called with the same argument, the argument object is already shimmered to `lambdaType` so no conversion is needed. It also already contains the right value of `procPtr->numCompiledLocals` from the previous conversion. So all is well.

The bug occurs when the lambda argument is a list but the body element already has a `tclByteCodeType` internal type. In this case, again `TclNRApplyObjCmd` calls `TclGetLambdaFromObj` to shimmer the argument to a `lambdaType` and get a new `procPtr`. However, when `TclPushProcCallFrame` is called, it finds the body element is already of the `tclByteCodeType` type and [does not recompile](https://core.tcl-lang.org/tcl/artifact?name=37dbfa89bf70d3f9&ln=1579) the body script. **Consequently `procPtr->numCompiledLocals` in the newly allocated `procPtr` does not get updated.** Subsequently, when the byte code is executed it tries to access the expected locations for local variables which has not actually been allocated and crashes.

Proposed fix:

The proposed [fix](https://core.tcl-lang.org/tcl/artifact?name=37dbfa89bf70d3f9&ln=2461) is to always free the internal representation of the body element `Tcl_Obj` of a lambda argument when the latter is shimmered to a `lambdaType`. This ensures recompilation.

This is the simplest and cleanest fix I can come up with given my limited knowledge of this area. An alternative more efficient alternative might be to "remember" the value of numCompiledLocals and stash it away in the `tclByteCodeType` internal rep to be used to reinitialize `procPtr->numCompiledLocals` when the body itself does not need recompilation. I am reluctant to explore that being unsure of what other compilation side-effects also would need to be accounted for. Someone with more expertise might explore that path.

Why this has not shown up:

Reproducing this at the script level is hard (impossible?) in the current Tcl implementation because it requires certain conditions - the lambda itself must not already have an internal lambda rep AND the body element must already have byteCode internal rep AND the body element must be unshared (shared Tcl_Obj are always recompiled). The shimmering and reference counting that happens in script level commands means these conditions are rare (never occur?). Nevertheless this seems to be a genuine bug as illustrated in the C code.

Why this fix has more relevance now:

With TIP 625 list optimizations, this can be reproduced at the script level with the following code.

```
set lambda [list {} {set x 42}]
apply [lrange $lambda 0 end]
apply [lrange $lambda 0 end]
```

With TIP 625, the `lrange` commands return a new Tcl_Obj (because the string representation must be canonical) but share the same internal list representation since the entire list is being returned. Consequently the second apply produces the conditions required for the crash.

Pre-TIP 625, the `lrange` commands would not only return a new Tcl_Obj but would also return an entirely new internal list representation even when the entire list was covered by the range (this is sub-optimal). The conditions for the bug are thus not met and the bug is not triggered.

merged in [73a6af23a5e23f40]

@sebres. According to Github ACTIONS, your bug-fix works. Thanks!

Branch bug-4eb3a155ac--procptr-bytecode must fix it.

As discussed in tclchat (IRC), the fix of Ashok covers only one case, as well as basically too heavy because would always reset the body of lambda, thus could unintentionally lost large internal representation of some object if body is evaluated as a list, e. g. basically it wouldn't be able anymore evaluate lambdas as pure-list (using Tcl_EvalObjv/TclNREvalObjv), because will always shimmer to string.

Anyway, I could find the real reason of the issue and it looks much more grave as assumed - the procPtr object (of type tclProcBodyType) is stored (but not referenced) in its bytecode (in object of type tclByteCodeType), but if lambda/proc/whatever becomes free, codePtr->procPtr remains unchanged, although procPtr doesn't exists anymore, because released in TclProcCleanupProc. 
And since ByteCode would not be recompiled later, with that constellation I see dozen cases were it can segfault later, Ashok found only one case.

I rebased the branch apn-apply-bug to 8.6 (where it is also pretty reproducible) and will provide a common solution for the issue (reset codePtr->procPtr in TclProcCleanupProc).

I think the apn-apply-bug is OK to be merge to core-8-6-branch.

Thanks, @Ashhok, for analysing and fixing this bug! It might be that a better fix is possible, but since this bug is so rare it doesn't really matter; low priority. I leave it to you, further.

*Comments from sebres on the chat:*

<sebres>: apn: nice catch... just as for the fix [072cffce6f] - it is a bit too heavy, I mean always to shimmer to pure string body (for instance it'd never use a list eval, if body is list), also could lost some large object internal representations (apply [list args [list ... $largeObj]]), and would need to recreate it by the evaluation e. g. shimmer back to expected type)

<sebres>: apn: isn't possible to correct procPtr->numCompiledLocals or even force that recompilation only in case where it is wrong (we assuming invocation of byteCode vs. lambda/proc byteCode)?

*My response on the chat:*

@sebres, regarding [072cffce6f], I was just glad I was not completely off-track a few days ago when I logged a bogus ticket about bug in apply! Regarding the fix, my first thought had been that it might be potentially heavyweight as you say  because of the internal rep being discarded. But then rethinking, I concluded any internal rep is going to get shimmered to a ByteCode object anyways when the script (in bodyPtr) is compiled by TclCompileScript. So it is only being discarded a little earlier.  This was the cleanest solution I could find but this is my foray into the byte code world so I could be wrong about that.

It is also a rare case that the lambda object does not have a internal Lambda representation but the body object has an internal ByteCode representation.

"apn: isn't possible to correct procPtr->numCompiledLocals or even force that recompilation only in case where it is wrong (we assuming invocation of byteCode vs. lambda/proc byteCode)?" - I went down that path too (have body store that value and update procPtr in the case the body is not recompiled) but beyond my abilities at this time. I'm not sure what other side effects the body compilation has and what else might need to be fixed/restored.