[SOLVED] segfault on QLibrary::Load()

XGuy

Hi, I'm experiencing a strange behavior when i want to load a DLL in my app.
Here is the source code:

@
QLibrary lib;
lib.setFileName("D:\myDLL.dll");
if(lib.isLibrary("D:\myDLL.dll"))
{
if(lib.load()) // I receive segfault in here
{
printf("Library is loaded.\n");
}
}
@

I changed the code to this but no chance. (but this code runs successfully in Visual Studio 2010, I'm even capable of resolve function symbols and call them.)

@
HINSTANCE hdl = 0;
hdl = LoadLibraryA("D:\myDLL.dll"); // I receive segfault in here
if(!hdl)
{
printf("Error loading");
}
@

Jeroentjehome

Just the most stupid of questions, but does the library even exists in that folder??
The load function should not be needed. Use the resolve to get a pointer to the desired function. The library will be loaded if possible. If no library is found, the resolve will return NULL
Also, in Windows you do not need a '\' character in your path!

Update by SGAIST. Yes, the Unix notation like in my example ;-) <<
A simple 'D:\myDll' should be enough. The dll should be added automatic by the QLibrary if you use Win. Had problems with it myself, that it could not find the library until I added the dll extension.
This piece of code did it for me:
@
QString strDirPath(qApp->applicationDirPath());
QString strLib(strDirPath + "/Lib/PCANBasic");

// Check to open the library
m_CanLib_plib = new QLibrary(this);
m_CanLib_plib->setFileName(strLib);
m_CanLib_plib->load();

if (m_CanLib_plib->isLoaded() == true)
{
    // resolve your function pointers here!!
}

@

SGaist

Hi,

@ Jeroentje@home You need to escape the backslashes in path strings other it will try to escape the next character.

Unless it was a typo and you meant that with Qt you can use the / unix notation ? ;)

XGuy

[quote author="Jeroentje@home" date="1398839646"]Just the most stupid of questions, but does the library even exists in that folder??
[/quote]

When below code returns true, it makes us sure that the lib exists. and by the way, if lib doesn't exist it shouldn't through a segfault signal!
@ if(lib.isLibrary("D:/myDLL.dll")) @

even changing the "" to "/" also gives a segfault.

@

HINSTANCE hdl = 0;
hdl = LoadLibraryA("D:/myDLL.dll"); // I get segfault in here
if(!hdl)
{
printf("Error loading");
}

@

also using resolve gives me segfault.
@
typedef char* (__stdcall myFunc)(char, BOOL, BOOL, BOOL, BOOL, char*);
myFunc *funcHDL = NULL;
lib.setFileName("D:/myDLL.dll");
if(lib.isLibrary("D:/myDLL.dll"))
{
funcHDL = (myFunc *) lib.resolve("myFunc"); // I get segfault in here(calling resolve)
if(funcHDL != NULL)
{

}
}

@

XGuy

just bare in mind that this code works on Visual Studio 2010.

SGaist

Then the basic question, what Qt version are you using ? (Arch, Compiler etc…)

Jeroentjehome

Just a thought, but is it a 64 bits dll?? If using Qt with MinGw you have a 32 bits compiler. That might give a problem? Not really sure, just a thought.
Second thought: Is your dll library code function exported to C using the "extern C" option??
Third: How is the dll compiled, what compiler and version?

pmoglaikar

Hi,

@XGuy : I guess you will have to check basic things first as,

Is your dll library code function exported to C using the “extern C” option just ask by Jeroentje@home.

if yes then check whether you added __stdcall at function declration & defination are there or not if your using c++ compliion
e.g.

Sample.hxx

void __stdcall
myFun ( int a,
float b
);

Sample.cpp

void __stdcall
myFun ( int a,
float b
)
{
....... code
}

Thanks
Prashant

XGuy

Thanks for your help.

Environment:
Qt 5.1.0, Windows 7, Compiler: MSVC2010 32bit.

And yes It is exported to C language using extern C though I'm using __stdcall at function deceleration and definition(have a look at my code).
Actually I'm not sure what compiler was used for compiling the dll but from sample codes which came with the dll I deduced that it is exported to C language. To be more specific this dll is used in other projects which are developed by VS and this is the first time we want to use it in QT.

MuldeR

If that crashes already:
@HINSTANCE hdl = 0;
hdl = LoadLibraryA("D:\myDLL.dll"); // I receive segfault in here
if(!hdl)
{
printf("Error loading");
}@

...it's definitely not a Qt problem at all.

It also cannot be related to the function your are exporting from DLL, because it already crashed upon loading the DLL. The only thing that should have been executed up to that point is the "DllMain":http://goo.gl/3jmjRz function of your DLL. So does that function do anything in your DLL? Well, it shouldn't be doing anything, except for initializing fields etc., anyway. But you never know...

Furthermore: Make sure that both, your "main" executable and your DLL, are compiled by the same compiler version and that both use the shared C++ Runtime (/MD option)! Otherwise you can run into serious trouble, unless extreme care is taken. That's because if you use static C++ Runtime (/MT option), each module (DLL or EXE) will get it's own completely separate copy of the C++ Runtime built-in. And if you use shared C++ Runtime but different compiler versions, your modules (DLL or EXE) will make use of different C++ Runtime DLL's (msvcr?.dll). So make sure they use the same Runtime DLL.

You may wish to verify this with Dependency Walker:
http://www.dependencywalker.com/

Should be looking like this for all DLL's you use:
"!http://i.imgur.com/eJYiq8Ns.png(ScreenShot)!":http://i.imgur.com/eJYiq8N.png

_

From the MSDN:
[quote]Using the statically linked CRT implies that any state information saved by the C runtime library will be local to that instance of the CRT. For example, if you use strtok, _strtok_l, wcstok, _wcstok_l, _mbstok, _mbstok_l when using a statically linked CRT, the position of the strtok parser is unrelated to the strtok state used in code in the same process (but in a different DLL or EXE) that is linked to another instance of the static CRT. In contrast, the dynamically linked CRT shares state for all code within a process that is dynamically linked to the CRT. This concern does not apply if you use the new more secure versions of these functions; for example, strtok_s does not have this problem.

Because a DLL built by linking to a static CRT will have its own CRT state, it is not recommended to link statically to the CRT in a DLL unless the consequences of this are specifically desired and understood. For example, if you call _set_se_translator in an executable that loads the DLL linked to its own static CRT, any hardware exceptions generated by the code in the DLL will not be caught by the translator, but hardware exceptions generated by code in the main executable will be caught.[/quote]

XGuy

I got it working in release mode! I ran the program executable in another machine and it's working.
thank you all.