You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: Can not close figure when using multiple figures on MacOS X #28387
I can reproduce this, but only when using tabbed window mode: plt.rcParams["macosx.window_mode"] = "tab".
It looks like it was introduced by #27290 and reverting that commit does fix this issue on main for me. v3.8.1 works as expected, v3.8.2 is where this issue started to occur.
cc @ksunden
Does reverting #27290 also bring back the segfault on py312?
My guess is that we have generated some sort of deadlock on the GIL and probably need to change some of our logic on close on macOS to be "please exit when you can" from "please exit now, I'all wait"
Does reverting #27290 also bring back the segfault on py312?
Yes, it sure does, sorry I shouldn't have implied we should revert it, just that reverting does get us the old desired behavior with tabs.
My guess is that we have generated some sort of deadlock on the GIL and probably need to change some of our logic on close on macOS to be "please exit when you can" from "please exit now, I'all wait"
I agree with this assumption of needing to update our logic.
Hmmm... interestingly, you can actually pull the tabs apart into separate windows, and then they close perfectly fine...
I wonder if the deadlock is caused by dispatching the close signal to two tabs at once...
I will note that it also freezes on hitting an individual tab close button, not just the red window close button.
A few quick print debugging steps do in fact confirm that we are hanging at PyGILState_Ensure in _buffer_release. Though wonder if tracing back farther will be productive.
Further, during normal separated window closing, _buffer_release is not called at all, so not sure why it is called when tabbed, perhaps it is closing one, triggering a draw on the other, even if they are closing?
Activity
greglucas commentedon Jun 13, 2024
I can reproduce this, but only when using tabbed window mode:
plt.rcParams["macosx.window_mode"] = "tab".It looks like it was introduced by #27290 and reverting that commit does fix this issue on main for me. v3.8.1 works as expected, v3.8.2 is where this issue started to occur.
cc @ksunden
tacaswell commentedon Jun 13, 2024
Does reverting #27290 also bring back the segfault on py312?
My guess is that we have generated some sort of deadlock on the GIL and probably need to change some of our logic on close on macOS to be "please exit when you can" from "please exit now, I'all wait"
greglucas commentedon Jun 13, 2024
Yes, it sure does, sorry I shouldn't have implied we should revert it, just that reverting does get us the old desired behavior with tabs.
I agree with this assumption of needing to update our logic.
ksunden commentedon Jun 14, 2024
Hmmm... interestingly, you can actually pull the tabs apart into separate windows, and then they close perfectly fine...
I wonder if the deadlock is caused by dispatching the close signal to two tabs at once...
I will note that it also freezes on hitting an individual tab close button, not just the red window close button.
A few quick print debugging steps do in fact confirm that we are hanging at
PyGILState_Ensurein_buffer_release. Though wonder if tracing back farther will be productive.Further, during normal separated window closing,
_buffer_releaseis not called at all, so not sure why it is called when tabbed, perhaps it is closing one, triggering a draw on the other, even if they are closing?Add GIL Release to flush_events in macosx backend