Tk Source Code

It's possible for the font panel to be displayed when Tk is first loaded. If this does happen, it can behave badly, including leading to a segfault. This is triggered via the macOS "Saved Application State" system.

To replicate:

1. open wish from terminal
2. execute "tk fontchooser show"
3. exit via ctrl-c in terminal
4. examine ~/Library/Saved Application State/com.tcltk.wish.savedState/windows.plist - note includes font panel window
5. re-open wish from terminal
6. font panel will be visible

(Clearing the saved state can be done by, e.g., closing the font panel, and waiting for the state to be saved. Sometimes moving other windows etc. is needed)

Some bad behaviour as a result (probably other things):

1. tk fontchooser configure -font "..." will result in segfault
2. In a startup script, "tk fontchooser cget -visible" will be 0.  It will be 1 after idle event processing, though no intervening <<TkFontchooserVisibility>> is generated.

(Hiding and showing the panel will ensure everything is initialized properly.)

Life would probably be simplest all around if the font panel didn't come up on startup even if it was in saved application state.

I found a fairly easy way to fix the issue that Tk_Finalize was not being
called when closing the wish app with command-Q.  If ::tk::mac::Quit is not
defined I call Tcl_Exit directly rather than ask the interpeter to run the
exit command.  Evidently the interpreter is not in a state where the exit
command leads to a call to Tcl_Exit.

I tested on 8.7.  It built and worked correctly.  So I merged the bug-fix
branch.

I will mark this ticket as pending, while we wait for the other shoe to drop.

Well, I am confused.  Reading the code it seems that the new version
should be logically equivalent.  But there is some reason that Tcl_Finalize
does not get called in the case that Wish is launched from an icon and
terminated with command-Q.

Actually, I spoke a bit too soon.  There is an exit scenario where
Tcl_Finalize does not get called with your proposal.  That is when
Wish is launched from its icon and it is terminated with command-Q
(or, equivalently, the Quit menu).

My original fix contained:

if (isLaunched || (isatty(0) && isatty(1))) {
    Tcl_ExitProc *prevExitProc = Tcl_SetExitProc(TkMacOSXExitProc);
...

You removed the isLaunched conditional.  That was there to handle
exactly this scenario.  Is there a reason why it was removed?

This is great, Jan.  I made some stylistic changes to avoid having to
use platform-specific conditional compilation blocks and to provide a
general mechanism for (unix) ports to add an exit proc.  (Yes, I know
that will never happen, but nonetheless ...)

I logged calls to Tcl_Finalize and verified that every exit scenario
that I know of calls both [NSApplication terminate] and Tcl_Finalize.
Also, the fontchooser behavior is correct.

I haven't tested that it builds with 8.7 yet.  I am sure it will but
I will check anyway.

Thank you, Jan!  That makes sense. I will test and review.

Proposed solution here: [0e6cec30636d19e1]

I really didn't find a better way than calling Tcl_SetExitProc() from tkAppInit.c. Please test/review! Does this work as you expect?

I'll have a look. TIP #512 explains what's the problem with calling Tcl_SetExitProc from stub-enabled extensions. But you can call it just fine from tclAppInit.c. I wouldn't do that here, since the cleanup should be part of the Tk shared library (so any application linking with it will do the same cleanup). But - sure - there's another solution here.

So, stay tuned ....

It turns out that Tcl_SetExitProc is deprecated in Tk 8.7, meaning that
this fix cannot be used in 8.7.

I am reopening the ticket, targeting 8.7 and assigning to Jan since he
deprecated Tcl_ExitProc.  Hopefully he will have a better idea for how
to fix this.

I have merged the bug-fix branch, and will close the ticket (again).

I think the bug-fix branch is ready to be merged.  All tests pass.  My
testing of various apps reveals no issues.  The termination process for
Tk apps is much cleaner now.  The fontchooser and colorchooser behavior
is now rational.

I would appreciate any reviews and welcome any comments.  If there are
no issues, I will merge the changes (again :^( ).

There is a new bug-c2483bfe4b branch which implements a clean simple solution
to this problem.  It does two things:

1. Use Tcl_SetExitProc to install a custom exit function to be called by
Tcl_Exit in place of the exit function from the C runtime.  The replacement
first closes the NSFontPanel or the NSColorPanel, if they are visible, and
then calls the terminate method of NSApplication.  That method, which does
not return, terminates the process after doing some macOS finalization. So
it is an appropriate replacement for exit.

2. Install a SIGINT handler which calls Tcl_Exit instead of calling the
C runtime exit as is done by the default handler.  This fixes the original
issue of this ticket which was really only about what happens when Wish
is killed with ^C.

@bll: I verfied that if Wish is killed with a SIGHUP while the fontchooser
is visible, a fontchooser will be visible the next time Wish is run.  So
I will follow your suggestion and use the same handler for SIGHUP and SIGTERM.

This is really just doing what the manual says:

"No-one should ever invoke the exit system procedure directly; always invoke
 Tcl_Exit instead, so that it can invoke exit handlers. "

The signal handlers were not following that rule, since they were calling exit.

As long as you are adding signal handlers, I would add SIGHUP and SIGTERM in 
addition to SIGINT.  Those are the common signals that should be handled.

I can't find anything in the Apple API which would allow doing that.  Once
you create either of those objects your options are to call orderFront or
orderOut.  When you call either of those methods, the state gets saved.
If you exit the application while a panel is open, it will be reopened
the next time the application is run.

There are many different execution paths that can be followed when a Tk
application is terminated.  Most of them terminate the process before
Tk_MainLoop exits.  That is what happens when a user types ^C or ^D in the
shell and it is also happens when the system calls the non-returning
[NSApplication terminate] in response to the user selecting the Quit menu
or typing the command-Q shortcut. The only path for which the TkMain program
exits normally is when a user closes the main window of the application.

To prevent the panels from reopening, what is needed is to make sure that
all of those execution paths include code which closes the panels if they
are open. But I also want to make sure that Tk gets a chance to run its exit
handlers. That doesn't happen if you terminate the process without calling
Tcl_Exit or, at least, Tcl_Finalize. So it doesn't happen in the many cases
where the process is killed before Tk_MainLoop returns.  Apple provides
callbacks to warn about an imminent call to [NSApplication terminate].  So
that is possible to arrange.  I am working to do this as cleanly and simply
as possible.  I think it will work out fine.  Setting a signal handler to
deal with the case of ^C termination is not some horribly complicated thing
that must be avoided at all costs.  That is exactly what a SIGINT handler is for.

I misunderstood the nature of exit handlers (and the delete handlers which
Sergey suggested -- it turns out they have the same issues).  The bottom
line is that they are not what Nicolas needs after all and he will just
have to adjust his strategy.  The tk::mac::Quit design is a bit wonky as
well.  But I think I will be able to make all of these things work correctly
without increasing the complexity of the code.  It just takes some care.
The hard part really is tracing through the execution paths in all of these
different exit scenarios in order to figure out the least intrusive way
to make sure they all include the same two steps -- closing the font and
color panels and running the exit handlers.

Marc,

thanks for the clarification. So I should refine my question: is it possible in the framework to open the font and file selection dialogs in a mode which prevent them to be persisted to the saved application state? If yes, this seems to me to be a better approach than to add exit and even signal handling logic which tries to carry out the cleanup of the saved application state.

This ticket should still be open.  The merge was backed out.

@CHW: A Tk program does initialization when it starts up finalization when it
terminates.  On macOS a Tk program creates an NSApplication object during
its initialization.  An NSApplication object does its own initialization
when it is constructed and its own finalization when it is destroyed. Saving
the application state (mainly, the size and position of the open windows) is
part of the normal finalization of an NSApplication object.  All bundled
macOS applications save some state on exit. I am not interested in redesigning
macOS or in making Tk applications behave differently from all other macOS
applications when run on macOS.  I merely want Tk to construct and destroy
its NSApplication object in the expected way while also allowing Tk to do
its initialization and finalization in the way that Tk expects. I don't
see that as a workaround, and I don't see breaking the NSApplication
finalization process as a solution.

This currently works fine if the Tk program is terminated by using the
Quit menu or the command-Q shortcut.  It should also work fine if the Tk
program is terminated in any of the other possible ways: pressing ^C or ^D
when running the program in a shell, as well as closing the main window
(unless the close protocol is handled by the application).

@Jan: Thanks. The only change in the generic code was to add a check that
the Tk_Window passed to TkSendVirtualEvent is not 0.  I don't think that
could break X11, since the result of passing 0 is a segfault.  However,
the bugfix branch does make temporary changes to TkAppInit.c in the unix
directory which are likely responsible for the X11 failure.  Those
changes will be removed before I merge the bug fix branch.  They are just
there temporarily to check that exit handlers are working.  That said, I
think the X11 failure demonstrates a serious issue with TkMainEx and how
exit handlers (don't) work. At least there is something that makes no
sense to me.  I am going to write to the core list about this. We can
discuss it there with all of the experts present.

Travis build is failing for X11: https://travis-ci.org/github/tcltk/tk/jobs/735634171

Thus a naive question of a macos noob is: can we at all prevent from saved 
application state? To fight the problem where it starts and not to try to
work around?

Thanks!  I will close this ticket and merge the fix.

Marc, verified this worked (both avoiding the crash and keeping the dialog's being 'saved' between launches). Thanks!

No, this was not fixed.  But I think it is fixed now in the bug-c2483bfe4b
branch.

The same problem occurred with the colorchooser.  The native ColorPanel and
FontPanel are shared between all apps.

The crash was caused by passing a 0 Tk_Window to TkSendVirtualEvent, since
the bogus fontchooser did not have an associated Tk_Window.  I added a guard.

I added an implementation of [NSApp applicationWillTerminate:] which closes
the panels if they are open.

To make the standard cleanup happen when Wish is killed with ^C I added a
SIGINT handler which calls [NSApp terminate:].  This is only added when the
application's stdin is a tty.

I believe that I fixed that crash.  You should not see it with the current
core-8-6-branch tip.

The reason that the fontchooser pops up is that if you kill the Wish app
suddenly it does not get a chance to update the information in

"~/Library/Saved Application State/com.tcltk.wish.savedState/windows.plist"

The operating system will reopen the fontchooser if it is listed in that file.

Also, deleting that file will keep it from reopening next time.

The font panel only shows on app startup  if you terminate the Wish process with Control-C in Terminal, not if you quit Wish using Command-Q. Control-C is not the normal shutdown process for Wish. Given that we have to use a non-standard process to trigger this bug, how prevalent is it likely to be in production?