search

bottlesdevs / Bottles

Run Windows software and games on Linux
https://usebottles.com
GNU General Public License v3.0
6.35k stars 266 forks source link

[BUG] Race condition launching applications from CLI #1104

Closed tgschultz closed 2 years ago

tgschultz commented 2 years ago

Describe the bug Using the command line flatpak run com.usebottles.bottles -e 'C:\Program Files\Program\Program.exe' -b 'Bottle' exits immediately after the warning WARNING Windows path detected. Avoiding validation.. If the -b argument is removed, Bottles will launch to the bottle list with Run Here buttons as expected. Running with no arguments also launches Bottles as expected. Specified program and bottle configuration appear to be irrelevant and this same command with an identically configured bottle appears to work fine on Ubuntu 20.04.

This appears to also prevent all .desktop files created by Bottles from working.

To Reproduce Steps to reproduce the behavior:

  1. Install Fedora Silverblue 35 and Bottles flatpak
  2. Launch Bottles and create a bottle called 'Applications'
  3. Install PuTTY x86 64-bit from https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html
  4. flatpak run com.usebottles.bottles -e 'C:\Program Files\PuTTY\putty.exe' -b 'Applications'
  5. Bottles exits without ever launching the application

Expected behavior The specified program should launch in the specified bottle

Desktop (please complete the following information):

Additional context Flatpak 1.12.3 Bottles 2022.2.28-trento-2

tgschultz commented 2 years ago

In the process of troubleshooting to determine why this behavior might be unique to Silverblue, I discovered that if the command is issued once and then issued again within a short window of time, ~5-7 seconds, it does work. On the second launch the following messages are displayed after the Windows path detected. warning:

wineserver: using server-side synchronization.
002c:err:wineboot:process_run_key Error running cmd L"C:\\windows\\system32\\winemenubuilder.exe -r" (2).
0068:err:module:open_builtin_so_file failed to load .so lib "/var/home/tgschultz/.var/app/com.usebottles.bottles/data/bottles/runners/caffe-7.0/lib/wine/x86_64-unix/wineusb.sys.so"
0068:err:ntoskrnl:ZwLoadDriver failed to create driver L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\wineusb": c0000142

It is my experience that those errors are normal, but it is interesting that they only occur in the second launch. With a better understanding of Bottles's program flow that might help narrow down what's going on.

This behavior may be related to #1041

mirkobrombin commented 2 years ago

I was able to reproduce it with Notepad++ but only a few times

tgschultz commented 2 years ago

Alright, go it:

window.py#L375 waits for 1 second in order to allow the RunAsync thread to launch the wine process. I guess this isn't long enough in some circumstances because lengthening the sleep to 5 seconds allows the command line to launch every time.

I'll see if I can work out a better mousetrap that doesn't have this race condition and submit a PR.

mirkobrombin commented 2 years ago

Alright, go it:

window.py#L375 waits for 1 second in order to allow the RunAsync thread to launch the wine process. I guess this isn't long enough in some circumstances because lengthening the sleep to 5 seconds allows the command line to launch every time.

I'll see if I can work out a better mousetrap that doesn't have this race condition and submit a PR.

We can also use a callback to make the RunAsync operation close the window.

tgschultz commented 2 years ago

After spending some time playing around with different scenarios, I've discovered a lot of issues with launching programs from the command line:

These lead me to believe a more holistic fix is necessary. As I do not write Python very often, have no experience with the GTK module, and am just starting to come to grips with Bottles's code structure, I will have to spend some time investigating the best approach.

mirkobrombin commented 2 years ago

If the Bottles GUI is running, command line launches (and therefore .desktop files) are ignored.

Not an issue at all, as if you have Bottles opened you can still launch programs from here :D (not a priority)

  • If Bottles is launching a command line program and another launch is initiated, the second launch will error out.
  • If Bottles launches two programs (from the same Bottle only?) from the command line and closes the second one, the first program will become unresponsive.

There is another issue about the CLI (which should be just rewritten from scratch) https://github.com/bottlesdevs/Bottles/issues/927

tgschultz commented 2 years ago

Well, if that's the case then I'll just see about fixing the race condition for now.