zed-industries
Crash right after launching it (20 seconds after opening)
Check for existing issues
- [X] Completed
Describe the bug / provide steps to reproduce it
OK so after 20 seconds ( counted) it crashes right after opening it, and i also noticed that it reaches like 150% cpu time on activity monitor right before it crashes. Zed had been working for me for like 1 week and now it suddendly crashes The log that pops up after says this ( added as a file cause it was too long) Uploading log.txt…
Environment
Mac OS , macbook air m1 2020
If applicable, attach your ~/Library/Logs/Zed/Zed.log file to this issue.
No response
Hey @GrigoriosTsenos, is this a reproducible crash? Does it happen on every open?
Hey @GrigoriosTsenos, is this a reproducible crash? Does it happen on every open?
yes it does, on every single open
Can you post the path of your project? The crash seems to be in the Rust stdlib on parsing of path components.
Can you post the path of your project? The crash seems to be in the Rust stdlib on parsing of path components.
right when i open zed, which is when it crashes, it opens a .cpp file on my "home" folder , which is on Users/gregtsen/ex2.cpp is that what you want?
Can you post the path of your project? The crash seems to be in the Rust stdlib on parsing of path components.
wait you were on the right direction, i removed the folder that i had opened in the project and it doesn't crash anymore. What the hell??
What was the directory's path/name?
i already told you, it was the user's home address like ~/
Thanks for reporting this, and sorry that Zed is crashing for you!
Looking at the crash report, the crash seems to be this one: https://developer.apple.com/documentation/xcode/sigtrap_sigill. "Some lower-level libraries, such as Dispatch, trap the process with this exception upon encountering an unrecoverable error, and log additional information about the error in the Additional Diagnostic Information section of the crash report."
We've seen about 16 of these across the user-base in the last week, so it'd be nice to get to the bottom of it.
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x000000019dec0254
Termination Reason: Namespace SIGNAL, Code 5 Trace/BPT trap: 5
Terminating Process: exc handler [24356]
Unfortunately it does not actually seem like there is an "Additional Diagnostic Information" section in the crash report :/.
Looking into the crash itself, it's happening on the settings-file-watching thread:
Thread 36 Crashed:: Dispatch queue: com.apple.root.user-initiated-qos\
0 CoreFoundation 0x19dec0254 __CFCheckCFInfoPACSignature + 44\
1 CoreFoundation 0x19de1da98 CFRunLoopStop + 24\
2 zed 0x102148d6c _RNvXs0_NtNtNtCsd554QpkqIhs_12futures_util6stream6stream5chainINtB5_5ChainINtCskoDtZKjXBhE_13async_channel8ReceiverINtNtCslfhLIBgn4yl_5alloc3vec3VecNtNtCs7np0t9xp4Sb_3std4path7PathBufEEINtNtB9_4once4OnceNCNCNvXsf_Cs3rc24L8flRB_2fsNtB3o_6RealFsNtB3o_2Fs5watch0s_0EENtNtCsj7cdLBxwZIu_12futures_core6stream6Stream9poll_nextB3o_ + 1456\
3 zed 0x1030584fc _RNCNvNtCsghNOtKLFwRK_8settings13settings_file17watch_config_file0B5_ + 1196\
4 zed 0x103048d3c _RNvMs1_NtCsdIkmODOuIBJ_10async_task3rawINtB5_7RawTaskINtNtCsjeQ7c5BoyiG_4core3pin3PinINtNtCslfhLIBgn4yl_5alloc5boxed3BoxDNtNtNtBU_6future6future6Futurep6OutputuNtNtBU_6marker4SendEL_EEuNCINvMs3_NtCsgCtGquV6AHx_4gpui8executorNtB36_18BackgroundExecutor14spawn_internaluE0uE3runCsghNOtKLFwRK_8settings + 332\
5 libdispatch.dylib 0x19db5e3e8 _dispatch_client_callout + 20\
6 libdispatch.dylib 0x19db70080 _dispatch_root_queue_drain + 864\
7 libdispatch.dylib 0x19db706b8 _dispatch_worker_thread2 + 156\
8 libsystem_pthread.dylib 0x19dd0afd0 _pthread_wqthread + 228\
9 libsystem_pthread.dylib 0x19dd09d28 start_wqthread + 8\
The file you uploaded has some extra backslashes, so this stack-trace is from a similar crash from a different user, but I think it's very likely the same:
Trace/BPT trap: 5 on thread 3975210 ( com.apple.root.user-initiated-qos)
CoreFoundation __CFCheckCFInfoPACSignature
CoreFoundation CFRunLoopStop
crates/fsevent/src/fsevent.rs:0: <fsevent::Handle as core::ops::drop::Drop>::drop
/rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/core/src/ptr/mod.rs:507: core::ptr::drop_in_place::<fsevent::Handle>
/rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/core/src/mem/mod.rs:992: core::mem::drop::<fsevent::Handle>
crates/fs/src/fs.rs:368: <fs::RealFs as fs::Fs>::watch::{closure#0}::{closure#1}
/Users/administrator/.cargo/registry/src/index.crates.io-6f17d22bba15001f/futures-util-0.3.30/src/stream/once.rs:46: <futures_util::stream::once::Once<<fs::RealFs as fs::Fs>::watch::{closure#0}::{closure#1}> as futures_core::stream::Stream>::poll_next
/Users/administrator/.cargo/registry/src/index.crates.io-6f17d22bba15001f/futures-util-0.3.30/src/stream/stream/chain.rs:56: <futures_util::stream::stream::chain::Chain<async_channel::Receiver<alloc::vec::Vec<std::path::PathBuf>>, futures_util::stream::once::Once<<fs::RealFs as fs::Fs>::watch::{closure#0}::{closure#1}>> as futures_core::stream::Stream>::poll_next
crates/settings/src/settings_file.rs:50: settings::settings_file::watch_config_file::{closure#0}
/rustc/aedd173a2c086e558c2b66d3743b344f977621a7/library/core/src/task/poll.rs:51: <core::task::poll::Poll<()>>::map::<core::result::Result<(), alloc::boxed::Box<dyn core::any::Any + core::marker::Send>>, core::result::Result<(), alloc::boxed::Box<dyn core::any::Any + core::marker::Send>>::Ok>
/Users/administrator/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-task-4.7.0/src/raw.rs:557: <async_task::raw::RawTask<core::pin::Pin<alloc::boxed::Box<dyn core::future::future::Future<Output = ()> + core::marker::Send>>, (), <gpui::executor::BackgroundExecutor>::spawn_internal<()>::{closure#0}, ()>>::run
libdispatch.dylib _dispatch_client_callout
libdispatch.dylib _dispatch_root_queue_drain
libdispatch.dylib _dispatch_worker_thread2
libsystem_pthread.dylib _pthread_wqthread
libsystem_pthread.dylib start_wqthread
It looks like we call CFRunLoopStop when we drop the fsevent::Handle; but I'm guessing the loop thinks it is not in a stoppable state.
One thing that is potentially interesting is that it seems like you're opening zed in your home directory (which will obviously contain your settings file), but I haven't yet figured out how to reproduce this myself.
Do you have time in the next few days to see if we can figure out any more information over a screen share? If so, please email me [email protected]
I did a bit more digging here, and it seems like __CFCheckCFInfoPACSignature is trying to validate a pointer using ARM's pointer authentication code; and somehow we're failing that validation...
It looks like we're not calling CFRetain on the run loop (which we should apparently). I wonder if this is a use-after-free where the run loop has been released before we call CFRunLoop stop in the Drop handler.
Potential fix here: https://github.com/zed-industries/zed/pull/11241
(The only thing that doesn't quite make sense about that theory, is that it shouldn't be crashing so reliably after 20s...)
I did a bit more digging here, and it seems like
__CFCheckCFInfoPACSignatureis trying to validate a pointer using ARM's pointer authentication code; and somehow we're failing that validation...It looks like we're not calling
CFRetainon the run loop (which we should apparently). I wonder if this is a use-after-free where the run loop has been released before we call CFRunLoop stop in the Drop handler.Potential fix here: #11241
where do i find these files so i can correct it with the CFRetain?
~A fix for this is now included in 0.134.0-pre.~
Whoops, this one isn't confirmed yet. Leaving it open until we can confirm.
@GrigoriosTsenos are you able to run the preview release from https://zed.dev/releases/preview/0.134.0? If so that contains the (probable) fix.