#4092 Tcl_Panic in Tcl_ScanObjCmd after TclStackRealloc

obsolete: 8.5.3
open-fixed
4
2011-04-12
2008-07-28
No

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.

Discussion

  • Alexander James Pasadyn

    Logged In: YES
    user_id=1055638
    Originator: YES

    File Added: panic_stacktrace.txt

     
  • Alexander James Pasadyn

    Logged In: YES
    user_id=1055638
    Originator: YES

    File Added: stack_alloc_calls.txt

     
  • miguel sofer

    miguel sofer - 2008-07-28
    • priority: 5 --> 9
     
  • miguel sofer

    miguel sofer - 2008-07-28

    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.

     
  • miguel sofer

    miguel sofer - 2008-07-29
    • priority: 9 --> 5
    • status: open --> open-fixed
     
  • miguel sofer

    miguel sofer - 2008-07-29

    Logged In: YES
    user_id=148712
    Originator: NO

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

     
  • Alexander James Pasadyn

    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!

     
  • miguel sofer

    miguel sofer - 2008-07-29

    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!)

     
  • miguel sofer

    miguel sofer - 2009-05-01
    • priority: 5 --> 6
     
  • miguel sofer

    miguel sofer - 2011-04-12
    • priority: 6 --> 4
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks