[Bug] Vesktop opens multiple, duplicate app instances

[Arcitec]

Edit: It's an upstream bug, waiting on: https://github.com/electron/electron/issues/43350

Operating System

Fedora Workstation 40

Linux Only ~ Desktop Environment

GNOME on Wayland

Package Type

Official RPM

What happens when the bug or crash occurs?

Vesktop often opens duplicate copies of itself after you close its window. And because it opens multiple copies of itself (running simultaneously), it breaks the login state:

What is the expected behaviour?

The startup task should detect the running instance and trigger it to open the window instead of starting a new copy of the app.

How do you recreate this bug or crash?

1. Start the app (native RPM but probably affects everything else too).
2. Close the window so that Vesktop minimizes itself to the system dray.
3. Start the app again via your desktop environment (I have it on the GNOME Dock).
4. Very often (or almost always), this will cause Vesktop to open a brand new copy of itself.

I have seen this bug on 2 separate computers now. Which leads me to believe that there's no code (or incomplete code) for "detect a running Vesktop instance and bring that to life instead of starting a new copy of the app".

Typically, apps will do some kind of thing like this to solve that:

int main() {
   var instance = find_existing_instance();
   if (instance) {
       print("Vesktop is already running. Activating existing instance...");
       instance.activate();
       exit(0);
   }
   // normal startup
}

Debug Logs

Alright... I see something that indicates what this bug is about...

1. First I close the existing app window (so that it goes to the tray), and then I run vesktop in the terminal:

$ vesktop

#
# Fatal process out of memory: Failed to reserve virtual memory for CodeRange
#
----- Native stack trace -----

[1]    973327 trace trap (core dumped)  vesktop

2. Then I try again in the terminal, and now it starts the duplicate Vesktop instance:

$ vesktop
Checking for beta autoupdate feature for deb/rpm distributions
Found package-type: rpm
Checking for update
[arRPC > ipc] not available, trying again (attempt 1)
[arRPC > ipc] listening at /run/user/1000/discord-ipc-1
[arRPC > websocket] 6463 in use!
[arRPC > websocket] listening on 6464
[arRPC > process] started
src/gbm_drv_common.c:131: GBM-DRV error (get_bytes_per_component): Unknown or not supported format: 808530000

src/gbm_drv_common.c:131: GBM-DRV error (get_bytes_per_component): Unknown or not supported format: 808530000

src/gbm_drv_common.c:131: GBM-DRV error (get_bytes_per_component): Unknown or not supported format: 808530000

src/gbm_drv_common.c:131: GBM-DRV error (get_bytes_per_component): Unknown or not supported format: 808530000

src/gbm_drv_common.c:131: GBM-DRV error (get_bytes_per_component): Unknown or not supported format: 808530000

Update for version 1.5.3 is not available (latest version: 1.5.3, downgrade is disallowed).
checkForUpdatesAndNotify called, downloadPromise is null

3. And now I try vesktop in terminal again while the duplicate copy is running:

$ vesktop
Checking for beta autoupdate feature for deb/rpm distributions
Found package-type: rpm
Checking for update
Vesktop is already running. Quitting...

So it seems to me like the existing instance check fails and core-dumps once. Then, the next time, it starts a new instance instead, and then after that, it's able to find the new instance and bring that to the front.

This actually perfectly matches up with the fact that the dock button does NOTHING the first time you click it and then the SECOND click it brings up a new app copy. This indicates that the core dump/crash happens, and then the next click starts a fresh instance instead.

So it's basically losing contact with the older app instance sometimes. Hmm.

Request Agreement

• [X] I have searched the existing issues and found no similar issue
• [X] I am using the latest Vesktop and Vencord versions
• [X] This issue occurs on an official release (not just the AUR or Nix packages)

[Arcitec]

This bug happens extremely frequently for my mother, who is in the habit of clicking the Close button on app windows constantly. So several times per day when she clicks on Vesktop she gets a new login request.

I'm gonna have to set her Vesktop to "exit after closing window, do not stay in tray" for now... (Vesktop Settings: Behavior: Minimize to Tray = Off).

[Arcitec]

Oh and if I had to guess, this is most likely a bug in the Electron wrapper and nothing that you can do anything about?

[Covkie]

https://github.com/electron/electron/issues/43350

[Arcitec]

@Covkie Ah thank you, great find! Yes that sounds extremely likely to be the issue, because we both use Steam and launch Steam frequently.

Edit: https://github.com/electron/electron/issues/43350#issuecomment-2355588960

Edit: I see you reported it to Electron originally. Thank you for that.

[FuzzyQuils]

I've had the stock Discord app from Discord themselves also do this every time I start it from either the dock or KDE's application menu; I'm not sure if this is exclusive to Vesktop.