Ruby crashes during `require 'tk'` on macOS 10.14.6 (Mojave)

[suetanvil]

When I install the tk gem with gem install tk and then type require 'tk' into irb, the program crashes with the error message below. This appears to be due to a new limitation of the macOS GUI layer.

I am able to work around this by installing ActiveTcl 8.6 and then reinstalling the gem.

I am using Ruby 2.7.0 built from sources using rbenv.

I also attempted to work around this using the tcl-tk package provided by HomeBrew. I was not successful but it is possible I did not correctly specify the version of Tcl/Tk to use.

If you would like, I am willing to submit a pull request that updates the README.md and lists ActiveTcl as a dependency for macOS.

Backtrace follows:

2021-04-27 12:24:31.874 ruby[22997:225436] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'NSWindow drag regions should only be invalidated on the Main Thread!'
*** First throw call stack:
(
	0   CoreFoundation                      0x00007fff2c10eacd __exceptionPreprocess + 256
	1   libobjc.A.dylib                     0x00007fff56812a17 objc_exception_throw + 48
	2   CoreFoundation                      0x00007fff2c128629 -[NSException raise] + 9
	3   AppKit                              0x00007fff296cd5ca -[NSWindow(NSWindow_Theme) _postWindowNeedsToResetDragMarginsUnlessPostingDisabled] + 317
	4   AppKit                              0x00007fff296ca9f7 -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1479
	5   AppKit                              0x00007fff296ca42a -[NSWindow initWithContentRect:styleMask:backing:defer:] + 45
	6   Tk                                  0x00007fff37ea6eae TkMacOSXMakeRealWindowExist + 749
	7   Tk                                  0x00007fff37ea6aea TkWmMapWindow + 56
	8   Tk                                  0x00007fff37e19c05 Tk_MapWindow + 155
	9   Tk                                  0x00007fff37e21dae TkInstallFrameMenu + 267
	10  Tcl                                 0x00007fff37db6e7c TclServiceIdle + 75
	11  Tcl                                 0x00007fff37d9e4b9 Tcl_DoOneEvent + 344
	12  tcltklib.bundle                     0x000000010d2d2f20 call_DoOneEvent_core + 16
	13  tcltklib.bundle                     0x000000010d2d29fb tk_funcall + 427
	14  libruby.2.7.dylib                   0x0000000109716843 rb_protect + 339
	15  tcltklib.bundle                     0x000000010d2cb592 lib_eventloop_main_core + 642
	16  libruby.2.7.dylib                   0x00000001097169c0 rb_ensure + 240
	17  tcltklib.bundle                     0x000000010d2ceacd lib_mainloop + 173
	18  tcltklib.bundle                     0x000000010d2d1dd4 ip_mainloop + 180
	19  libruby.2.7.dylib                   0x00000001098c97c0 vm_call_cfunc + 368
	20  libruby.2.7.dylib                   0x00000001098af69f vm_exec_core + 14527
	21  libruby.2.7.dylib                   0x00000001098c45dc rb_vm_exec + 2780
	22  libruby.2.7.dylib                   0x000000010987f35e thread_do_start + 910
	23  libruby.2.7.dylib                   0x000000010987ecad thread_start_func_2 + 557
	24  libruby.2.7.dylib                   0x000000010987e89c thread_start_func_1 + 268
	25  libsystem_pthread.dylib             0x00007fff581d52eb _pthread_body + 126
	26  libsystem_pthread.dylib             0x00007fff581d8249 _pthread_start + 66
	27  libsystem_pthread.dylib             0x00007fff581d440d thread_start + 13
)
libc++abi.dylib: terminating with uncaught exception of type NSException
^CAbort trap: 6 (core dumped)

[jeremyevans]

I don't have access to a macOS system, so I'm not going to be able to debug this.

From the error message, it appears to be threading related. Are you using tk 0.4.0, which defaults to running the event loop on the main thread? If not, can you try it with tk 0.4.0?

I'm OK with an update to the README that mentions this macOS issue and that ActiveTcl should be tried if you run into problems. However, I don't think we should say it is a dependency unless there is some proof that using ActiveTcl is the only way to fix the issue.

[suetanvil]

It is indeed tk-0.4.0, according to gem.

[zor-el]

@jeremyevans, my hunch may be totally wrong, but I feel this StackOverflow answer might be relevant and possibly related to your commit from March 23rd 85d228a.

[jeremyevans]

@zor-el It's possible, especially if tk-0.3.0 works and tk-0.4.0 does not. However, if tk-0.4.0 works with ActiveTcl, it seems to more like to be related to the tcl/tk installation. I don't think we should revert 85d228a, at least not by default. ruby-tk is almost unusably slow before that commit.

[shawnanastasio]

I'm encountering the same error on an M1 macbook with macOS 12 using brew's tcl-tk version 8.6.12.

I've installed the gem using:

gem install tk -- --with-tcl-include=/opt/homebrew/opt/tcl-tk/include --with-tk-include=/opt/homebrew/opt/tcl-tk/include --with-tcl-shlib-search-path=/opt/homebrew/opt/tcl-tk/lib --with-tk-shlib-search-path=/opt/homebrew/opt/tcl-tk/lib

and I get the same crash when trying to use tk from ruby.

I have discovered, though, that uncommenting RUN_EVENTLOOP_ON_MAIN_THREAD = true here fixes this and allows tk to work.

EDIT: On further inspection, it seems that the check here that should set RUN_EVENTLOOP_ON_MAIN_THREAD=true is not getting hit with the tcl-tk distribution from brew, since it reports a TclTkLib::WINDOWING_SYSTEM of x11 instead of aqua (despite it clearly using aqua and not X11).

[jeremyevans]

@shawnanastasio Thanks for the information. Maybe we should default RUN_EVENTLOOP_ON_MAIN_THREAD to false on Mac OS?

[shawnanastasio]

@shawnanastasio Thanks for the information. Maybe we should default RUN_EVENTLOOP_ON_MAIN_THREAD to false on Mac OS?

Yes, I think removing the aqua backend check and setting it unconditionally on macOS might be a good idea (though it needs to be set to true, not false).

[jeremyevans]

@shawnanastasio Understood. We switched the RUN_EVENTLOOP_ON_MAIN_THREAD default in another case from false to true in 85d228a, so switching it in other cases makes sense. Can you try #44?

[shawnanastasio]

@shawnanastasio Understood. We switched the RUN_EVENTLOOP_ON_MAIN_THREAD default in another case from false to true in 85d228a, so switching it in other cases makes sense. Can you try #44?

Yes, I can confirm that this works on M1/macOS 12.2/brew tcl-tk 8.6.12/brew ruby 2.7.5.

As an aside, perhaps extconf.rb could be amended to look for tcl/tk in /opt/homebrew so that specifying its path at build time is no longer necessary? The M1 version of homebrew defaults to this new prefix instead of the old /usr/local which I see the program already checks.

[jeremyevans]

@shawnanastasio Understood. We switched the RUN_EVENTLOOP_ON_MAIN_THREAD default in another case from false to true in 85d228a, so switching it in other cases makes sense. Can you try #44?

Yes, I can confirm that this works on M1/macOS 12.2/brew tcl-tk 8.6.12/brew ruby 2.7.5.

OK, I merged #44.

As an aside, perhaps extconf.rb could be amended to look for tcl/tk in /opt/homebrew so that specifying its path at build time is no longer necessary? The M1 version of homebrew defaults to this new prefix instead of the old /usr/local which I see the program already checks.

That makes sense to me. I don't have a Mac to test with, so can you submit a pull request for that?

[shawnanastasio]

That makes sense to me. I don't have a Mac to test with, so can you submit a pull request for that?

Sure. A first naive attempt of just appending "/opt/homebrew" to the relevant arrays didn't seem to work -- in fact I'm not sure if the code as it is will even detect brew's tcl-tk on Intel macs that use the /usr/local prefix. I'll try to work on this some more when I have time and submit a PR.