Tcl Source Code

When debugging a simple script with Komodo the tclsh crashes in tclVar.c DeleteSearches

It crashes when stepping over a proc statement in Komodo, example script:
  puts "" ;# allows to attach the VisualStudio debugger to tclsh.exe before crashing
  proc test {} {
    puts "Hello World"
  }
  test

The crash happens with any Komodo version, Komodo launches this script via command:
  C:\Temp\tcl\bin\tclsh85g.exe "C:/Program Files/ActiveState Komodo IDE 5/lib/support/tcl/appLaunch.tcl" 127.0.0.1 17000 C:/Temp/tcl/hello.tcl tcldbgp5548

I compiled tcl with Visual Studio 2005 Professional, shared with and without thread support:
nmake -nologo -f makefile.vcOPTS=symbols
nmake -nologo -f makefile.vc installOPTS=symbols
nmake -nologo -f makefile.vc
nmake -nologo -f makefile.vc install
nmake -nologo -f makefile.vcOPTS=threads,symbols
nmake -nologo -f makefile.vc installOPTS=threads,symbols
nmake -nologo -f makefile.vcOPTS=threads
nmake -nologo -f makefile.vc install OPTS=threads

The crash appears in all tclsh variations. I am using tcl 8.5.8 here, but the crash appeared in 8.5.3 too:
Unhandled exception at 0x100f5c93 (tcl85g.dll) in tclsh85g.exe: 0xC0000005: Access violation reading location 0x0000000c.
In tclVar.c function DeleteSearches() at line 4345, just after Tcl_FindHashEntry returned NULL.

The crashdump is attached (if it helps).

The stack looks like this, but it does not tell me much:
>tcl85g.dll!DeleteSearches(Interp * iPtr=0x00a0ab40, Var * arrayVarPtr=0x00a8f238)  Line 4345 + 0x3 bytesC
 tcl85g.dll!UnsetVarStruct(Var * varPtr=0x00a8f238, Var * arrayPtr=0x00000000, Interp * iPtr=0x00a0ab40, Tcl_Obj * part1Ptr=0xdddddddd, Tcl_Obj * part2Ptr=0x00000000, int flags=64)  Line 2309 + 0xd bytesC
 tcl85g.dll!TclDeleteVars(Interp * iPtr=0x00a0ab40, TclVarHashTable * tablePtr=0x00a9bfa0)  Line 4489 + 0x1c bytesC
 tcl85g.dll!Tcl_PopCallFrame(Tcl_Interp * interp=0x00a0ab40)  Line 469 + 0x10 bytesC
 tcl85g.dll!TclObjInterpProcCore(Tcl_Interp * interp=0x00a0ab40, Tcl_Obj * procNameObj=0x00a7b258, int skip=1, void (Tcl_Interp *, Tcl_Obj *)* errorProc=0x100d44f0)  Line 1846 + 0x9 bytesC
 tcl85g.dll!TclObjInterpProc(void * clientData=0x00a61e38, Tcl_Interp * interp=0x00a0ab40, int objc=5, Tcl_Obj * const * objv=0x00a8b7e8)  Line 1652 + 0x16 bytesC
 tcl85g.dll!TclEvalObjvInternal(Tcl_Interp * interp=0x00a0ab40, int objc=5, Tcl_Obj * const * objv=0x00a8b7e8, const char * command=0x00000000, int length=0, int flags=0)  Line 3689 + 0x1d bytesC
 tcl85g.dll!Tcl_EvalObjv(Tcl_Interp * interp=0x00a0ab40, int objc=5, Tcl_Obj * const * objv=0x00a8b7e8, int flags=0)  Line 3885 + 0x19 bytesC
 tcl85g.dll!TclEvalObjEx(Tcl_Interp * interp=0x00a0ab40, Tcl_Obj * objPtr=0x00a7af88, int flags=0, const CmdFrame * invoker=0x00000000, int word=0)  Line 5116 + 0x15 bytesC
 tcl85g.dll!Tcl_UplevelObjCmd(void * dummy=0x00000000, Tcl_Interp * interp=0x00a0ab40, int objc=1, Tcl_Obj * const * objv=0x00a0b73c)  Line 948 + 0x19 bytesC
 tcl85g.dll!TclEvalObjvInternal(Tcl_Interp * interp=0x00a0ab40, int objc=3, Tcl_Obj * const * objv=0x00a0b734, const char * command=0xffffffff, int length=-1, int flags=0)  Line 3689 + 0x1d bytesC
 tcl85g.dll!TclExecuteByteCode(Tcl_Interp * interp=0x00a0ab40, ByteCode * codePtr=0x00a8d828)  Line 2328 + 0x1d bytesC
 tcl85g.dll!TclObjInterpProcCore(Tcl_Interp * interp=0x00a0ab40, Tcl_Obj * procNameObj=0x00a7b378, int skip=1, void (Tcl_Interp *, Tcl_Obj *)* errorProc=0x100d44f0)  Line 1758 + 0xd bytesC
 tcl85g.dll!TclObjInterpProc(void * clientData=0x00a6bac8, Tcl_Interp * interp=0x00a0ab40, int objc=4, Tcl_Obj * const * objv=0x00a0b620)  Line 1652 + 0x16 bytesC
 tcl85g.dll!TclEvalObjvInternal(Tcl_Interp * interp=0x00a0ab40, int objc=4, Tcl_Obj * const * objv=0x00a0b620, const char * command=0xffffffff, int length=-1, int flags=0)  Line 3689 + 0x1d bytesC
 tcl85g.dll!TclExecuteByteCode(Tcl_Interp * interp=0x00a0ab40, ByteCode * codePtr=0x00a80390)  Line 2328 + 0x1d bytesC
 tcl85g.dll!TclCompEvalObj(Tcl_Interp * interp=0x00a0ab40, Tcl_Obj * objPtr=0x00a530e0, const CmdFrame * invoker=0x00a0b420, int word=3)  Line 1450 + 0xd bytesC
 tcl85g.dll!TclEvalObjEx(Tcl_Interp * interp=0x00a0ab40, Tcl_Obj * objPtr=0x00a530e0, int flags=0, const CmdFrame * invoker=0x00a0b420, int word=3)  Line 5264 + 0x15 bytesC
 tcl85g.dll!Tcl_UplevelObjCmd(void * dummy=0x00000000, Tcl_Interp * interp=0x00a0ab40, int objc=1, Tcl_Obj * const * objv=0x00a0b5f0)  Line 948 + 0x19 bytesC
 tcl85g.dll!TclEvalObjvInternal(Tcl_Interp * interp=0x00a0ab40, int objc=3, Tcl_Obj * const * objv=0x00a0b5e8, const char * command=0xffffffff, int length=-1, int flags=0)  Line 3689 + 0x1d bytesC
 tcl85g.dll!TclExecuteByteCode(Tcl_Interp * interp=0x00a0ab40, ByteCode * codePtr=0x00a7d938)  Line 2328 + 0x1d bytesC
 tcl85g.dll!TclCompEvalObj(Tcl_Interp * interp=0x00a0ab40, Tcl_Obj * objPtr=0x00a52f30, const CmdFrame * invoker=0x00a0b584, int word=1)  Line 1450 + 0xd bytesC
 tcl85g.dll!TclEvalObjEx(Tcl_Interp * interp=0x00a0ab40, Tcl_Obj * objPtr=0x00a52f30, int flags=0, const CmdFrame * invoker=0x00a0b584, int word=1)  Line 5264 + 0x15 bytesC
 tcl85g.dll!Tcl_CatchObjCmd(void * dummy=0x00000000, Tcl_Interp * interp=0x00a0ab40, int objc=3, Tcl_Obj * const * objv=0x00a0b5b0)  Line 253 + 0x1e bytesC
 tcl85g.dll!TclEvalObjvInternal(Tcl_Interp * interp=0x00a0ab40, int objc=3, Tcl_Obj * const * objv=0x00a0b5b0, const char * command=0xffffffff, int length=-1, int flags=0)  Line 3689 + 0x1d bytesC
 tcl85g.dll!TclExecuteByteCode(Tcl_Interp * interp=0x00a0ab40, ByteCode * codePtr=0x00a79010)  Line 2328 + 0x1d bytesC
 tcl85g.dll!TclObjInterpProcCore(Tcl_Interp * interp=0x00a0ab40, Tcl_Obj * procNameObj=0x00aefbd8, int skip=1, void (Tcl_Interp *, Tcl_Obj *)* errorProc=0x100d44f0)  Line 1758 + 0xd bytesC
 tcl85g.dll!TclObjInterpProc(void * clientData=0x00a39b48, Tcl_Interp * interp=0x00a0ab40, int objc=4, Tcl_Obj * const * objv=0x00a0b448)  Line 1652 + 0x16 bytesC
 tcl85g.dll!TclEvalObjvInternal(Tcl_Interp * interp=0x00a0ab40, int objc=4, Tcl_Obj * const * objv=0x00a0b448, const char * command=0xffffffff, int length=-1, int flags=0)  Line 3689 + 0x1d bytesC
 tcl85g.dll!TclExecuteByteCode(Tcl_Interp * interp=0x00a0ab40, ByteCode * codePtr=0x00a57ac8)  Line 2328 + 0x1d bytesC
 tcl85g.dll!TclCompEvalObj(Tcl_Interp * interp=0x00a0ab40, Tcl_Obj * objPtr=0x00aefe18, const CmdFrame * invoker=0x00000000, int word=0)  Line 1450 + 0xd bytesC
 tcl85g.dll!TclEvalObjEx(Tcl_Interp * interp=0x00a0ab40, Tcl_Obj * objPtr=0x00aefe18, int flags=0, const CmdFrame * invoker=0x00000000, int word=0)  Line 5264 + 0x15 bytesC
 tcl85g.dll!Tcl_UplevelObjCmd(void * dummy=0x00000000, Tcl_Interp * interp=0x00a0ab40, int objc=1, Tcl_Obj * const * objv=0x00a0b418)  Line 948 + 0x19 bytesC
 tcl85g.dll!TclEvalObjvInternal(Tcl_Interp * interp=0x00a0ab40, int objc=3, Tcl_Obj * const * objv=0x00a0b410, const char * command=0xffffffff, int length=-1, int flags=0)  Line 3689 + 0x1d bytesC
 tcl85g.dll!TclExecuteByteCode(Tcl_Interp * interp=0x00a0ab40, ByteCode * codePtr=0x00a4c858)  Line 2328 + 0x1d bytesC
 tcl85g.dll!TclObjInterpProcCore(Tcl_Interp * interp=0x00a0ab40, Tcl_Obj * procNameObj=0x00a25708, int skip=1, void (Tcl_Interp *, Tcl_Obj *)* errorProc=0x100d44f0)  Line 1758 + 0xd bytesC
 tcl85g.dll!TclObjInterpProc(void * clientData=0x00a70bb8, Tcl_Interp * interp=0x00a0ab40, int objc=2, Tcl_Obj * const * objv=0x00a0b1d0)  Line 1652 + 0x16 bytesC
 tcl85g.dll!TclEvalObjvInternal(Tcl_Interp * interp=0x00a0ab40, int objc=2, Tcl_Obj * const * objv=0x00a0b1d0, const char * command=0x00a2abd6, int length=14, int flags=0)  Line 3689 + 0x1d bytesC
 tcl85g.dll!TclEvalEx(Tcl_Interp * interp=0x00a0ab40, const char * script=0x00a2a038, int numBytes=2988, int flags=0, int line=107, int * clNextOuter=0x00000000, const char * outerScript=0x00a2a038)  Line 4387 + 0x21 bytesC
 tcl85g.dll!Tcl_EvalEx(Tcl_Interp * interp=0x00a0ab40, const char * script=0x00a2a038, int numBytes=2988, int flags=0)  Line 4043 + 0x1d bytesC
 tcl85g.dll!Tcl_FSEvalFileEx(Tcl_Interp * interp=0x00a0ab40, Tcl_Obj * pathPtr=0x00a256a8, const char * encodingName=0x00000000)  Line 1814 + 0x13 bytesC
 tcl85g.dll!Tcl_Main(int argc=-1, char * * argv=0x00a05ea8, int (Tcl_Interp *)* appInitProc=0x00401090)  Line 441 + 0x11 bytesC
 tclsh85g.exe!main(int argc=6, char * * argv=0x00a05e90)  Line 102 + 0x15 bytesC
 tclsh85g.exe!__tmainCRTStartup()  Line 597 + 0x19 bytesC
 tclsh85g.exe!mainCRTStartup()  Line 414C
 kernel32.dll!_BaseProcessStart@4()  + 0x23 bytes

allow_comments - 1

This was a symptom of 3037525, now fixed in 8.5.9 and head.

With default allocators I mean that USE_THREAD_ALLOC nor USE_TCLALLOC are defined. In this case tclAlloc.c implements TclpAlloc/TclpFree/TclpRealloc as plain calls to malloc/realloc/free (near the end of the file).

USE_THREAD_ALLOC is not on by default (when using the makefile.vc), it must be turned on with OPTS=thrdalloc,...
USE_TCLALLOC is also not used by default; to use this, one must change the makefile.vc (e.g. add it to the TCL_CFLAGS variable).

I thought that threads and USE_THREAD_ALLOC were the defaults in windows anyway. What allocator is being used when you say 'default'?

I just ried VC 6 today, and it also crashes with default allocators - but works with thread thrdalloc.

To just summerize my observations:
VC6 default allocators -> crash
VC8 default allocators -> crash
VC9 default allocators -> crash
VC6 USE_THREAD_ALLOC or USE_TCLALLOC -> works
VC8 USE_THREAD_ALLOC or USE_TCLALLOC -> works
VC9 USE_THREAD_ALLOC or USE_TCLALLOC -> works

So it seems to work when compiled using
  nmake -f makefile.vc OPTS=threads,thrdalloc
but crashes when using
  nmake -f makefile.vc OPTS=threads
or
  nmake -f makefile.vc

Having knowledge of exactly what komodo and dbgp_tcldebug are doing, this is undoubtedly an issue in the core.  The debugger only sends pure Tcl instrumentation to the interpreter, and does it with code that works back to Tcl 7.x.  It does do things like override proc and check for all sorts of other calls.

I'm not convinced that it isn't some weird C runtime error though, as it doesn't appear to occur with ActiveTcl's MSVC6 compiled binaries.

I have no way to repro or investigate this: no windows and no komodo (knowledge, installation or sources). 

The fact that such a trivial script crashes clearly points at either the user's installation or at komodo: either it is doing something wong, or it is exercising some very unusual code path in tcl itself. Not discarding the 2nd possibility (a bug in tcl), but this can only be determined by the komodo vendor. I suggest getting support from them.

Passing the buck.

File Added - 354986: tcl-dlls-loaded.PNG

About the c-lib I can at least for sure say...

at compile time is defined through vcvarsall.bat x86 (this example is from VC9):
DevEnvDir=C:\Programme\Microsoft Visual Studio 9.0\Common7\IDE
FrameworkDir=C:\WINDOWS\Microsoft.NET\Framework
FrameworkVersion=v2.0.50727
INCLUDE=C:\Programme\Microsoft Visual Studio 9.0\VC\ATLMFC\INCLUDE;C:\Programme\Microsoft Visual Studio 9.0\VC\INCLUDE;C:\Programme\Microsoft SDKs\Windows\v7.0\include;
LIB=C:\Programme\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;C:\Programme\Microsoft Visual Studio 9.0\VC\LIB;C:\Programme\Microsoft SDKs\Windows\v7.0\lib;
LIBPATH=C:\WINDOWS\Microsoft.NET\Framework\;C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;C:\Programme\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;C:\Programme\Microsoft Visual Studio 9.0\VC\LIB;
VCINSTALLDIR=C:\Programme\Microsoft Visual Studio 9.0\VC
VS90COMNTOOLS=c:\Programme\Microsoft Visual Studio 9.0\Common7\Tools\
VSINSTALLDIR=C:\Programme\Microsoft Visual Studio 9.0
VSSDK90Install=C:\Programme\Microsoft Visual Studio 2008 SDK\
WindowsSdkDir=C:\Programme\Microsoft SDKs\Windows\v7.0\

at runtime its loading the c+-runtime libs from WinSxS (from my VC9 tests):
c:\windows\winsxs\x86_microsoft.vc90.debugcrt_1fc8b3b9a1e18e3b_9.0.30729.4148_x-ww_5d84dd2f\MSVCR90D.DLL

for me this looks ok.

The problem with reproducing this without Komodo is, that I don't know what it does behind the scenes. Komodo uses dbgp_tcldebug.exe from TclPro with all sources compiled to bytecode. It looks that the startup script, which wraps the to be debugged script, loads and evals all stuff from a socket connected to dbgp_tcldebug.exe. So no way for to find out what it realy does (all relevant sources obfuscated).

Another possibility: some problem (in the makefile?) causing the use of a different C library at compile and run times

Note that ALL calls in tclVar.c (8.5 head) are guarded, they look like
    if (varPtr->flags & VAR_SEARCH_ACTIVE) {
DeleteSearches(iPtr, varPtr);
    }
and DeleteSearches checks that flag too. So it COULD be a bug in flag maintenance ...

Or not. What seems (to me) to be happening is general memory corruption involving the C stack: the mention of TclStackFree modifying the C stack makes anything after that very suspect.

If that is true it makes no sense whatsoever to discuss those stack traces: they would at best show the spot where the thing finally crashed (pointing at some random innocent bystander), at worst just random noise.

We would need some better clues:
  - a way to repro without Komodo
  - a purify or valgrind or similar report of the crash
  - better, complete info about the build and run environment

Something like this could be caused by using at runtime a different dll than the one that was compiled. Do we know that this is not what is happening? Is there any other Tcl8.5 in the system? Can the crash be reproduced in a clean tcl-less system, or in a --disable-shared build (don't know if/how those can be produced in windows)? Does Komodo use tclInt.h, and the incompat is between Komodo and tcl versions?

Those are all supposed to be guarded by condition flags on the variables that those hashes back up. In particular, they all refer to the tables of traces and array-searches in progress; what seems to be happening is the deletion of an array search when none exists. That's very strange! Either the teardown of variables is wrong (possible; array searches aren't used very often) or the variable's flags field is corrupt. The latter is far worse than the former!

It'd be good if we could reproduce this (for a tast suite case) before deciding how to fix it. It's easy to band-aid it, but I'd rather have the underlying problem fixed; DeleteSearches isn't supposed to be called when there aren't any searches on the array...

If it is ok for Tcl_FindHashEntry to return NULL values, then there are several functions where the return value is not checked for it:
Tcl_LogCommandInfo (tclNamesp.c:6977)
UnsetVarStruct (tclVar.c:2350)
UnsetVarStruct (tclVar.c:2379)
Tcl_ArrayObjCmd (tclVar.c:2862)
ParseSearchId (tclVar.c:4301)
DeleteSearches (tclVar.c:4343)
TclDeleteNamespaceVars (tclVar.c:4413)
DeleteArray (tclVar.c:4604)

All of these functions call Tcl_GetHashValue before checking for Null.
I am not saying this is generally wrong, since i can not know when a hash entry is garantied to exist. But it can potentially crash.
Till now I had crashes in DeleteSearches and in UnsetVarStruct exactly when those functions tried to dereference a NUL pointer via Tcl_GetHashValue.

File Added - 354916: varSearches.PNG

The varSearches hasharray looks like it has been created from Tcl_InitHashTable(&iPtr->varSearches, TCL_ONE_WORD_KEYS) and never modified.

To see how it looks just before the crash, please see the attachment varSearches.png.

The problem is that it crashed because Tcl_FindHashEntry returned null because Tcl_CreateHashEntry returned NULL.  Internally it calculates a hash and an index (1) but the tablePtr->buckets[index] is NULL.

FYI: Tcl_FindHashEntry _really is_ just Tcl_CreateHashEntry with a NULL third argument. This isn't documented, but it's true anyway. Please don't use this fact (other than to note that if NULL is returned, the entry isn't there and wasn't created).

* "Is it really an intended behaviour that TclStackFree modifies the stackframe (return address of a caller)?":
NO! Any evidence that this is happening?

* "Tcl_CreateHashEntry returns NULL": that can indeed happen, IFF the third is NULL - in which case the standard thing is to call Tcl_FinHashEntry instead. Where is this happening? I cannot see it in the stack trace.

If you were under linux, I suggest running this under valgrind. Do you have access to purify, or any other such tool? I don't, sorry.

Reducing prio: I do not think that the current state of knowledge about this merits holding a release.

I know now, the problem occurs with default heap allocators (malloc/realloc/free). It appears to work with USE_THREAD_ALLOC or with USE_TCLALLOC. I guess its because of different memory layout. This supports my opinion it could be a buffer overrun (on heap) .

I tried to debug this, but its very hard to understand whats going on. Is it realy an intended behaviour that TclStackFree modifies the stackframe (return address of a caller)?
The debugger and me are very confused that a function does not return to the caller but jumps into the middle of a function after TclStackFree and return has been executed (somewhere during proc statement processing).

is this not what the debug target does? I goona try this and some other things later.
Last weekend I found that compiling with VS 2008 SP1 and with MinGW 5.1.6 shows the exactly same crash. I added my compiled binaries to the ftp server (see the link below).

I tried putting an if-not-null around the stuff after calls to Tcl_GetHashValue, but then its crashing somewhere else. Could it be a buffer overrun destroying the Tcl-Interpreter structures?

Since the tclConfig.sh from ActiveTcl looks so different to those generated with my compilations, i will try to modify the makefile.vc a bit (e.g. remove -DTCL_TOMMATH, add -DUSE_THREAD_ALLOC and the like). I will try this during this week or next weekend ...unless some of you have other ideas or even a solution :)

Perhaps trying VS2005 but remove any optimization in the compile.

Hm. With you seeing the problem in all build variants the item (3) becomes less likely as source of it. Now I would think that (2) is most suspicious, i.e. the difference in compilers. IIRC Pat Thoyts is building Tcl with VS2008 or something like that. Might be a good idea to talk to him, maybe he can remember if VS2005 has problems.

My Tcl binaries: ftp://devuser:[email protected]/devuser/

btw: I am experiencing this issue in all 4 variants: regular, threaded, symbols and threaded+symbols.

Well, with AT working and yours not, we can look at the differences to see if we get some clues about where the problem could be.

(1) AT - win/Makefile.in --- yours - makefile.vc
(2) AT - MSVC6 --- yours - MS VS2005.
(3) AT - regular --- yours - symbols = debug build.

Of these three the last looks most suspicious to me, as the debug build not simply keeps the symbols for the debugger, but also activates some code paths to help with debugging the internals, and the bug could lurk there.

I am near the end of what I can help with, as it seems that (a) Komodo itself is not at fault, just able to trigger the problem in the Tcl core, and (b) the internals of Tcl variables are not my area of expertise.

The last person to really around in the internals of Tcl variables is msofer.
Would you mind handing this bug to him ?

I debugged it a bit:
Tcl_CreateHashEntry returns NULL and that is dereferenced by Tcl_GetHashValue-macro -> crash

I am not using a ActiveTcl binary distribution, i am using the 8.5.8 sources form sourceforge and compile them myself using Visual Studio. I also heard from others that ActiveTcl has no problem, but I have one when compiling with win\makefile.vc.

I am using:
Windows XP SP3
Komodo 5.2.2, build 35694
MFC Runtime Libs: 8.0.50727.4053
tcl 8.5.8 sources (all unmodified)
Visual Studio 2005 Professional 8.0.50727.879 (SP1)

Before running the script in Komodo I changed the tclsh/wish interpreters to those I just compiled.

Using

* Windows XP sp2
* Komodo IDE 5.2.0-alpha1 and Komodo IDE 5.2.3
* ActiveTcl 8.5.8.291682

and the script supplied in the details I was unable to reproduce the problem.

I put the script into a file Tcl-1.tcl, then started the Tcl debugger in Komodo, either via 'Go' or 'Step In'. The scripts prints 'Hello world', then exits. Windows gives me no note of a crash.
It doesn't matter if I let the script just run through, or step it until the end.

better get this assigned to somebody

pass the hot potato as suitable.

File Added - 352350: stack.zip

File Added - 352349: tcl.zip

File Added - 352348: tclsh85g.zip