Electron crashes during OSX sleep / wakeup

[AndreyMalykhin]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for an issue that matches the one I want to file, without success.

Issue Details

• Electron Version:
  • 8.2.2
• Operating System:
  • macOS Catalina

To Reproduce

Sometimes electron crashes somewhere between sleep and wakeup on OSX. Possibly related to having multiple displays.

Additional Information

Original crash dump:
electron.crash.zip

Decoded native stack trace:

_platform_memmove$VARIANT$Haswell + 320
electron::api::Screen::OnDisplayAdded(display::Display const&) (in Electron Framework) (electron_api_screen.cc:120)
display::DisplayChangeNotifier::NotifyDisplaysChanged(std::__1::vector<display::Display, std::__1::allocator<display::Display> > const&, std::__1::vector<display::Display, std::__1::allocator<display::Display> > const&) (in Electron Framework) (display_change_notifier.cc:64)
display::(anonymous namespace)::ScreenMac::ConfigureTimerFired() (in Electron Framework) (screen_mac.mm:324)
base::RetainingOneShotTimer::RunUserTask() (in Electron Framework) (timer.cc:333)
base::TaskAnnotator::RunTask(char const*, base::PendingTask*) (in Electron Framework) (task_annotator.cc:142)
base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl(base::sequence_manager::LazyNow*, bool*) (in Electron Framework) (thread_controller_with_message_pump_impl.cc:0)
base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoSomeWork() (in Electron Framework) (thread_controller_with_message_pump_impl.cc:219)
invocation function for block in base::MessagePumpCFRunLoopBase::RunDelayedWorkTimer(__CFRunLoopTimer*, void*) (in Electron Framework) (message_pump_mac.mm:459)
base::mac::CallWithEHFrame(void () block_pointer) (in Electron Framework) + 10
base::MessagePumpCFRunLoopBase::RunDelayedWorkTimer(__CFRunLoopTimer*, void*) (in Electron Framework) (message_pump_mac.mm:461)
__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20
__CFRunLoopDoTimer + 1095
__CFRunLoopDoTimers + 346
__CFRunLoopRun + 2427
CFRunLoopRunSpecific + 483
RunCurrentEventLoopInMode + 286
ReceiveNextEventCommon + 613
_BlockUntilNextEventMatchingListInModeWithFilter + 64
_DPSNextEvent + 2085
-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3044
-[NSApplication run] + 764
base::MessagePumpNSApplication::DoRun(base::MessagePump::Delegate*) (in Electron Framework) (message_pump_mac.mm:0)
base::MessagePumpCFRunLoopBase::Run(base::MessagePump::Delegate*) (in Electron Framework) (message_pump_mac.mm:189)
non-virtual thunk to base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run(bool, base::TimeDelta) (in Electron Framework) (thread_controller_with_message_pump_impl.cc:0)
base::RunLoop::Run() (in Electron Framework) (run_loop.cc:158)
content::BrowserMainLoop::RunMainMessageLoopParts() (in Electron Framework) (browser_main_loop.cc:1062)
content::BrowserMainRunnerImpl::Run() (in Electron Framework) (browser_main_runner_impl.cc:151)
content::BrowserMain(content::MainFunctionParams const&) (in Electron Framework) (browser_main.cc:47)
content::ContentMainRunnerImpl::RunServiceManager(content::MainFunctionParams&, bool) (in Electron Framework) (content_main_runner_impl.cc:960)
content::ContentMainRunnerImpl::Run(bool) (in Electron Framework) (content_main_runner_impl.cc:0)
service_manager::Main(service_manager::MainParams const&) (in Electron Framework) (main.cc:423)
content::ContentMain(content::ContentMainParams const&) (in Electron Framework) (content_main.cc:19)
ElectronMain + 84
0x000009b0 (in Electron Framework)
start + 1

[nornagon]

I've also observed this in other versions of Electron.

[nornagon]

The last PR to touch this code was #19016 by @MarshallOfSound, though that was to fix an issue on Windows. I'm not really sure which bit is segfaulting though.

[codebytere]

@nornagon that invokes

void Screen::OnDisplayAdded(const display::Display& new_display) {
  base::ThreadTaskRunnerHandle::Get()->PostNonNestableTask(
      FROM_HERE, base::Bind(&DelayEmit, base::Unretained(this), "display-added",
                            new_display));
}

which then calls screen->Emit(name, display) so my guess is probably that |this| is gone?

[nornagon]

The stack trace is in OnDisplayAdded, not in Screen::Emit. I don’t think `this` is dereferenced in OnDisplayAdded.

…

On Tue, Jun 16, 2020 at 08:00 Shelley Vohr ***@***.***> wrote: @nornagon <https://github.com/nornagon> that invokes void Screen::OnDisplayAdded(const display::Display& new_display) { base::ThreadTaskRunnerHandle::Get()->PostNonNestableTask( FROM_HERE, base::Bind(&DelayEmit, base::Unretained(this), "display-added", new_display)); } which then calls screen->Emit(name, display) so my guess is probably that |this| is gone? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#24135 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABKGAFMVU4PQCRDNSBBW7LRW6CKPANCNFSM4N6MIJPQ> .

[AndreyMalykhin]

Also to note, there is no usage of Screen events API (https://www.electronjs.org/docs/api/screen) in the app.

[aguynamedben]

We're potentially seeing the same issue in our app, on Electron 7.3.1. I just tried upgrading to Electron 8.4.1 to see if that fixes it.

Multiple engineers on our team have seen it while their laptop is sleeping while connected to an external display. It's happened multiple times overnight to me when I left my Macbook Pro hooked up to a 4k monitor via USB-C/Thunderbolt 3. I'm going to test more tomorrow with an extra laptop and external display.

This has been difficult to track down because our app uses @sentry/electron for crash/minidump reporting. Crashes are usually reported to Sentry (i.e. process.crash(), etc.) but with whatever this crash is, we never see a dump. We just see the app go dark at some point in our logging. No crash report. The app is just no longer running the next morning.

Thanks for the work you put into Electron. It's enabled us to build things we never could have built before. 🙏

[nornagon]

@sentry/electron has a custom crash uploading system. They bypass crashpad's uploader, so they'll only upload crashes later.

[nornagon]

@aguynamedben did upgrading to 8.4.1 address the issue?

[deepak1556]

Looks like this issue is still present with E9, just got a report in vscode for the same trace microsoft/vscode#108860

[wdarm]

I'm readily able to reproduce this with both VisualStudioCode and Microsoft teams but I'm not a developer on either App so I can't readily debug this issue.

Is anyone looking into this?

[nornagon]

FWIW from looking at Slack's internal crash metrics, the highest Electron version we've observed this crash on is 9.0.5. We've been shipping Electron 10 in prod for a long time, so I'm confident that this has been fixed in some version newer than v9.0.5.