alacritty: Crash when automatically switching graphics on macos 10.14.4

This is on macos 10.14.4, with alacritty installed from brew.

logs: https://pastebin.com/VGsNdH5a

Process:               alacritty [18348]
Path:                  /Applications/Alacritty.app/Contents/MacOS/alacritty
Identifier:            io.alacritty
Version:               0.2.9 (1)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           alacritty [18348]
User ID:               66985

Date/Time:             2019-03-26 16:50:54.331 -0400
OS Version:            Mac OS X 10.14.4 (18E226)
Report Version:        12
Anonymous UUID:        6BD1F33D-FD37-26D0-62C3-C831BD012BDF

Sleep/Wake UUID:       7E21666D-F8BB-4BC8-8E46-BEBA3063E8DC

Time Awake Since Boot: 43000 seconds
Time Since Wake:       27000 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [18348]

VM Regions Near 0:
--> 
    __TEXT                 000000010deba000-000000010e262000 [ 3744K] r-x/rwx SM=COW  /Applications/Alacritty.app/Contents/MacOS/alacritty

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   io.alacritty                  	0x000000010e172cd0 main + 608
1   libdyld.dylib                 	0x00007fff7483b3d5 start + 1

Thread 1:: config watcher
0   libsystem_kernel.dylib        	0x00007fff7497386a __psynch_cvwait + 10
1   libsystem_pthread.dylib       	0x00007fff74a2c56e _pthread_cond_wait + 722
2   io.alacritty                  	0x000000010e14e982 std::thread::park::h2412351193f4ffea + 242

https://pastebin.com/u4wZdV0i

Process:               alacritty [41717]
Path:                  /Applications/Alacritty.app/Contents/MacOS/alacritty
Identifier:            io.alacritty
Version:               0.2.9 (1)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           alacritty [41717]
User ID:               66985

Date/Time:             2019-03-26 22:29:58.796 -0400
OS Version:            Mac OS X 10.14.4 (18E226)
Report Version:        12
Anonymous UUID:        6BD1F33D-FD37-26D0-62C3-C831BD012BDF

Sleep/Wake UUID:       31F4967E-E806-4239-A38F-C5937930C6E1

Time Awake Since Boot: 60000 seconds
Time Since Wake:       6600 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [41717]

VM Regions Near 0:
--> 
    __TEXT                 000000010bbad000-000000010bf55000 [ 3744K] r-x/rwx SM=COW  /Applications/Alacritty.app/Contents/MacOS/alacritty

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   ???                           	000000000000000000 0 + 0
1   io.alacritty                  	0x000000010be65cd4 main + 612
2   libdyld.dylib                 	0x00007fff7483b3d5 start + 1

https://pastebin.com/0RGjcLXJ

Process:               alacritty [39633]
Path:                  /Applications/Alacritty.app/Contents/MacOS/alacritty
Identifier:            io.alacritty
Version:               0.2.9 (1)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           alacritty [39633]
User ID:               66985

Date/Time:             2019-03-26 22:30:01.159 -0400
OS Version:            Mac OS X 10.14.4 (18E226)
Report Version:        12
Anonymous UUID:        6BD1F33D-FD37-26D0-62C3-C831BD012BDF

Sleep/Wake UUID:       31F4967E-E806-4239-A38F-C5937930C6E1

Time Awake Since Boot: 60000 seconds
Time Since Wake:       6600 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000400002d8a
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [39633]

VM Regions Near 0x400002d8a:
    CoreServices           0000000123628000-000000012364c000 [  144K] rw-/rwx SM=COW  
--> 
    MALLOC_NANO            0000600000000000-0000600008000000 [128.0M] rw-/rwx SM=PRV  

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   io.alacritty                  	0x0000000105704cd0 main + 608
1   libdyld.dylib                 	0x00007fff7483b3d5 start + 1

Thread 1:: config watcher
0   libsystem_kernel.dylib        	0x00007fff7497386a __psynch_cvwait + 10
1   libsystem_pthread.dylib       	0x00007fff74a2c56e _pthread_cond_wait + 722
2   io.alacritty                  	0x00000001056e0982 std::thread::park::h2412351193f4ffea + 242

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 19
  • Comments: 42 (17 by maintainers)

Commits related to this issue

Most upvoted comments

@chrisduerr macos 10.14.4 came out yesterday, so yes that’s the recent change. Alacritty was running fine otherwise for the past month.

Hello, Macos 10.14.5 is released, I tried this on master enabling NSSupportsAutomaticGraphicsSwitching and it seems to work well, still half an hour doing it and no crash so far.

With “Some(true)” it crashed switching GPUs, in either direction.

I can check whether the standard build does the same later today. (Or someone else on this thread can.)

On Fri, Mar 29, 2019, 10:28 AM Christian Duerr notifications@github.com wrote:

So as a summary, it crashes when it’s None, or it crashes when it’s Some(true) and you switch the GPU? However when using Some(true) without switching it always works?

It would also be interesting if this is caused by Alacritty’s OpenGL code, or by the windowing library Alacritty is using.

So if someone could verify if https://github.com/tomaka/glutin works, that would be nice. Once cloned, it can be tested using cargo run –example window.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jwilm/alacritty/issues/2221#issuecomment-478017781, or mute the thread https://github.com/notifications/unsubscribe-auth/ABC7_ccRSk3w5mz0gMobw1X62472QHvcks5vbiMRgaJpZM4cM17J .

alacritty also started crashing frequently for me since upgrading to 10.14.4.

OS X crash report: https://pastebin.com/fp5P2mV8

I think that disabling automatic graphics switching is probably a good idea to smooth out the waves a bit and make sure nobody runs into the issue because they haven’t updated yet.

Though if that’s the case, maybe we can already disable this workaround in 0.3.1 again. Of course if individuals want to enable graphics switching on their own, this is quite a trivial change.

Thanks for letting me know though.

A new release is just around the corner and likely to land this weekend. The brew package should be updated shortly after.

For me Alacritty crashes every time I pug in or unplug my laptop from a power source because that causes the GPU switch, it’s very annoying but it is stable otherwise. I’m using the latest homebrew version I don’t think that forcing the OS to use a specific GPU or disabling hw acceleration is a solution.

Ive just disabled automatic graphic switching in the mean time and haven’t had any crashes since.

Is this a recent change? I haven’t heard about this before and now a couple of people seem to be having that issue.

Alacritty also hasn’t been updated recently, so that makes it even weirder. Potentially a faulty macos update? If not maybe downgrading Alacritty helps?

I’m personally interested if cargo run produces any output, since that’s much more likely to produce a useful backtrace when Alacritty crashes. Though a SIGSEGV is very unrustlike so that strikes me as odd.

I just updated last night, and I have already experienced multiple crashes this morning. Thankfully, TMUX has my back:

tmux attach-session -t 0

…and I’m back in business where I left off.

@ChadTaljaardt I would wait to close until a fix is released. New macos builds can stay in beta for a while…

I heard that the macos version 10.14.5 has a fix for this and a beta will be released soon.

Can someone check if setting this to false instead of true fixes the issue?

That should disable automatic graphics switching and would likely be an improvement over just crashing permanently.

Both versions appear to start fine regardless of acceleration being enabled.

Oh, then I’ve misunderstood you. So it is still possible to start Alacritty, it just crashes when switching?

Also I’d imagine it would be possible to force which GPU certain applications use, that might drain battery slightly faster (or make Alacritty slower), but that probably wouldn’t interfere with using it.

Switching from integrated to discrete GPU with the brew cask version:

RUST_BACKTRACE=1 /Applications/Alacritty.app/Contents/MacOS/alacritty 
2019-03-30 12:54:03.360 alacritty[53539:1095567] *** Assertion failure in -[NSCGLSurface flushRect:], /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppKit/AppKit-1671.40.119/OpenGL.subproj/NSCGLSurface.m:569
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:355:21
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::panicking::default_hook::{{closure}}
   2: std::panicking::rust_panic_with_hook
   3: std::panicking::continue_panic_fmt
   4: rust_begin_unwind
   5: core::panicking::panic_fmt
   6: core::panicking::panic
   7: main
fatal runtime error: failed to initiate panic, error 5
Abort trap: 6

Switching from discrete GPU to integrated:

RUST_BACKTRACE=1 /Applications/Alacritty.app/Contents/MacOS/alacritty 
2019-03-30 12:55:01.075 alacritty[53618:1096391] *** Assertion failure in -[NSCGLSurface flushRect:], /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppKit/AppKit-1671.40.119/OpenGL.subproj/NSCGLSurface.m:569
Bus error: 10

Carsh on switching in either direction.

On Fri, Mar 29, 2019, 6:51 AM Christian Duerr notifications@github.com wrote:

So it only crashes on the integrated GPU, or only on the dedicated one?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jwilm/alacritty/issues/2221#issuecomment-477954902, or mute the thread https://github.com/notifications/unsubscribe-auth/ABC7_SvMzDZ_Q6A5wLmgB2MVJN_1QsYwks5vbfAugaJpZM4cM17J .

Oh, my bad. It needs to be changed to Some(true), not just true.

@chrisduerr I am not sure how to see which gfx card is active, although I do see that my Mac supports “automatic switching” (I assume between the built-in Intel chip, and the Radeon).

MacBook Pro (15-inch, 2018) 2.2 GHz Intel Core i7 16 GB 2400 MHz DDR4 Radeon Pro 555X 4 GB Intel UHD Graphics 630 1536 MB

@chrisduerr Good idea. I just cloned the repo and am running Alacritty from iTerm2. I’ll post back here if it crashes again.

Though a SIGSEGV is very unrustlike so that strikes me as odd.

Yup, I agree.

@jrop Im using tmux too, but sometimes alacritty crashes 5 times in a row, i might have to revert to using the built in terminal until this is fixed.