#2828 Tk Mac crashes when accelerator key spawns window

Lloyd Wood

I have a cross-platform application that I have just added menu accelerators (keypress shortcuts) to.Works fine on Tcl/Tk in Linux and in Windows (Cygwin Insight). Freezes on Mac OS X 10.6 Snow Leopard when an accelerator key is pressed to spawn a window.

I have a demonstration of this freeze (can't upload the tarball code, there's a 256k limit):
tar xvf savi-dev-kevin.tar
cd savi-dev-kevin
make ARCH=macosx
./savi &
Click on the letterbox-shaped table-of-numbers window, then press either command-G to spawn the Global coverage window, command-F to spawn the fisheye window, or command-M to get the _empty space_ dialog - all windows will draw but missing a Mac titlebar and controls, and then the application freezes.

If you relaunch savi and only point and click on the menu options, everything is fine. If you relaunch savi and force use of popup menus rather than the Mac menubar with the savi -redrawn-menus flag (more on the reason for that flag below), accelerators work fine. It's accelerators plus the Mac menubar that is the problem.

A previous example you may have read about on the tcl-mac mailing list: The Tk Mac menubar never worked at all in 10.5 when Tk applications were launched from the terminal (I implemented a workaround for that in savi with -redrawn-menus and popup menus within window frames that avoided using the broken menubar - oddly, I see accelerators work fine from the Mac popup menus I implemented to work around that previous problem. Again, it's related to the Mac menubar). The release of 10.6 and the upgrade to Tcl/Tk in Xcode eventually fixed that problem (along with other Mac-specific problems like too-wide listboxes causing hangs), but that took eighteen months to happen, and has now exposed this crash.

This appears at first glance to be a similar _maybe the Tk shipped with 10.7 will fix it_-level Mac menuing bug; I do not see what I can do about it, as the installed base on Snow Leopard has Xcode with Tcl/Tk 8.5.7 and that's it.

Tk on the Mac should imo be as robust as Tk on other platforms, and should not require workarounds to prevent crashes.

(I posted about this to the tcl-mac list, but, despite being a subscriber, my posts hit a filter rule and are queued for a moderator to look at. Hence the background detail here.)


  • Donal K. Fellows

    • priority: 5 --> 9
    • assigned_to: hobbs --> das
  • Stefan Haller

    Stefan Haller - 2010-09-14

    Here's a small example that illustrates the problem. Choosing "Show Dialog" from the File menu works fine; hitting F1 hangs. (When using wish8.4 instead of wish, it works fine.)

    This bug also affects git gui and gitk. For example, hitting Command-P in git gui (for "Push") hangs.



    menu .mbar
    . config -menu .mbar

    .mbar add cascade -label "File" -menu [menu .mbar.file]

    set m .mbar.file
    .mbar.file add command -label "Show Dialog" -command show_dialog \ -accelerator F1

    bind . <F1> show_dialog

    proc show_dialog {} {
    set w .error
    toplevel $w
    message $w.m -text "Message text" -justify center -aspect 400
    pack $w.m -side top -fill x -padx 20 -pady 20
    button $w.ok -default active -text "OK" -command "destroy $w"
    pack $w.ok -side bottom -fill x
    tkwait window $w

  • Lloyd Wood

    Lloyd Wood - 2010-09-14


    I tried out your wish script on OS X 10.6.4 with the default Tcl/Tk install supplied by Apple.

    Though I reported this bug and can get SaVi to crash as I described in the bug description, your script works fine to spawn the OK dialog - both when doing fn-F1 or selecting standard function key use in the keyboard prefs panel.

    Comparing with my experience with SaVi (accelerator keys in menubar cause a crash, accelerator keys from popup menus in window do not) your script puts the menu in a window rather than the menubar - so I would not expect it to crash.

    Why did you choose F1? Do you have something else also using F1? Does the script crash when a different letter-key accelerator is chosen?

  • Stefan Haller

    Stefan Haller - 2010-09-19

    That's very strange; the script freezes reliably for me (I'm also on 10.6.4). How exactly do you launch it?

    About menu bar vs. window: in my experience all you need is a main menu with an accelerator, and any key binding with the same key; it doesn't seem to matter what ui element the key is bound to.

    As for F1 vs. other keys: I simply picked F1 randomly because it's the same in the --accelerator option and the bind command. Any other key also reproduces the problem. For Cmd-J, for example, use "-accelerator Cmd-J" and "bind . <M1-Key-j> show_dialog".

  • Lloyd Wood

    Lloyd Wood - 2010-09-19

    Aha, my mistake, sorry.

    I have Fink installed, so /sw/bin/wish also exists, and gets priority in the path when I type:
    wish accel.tcl
    That doesn't crash - but is producing a Tk-on-X window with classic popup-type menus in the window. It's a red herring.

    /usr/bin/wish accel.tcl
    produces a blank square non-functional window.

    chmod +x accel.tcl
    menu: command not found
    and a host of other errors.

    If I alter the first line of accel.tcl from #!/usr/bin/wish to say !#/sw/bin/wish then
    works non-crashingly as before.

    I have duplicated your crash by doing:
    and then using File/Source... to load in accel.tcl. Pressing F1 gets me a freeze with a borderless 'Message text' window. So, yes, I've now duplicated your crash, which has effectively duplicated mine in a lot less code.

    As well as being buggy, the Tk/wish supplied with OS X is poor at being launched from the Terminal command line, as the above examples suggest. SaVi launches from the command line, and couldn't even get a menubar in 10.5.

    (I've found that I need to bind both upper and lower case keys, ie Command-J and Command-j, to get binding to work. M1-Key to arbitraility choose a modifier is new syntax to me; I've been setting $KEY by platform to Ctrl or Command...)

  • Kevin Walzer

    Kevin Walzer - 2011-01-06

    I've tried this sample script, and I find that commenting out the tkwait line appears to fix the issue WRT F1.

    I also cannot reproduce the issue with another binding, cf. Command-S. If you replace <F1> with <Command-S> it also works fine, with or without the tkwait line.

  • Don Porter

    Don Porter - 2011-06-02

    status for 8.5.10 ?

  • Kevin Walzer

    Kevin Walzer - 2011-06-02

    I've tested steffanhaller's sample script with various tweaks. While the script as presented does cause Wish to freeze, the following adjustments cause the dialog to display without any freeze:

    1. Remove the tkwait line.
    2. Map the accelerator to any key other than F1.

    I'm not sure why F1 causes the crash and nothing else does--digging into the Tk Mac source code does not yield any obvious problems--but in any event a workaround is trivial. Given the ease of working around this issue, it's hard to justify a priority of 9 for this bug, something that would hold up a release. As a result I'm lowering the priority to 5 and resolving it as "works for me" though I am leaving the bug open. If anyone else wants to investigate this more closely and contribute a patch, I will be glad to review it.

  • Kevin Walzer

    Kevin Walzer - 2011-06-02
    • assigned_to: das --> wordtech
    • priority: 9 --> 5
    • status: open --> open-works-for-me
  • Lloyd Wood

    Lloyd Wood - 2011-06-03
    • status: open-works-for-me --> open-later
  • Lloyd Wood

    Lloyd Wood - 2011-06-03

    Reducing the priority may be reasonable (though I wonder about developers implementing accelerators and not testing with shipping Tk in Leopard/Snow Leopard - the safest workaround is not to implement accelerators at all) - but putting 'works for me' when you've actually duplicated the crash yourself with an unmodified test script is not, imo - testing that script shows it doesn't work for you! 'Later' is probably better?

  • Stefan Haller

    Stefan Haller - 2011-06-13

    I can easily reproduce this with other accelerators than F1; you just have to change this in both the "-accelerator" option of the menu, and in the bind command. For example, to test it with Command-J, use "-accelerator Cmd-J" and "bind . <M1-Key-j> show_dialog".

    I don't see an easy way to work around it, and I'm surprised at your choice of priority.

    Also, I ran into this with existing, real software (git), so it's not an academic problem. I suspect the reason why it doesn't come up much more often with git is that the official git binaries are built against wish8.4. If you build git yourself from source, you immediately run into the problem by choosing "Revert Changes" (Command-J) in git gui.

    Here is my attempt at a workaround for git gui, but it's an ugly and unreliable hack, and it shouldn't be needed: <http://www.spinics.net/lists/git/msg141068.html>

  • Lloyd Wood

    Lloyd Wood - 2011-06-13

    I'm raising the priority back up. That's two applications that have reported this so far. That makes it a cross-platform show-stopper.

  • Lloyd Wood

    Lloyd Wood - 2011-06-13
    • priority: 5 --> 9
  • Kevin Walzer

    Kevin Walzer - 2011-06-13
    • priority: 9 --> 5
    • status: open-later --> open-out-of-date
  • Kevin Walzer

    Kevin Walzer - 2011-06-13

    On further testing, I am unable to reproduce this error either against a recent build of Tk 8.6 from Fossil trunk or against a year-old build of Tk 8.5 Cocoa (8.5.9) in stefan's sample script. I can reproduce it against the version of Tk-Ccoa bundled with Snow Leopard, which is 8.5.7. I'm not sure when this got fixed, but the Snow Leopard build of Tk-Cocoa is half-baked and full of bugs. Apple does not update its builds of Tk until the next release of the OS, so there's nothing that can be done here. I suggest linking your apps against a more recent, stable version of Tk-Cocoa or incorporating one of the numerous workarounds documented here. I'll leave this bug open for a bit longer to allow comments, but since this bug is apparently found only in Tk-Cocoa bundled with Snow Leopard, no further action can be taken.