alloc: 无效块 - Tcl_IncrRefCount 和 Tcl_DecrRefCount 线程对于线程化 Tcl / 每个线程 1 个 interp 是安全的吗？答案

【问题标题】：alloc: invalid block - Are Tcl_IncrRefCount and Tcl_DecrRefCount thread safe for threaded Tcl / 1 interp per thread?alloc: 无效块 - Tcl_IncrRefCount 和 Tcl_DecrRefCount 线程对于线程化 Tcl / 每个线程 1 个 interp 是安全的吗？
【发布时间】：2015-02-11 19:04:50
【问题描述】：

我们的 32 位服务器应用程序静态嵌入 tcl 8.4.11。在 Red Hat Linux 6.5 64 位上，我们遇到了崩溃/核心转储。失败的样子

alloc: 无效块: 0xf6f00f58: 88 f6 0

在问题的底部，我记录了我们看到的两个不同的核心转储。

我们已经隔离了 TCL 对象的潜在根本原因，该对象在同时运行不同 TCL 解释器实例的两个线程之间共享。我们认为这是因为 TCL 对象是从这些同时执行的 TCL 解释器传递给 Tcl_IncrRefCount / Tcl_DecrRefCount 的。

TCL 编译为线程时，Tcl_IncrRefCount / Tcl_DecrRefCount 线程安全吗？
TCL 解释器实例是否共享 TCL 对象？有什么方法可以禁用跨解释器实例的 TCL 对象共享？
TCL 8.6.3 版的情况是否有所好转？

(gdb) bt
#0  __kernel_vsyscall () at arch/x86/vdso/vdso32/sysenter.S:49
#1  0x001b7871 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0x001b914a in abort () at abort.c:92
#3  0x080f611c in Tcl_PanicVA ()
#4  0x080f613b in Tcl_Panic ()
#5  0x0810133c in Ptr2Block ()
#6  0x08100e04 in TclpFree ()
#7  0x080b46a7 in Tcl_Free ()
#8  0x08100686 in FreeStringInternalRep ()
#9  0x080fdac1 in ResetObjResult ()
#10 0x080fd316 in Tcl_GetStringResult ()
#11 0x0808aaad in run_tcl_proc (pDevice=0x8e0ba08, pInterp=0x8d798c0, iNumArgs=2, objv=0x115434c, bIsCommand=0 '\000', pCommand=0x0)
#12 0x08093672 in Tcl_begin_next_state (pDevice=0x8e0ba08, iNextState=RunPoll, pCommand=0x0)
#13 0x08093759 in Tcl_port_thread (dummy=0x8d1cab8)
#14 0x008bcb39 in start_thread (arg=0x1154b70) at pthread_create.c:301
#15 0x0026fc2e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133
(gdb)

(gdb) bt
#0  __kernel_vsyscall () at arch/x86/vdso/vdso32/sysenter.S:49
#1  0x00395871 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0x0039714a in abort () at abort.c:92
#3  0x080f611c in Tcl_PanicVA ()
#4  0x080f613b in Tcl_Panic ()
#5  0x0810133c in Ptr2Block ()
#6  0x08100e04 in TclpFree ()
#7  0x080b46a7 in Tcl_Free ()
#8  0x080d21b6 in TclExecuteByteCode ()
#9  0x080d1bc1 in TclCompEvalObj ()
#10 0x080fbd5c in TclObjInterpProc ()
#11 0x080b026a in TclEvalObjvInternal ()
#12 0x080d2716 in TclExecuteByteCode ()
#13 0x080d1bc1 in TclCompEvalObj ()
#14 0x080fbd5c in TclObjInterpProc ()
#15 0x080b026a in TclEvalObjvInternal ()
#16 0x080b0517 in Tcl_EvalObjv ()
#17 0x0808aa02 in run_tcl_proc (pDevice=0x94a2500, pInterp=0xac2bba0, iNumArgs=2, objv=0x11b034c, bIsCommand=0 '\000', pCommand=0x0)
#18 0x08093672 in Tcl_begin_next_state (pDevice=0x94a2500, iNextState=RunPoll, pCommand=0x0)
#19 0x08093759 in Tcl_port_thread (dummy=0x9365e98)
#20 0x00356b39 in start_thread (arg=0x11b0b70) at pthread_create.c:301
#21 0x0044dc2e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133
(gdb)

【问题讨论】：

我们通过在阅读器调用 Tcl_SetObjResult 之前在阅读器线程中使用 Tcl_DuplicateObj 解决了这个崩溃。对象的写入者和读取者已经被互斥，但是当写入者释放先前的写入时发生崩溃，与释放读取器返回的结果对象的 tcl 解释器发生冲突。

标签： c thread-safety tcl core panic

【解决方案1】：

调用Tcl_IncrRefCount（实际上是一个简单的宏）和Tcl_DecrRefCount（一个复杂的宏）是某种线程安全的，但这只是因为每个Tcl_Obj只能从创建它的线程；对 T_IRC 和 T_DRC 的并行调用很好，只要它们的值不同。这样做的好处是访问不需要锁定（Tcl_Obj 结构的内存管理器利用了这一点）。

请注意，除非您非常小心，否则多线程访问根本不是一个好计划，因为如果类型转换需要，即使像 Tcl_GetIntFromObj 这样的读取器操作也可以写入底层结构被应用。 这些操作没有被锁定。 这样做需要对当前值的类型有非常深入的了解——虽然@987654327 通常不鼓励你在 Tcl 中首先考虑这一点@ 可以帮助在 8.6 中探索这一点——并且在线程之间进行一些非常小心的联锁，这样一个线程就不会写，而另一个线程会偷看。 根本不要这样做，虽然不是 100% 准确，但这种方法最不可能导致头痛。

您可能应该阅读更多有关您应该如何做的信息。 The ActiveState blog有合理的介绍。

【讨论】：