Crash when number of display changes

General JUCE discussion
1

Got the below crash when I closed the lid of my macBook, so that the only screen to use would be my external monitor. I am using macOS Monterey.

Thread 0 Crashed:: MainThread Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	    0x7ff812411112 __pthread_kill + 10
1   libsystem_pthread.dylib       	    0x7ff812447214 pthread_kill + 263
2   libsystem_c.dylib             	    0x7ff812393d10 abort + 123
3   libsystem_malloc.dylib        	    0x7ff8122713e2 malloc_vreport + 548
4   libsystem_malloc.dylib        	    0x7ff8122745ed malloc_report + 151
5   Digitakt                      	       0x188eacc08 juce::HeapBlock<juce::Displays::Display, false>::~HeapBlock() + 24 (juce_HeapBlock.h:156)
6   Digitakt                      	       0x188eacbc5 juce::HeapBlock<juce::Displays::Display, false>::~HeapBlock() + 21 (juce_HeapBlock.h:155)
7   Digitakt                      	       0x188eacb27 juce::ArrayBase<juce::Displays::Display, juce::DummyCriticalSection>::~ArrayBase() + 39 (juce_ArrayBase.h:56)
8   Digitakt                      	       0x188eacaf5 juce::ArrayBase<juce::Displays::Display, juce::DummyCriticalSection>::~ArrayBase() + 21 (juce_ArrayBase.h:54)
9   Digitakt                      	       0x188eacad5 juce::Array<juce::Displays::Display, juce::DummyCriticalSection, 0>::~Array() + 21 (juce_Array.h:132)
10  Digitakt                      	       0x188dd22b5 juce::Array<juce::Displays::Display, juce::DummyCriticalSection, 0>::~Array() + 21 (juce_Array.h:132)
11  Digitakt                      	       0x188dd33c0 juce::Displays::refresh() + 240 (juce_Displays.cpp:203)
12  Digitakt                      	       0x188fe78a8 juce::Displays::findDisplays(float)::$_93::operator()() const + 24 (juce_mac_Windowing.mm:504)
13  Digitakt                      	       0x188fe786d decltype(std::__1::forward<juce::Displays::findDisplays(float)::$_93&>(fp)()) std::__1::__invoke<juce::Displays::findDisplays(float)::$_93&>(juce::Displays::findDisplays(float)::$_93&) + 29 (type_traits:3694)
14  Digitakt                      	       0x188fe781d void std::__1::__invoke_void_return_wrapper<void, true>::__call<juce::Displays::findDisplays(float)::$_93&>(juce::Displays::findDisplays(float)::$_93&) + 29 (__functional_base:348)
15  Digitakt                      	       0x188fe77ed std::__1::__function::__alloc_func<juce::Displays::findDisplays(float)::$_93, std::__1::allocator<juce::Displays::findDisplays(float)::$_93>, void ()>::operator()() + 29 (functional:1558)
16  Digitakt                      	       0x188fe6539 std::__1::__function::__func<juce::Displays::findDisplays(float)::$_93, std::__1::allocator<juce::Displays::findDisplays(float)::$_93>, void ()>::operator()() + 25 (functional:1732)
17  Digitakt                      	       0x1895b3042 std::__1::__function::__value_func<void ()>::operator()() const + 50 (functional:1885)
18  Digitakt                      	       0x1895b2fc5 std::__1::function<void ()>::operator()() const + 21 (functional:2560)
19  Digitakt                      	       0x188f4278d juce::DisplaySettingsChangeCallback::displayReconfigurationCallback(unsigned int, unsigned int, void*) + 61 (juce_mac_Windowing.mm:456)
20  SkyLight                      	    0x7ff8173f60df displayWillConfigNotifyProc + 866
21  SkyLight                      	    0x7ff8173ec3ed CGSPostLocalNotification + 269
22  SkyLight                      	    0x7ff8173ebe91 (anonymous namespace)::notify_datagram_handler(unsigned int, CGSDatagramType, void*, unsigned long, void*) + 98
23  SkyLight                      	    0x7ff8176aea78 CGSDatagramReadStream::dispatchMainQueueDatagrams() + 202
24  SkyLight                      	    0x7ff8176ae99f invocation function for block in CGSDatagramReadStream::mainQueueWakeup() + 18
25  libdispatch.dylib             	    0x7ff81228fad8 _dispatch_call_block_and_release + 12
26  libdispatch.dylib             	    0x7ff812290cc9 _dispatch_client_callout + 8
27  libdispatch.dylib             	    0x7ff81229d5d8 _dispatch_main_queue_callback_4CF + 951
28  CoreFoundation                	    0x7ff81254c689 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9
29  CoreFoundation                	    0x7ff81250d75e __CFRunLoopRun + 2752
30  CoreFoundation                	    0x7ff81250c5dd CFRunLoopRunSpecific + 563
31  HIToolbox                     	    0x7ff81b13e4f1 RunCurrentEventLoopInMode + 292
32  HIToolbox                     	    0x7ff81b13e247 ReceiveNextEventCommon + 587
33  HIToolbox                     	    0x7ff81b13dfe5 _BlockUntilNextEventMatchingListInModeWithFilter + 70
34  AppKit                        	    0x7ff814f3ab2c _DPSNextEvent + 886
35  AppKit                        	    0x7ff814f39198 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1411
36  AppKit                        	    0x7ff814f2b589 -[NSApplication run] + 586
37  Live                          	       0x10b520f3a 0x10a406000 + 17936186
38  dyld                          	       0x11b6ed4fe start + 462
2

Is the crash consistent/reproducible? We had reports of something similar a while back but none of the team were able to trigger the crash.

If you have a way of reproducing the issue, are you able to trigger the issue with address sanitizer enabled? The extra diagnostic output from Asan will give us a better idea of how to avoid the crash.

3

It is not consistent… I also tried to run with asan but no report was generated.

4

That’s frustrating. Are you able to trigger it with a debugger attached? If so, maybe you could try sticking a breakpoint on the destructor of Displays and see whether this object is being unexpectedly destroyed before the refresh call is made. I’m not sure how that could happen at the moment, but I also can’t think of another way that the array of displays would be invalidated.