zed
zed copied to clipboard
windows: Fix runtime `BorrowMutError`
Closes #10884 #11094
Possibly closes #11192
https://github.com/zed-industries/zed/assets/14981363/91b1af73-8896-4988-8205-2950ecbf77e1
Release Notes:
- N/A
#11192 Not resolved. Crash continues in same manner even after fix by @JunkuiZhang
Log: zed.log
EDIT: Wording mistake.
#11192 Not resolved. Crash continues in same manner even after fix by @JunkuiZhang
Log: zed.log
EDIT: Wording mistake.
The log file #11192 attached indicates that crash was caused by BorrowMutError
, which should be fixed by this PR. The new log file you attached indicates that the crash reason is ERROR_OUT_OF_POOL_MEMORY
, which is an issue on the blade
side. And I have no idea what causes the crash, there is an open issue #10018 here. It seems to be a long-standing issue, and currently, the priority for resolving it is relatively low.
I seem to have botched the merge, I'll fix it and merge this later today :)
That said, I'm wondering if this PR can be superseded by https://github.com/zed-industries/zed/pull/11393, as both seem to be related to state management improvements. Spawning the task is ok if that's what we need to do, but in principle I'd prefer closer state management.
That said, I'm wondering if this PR can be superseded by #11393
Oh yes. I have merged the changes of this PR into #11393 , so this PR can be closed.
Spawning the task is ok if that's what we need to do, but in principle I'd prefer closer state management.
I'm not exactly sure what happened behind the scenes, but the implementation on macOS is also achieved through spawning tasks, and removing it would result in the same BorrowMutError
. Therefore, I suspect it might be an issue with Zed's deeper-level implementation.
executor
.spawn(async move {
let mut lock = window_state.as_ref().lock();
if let Some(mut callback) = lock.activate_callback.take() {
drop(lock);
callback(is_active);
window_state.lock().activate_callback = Some(callback);
};
})
.detach();
ahhh, I see. Thank you!