#5050 Tcl Scripts results in "called Tcl_FindHashEntry on deleted"

obsolete: 8.5.11
open
Don Porter
5
2012-06-08
2012-06-07
arius
No

Tcl Version: 8.5.11
OS Platform and Version: Windows 7 (64 bit) & Linux (32 bit)
Thread Package: 2.6.6 (Linux) & 2.6.7 (Windows)

Problem Behavior:
- If script execution has finished the following output appears: called Tcl_FindHashEntry on deleted
- Additionally, under Linux a core dump is created

Expected Behavior:
- A clean finalization of Tcl interpreter

Tcl-Script:

package require Thread

set th1 [thread::create {puts worker_running ; thread::wait ; puts worker_stopped}]

thread::send -async $th1 {puts script_started; after 5000; puts script_done} go

puts "waiting for go..."

vwait go

if { [thread::exists $th1] } {
thread::release $th1
puts worker_released
}

puts main_done

Discussion

  • arius
    arius
    2012-06-07

    Not reproducible with...

    Tcl Version: 8.6b2
    OS Platform and Version: Windows 7 (64 bit)
    Thread Package: 2.6.7 (Windows)

     
  • Don Porter
    Don Porter
    2012-06-08

    • assigned_to: vasiljevic --> dgp
     
  • arius
    arius
    2012-06-08

    Set the following environment variable on the command line at Windows...

    set TCL_FINALIZE_ON_EXIT=1

    ...and executed the script again with Tcl version 8.6b2.

    => No output on the command line appeared pointing to finalization problems.

     
  • Don Porter
    Don Porter
    2012-06-11

    Note that due to variations in thread scheduling, this
    demo script is not deterministic. The fact that it runs
    once without failing doesn't confirm correct operations.

    Making several runs with combinations of the 8.5 and
    trunk branch tips as well as Thread 2.6.7 and 2.7b1
    I am able to see either panics or segfaults in all combinations
    when TCL_FINALIZE_ON_EXIT is set.

    Using Tcl 8.6's default setting where thread finalization is skipped
    does appear to avoid the problem. So in some sense, this isn't
    really fixed, but 8.6 works around it.

     
  • Yes. This is, as you remember, the very motivation for the 8.6 move (bug 2001201).
    Bottom line: the OS's exit() is the fastest and most rational way of exiting, especially in a multithreaded setup since the ordered untangling of a locking graph is in general intractable.

    Note that the existence of bugs in thread finalization, when forced, is an orthogonal matter; we didn't even need them to prefer quick-exits !