App crash when compiled with TCL_MEM_DEBUG

Question

On TCL 8.6.9, I tried to use TCL_MEM_DEBUG to help diagnose a memory leak in my app but I get a crash when using/enabling it.

The same code is running fine when TCL is compiled without it but crash when I use the flag.

The code crash in TCL when calling function "Tcl_ResetResult->ResetObjResult->Tcl_IsShared(Tcl_DbIsShared in debug)".

It occurred while executing "Tcl_Eval()".

(It is an application with multiple thread(interpreter)).

Thanks

A little bit more info: This happens in a thread that was created in a DLL. So what we do here when the DLL is loaded from TCL, we create a new TCL interpreter(Tcl_CreateInterp) then we create a new thread where we use that interpreter. Others threads(with their own interpreter) send command to that thread that execute them. This is when this crash occur.

In memory debug mode, the implementation checks that the thread locality rules are followed (among other things). Is there an error message associated with the crash (ie was it an ordered panic or a disorderly flat-out crash)? — Donal Fellows
Hi Donal, I'm not sure about your question (panic or flat-out). But it does endup in "Panic" saying something like "table object not created". Not sure. I'm not at work right now but tomorrow morning I'll get the exact error. — Eric
The exact line is "Tcl_Panic("object table not initialized");" in function "Tcl_DbIsShared()". — Eric

sebres sebres · Accepted Answer · 2019-11-15T17:02:41

Yes, this situation can indeed occur in tcl compiled with TCL_MEM_DEBUG, if the thread currently calling IsShared, IncrRefCount or DecrRefCount etc but have not yet created any object itself.
Actually the object table is created per thread in its TSD in function TclDbInitNewObj (so on demand if first object going created in thread)...

So I guess some obj is created in thread Th1 and supplied to thread Th2, but thread Th2 still did not created any object.
Normally it never occurs because an interpreter is created in the thread self (and during init-phase several objects will be created). Just you did write above:

we create a new TCL interpreter(Tcl_CreateInterp) then we create a new thread where we use that interpreter.

Although I don't think it is good idea at all (overwork in thread-storage etc), but I think it could be a bit unexpected behavior on our side and if we can we should fix that.

~~As long as it is still not fixed, as workaround just create 1 empty object in every thread working with tcl-objects in your app, like this:~~

#ifdef TCL_MEM_DEBUG
if (1) { Tcl_Obj *objPtr = Tcl_NewObj(); Tcl_DecrRefCount(objPtr); };
#endif

UPDATE:

I don't think the suggested workaround would help, because you'd probably get another panic
Trying to check shared status of Tcl_Obj allocated in another thread.
It looks like current implementation of TCL_MEM_DEBUG was never concepted to handle tcl-objects across the threads.

So at the moment the "solution" to the issue would be to create the interpreter directly in the target thread.

App crash when compiled with TCL_MEM_DEBUG

1 Answers