32-Bit Qt crashes when calling a 32-bit DLL function (char*)
-
My 32-bit Qt windows application crashes whenever it calls a specific function from a 32-bit DLL. Other functions from this DLL work fine... only the following causes an "Exception Triggered" by an "inferior":
int16_t deviceInit (const char* filePath);
And I'm calling it via:const char cstr[] = { "C:\\File.bin"}; deviceInit (cstr);
I'm thinking maybe it's how characters/strings/unicode are passed.. or some mismatch in the compiler settings/multithread, or MSVC versions.
I'm using Qt 5.15.2 MSVC2019 32-bit (17.9.3462). I tried the C/C++ compiler options to "x86_amd64" as well "x86", but it still crashes. Also tried en/disabling "Force UTF-8 MSVC compiler output".
As a test, I built a Win32 application using VS Studio 2022 and calling the DLL function works fine. If the path or file is bad, the function returns an error code, but it does not cause a crash. Since VS Studio and Qt are using the same compiler, maybe it's the build system / linker ? MSBuild , CMake ?
The setup in VS Studio is a bit different than Qt.. I had to point the Library directory to the folder containing McxApi.lib and then use:
#pragma comment(lib, "McxAPI")
VS Studio shows the compile and linker command-line settings to be
/JMC /permissive- /ifcOutput "ConsoleA.3e145a6e\Debug\" /GS /analyze- /W3 /Zc:wchar_t /ZI /Gm- /Od /sdl /Fd"ConsoleA.3e145a6e\Debug\vc143.pdb" /Zc:inline /fp:precise /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /errorReport:prompt /WX- /Zc:forScope /RTC1 /Gd /Oy- /MDd /FC /Fa"ConsoleA.3e145a6e\Debug\" /EHsc /nologo /Fo"ConsoleA.3e145a6e\Debug\" /Fp"ConsoleA.3e145a6e\Debug\ConsoleApplication1.pch" /diagnostics:column /OUT:"C:\Projects\Temp\9\ConsoleApplication1\Debug\ConsoleApplication1.exe" /MANIFEST /NXCOMPAT /PDB:"C:\Projects\Temp\9\ConsoleApplication1\Debug\ConsoleApplication1.pdb" /DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /DEBUG /MACHINE:X86 /INCREMENTAL /PGD:"C:\Projects\Temp\9\ConsoleApplication1\Debug\ConsoleApplication1.pgd" /SUBSYSTEM:WINDOWS /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"ConsoleA.3e145a6e\Debug\ConsoleApplication1.exe.intermediate.manifest" /LTCGOUT:"ConsoleA.3e145a6e\Debug\ConsoleApplication1.iobj" /ERRORREPORT:PROMPT /ILK:"ConsoleA.3e145a6e\Debug\ConsoleApplication1.ilk" /NOLOGO /TLBID:1
In Qt, the make and .pro settings are:
C:/Qt/5.15.2/msvc2019/bin/qmake.exe C:\Projects\Temp\8\test\source\test.pro -spec win32-msvc "CONFIG+=debug" "CONFIG-=qml_debug" && C:/Users/temp/msvc_make.bat qmake_all QT += core gui quick #INCLUDEPATH += $$PWD/ LIBS += -L$$PWD/libfolder -lMcxAPI greaterThan(QT_MAJOR_VERSION, 4): QT += widgets CONFIG += c++11 ...
-
Don't see what Qt has to do with this crash. Normally when a program crashes you look into the backtracce to see what's going wrong. Since your string does only contain ASCII characters this is for sure no encoding problem.
-
Hi just a guess, but I notice for the VS Studio 2022 compilation you're using the /sdl switch which sets pointers in your classes to nullptr at start (as a debugging help) but I don't see that switch in your Qt .pro file for MSVC 2019.
Maybe if you try removing the /sdl switch (or adding it to the .pro file) the builds will behave less differently. -
@hskoglund Thanks, was definitely worth a shot! I couldn't find how to enable SDL in Qt, but in VS Studio it's easy to disable (Project's Configuration Properties- > C/C++ -> General-> SDL Checks). Unfortunately, the function call works in VS with or without the SDL Checks, so sadly it doesn't seem like that's the difference.
The same cl.exe compiler is used in VS and QT (C:\Program Files...\Hostx86\x86\MS "19.39.33521 for x86"), but I don't see which linker is used. Neither VS nor QT are using link.exe.
Looking at the API, there is no other function that takes a char*, but there is another function that returns it
GetErrorDescription(int16_t, char*);
and this function does not cause a crash.. so it's only passing the char pointer into the dll function, and only in Qt, that causes a crash. -
Ok, it was a nice try :-)
So compiler is the same but what about the app itself, is it really the same for Qt and Visual Studio? To me it looks like Visual Studio builds a console app without any calls to Qt and the Qt build is for a gui/QML flavored app.
I.e. to debug this I think you need to use the same app for both of the build environments.