Airwindows 2.13.0

chaircrusher · June 30, 2025, 3:05am

AirWindows 2.13.0 on Windows 11 tries to update and fails every time.

Relevant lines in log.txt:

[0.080 info src/plugin.cpp:269 extractPackages] Extracting package C:/Users/Kent Williams/AppData/Local/Rack2/plugins-win-x64/Airwin2Rack-2.13.0-win-x64.vcvplugin Loading plugin from C:/Users/Kent Williams/AppData/Local/Rack2/plugins-win-x64/Airwin2Rack [0.663 warn src/plugin.cpp:237 loadPlugin] Could not load plugin C:/Users/Kent Williams/AppData/Local/Rack2/plugins-win-x64/Airwin2Rack: Failed to load library C:/Users/Kent Williams/AppData/Local/Rack2/plugins-win-x64/Airwin2Rack/plugin.dll: code 12 log.txt (415.8 KB)

Andre_M · June 30, 2025, 4:15am

I know that’s not a solution, but few month ago somebody here recommended me the “Nightbin” module by Questionable Modules, which updates Airwindows and other modules with github repositories straight from github. And I updated Airwindows to 2.14 without any problems, using this Nightbin thing.

LarsBjerregaard · June 30, 2025, 7:02am

How long have you been running Rack on this particular machine? It looks like you have a space in your username, and therefor in the path to all Rack files and plugins. There’s been several cases where this has proven to be a bad idea, and other programs might choke on that as well. If I were you I would definately change that username/path if you can.

LarsBjerregaard · June 30, 2025, 7:08am

Ah, never mind, it looks like it’s this one:

pachde · June 30, 2025, 3:27pm

Rack itself has solved the problems with spaces and non-ASCII in paths. These are, after all, perfectly valid paths on the operating system. Rack provides correct and safe file APIs in the system namespace.

Any such issues are a bug in the plugin and should be reported to the developer. Unfortunately, the issue may be a bug in a dependency that the developer isn’t able or willing to pursue.

If that’s too much swimming upstream to get developers to fix their bad code, then yeah, remove spaces and non-ASCII in your paths, including your user name.

baconpaul · June 30, 2025, 9:15pm

That’s not the case here though. This looks like the tool chain ejecting a bad binary somehow since the nightly works. Rack team reverted the library to 2.12

Squinky · June 30, 2025, 9:24pm

There was an issue where the toolchain cpp lib would crash on windows. A lot of us got bit by that. If that’s the issue, I think there was a toolchain update to fix that? btw, I had that bug for like 5 years. I just wrote my own stdlib functions…

baconpaul · July 1, 2025, 3:20am

In this case the older tool chain nightly works and the library official does not. Ring any bells?

Airline is lots of code. Gcc bigobj issue maybe?

Squinky · July 1, 2025, 4:24am

Sounds familiar. Ask @cschol ?

Squinky · July 2, 2025, 1:13am

Oh, here are some of the closed issues that I logged. Looks like they were from 2021.

github.com/VCVRack/library

Crashes on Windows platform

opened 10:03PM - 22 Nov 20 UTC

closed 01:14PM - 06 Oct 21 UTC

squinkylabs

It's probably just superstition on my part, but when I was going though that cra…shing stuff last week and the week before the only thing I could think of is that "something" is different between local builds and tooling server builds for windows. If course the linkage is different. I was unable (in the sort amount of time I tried) to generate a static link locally. Seems like it would "be nice" if it were possible to make the two builds more similar? Anyway, the worry is that someone else will run into this mystery issues and their plugins will start crashing (like one of the people reporting constant win crashes. fwiw my issues were 100% repro, so doesn't sound quite the same.

github.com/VCVRack/rack-plugin-toolchain

std::mt19937 crashes with toolchain build on windows

opened 02:30PM - 02 Aug 21 UTC

closed 04:55AM - 16 Apr 25 UTC

squinkylabs

Once again I've run into compatibility problem with the toolchain build in windo…ws where it crashes with perectly good c++ code. This time it's in mt19937. Calling it from my process(args) function corrupts the stack and crashes. Since I need to do this I may have to use an open-source implementation of the mersenne twister algorithm. So far my problems are: 1) sometimes trying to catch an exception in draw code crashed the toolchain build (but not a local msys build). Solution: remove the code that does that. 2) using std::stringstream from draw code crashes with the toolchain build (but not a local msys build). Solution: wrote my own subset of stringstream that works. 3) [new] calling mt19937 from process call immediately crashes with a corrupt stack. solution: none yet.

github.com/VCVRack/rack-plugin-toolchain

I think I've isolated the windows crash introduced by the new toolchain

opened 06:16AM - 05 Mar 21 UTC

closed 04:55AM - 16 Apr 25 UTC

squinkylabs

You may remember last year that four of my old plugins started crashing the modu…le browser when the library switched to the new toolchain. At the time I found that the crashes were from usage of std::stringstream, and from the inability to catch any exception. But I couldn't pin it down. So I removed all the offending code from my old plugins, and they have been fine. Today I recreated this issue: it happens when the ui thead does one of these things, i.e. if my draw() call does them. This does not happen when I make a local build - with a local build any valid c++ 11 seems to work just fine, regardless of thread. Anyway, I could further isolate this. I would think I could even make a dedicated repo with just a "hello world" plug that would crash. Anyone interested in pursuing this?