Menu
▾
▴
[Tcl-bugs] [ tcl-Bugs-2030670 ] Tcl_Panic in Tcl_ScanObjCmd after TclStackRealloc
|
From: SourceForge.net <no...@so...> - 2009-05-01 01:30:13
|
Bugs item #2030670, was opened at 2008-07-28 17:23 Message generated for change (Settings changed) made by msofer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2030670&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 47. Bytecode Compiler Group: obsolete: 8.5.3 Status: Open Resolution: Fixed >Priority: 6 Private: No Submitted By: Alexander James Pasadyn (ajpasadyn) Assigned to: miguel sofer (msofer) Summary: Tcl_Panic in Tcl_ScanObjCmd after TclStackRealloc Initial Comment: 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. ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2008-07-29 12:00 Message: 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!) ---------------------------------------------------------------------- Comment By: Alexander James Pasadyn (ajpasadyn) Date: 2008-07-29 11:41 Message: 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! ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2008-07-29 10:51 Message: Logged In: YES user_id=148712 Originator: NO Tested, committed: thanks again. Leaving open as reminder to add tests. ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2008-07-28 17:40 Message: 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. ---------------------------------------------------------------------- Comment By: Alexander James Pasadyn (ajpasadyn) Date: 2008-07-28 17:25 Message: Logged In: YES user_id=1055638 Originator: YES File Added: stack_alloc_calls.txt ---------------------------------------------------------------------- Comment By: Alexander James Pasadyn (ajpasadyn) Date: 2008-07-28 17:24 Message: Logged In: YES user_id=1055638 Originator: YES File Added: panic_stacktrace.txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2030670&group_id=10894 |