[Bug]: After v18, an app using requestSingleInstanceLock() will crash if a lower version also starts.

[rooklift]

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 a bug report that matches the one I want to file, without success.

Electron Version

18.0.2

What operating system are you using?

Windows

Operating System Version

Windows 10 version 21H2

What arch are you using?

x64

Last Known Working Electron version

17.3.1

Expected Behavior

requestSingleInstanceLock() should not cause crashes when using different versions of Electron.

Actual Behavior

When an app is built with Electron 18, if it uses requestSingleInstanceLock() and an older version attempts to start, the v18 app crashes in the Main process.

To reproduce:

• Create an app that uses requestSingleInstanceLock()
• Build it for both v18 and v17 of Electron
• Start the v18 version and leave it running
• Start the v17 version

At this point (on Windows 10 at least) a crash will occur in the Main process of v18, likely leading to an unresponsive window.

Testcase Gist URL

https://github.com/rooklift/electron_lock_test

[jkleinsc]

@rooklift what is the use case where you are running into this? eg why would two different versions of the same application be running?

[rooklift]

Rather niche circumstances I suppose - I could accept things not being compatible, but it really shouldn't crash imo...

The actual reason I ran into this was that I tend to develop using the latest Electron version (i.e. I just run electron . in my repo) but I have an older version of my app installed, with a certain filetype associated to it. So while testing some code using electron . when I double-clicked a file it opened in the old version, which (correctly) quit due to the Lock, but then the dev version crashed.

Still, I'm sure there are other circumstances where someone could run into this. Electron is very flexible after all, so the idea of someone having 2 different versions of something installed isn't very far-fetched.

[UndefinedOffset]

Not sure it's related but I noticed a similar crash during a restart after an update to the application when moving between Electron 16.0.4 and 18.0.0 using Squirrel.Windows. See attached screenshot from Sentry. Based on the trace it looks like it is.

[jkleinsc]

#34139 should probably resolve this issue.

[rooklift]

Tested in 18.2.2, which I think includes that fix? It still crashes.

[VerteDinde]

@rooklift Do you happen to have a dmp file or stack trace of the crash that's occurring? I'm curious whether or not it's also happening on the check for read_ack_pipe or somewhere else when requesting the singleInstanceLock

[rooklift]

@rooklift Do you happen to have a dmp file or stack trace of the crash that's occurring? I'm curious whether or not it's also happening on the check for read_ack_pipe or somewhere else when requesting the singleInstanceLock

Just to be clear (forgive me if this is an unneeded clarification), it's not happening when the v18 app calls requestSingleInstanceLock(), rather it's happening when the older version calls it.

• v18 app calls requestSingleInstanceLock()
• time passes
• v17 (or earlier) app calls requestSingleInstanceLock()
• v18 app "crashes" (I believe in the main process; the window becomes unresponsive, but code in the renderer continues to run).

As for dump files, I'm afraid I don't know how to create those (well, I can dump memory via the task manager, but I don't know how to read them...)

[VerteDinde]

Oh no worries, I appreciate being as clear as possible! 🙂 Sorry for not specifying this too - you should be able to generate a crash dump by adding the following snippet to your main process code, before app.whenReady:

const { app, crashReporter } = require('electron')

console.log(app.getPath('crashDumps'))
crashReporter.start({ submitURL: '', uploadToServer: false })

If you then reproduce the crash, zip up the crash dumps directory and attach it here. I'm not entirely sure if this sort of main process crash will produce a dump file, to be honest, just trying to find more information on where in the call to the single instance lock it's actually crashing. I'm trying to reproduce this on my end now as well.

[rooklift]

Hmm I tried it but no significant files were produced at the location.

[VerteDinde]

We actually can repro this (thanks @dsanders11!) Repro steps below, I'm looking into it now and will report back. Thanks for trying to generate a dmp file!

Repro Steps:

1. Open Electron Fiddle.
2. Create two Fiddles, one using v17 and another using v18
3. Pass app.name = "app-name" in both Fiddles, so they have the same name
4. Launch the v18 Fiddle first
5. Launch the v17 Fiddle

[dsanders11]

Here's a minimal gist repro: https://gist.github.com/dsanders11/72c74ab34e2832c3c272602d2570661b

The only thing added to the default Fiddle is explicitly setting app.name and adding a call to app.requestSingleInstanceLock() (but doesn't bother to check the result or anything).

As @VerteDinde said, load the gist in two Fiddle windows, run one on v18 first and the other on v17. In my testing once starting the second one on v17, the v18 app becomes immediately unresponsive, but doesn't hard crash.

[UndefinedOffset]

I'm seeing something similar when moving from 18.2.0 -> 18.2.2, not sure if this is the same issue you are seeing or not. Basically when it happened the update just finished installing (via Squirrel.Windows) and the app was about to prompt to restart. But instead the window froze and it's contents went blank. It seemed like the main process may have crashed based on what one of my other team members said there were 2 processes instead of the normal 3 running. I'm not sure which one was gone but based on what a few people said here I'm guessing it was the main process.

Sentry reported this stack trace:

EXCEPTION_BREAKPOINT / 0x7ff62453c304: Fatal Error: EXCEPTION_BREAKPOINT / 0x7ff62453c304
  File "process_singleton_win.cc", line 402, in ReadAck
    CHECK(read_ack_pipe != INVALID_HANDLE_VALUE);
  File "process_singleton_win.cc", line 435, in ProcessSingleton::NotifyOtherProcess
    ReadAck(notification_ack_callback_, program_name_, user_data_dir_);
  File "process_singleton_win.cc", line 499, in ProcessSingleton::NotifyOtherProcessOrCreate
    ProcessSingleton::NotifyResult result = NotifyOtherProcess();
  File "electron_api_app.cc", line 1172, in electron::api::App::RequestSingleInstanceLock
    switch (process_singleton_->NotifyOtherProcessOrCreate()) {
  File "function_template.h", line 213, in gin::internal::Dispatcher<T>::DispatchToCallbackImpl
    invoker.DispatchToCallback(holder->callback);
...
(3 additional frame(s) were not displayed)

[UndefinedOffset]

Seeing the same issue going from 18.2.2 -> 18.2.4, the conditions are the same. Auto update just finished installing then hard lock. Interestingly the window's render process seems to be still refreshing but you can't interact with the window. This time the processes expected were all there but one was listed as "not responding" by windows which appeared to be the renderer as it's title in the task manager seemed to indicate that. Perhaps this hang is related to #34297?

EXCEPTION_BREAKPOINT / 0x7ff65d04c0e6: Fatal Error: EXCEPTION_BREAKPOINT / 0x7ff65d04c0e6
  File "process_singleton_win.cc", line 391, in ReadAck
    CHECK(read_ack_pipe != INVALID_HANDLE_VALUE);
  File "process_singleton_win.cc", line 424, in ProcessSingleton::NotifyOtherProcess
    ReadAck(notification_ack_callback_);
  File "process_singleton_win.cc", line 488, in ProcessSingleton::NotifyOtherProcessOrCreate
    ProcessSingleton::NotifyResult result = NotifyOtherProcess();
  File "electron_api_app.cc", line 1172, in electron::api::App::RequestSingleInstanceLock
    switch (process_singleton_->NotifyOtherProcessOrCreate()) {
  File "function_template.h", line 213, in gin::internal::Dispatcher<T>::DispatchToCallbackImpl
    invoker.DispatchToCallback(holder->callback);
...
(3 additional frame(s) were not displayed)