Sublime Forum

ST4 Crashes on MacOS 10.14.6 (18G9028)

#1

I’m getting consistent ST4 crashes when compiling my C/C++ project while directories open with ST4. It doesn’t happen when I just build/clean the project, but I have automated scripts to build various configurations which create a temporary directory, build the project, then immediately remove the directory. If the temporary directory is not removed, ST4 does not crash.

I made sure to include the temporary directories to my .gitignore and have "index_exclude_gitignore": true, for ST4, so it shouldn’t try to index them.

For reference, all temporary directories start with tmpbuild_* and they are indeed grayed out on the ST4 folders sidebar.

Here’s the first part of the MacOS crash report:

Process:               sublime_text [35063]
Path:                  /Applications/Sublime Text.app/Contents/MacOS/sublime_text
Identifier:            sublime_text
Version:               Build 4107 (4107)
Code Type:             X86-64 (Native)
Parent Process:        ??? [33111]
Responsible:           sublime_text [35063]
User ID:               501

Date/Time:             2021-06-07 09:17:50.343 -0700
OS Version:            Mac OS X 10.14.6 (18G9028)
Report Version:        12
Bridge OS Version:     5.3 (18P4556)
Anonymous UUID:        022795B5-C8D9-2C6A-C566-0696ED307A30

Sleep/Wake UUID:       4BA36ACA-0691-49A2-9D08-2570693E787B

Time Awake Since Boot: 300000 seconds
Time Since Wake:       240000 seconds

System Integrity Protection: enabled

Crashed Thread:        0

Exception Type:        EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes:       0x0000000000000001, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Illegal instruction: 4
Termination Reason:    Namespace SIGNAL, Code 0x4
Terminating Process:   exc handler [35063]

Application Specific Information:
crashed on child side of fork pre-exec
BUG IN CLIENT OF LIBPLATFORM: os_unfair_lock is corrupt

Thread 0 Crashed:
0   libsystem_platform.dylib      	0x00007fff6c1341f4 _os_unfair_lock_corruption_abort + 23
1   libsystem_platform.dylib      	0x00007fff6c130ca6 _os_unfair_lock_lock_slow + 251
2   libsystem_pthread.dylib       	0x00007fff6c13dec4 _pthread_atfork_prepare_handlers + 48
3   libSystem.B.dylib             	0x00007fff68f2aa2d libSystem_atfork_prepare + 11
4   libsystem_c.dylib             	0x00007fff6bfa0d7b fork + 12
5   com.sublimetext.4             	0x000000010b07a56f osx_send_dump(char const*, char const*, void*, bool) + 552
6   com.sublimetext.4             	0x000000010b17dc4c google_breakpad::ExceptionHandler::WriteMinidumpWithException(int, int, int, __darwin_ucontext*, unsigned int, bool, bool) + 3058
7   com.sublimetext.4             	0x000000010b17de27 google_breakpad::ExceptionHandler::SignalHandler(int, __siginfo*, void*) + 57
8   libsystem_platform.dylib      	0x00007fff6c132b5d _sigtramp + 29
9   ???                           	0x00000001156d0e38 initialPoolContent + 520
10  libobjc.A.dylib               	0x00007fff6a76b884 _object_remove_assocations + 161
11  libobjc.A.dylib               	0x00007fff6a76b7b0 objc_destructInstance + 106
12  libobjc.A.dylib               	0x00007fff6a76b735 object_dispose + 19
13  libxpc.dylib                  	0x00007fff6c18bf85 xpc_atfork_child + 125
14  libSystem.B.dylib             	0x00007fff68f2ab18 libSystem_atfork_child + 54
15  libsystem_c.dylib             	0x00007fff6bfa0d97 fork + 40
16  com.sublimetext.4             	0x000000010b07a56f osx_send_dump(char const*, char const*, void*, bool) + 552
17  com.sublimetext.4             	0x000000010b17dc4c google_breakpad::ExceptionHandler::WriteMinidumpWithException(int, int, int, __darwin_ucontext*, unsigned int, bool, bool) + 3058
18  com.sublimetext.4             	0x000000010b17ce1c google_breakpad::ExceptionHandler::WaitForMessage(void*) + 248
19  libsystem_pthread.dylib       	0x00007fff6c13b2eb _pthread_body + 126
20  libsystem_pthread.dylib       	0x00007fff6c13e249 _pthread_start + 66
21  libsystem_pthread.dylib       	0x00007fff6c13a40d thread_start + 13

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000001302  rbx: 0x0000000001010002  rcx: 0x00007fff6c135cad  rdx: 0x0000000000000000
  rdi: 0x0000000000001302  rsi: 0x0000000000000203  rbp: 0x0000700002b19a30  rsp: 0x0000700002b199f8
   r8: 0x00747865745f656d   r9: 0x0000000000000000  r10: 0x0000000000000000  r11: 0x0000000000000246
  r12: 0x000000010bfa062c  r13: 0x0000000000000203  r14: 0x0000000000000000  r15: 0x0000000000010000
  rip: 0x00007fff6c1341f4  rfl: 0x0000000000010246  cr2: 0x000000010b69d990
  
Logical CPU:     9
Error Code:      0x00000000
Trap Number:     6
0 Likes

#2

Ok, so I narrowed it down to just plain deleting a particular directory!

Steps to reliably reproduce on my machine:

mkdir /tmp/reproduce/
cd /tmp/reproduce
subl .
git clone https://github.com/memfault/memfault-firmware-sdk.git
rm -rf memfault-firmware-sdk
0 Likes

ST4 consistently crashes on large directory structure changes
#3

Also seems to happen when I run subl --safe-mode ., which is surprising

0 Likes