Tcl Source Code

(I could *not* trigger this rare event, but I'm sure
from the code that the bug is there)
InfoLevelCmd uses "iPtr->varFramePtr->objv" - as far as
I can tell, it is the only user.
Now "iPtr->varFramePtr->objv" is a pointer into the
evaluation stack: it is set in TclObjInterpProc
(tclProc.c), which gets it from TclExecuteByteCode
(tclExecute.c) [see INST_INVOKE]
The trouble is that the evaluation stack may grow (and
move), so that some combination of events will leave
iPtr->varFramePtr->objv pointing to ckfreed memory.
The combination of events could be:
 - proc A invokes proc B; proc B grows the stack
 - after returning from B, proc a requests "info level"

I do not see yet any nice & simple solution. Among the
clumsy and/or complicated solutions:
 - store instead a stack offset into the CallFrame; let
InfoLevelCmd know about the execution stack (to my
eyes, a very bad thing)
  - do not free the old stack memory until execution is
back at level 0, thereby keeping the pointers valid

Remark also that fixing matters in the first manner
will work for bytecodes, but may break "info level" for
non-compiled scripts! The second one may be very costly
in memory.

Logged In: YES 
user_id=79902

I attach a *very* basic fix.  It is not yet of a quality
that I'd like to see in the core, but it does indicate the
sort of thing that needs to be done.

File Added - 4056: infolevel-bug.tcl

Logged In: YES 
user_id=79902

Added a script to do this, but I still can't guarantee that
it will actually successfully trigger the error for anyone
other that me (it is *very* dependant on the allocation
mechanism).  However, when I've tested with some version of
8.0, 8.3 and the current 8.4, I systematically get a crash
with the code as attached, and no crash if I put a comment
character in front of the list command.

Logged In: YES 
user_id=79902

This bug has certainly existed since 8.1.0, and might also
exist in 8.0.* (the diffs get a little large at that point
for convenient reading...)

Logged In: YES 
user_id=148712

The code does not demonstrate the effect in my setup (linux
RH 6.2). It is difficult to trigger the event, as dkf
explained to me: you have to cause the memory at the
previous location of the evaluation stack to be reused in
order for the bug to cause a core dump.

Logged In: YES 
user_id=80530

Looks like the TEXTAREA entry box mangled
the demonstration script.  Could you upload
it as an attached file?

Logged In: YES 
user_id=79902

The following exercises the bug:

   set s {list }
   for {set i 0} {$i<2000} {incr i} {append s "$i "}
   proc B {} [append s {; puts [string length [info body
B][info body B]]}
   proc A {} {
      puts A=[info level]=[info level 0]; B; puts A=[info
level]=[info level 0]
   }
   A

Logged In: YES 
user_id=79902

The following exercises the bug:

   set s {list }
   for {set i 0} {$i<2000} {incr i} {append s "$i "}
   proc B {} [append s {; puts [string length [info body
B][info body B]]}
   proc A {} {
      puts A=[info level]=[info level 0]; B; puts A=[info
level]=[info level 0]
   }
   A