Tcl Source Code

I have an application that often panics (TclStackFree: incorrect freePtr. Call out of sequence?) when using the tcllib smtp package to send an e-mail message.  Unfortunately, even after I identified the Tcl issue, I wasn't able to use that information to produce a test case that didn't contain any private data.  I could trap the arguments to the "subst" call that was failing, but when run in isolation, the problem never appeared.  In fact, removing even completely unrelated procedures and commands from the script would cause the failure to go away.

Since I could make it happen reliably, I was able to find out what was wrong.  I had assumed some memory was getting trashed somewhere, but it actually just looks like an issue with a code path that is really hard to get to.  Basically TclStackRealloc usually just ends up returning its input pointer, but if you can get it to return something else the old one is still in the sequence.  When I debugged it, I saw that the "move" input to GrowEvaluationStack was getting repurposed (and set to zero) in my case, and that was causing the only code I could see that was adjusting the pointer sequences to get skipped.  So I added a separate variable for the other usage and it seems to be working for me.  Please take a look at this and suggest something else if this patch would cause other problems.

Logged In: YES 
user_id=148712
Originator: NO

Testing this probably requires a special function in tclTest.c. I also cannot see a script that would reliably trigger this, even less accross future changes.

What the test would have to do is: StackAlloc 0 bytes and then realloc in a manner that is sure to trigger an actual move (it can peek at the current stack's size and request more than that!)

Logged In: YES 
user_id=1055638
Originator: YES

I am curious to see how to test that with a simple-looking script.  I'm sure there's some way to get the stacks into the right state easily, but I could not find it!

Logged In: YES 
user_id=148712
Originator: NO

Tested, committed: thanks again. Leaving open as reminder to add tests.

Logged In: YES 
user_id=148712
Originator: NO

The problem seems to appear when allocating 0 bytes and then reallocating so that it doesn't firt in the current stack. This ends up moving 0 bytes ... I get it. 
Your patch looks fine, thank you - I'll test and commit this week.

File Added - 286292: stack_alloc_calls.txt

Logged In: YES 
user_id=1055638
Originator: YES

File Added: stack_alloc_calls.txt

File Added - 286291: panic_stacktrace.txt

Logged In: YES 
user_id=1055638
Originator: YES

File Added: panic_stacktrace.txt

File Added - 286290: tclstack.patch