search

jqnatividad / qsv

Blazing-fast Data-Wrangling toolkit
https://qsv.dathere.com
The Unlicense
2.52k stars 71 forks source link

BUG: _ZSt28_throw_bad_arrray_new_lengthv on GNU 137 but not MSVC 130 #2257

Open Joebugg opened 3 weeks ago

Joebugg commented 3 weeks ago

Describe the bug Error message on upgrade.

To Reproduce Steps to reproduce the behavior: Install latest VCRT (1438). Copy QSV 130 to somewhere in path or add path to installed location. Run QSV 130 exe. Accept offer to upgrade. Run QSV 137. Get following error message: "The procedure entry point _ZSt28_throw_bad_arrray_new_lengthv could not be located in the dynamic link library C:\Program Files (x86)\gnuwin32\bin\qsv.exe."

Expected behavior It to list options and return to command prompt when done.

Desktop (please complete the following information): Windows Server 2019 64-bit Both x64 and x86 runtimes updated to latest from Microsoft (2015-2022 support).

Additional context I'm going to try moving it directly to the folder where I'm running the command from. I suspect it's mixing DLL versions if one is found in GnuWin32's path, before VC's.

Joebugg commented 3 weeks ago

Renamed libstdc++-6.dll (which was needed for QSV 130), and now it's no longer giving the ZSt28 error, but now it wants a compatible libstdc++ library. I assume there's a newer version of libstdc++-6.dll that is compatible with QSV and current runtimes?

jqnatividad commented 3 weeks ago

I'm afraid I don't have access to a Windows Server 2019 64-bit machine so it'll be hard to troubleshoot.

Can you share what qsv --version shows for the currently installed qsv?

Joebugg commented 3 weeks ago

I'll try reverting back through versions to narrow it down. It won't let me get that far, to show the version info, but I let it update to latest. Hex editor and hash of F8531339 verify that it's same as qsv.exe in qsv-0.137.0-x86_64-pc-windows-gnu.zip. Hmm, seems there's both a MSVC and Gnu version. The MS runtimes would thus have zero effect? I'll try hunting down the Gnu runtimes.

Joebugg commented 3 weeks ago

Reverted back to 130 and now it does it, too.

EXE I had copied from other PC that works: qsv 0.130.0-mimalloc-apply;fetch;geocode;Luau 0.635;to;polars-0.41.3;self_update-4-4;6.24 GiB-2.84 GiB-2.89 GiB-7.80 GiB (x86_64-pc-windows-msvc compiled with Rust 1.79) prebuilt EXE that I just downloaded: Displays nothing and returns to command line (even with --version or --list).

Ah, so the problem is library version/support. So if I used the MSVC exe, it'll work, fine. Begs the question how you get the correct Gnu runtimes...

Installation notes should probably mention version of compiler used (MinGW?) so that others don't have this issue. Also, not a bad idea to not update to a different main line with that --update command? I guess the three main ones on Windows are GNU/MSVC/Rust.

jqnatividad commented 3 weeks ago

Thanks for the thorough investigation @Joebugg .

I'll add an installation note per your suggestion.

Thinking about it more, maybe I should just prune the choices and stop building GNU version on Windows and just use MSVC. WDYT?

https://www.reddit.com/r/rust/comments/a63dlt/difference_between_the_gnu_and_msvc_toolchains/

Joebugg commented 3 weeks ago

I wonder if it makes more sense to offer it as a file you can just run the build tool on, in GCC. What kind of dependencies are we talking about? I mean, you kind of need the right compiler's library (AFAICT, there's multiple with the same filename?) to use it, anyways. Is it possible to legally include the standard library (or at list, link to correct one)?

GNU version sounds good but if I can't use it... As a user, that does me no good. MSVC has it's own annoyances like incompatibilities because of one pointless function call that you can't (easily?) disable on newer Visual Studio versions, so if you want a program to work on everything from NT 3.5 to 11, you have to make multiple versions. Not that I'd want to be using 2000 or XP anymore. ;)

To the average user, the only appreciable difference is that they install different set of runtime libraries. I assume there's some performance differences or convenience factors as well.

jqnatividad commented 3 weeks ago

The GitHub Action Publishing workflow uses windows-latest: https://github.com/jqnatividad/qsv/blob/2b5536084f42acfea4422797abcf3396074f856e/.github/workflows/publish.yml#L88-L97

And per GH, windows-latest is windows-2022 which may very well be the root cause of your specific problem. That image has the bundled libraries qsv uses: https://github.com/actions/runner-images?tab=readme-ov-file#available-images

I'll add that to the note. And maybe, add another variant that uses windows-2019 or just pin qsv windows gnu to always be more conservative and not use windows-latest...