sublimehq / sublime_text

Issue tracker for Sublime Text
https://www.sublimetext.com
814 stars 40 forks source link

Crash on aarch64/x86_64 macOS Ventura #5641

Closed ddcc closed 1 year ago

ddcc commented 2 years ago

Description of the bug

Editor seems to have gotten in a bad state where it keeps around the previous session, but keeps crashing after a couple of seconds. Note that some open files in the previous session are mounted remotely over SMB.

* thread #15, name = 'git_thread', stop reason = EXC_BAD_ACCESS (code=10, address=0x118dff000)
  * frame #0: 0x0000000108a347bf sublime_text`bool sgit::safe_mmap_try<sgit::open_pack(sgit::file_system*, substring)::$_0>(sgit::open_pack(sgit::file_system*, substring)::$_0)
    frame #1: 0x0000000108a31df1 sublime_text`sgit::indexed_pack::open(sgit::file_system*)
    frame #2: 0x0000000108a3e9fe sublime_text`sgit::repository::rescan(unsigned int, SP<sgit::config>)
    frame #3: 0x000000010866174e sublime_text`std::__1::__function::__func<git_repo::maybe_rescan()::$_27, std::__1::allocator<git_repo::maybe_rescan()::$_27>, void ()>::operator()()
    frame #4: 0x000000010872cdbd sublime_text`queue_run_helper(void*)
    frame #5: 0x00007ff80196f259 libsystem_pthread.dylib`_pthread_start
    frame #6: 0x00007ff80196ac7b libsystem_pthread.dylib`thread_start

sublime_text`sgit::safe_mmap_try<sgit::open_pack(sgit::file_system*, substring)::$_0>:
    0x108a34780 <+0>:   pushq  %rbp
    0x108a34781 <+1>:   movq   %rsp, %rbp
    0x108a34784 <+4>:   pushq  %r15
    0x108a34786 <+6>:   pushq  %r14
    0x108a34788 <+8>:   pushq  %r12
    0x108a3478a <+10>:  pushq  %rbx
    0x108a3478b <+11>:  movq   %rdx, %r14
    0x108a3478e <+14>:  movq   %rsi, %r12
    0x108a34791 <+17>:  movq   %rdi, %r15
    0x108a34794 <+20>:  leaq   0x2b9eed(%rip), %rdi      ; sgit::sigbus_jmp_set
    0x108a3479b <+27>:  callq  *(%rdi)
    0x108a3479d <+29>:  movb   $0x1, (%rax)
    0x108a347a0 <+32>:  leaq   0x2b9ef9(%rip), %rdi      ; sgit::sigbus_jmp_buf
    0x108a347a7 <+39>:  callq  *(%rdi)
    0x108a347a9 <+41>:  xorl   %ebx, %ebx
    0x108a347ab <+43>:  movq   %rax, %rdi
    0x108a347ae <+46>:  movl   %ebx, %esi
    0x108a347b0 <+48>:  callq  0x108b48b04               ; symbol stub for: sigsetjmp
    0x108a347b5 <+53>:  movl   %ebx, %ecx
    0x108a347b7 <+55>:  testl  %eax, %eax
    0x108a347b9 <+57>:  jne    0x108a347cc               ; <+76>
    0x108a347bb <+59>:  movq   (%r12), %rax
->  0x108a347bf <+63>:  movl   (%rax), %ecx

Steps to reproduce

Doesn't reproduce in safe mode, but reproduces when launched normally.

Expected behavior

Doesn't crash

Actual behavior

Crashes

Sublime Text build number

4126

Operating system & version

macOS 13.0

(Linux) Desktop environment and/or window manager

No response

Additional information

No response

OpenGL context information

No response

BenjaminSchaaf commented 2 years ago

It's crashing inside the git repository handling, specifically when reading from an mmaped file. Does the crash happen if you open the same folder(s) in safe mode?

I've tried to reproduce this, but no luck unfortunately.

ddcc commented 2 years ago

Hmm this is a very odd bug. After looking at it a bit more, I've narrowed it down to one particular private repo that's causing this issue. Previously, it was fine until at some point I made some changes to the repository and Sublime just started crashing. Unfortunately I don't remember what the specific changes were because I didn't make the connection at the time, but with the current crash the repo is just sitting on a branch with no uncomitted changes.

I worked around the issue earlier by setting show_git_status to false in order to load the problematic repository. After reverting that change, I've confirmed it does crash both in regular and safe mode. But, after restarting Sublime after the safe mode crash, in regular mode, it's not crashing on the repository anymore, and I'm not sure why. Additionally, I tried concurrently mounting the problematic repository earlier from an aarch64 machine with the same Sublime build/configuration, and it never crashed.

BenjaminSchaaf commented 2 years ago

My current guess is that a specific file is triggering an edge case in our git pack file reading. If it's not happening for you now, perhaps git garbage collection ran and that file no longer exists. If you're able to reproduce it again it would be great to check if it's only happening when the repo is on a network drive or also locally.

ddcc commented 2 years ago

Normally, most of my development is on a remote drive on a build machine. I have occasionally worked on the same repositories locally, but I don't recall ever experiencing similar reproducible crashes.

I have occasionally experienced crashes in Sublime when the local machine goes to sleep, the remote drive is unmounted, then the local machine is woken, and the remote drive is remounted. Sublime generally notices that the underlying file has changed and reloads it, but can then sometimes crash afterwards. Unfortunately, since these crashes aren't easy to reproduce and I don't get a system crash report for them, they're hard for me to report because I need to anticipate them and keep a lldb manually attached.

ddcc commented 2 years ago

Now that I know what to watch out for, I manage to catch a dump of the latter type of crash (remounted after sleep and new file is loaded), this time on an aarch64 machine.

* thread #14, name = 'git_thread', stop reason = EXC_BAD_ACCESS (code=10, address=0x152b2be3a)
  * frame #0: 0x00000001028b7f64 sublime_text`bool sgit::safe_mmap_try<sgit::find_object(sgit::object_id const&, sgit::pack_index const*, sgit::size_limit, sgit::pack_file const*)::$_2>(sgit::find_object(sgit::object_id const&, sgit::pack_index const*, sgit::size_limit, sgit::pack_file const*)::$_2)
    frame #1: 0x00000001028b6210 sublime_text`sgit::object_store::find_object(sgit::object_id const&, sgit::object_cache*, sgit::size_limit) const
    frame #2: 0x00000001025d32c8 sublime_text`std::__1::__function::__func<git_repo::request_object_for_object_id(sgit::object_id, std::__1::function<void (optional_result<sgit::object>&&)>&&)::$_31, std::__1::allocator<git_repo::request_object_for_object_id(sgit::object_id, std::__1::function<void (optional_result<sgit::object>&&)>&&)::$_31>, void ()>::operator()()
    frame #3: 0x000000010266c0a8 sublime_text`queue_run_helper(void*)
    frame #4: 0x00000001a913606c libsystem_pthread.dylib`_pthread_start(self=0x00000001707d7000, kport=<unavailable>, fun=<unavailable>, arg=<unavailable>, stacksize=<unavailable>, pflags=<unavailable>)
mateusz-plociennik commented 1 year ago

I have reproduced the issue with Sublime 4143 on my Mac mini (M1, 2020) with macOS Ventura 13.1 (22C65). I am connected to SMB share hosted from Windows 11 version 22H2 machine. I can't see anything special about the repo. Unfortunately it's a private one, so I'm unable to share it. I think it is related to the host going asleep.

Process 14453 stopped
* thread #15, name = 'git_thread', stop reason = EXC_BAD_ACCESS (code=10, address=0x156bbc000)
    frame #0: 0x0000000183d7f074 libsystem_platform.dylib`_platform_memmove + 420
libsystem_platform.dylib`:
->  0x183d7f074 <+420>: ldr    x6, [x1], #0x8
    0x183d7f078 <+424>: str    x6, [x3], #0x8
    0x183d7f07c <+428>: subs   x2, x2, #0x8
    0x183d7f080 <+432>: b.hs   0x183d7f074               ; <+420>
Target 0: (sublime_text) stopped.
(lldb) bt
* thread #15, name = 'git_thread', stop reason = EXC_BAD_ACCESS (code=10, address=0x156bbc000)
  * frame #0: 0x0000000183d7f074 libsystem_platform.dylib`_platform_memmove + 420
    frame #1: 0x00000001051158bc sublime_text`sha1_process + 148
    frame #2: 0x00000001050e6604 sublime_text`bool sgit::safe_mmap_try<sgit::read_object_hash_from_disk(sgit::file_system*, sgit::object_store*, sgit::object_cache*, substring, std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, sgit::working_dir_cache_entry, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const, sgit::working_dir_cache_entry> > >*, sgit::file_meta_data const&, substring, sgit::object_id const&, substring, sgit::active_filter*, character_encoding, sgit::newline_normalisation)::$_2>(sgit::read_object_hash_from_disk(sgit::file_system*, sgit::object_store*, sgit::object_cache*, substring, std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, sgit::working_dir_cache_entry, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const, sgit::working_dir_cache_entry> > >*, sgit::file_meta_data const&, substring, sgit::object_id const&, substring, sgit::active_filter*, character_encoding, sgit::newline_normalisation)::$_2) + 816
    frame #3: 0x00000001050e4068 sublime_text`sgit::read_object_hash_from_disk(sgit::file_system*, sgit::object_store*, sgit::object_cache*, substring, std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, sgit::working_dir_cache_entry, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const, sgit::working_dir_cache_entry> > >*, sgit::file_meta_data const&, substring, sgit::object_id const&, substring, sgit::active_filter*, character_encoding, sgit::newline_normalisation) + 2020
    frame #4: 0x00000001050d8d84 sublime_text`std::__1::vector<sgit::working_diff_entry, std::__1::allocator<sgit::working_diff_entry> > sgit::git_diff_working_dir_to_index_impl<sgit::table_entry_ignore_case_hash_traits>(sgit::file_system*, sgit::object_store*, sgit::object_cache*, substring, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, sgit::working_dir_cache_entry, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const, sgit::working_dir_cache_entry> > >*, sgit::config*, sgit::attribute_store*, std::__1::vector<atom, std::__1::allocator<atom> >*, atom_table*, sgit::filter_store const*, basic_hash_set<sgit::index_table_entry const*, sgit::table_entry_ignore_case_hash_traits, compact_occupancy_traits> const&, std::__1::vector<sgit::submodule, std::__1::allocator<sgit::submodule> > const&, std::__1::vector<sgit::unmerged_file, std::__1::allocator<sgit::unmerged_file> >*, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >*, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >*, bool, bool, bool, bool) + 8912
    frame #5: 0x00000001050ff66c sublime_text`sgit::repository::rescan(unsigned int, SP<sgit::config>) + 34748
    frame #6: 0x000000010510026c sublime_text`sgit::repository::rescan(unsigned int, SP<sgit::config>) + 37820
    frame #7: 0x0000000104dfda0c sublime_text`std::__1::__function::__func<git_repo::maybe_rescan()::$_27, std::__1::allocator<git_repo::maybe_rescan()::$_27>, void ()>::operator()() + 72
    frame #8: 0x0000000104e9f3e8 sublime_text`queue_run_helper(void*) + 160
    frame #9: 0x0000000183d5106c libsystem_pthread.dylib`_pthread_start + 148
mateusz-plociennik commented 1 year ago

BTW When I tried to add some files to the repo from Windows machine I got the following error:

> git add -- *
fatal: Unable to create 'index.lock': File exists.

Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue.
BenjaminSchaaf commented 1 year ago

This was fixed in build 4148 by not using mmap on macOS/Linux.