-
-
Notifications
You must be signed in to change notification settings - Fork 31.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves #88991
Comments
Using tkinter.filedialog crashes on macOS 12.0 Beta (21A5294g) on M1 when the open file dialog window is created. Full crash below: 2021-08-04 07:19:04.239 Python[40251:323363] *** Assertion failure in -[NSOpenPanel beginServicePanel:asyncExHandler:], NSVBOpenAndSavePanels.m:1910 |
Thanks for reporting issue and for including the backtrace. I presume you used the Universal 2 installer, given that you are running an M1 mac? Kevin, do you have access to the macOS 12 beta to help test whether this is a Tkinter or Tk bug? (I assume the latter, as it is likely Apple have changed the API again) |
Thanks for the report. I verified that the crash also occurs on an Intel Mac VM with Monterey beta 4 using the current python.org universal2 installers for 3.9.6 and 3.10.0rc1; they both have a private copy of Tk 8.6.11; so the problem does not appear to be Apple Silicon (M1) related. For what it's worth, the legacy python.org 3.9.6 Intel-only installer, which uses a copy of Tk 8.6.8, does not crash the Monterey beta 4. And no such failures are observed using any of those installers on the current Big Sur 11.5.1 release. |
I used brew.sh to install Python, which I think uses the universal installer (although I can’t check, reinstalling macOS after hours of failing to downgrade back to Big Sur). I can’t remember the exact error, but it seemed to be from Apple’s end since it complained about not having access to the save/open dialog box. After I reinstall macOS, if you need further testing, i’m open to trying.
|
As far as I know, Homebrew builds its own Python and Tk.
Thanks. I think the next step would be to try to reproduce just using Tcl and Tk as this most likely is an issue in Tk rather than Python. It's also quite possible that the underlying problem will be fixed in a future Monterey beta. Alas, I don't have time to look further into this in the immediate future. Perhaps someone can follow up directly with the Tk folks. |
I built Tcl and Tk 8.6 on Monterey beta (21A5294g) and I see this Anyway, this looks harmless and the messages will almost surely go Beta releases are betas, even for macOS.
On Thu, Aug 5, 2021 at 1:23 PM Ned Deily <report@bugs.python.org> wrote:
|
I should have mentioned that I tested on Intel hardware, not M1. I do not have access to an M1 Apple at this time. |
Thanks for looking into this, Marc. |
I am also experiencing this issue. I have an M1 Macbook Air running MaOS Monterey Version 12.0 Beta (21A5304g) with a fresh install of Python 3.9.6. When attempting to save or open anything from either the editor or console window I get the following error message "The Save file operation failed. The save file operation failed to connect to the open and save panel service.” I have granted the IDEL full drive access which hasn't resolved the issue. The dialog prevents any savings from occurring making the IDEL useless. I have submitted this issue through Apple's Feedback tool as well. |
Can also confirm this issue, tested on M1 and Intel Mac and both has the same error when using Monterey 12.0 Beta 21A5506j. On the same computer, using Big Sur, saves the file successfully and no error present. Seems like a Monterey issue, not dependent on specific hardware. (Intel/M1) Tested on fresh Python 3.9.6 (tk version 8.6) Installation on Big Sur and Monterey Beta (Build 21A5506j) on a M1 Macbook Pro and Early 2015 13" Macbook Pro. |
Same issue. Running Monterey beta. Experiencing crash. Is there any plan for a fix or is the plan to wait for Monterey to release? |
Unfortunately, I am still seeing this failure in Monterey beta 9. However, we are no longer alone. Here is a report of the same issue in Android Studio: This is reportedly fixed in the Adroid Studio beta, so maybe someone will be able to figure out what Google did to workaround the problem. |
I was able to fix this problem for Tk on Monterey beta [21A5543b]. Here is a synopsis. Tk used to open the file dialog by calling So my workaround was to add conditional code that only calls the runModal Needless to say, none of these changes are documented by Apple. |
Marc, thanks for the update. Will there be a Tcl/Tk release soonish that includes this fix? Alternatively, is there patch that we can apply to the latest release when building the copy of Tk included with the installers? |
Thanks for the heads-up about the "10.16" issue, Marc. Sorry I missed that aspect when reviewing your fix as we had run into that "feature" before. I guess the idea was that it made it easier during the early days of Big Sur to build some products that were not expecting the version numbering change. In any case, it isn't an issue for the python.org macOS installer builds; we currently support two variants: universal2 which builds on 11 Big Sur (or later) with Tk 8.6.11 (or later); and the deprecated Intel-only variant which builds on 10.9 with Tk 8.6.8. After all the testing we've done, I'd prefer to not disturb the patches in place for the imminent release of 3.9.8 and a patched 3.10.0 installer; we will pick up the final versions when 8.6.12 releases. I am planning to use 8.6.12rc1 with the also imminent 3.11.0a2 to give it a little exposure but the 10.16 fix is also not an issue for it. |
As of 2021-11-02, the macOS installer file on python.org for the 3.10.0 release has been updated to include an updated Tk library that includes this fix. All other files installed by the installer are the same as in the original 3.10.0 installer, other than the Tk libraries and the installer ReadMe file. This updated installer pkg, at https://www.python.org/ftp/python/3.10.0/python-3.10.0post1-macos11.pkg, is now the default download for macOS from python.org and appears on the 3.10.0 release page (https://www.python.org/downloads/release/python-3100/). If you have already installed the original 3.10.0 universal2 installer pkg from python.org and are encountering this problem with file dialog windows on macOS 12 Monterey, you can download and run the updated installer pkg to obtain the updated Tk libraries. The updated Tk will also be included in the macOS installers provided with the next Python releases: 3.9.8 (expected to be released this week) and 3.10.1 (planned for 2021-12-06), as well as the 3.11.0a2 development preview. |
Alas, the celebration was premature. Shortly after posting msg405488 above, I installed the updated 3.10.0 on yet another macOS system and, on this one, I observed a problem: under some circumstances at least, the Save dialog window becomes orphaned and does not disappear until IDLE terminates. Here is one sequence of commands I've used:
This happens on both Monterey and Big Sur, I haven't tried earlier systems. So, while the current fix does make IDLE file dialogs usable on Monterey, it introduces an orphaned (though seemingly harmless) window on presumably all systems. The big question is why didn't we see this during earlier testing? In my case, the answer is that on all the systems I tested with, the Save dialog window was in its default "compact" form and thus was completely hidden by the IDLE windows. Plus it doesn't seem to always happen if you vary the sequence of events slightly, not surprisingly. I only noticed the orphaned Save window now because on this latest system the Save window defaulted to the fully expanded version (with the side bar etc) and that Save window was wide enough to not be fully hidden behind the other IDLE windows. Sigh! Until we can resolve this, I have reverted the changes to the website so that the default macOS download is again the original 3.10.0 installer. The patched installer is still downloadable for testing at https://www.python.org/ftp/python/3.10.0/python-3.10.0post1-macos11.pkg. |
I found the cause of the zombie dialog window. I was supposed to call I see that if I open a new editor with Command-N and enter some text |
Do you mean Command-S after modifying an IDLE edit window that has already been Save (or was Opened, not New)? In that case, the file dialog shouldn't appear: it saves to the existing file. To change the file, you'd need to do a Save As ... (Shift-Command-S). Or perhaps I'm misunderstanding? |
Yes that is what I meant. So I guess everything may be OK now. I did When you press Command-S on a non-new edit window you do see the flash |
Yes, that is long-standing behavior of IDLE on macOS; I just verified that the Save menu flash also happens with the legacy 8.6.8 Tk. I have never noticed it as a problem before and I'm not aware of any user reports of it so I think we can live with that :) |
OK. Shift-Command-S works. I will attach the fossil diff which |
A (hypothetical) explanation: I think that each NSWindow maintains a queue of attached sheets. Failing to call the [parent endSheet] method left the file dialogue NSPanel in the queue, although it had been ordered offscreen and so was not visible. Opening the NSAlert added it to the top of the queue. Closing the alert caused it to be removed from the queue. But, since the queue was not empty, the window manager was supposed to orderFront the next sheet in the queue. That sheet was the file dialog, which had not been destroyed since adding it to the queue had incremented its reference count, and failing to remove it had not decremented its reference count. But the separate process that handles events for the file dialog had exited long ago. So that made the newly re-opened file dialog NSPanel into a zombie. |
OK, thanks to Marc's quick response, it looks like we have conquered the elusive zombie dialog window. So let's try again. Note that the download file name has changed to avoid any confusion: As of 2021-11-03, the macOS installer file on python.org for the 3.10.0 release has been updated to include an updated Tk library that includes this fix. All other files installed by the installer are the same as in the original 3.10.0 installer, other than the Tk libraries and the installer ReadMe file. This updated installer pkg, at https://www.python.org/ftp/python/3.10.0/python-3.10.0post2-macos11.pkg, is now the default download for macOS from python.org and appears on the 3.10.0 release page (https://www.python.org/downloads/release/python-3100/). If you have already installed the original 3.10.0 universal2 installer pkg from python.org and are encountering this problem with file dialog windows on macOS 12 Monterey, you can download and run the updated installer pkg to obtain the updated Tk libraries. The updated Tk will also be included in the macOS installers provided with the next Python releases: 3.9.8 (expected to be released this week) and 3.10.1 (planned for 2021-12-06), as well as the 3.11.0a2 development preview. |
Could this be bumped to a version update to like 3.10.1 or just replace the old package with this updated one? The package name and format now break automations that relied on matching version names in the url. This pattern has worked since 2.7 releases. For example: https://www.python.org/ftp/python/3.10.0/python-3.10.0-macos11.pkg no longer works https://www.python.org/ftp/python/3.9.7/python-3.9.7-macos11.pkg works |
I'm sorry that this caused problems for you. We rarely update the artifacts for a release but, in this case, 3.10.1 was not scheduled for release until the beginning of December (the normal 2-month release cycle) and there have been no problems identified so far with 3.10.0 that warrant expediting 3.10.1, something that would affect all platforms and downstream users and suppliers. On the other hand, this issue was a critical one but only for IDLE and tkinter users of the python.org macOS installer who have upgraded to macOS 12 Monterey, a very much smaller group and there was no easy workaround for those users. Simply replacing the installer without changing the URL file name, a so-called stealth update, is, in general, a very bad practice; it leads to even more confusion and we also want to make sure that the obsoleted installer is no longer being downloaded. As far as I know, we have never made any guarantees about the format of the URL of our download files; and, in fact, the file name format for the default python.org macOS installers *has* changed over the years as we have introduced new installer variants, stopped producing old ones, and changed the default variant, something that is planned to happen again in the upcoming 3.9.8 release. So the only reliable way to automatically find file names is from one of the python.org web pages, like for the release or for the platform (i.e. https://www.python.org/downloads/macos/). It would be better to fully support a REST API to provide access to release file data. There is an open website issue about that: python/pythondotorg#1352 |
After I posted the previous reply, I saw that there have been other users affected by this, so I have now also made the updated installer available under the old URL. |
Awesome, thanks for the clear update reason. Makes more sense now. I was An API to get the installer urls would be super helpful. Thanks Ned! On Wed, Nov 3, 2021 at 4:19 PM Ned Deily <report@bugs.python.org> wrote:
|
I'm pretty sure that's a documented feature. Any code compiled with a 10.15 or earlier SDK will never see version 11.0 or later when using regular in process APIs (and IIRC that includes usage of @available/__builtin_available) |
Where do you think that "feature" is documented? |
According to wikipedia, it was only the Big Sur beta that identified But I did eventually find a page showing a tweet that "documents" this behavior: I guess obscure tweets have replaced documentation. |
If you use the older methods to detect OSVersion, Monterey will also On Thu, Nov 4, 2021 at 7:54 AM Marc Culler <report@bugs.python.org> wrote:
|
I'd have to check, but I didn't learn this from Twitter, although it wouldn't surprise me if I learned this from a WWDC talk. The beta for Big Sur never identified itself as 10.16 other than through this feature. I guess Apple determined that too many applications only looked at the minor version determine if the current system is new enough. Applications compiled with/linked against a 11.0 or 12.0 SDK will always just see the real system version. Note that this also affects programs just opening the SystemVersion.plist file, that will get substituted by an alternative version when the opening process links against an older SDK. Calling sw_vers and parsing the output does return the right version though. |
Well, not exactly ... culler@abner ~ % export SYSTEM_VERSION_COMPAT=1 But that would only be helpful to me if the operatingSystemVersion https://developer.apple.com/documentation/foundation/nsprocessinfo/1410906-operatingsystemversion |
Thanks everyone, especially Marc! python.org macOS installers for 3.9.8, 3.10.0, and 3.11.0a2 with patched versions of Tk to avoid the filedialog problems on macOS 12 Monterey are now released and available for download. We can now close this issue and move on :) https://discuss.python.org/t/python-3-9-8-and-3-11-0a2-are-now-available/11763 |
FYI, it appears that 8.6.11 works ok with MacOS 12.1 (released on 13-Dec-2021). 8.6.12 also works with MacOS 12.1. I have not tested either extensively, however. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: