Import script in c++ code fails for 32bit, works for 64bit

[Selur]

I got the following code (on github):
which works fine when used with 64bit AviSynth.dll (3.7.1)

  try { // always fails for 32bit WTF?!
    std::cout << "Importing " << qPrintable(m_currentInput) << std::endl;
    const char* infile = m_currentInput.toLocal8Bit(); //convert input name to char*
    AVSValue arg(infile);
    m_res = m_env->Invoke("Import", AVSValue(&arg, 1));
  } catch (AvisynthError &err) { //catch AvisynthErrors
    std::cout << "Failed importing " << qPrintable(m_currentInput) << std::endl;
    std::cerr << "-> " << err.msg << std::endl;
    return false;
  } catch (...) { //catch everything else
    std::cerr << "-> invoking Import for " << qPrintable(m_currentInput) << " failed!" << std::endl;
    return false;
  }

but always fails for 32bit AviSynth.dll (3.7.1).
Output I get is:

loaded avisynth dll,..(I:/workspace/avsInfo/debug/AviSynth.dll)
loaded CreateScriptEnvironment definition from dll,..
loaded IScriptEnvironment using AVISYNTH_INTERFACE_VERSION,.. (9)
getting avs linkage from environment
Importing c:\Users\Selur\Desktop\version.avs

-> Does anyone have an idea what could cause this?
The code itself should be fine as it works fine with the 64bit AviSynth.dll.
Got the dlls from the AviSynthPlus_3.7.1_20211231-filesonly.7z package. (same with 'Avisynth+ 3.7.2 test 1 (20220113)')
According to the debug output the error seems to be in AviSynth!avs_is_yuv420ps which seems to loop.

Cu Selur

[vcmohan]

In vapoursynth YUV420PS is not allowed. Only YUV444PS can be input. Is it an issue?

[Selur]

My problem is with AviSynth not Vapoursynth, so not sure how this is related.

hmm,... when using
AviSynthPlus_3.7.1_20211231-filesonly.7z
+

version()
return last

it dies in avs_is_yuv420ps.

same when using the files from Avisynth_3.7.2_20220113_test1
it seems to die in avs_clip_get_error.

No clue why this is happening and only with the 32bit versions.

Cu Selur

[pinterf]

avs_is_yuv420ps and avs_clip_get_error are C interface calls.
Your linked code is using c++ interface.
Which component in your processing chain is using C interface calls?

[Selur]

Which component in your processing chain is using C interface calls?

None that I'm aware of. :/
I mean the whole project isn't large ( see: https://github.com/Selur/avsInfo/) and I don't see anything that uses the c interface calls.
(I include the avisynth.h and not the avisynth_h.h headers,..)
Also why does it work with 64bit and not with 32bit is really beyond me. :/

Cu Selur

[qyot27]

I've been seeing strange results with FFmpeg and avs2yuv (which do use the C interface) - some combinations of 32-bit builds of AviSynth+ and FFmpeg work, but not other combinations. 64-bit is completely unaffected.

Rolling 32-bit AviSynth+ all the way back to 3.5.1 (or even back to classic 2.6.1) was able to confirm that something probably came in during the Neo merge that is messing with 32-bit builds on Windows. Whatever it is, it affects both MSVC and GCC builds, may or may not affect Debug builds of AviSynth+, and may be a problem in FFmpeg or one of its dependencies (because I was seeing weird references to videolan and Java in one of the backtraces, and to my knowledge, the only thing that would probably refer to that inside of FFmpeg is libbluray, but libbluray shouldn't be screwing with AviSynth). That it could be a dependency chain issue would point to a problem potentially in MinGW-w64, except that it's also on the MSVC side as well. If the problem exists in normal 32-bit builds but not XP 32-bit builds, that would point to possibly being an issue in the Windows 10 SDK in MSVC 2019 (if it exists in the XP builds it would be a general issue with the cl compiler in MSVC 2019).

32-bit builds on other OSes are fine (tested with VMs of both Debian 10/i386 as well as OS X Tiger/PPC), so it's not even universally a GCC problem, just a Windows problem.

[qyot27]

Now that I'm reminded of how similar this is appearing, I certainly hope this isn't something caused by having fixed 64-bit GCC builds back in October:
https://github.com/AviSynth/AviSynthPlus/issues/237

It appears almost like the inverse of that, except even the MSVC builds are giving us problems.

[pinterf]

Originally Posted by Selur

None that I'm aware of. :/
I mean the whole project isn't large ( see: https://github.com/Selur/avsInfo/) and I don't see anything that uses the c interface calls.
(I include the avisynth.h and not the avisynth_h.h headers,..)
Also why does it work with 64bit and not with 32bit is really beyond me. :/

Cu Selur

Which compiler are you using?

[Selur]

Which compiler are you using?

MSVC 2019

Cu Selur

[pinterf]

Then these sentences need a bit more clarification:
"it dies in avs_is_yuv420ps."
"same when using the files from Avisynth_3.7.2_20220113_test1 it seems to die in avs_clip_get_error."
What does "dies" mean and which software is giving the error messages if there is an error message at all?
Since they are C interface functions, obviously something is using C interface in your chain, e.g. an ffmpeg, an ffms C plugin or I don't know.

[Selur]

I run the avsViewer in debug mode through QtCreator set ip to open the version.avs on my desktop and see this:

I uninstalled and reeinstalled the msvc 32bit run time files in hope that would help, which it did not.

First I thought I messed up the code somewhere, but like I wrote if I compile it with 64bit, everything works fine.
(you can see the whole code I use over at the github, see link in first post)

version.avs just contains:

version()
return last

extending it to:

ClearAutoloadDirs()
version()
return last

doesn't change a thing.

Cu Selur

[pinterf]

What happens when omitting 'return last'?

[Selur]

sadly:

#ClearAutoloadDirs()
version()
#return last

and

ClearAutoloadDirs()
version()
#return last

give the same error

Cu Selur

Ps.: same with Avisynth_3.7.2_20220201_test2 and Avisynth+ 3.7.2 test 3 (20220208)