search

russellbanks / Komac

The Community Manifest Creator for WinGet
GNU General Public License v3.0
213 stars 16 forks source link

[Bug]: Thread panic due to async operations #715

Closed Trenly closed 3 months ago

Trenly commented 3 months ago

Is there an existing issue for this?

What happened?

Environment

I use two linux VMs for my setup, both are running a flavor of Debian Linux but have different customizations and settings.

One VM is my "build" VM - it has more packages and SDKs installed, as well as having more memory and CPU allocated to it. I use this VM to create or build binaries for testing.

The second VM is my "runner" - It has a very minimal set of packages and no specially installed SDKs. I use this VM to test the binaries built on the other VM.

The Bug

On my build VM I have installed cargo along with the apt packaes such as make required to build Komac. I have cloned my fork of this repo onto the VM.

  1. cd ~/git/Komac
  2. cargo build --release --locked
  3. copy the binary to my other vm - scp ~/git/Komac/target/release/komac root@123.123.123.123:/usr/local/bin/
  4. On the runner vm komac --version
  5. Works! Shows 2.4.0
  6. Any other komac commad - such as listing versions of a package
  7. Fails with:

Message: Cannot start a runtime from within a runtime. This happens because a function (like block_on) attempted to block the current thread while the thread is being used to drive asynchronous tasks. Location: /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/zbus-4.4.0/src/utils.rs:49

However, if I use the same steps as above, but instead of using cargo build --release --locked I do cargo install komac --locked to use the version from crates.io, no errors occur

russellbanks commented 3 months ago

Thanks for reporting! I believe this is because keyring, the library komac uses for storing secrets, had an update recently that gives more choice over the platforms supported and whether to use async or not.

In keyring v2, it defaulted to using a different runtime than komac uses itself, so this wouldn't have been an issue. Now that I've chosen it to use the same runtime as it should be, it crashes trying to spawn a runtime inside the current runtime.

See:

The fix should just be dealing with tokens on a separate thread.

russellbanks commented 3 months ago

I've switched it to access tokens synchronously on Linux as that's how it is on Windows and macOS and tokens aren't accessed in an asynchronous manner anyway as its the first thing that's needed when komac starts.