Can't run library tests on 0.0.21

caesay commented 5 months ago

If using v0.0.20, everything works fine in my app. I have a library and a collection of bins. Both the library and the bins have tests.

After updating to v0.0.21, I can no longer test my library with the following error:

    Finished `test` profile [unoptimized + debuginfo] target(s) in 2.03s
     Running unittests src/lib.rs (target\debug\deps\velopack-740c02ecfe650ebf.exe)
error: test failed, to rerun pass `--lib`

Caused by:
  process didn't exit successfully: `C:\Source\velopack\src\Rust\target\debug\deps\velopack-740c02ecfe650ebf.exe` (exit code: 0xc0000139, STATUS_ENTRYPOINT_NOT_FOUND)

I can still test my bins via cargo test --bin {binname} but trying to run cargo test --lib or cargo test results in this failure, only on v0.0.21.

I don't know why that would be, and I don't really know where to go from here.

rodrigocfd commented 5 months ago

I've seen STATUS_ENTRYPOINT_NOT_FOUND in builds involving GTK and MSVC toolchain, but without more information I cannot diagnose what's wrong.

Will the applications themselves run fine, without the tests?

What's your toolchain?

Is there any DLL involved in your build process?

Do you have public repos, so I can try to run them here?

caesay commented 5 months ago

The application seems to run fine, but it does obviously worry me that the test runner is broken. Toolchain is x86_64-pc-windows-msvc There are no DLL's in the build process

I have published two branches

The steps to run this is

checkout the repository branch either cs/winsafe-working or cs/winsafe-broken
note that the only difference between the two branches is the winsafe version (and corresponding code update for changed winsafe api's)
Navigate to src/Rust and run cargo tw (short for test windows) or cargo tw86 (for x86)
Notice that the tests fail only on the cs/winsafe-broken branch.

Thanks for offering to look into this further. I wish I could provide you with more info but it's really puzzling!

rodrigocfd commented 5 months ago

I got the following error:

  --- stderr
  thread 'main' panicked at build.rs:15:104:
  Failed to execute nbgv get-version: Error { kind: NotFound, message: "program not found" }

That means I need to install this nbgv program in order to run your tests?

caesay commented 5 months ago

Ah, I forgot that was in the build.rs script. Just the library version is set using that command line tool. You can safely comment out that command from the build.rs script.

rodrigocfd commented 5 months ago

I don't know what's going on, but I have a lead that may help you.

For WinSafe 0.0.21, in this commit, I started using raw-dylib for the linker. Your error is STATUS_ENTRYPOINT_NOT_FOUND, so it might be related.

Since your application runs fine, something in your tests is conflicting with raw-dylib, and you do have a lot going on in your tests. My suggestion is to disable all your tests, and start enabling them one by one, until you find the offender.

caesay commented 5 months ago

STATUS_ENTRYPOINT_NOT_FOUND seems to say to my untrained eye that rust was unable to produce a valid test binary. I don't know how that would be related to any specific test. I noticed that commit too and thought it might have been the culprit. Since you don't have any ideas my only option is to migrate off of winsafe to the windows-rs crate, since it does not have this issue. Feel free to close this issue if you don't plan to look into it further.

caesay commented 5 months ago

If you think it would help narrow down a bug I could give it a go? But in general I don't have any interest in using GNU. The native and recommended toolchain for Rust on Windows is MSVC.

MSVC compiled binaries are faster (https://github.com/rust-lang/rustup/issues/1353) and smaller. They produce standard debugging symbols for use with Microsoft tools. They link to more modern runtimes (eg. ucrt.dll). They are more compatible (eg. static/dynamic libs must all be compiled with the same backend, and everybody compiling for windows already uses MSVC)

GNU is just a not-so-great port.

rodrigocfd commented 5 months ago

I just commented out all your test functions, as I suggested you, and your test built and ran normally.

Then I uncommented the test functions one by one, and after 30 minutes of work, I found the offender:

splash.rs – show_test_gif()

More specifically, this line:

let tx = show_splash_dialog("osu!".to_string(), Some(rd));

This function uses mpsc::channel, which I have no knowledge about.

I hope this helps.

rodrigocfd / winsafe

Can't run library tests on 0.0.21 #130