Tcl_AsyncDelete: async handler deleted by the wrong thread about tk HOT 5 CLOSED

I am getting the same error message, under different circumstances. I have a ruby program which uses the embedded TCL interpreter to run a TCL script. Note, it does not use TK and is meant to not create a TK event loop. Also, it worked fine a few versions ago, and was doing a:

require 'tcltklib'

I upgraded to Fedora 27 and my gem can no longer find a package called tcltklib. I found ruby-tk which appears to be the later version of the same thing, changed my code to require 'tk' and it seemed to run. However, I get the error:

Tcl_AsyncDelete: async handler deleted by the wrong thread
Aborted (core dumped)

I have boiled down the test case to just a few lines of code as follows:

require 'tk'
tclip = TclTkIp.new(nil, false)
tclip._eval("set i [interp create]")

When run, this produces the error. If my TCL doesn't create a new interpretor (inside the script) no error, but if I do, it crashes on exit. Note, the script completes and does its work. It is only at the end of the program that it produces the error.

If I add this line of code:

tclip._eval("interp delete $i")

I can keep the error from happening. But it seems like tcl should be able to clean itself up properly on exit even if there is a lingering interpreter left hanging around.

from tk.

Can you let me know if this is still an issue with the current version of Ruby? The error in the original post appears to be due to calling finalizers at exit. You could probably work around it by calling exit! at the end of the program. I'm not sure if that is a sufficient workaround for your purposes. I'm also not sure if this is a Ruby issue or a TCL issue. The backtrace shows the bug comes from TCL, but that could be due to invalid arguments being provided by Ruby.

from tk.

I still get the error message as described above.

I'm running Fedora 32. Ruby version is 2.7.1. Very latest right now looks to be 2.7.2, but FC32 hasn't picked that up.

from tk.

Can you please try pull request #20 and see if it solves this issue?

from tk.

I think this should be fixed by #20, since #12 was a very similar issue to this one and it was fixed by #20

from tk.