Attention : Marco Cantu and/or Team B members
Attention : Marco Cantu and/or Team B members
We are on a subscription for Delphi Enterprise and I have just moved from Berlin 1 to Berlin 2 in that subscription and as we have quite a number of projects on the go I have been ensuring they recompile under Berlin 2 and I believe I have found a show stopper and wondered if anyone else had found it:
One of our projects uses LoadLibrary() and it worked fine under Berlin 1 and magically without ANY code changes I have loaded up the same project in Berlin 2 and it has stopped working at the point of the LoadLibrary and to make matters worse I can't seem to narrow down where the AV is occurring but I seem to end up in system.pas
The code is all held in a single Delphi unit called uexImports
At the end of the unit is:
initialization
dllHandle := LoadLibrary( DLL );
finalization
FreeLibrary( dllHandle );
dllHandle is a cardinal and DLL is declared as:
const
DLL = 'Imports.dll';
Executable and DLL reside in the same folder
Like I said earlier : THIS WORKED in BERLIN 1 !! So what has changed ?? Has anyone come across this one ??
We are on a subscription for Delphi Enterprise and I have just moved from Berlin 1 to Berlin 2 in that subscription and as we have quite a number of projects on the go I have been ensuring they recompile under Berlin 2 and I believe I have found a show stopper and wondered if anyone else had found it:
One of our projects uses LoadLibrary() and it worked fine under Berlin 1 and magically without ANY code changes I have loaded up the same project in Berlin 2 and it has stopped working at the point of the LoadLibrary and to make matters worse I can't seem to narrow down where the AV is occurring but I seem to end up in system.pas
The code is all held in a single Delphi unit called uexImports
At the end of the unit is:
initialization
dllHandle := LoadLibrary( DLL );
finalization
FreeLibrary( dllHandle );
dllHandle is a cardinal and DLL is declared as:
const
DLL = 'Imports.dll';
Executable and DLL reside in the same folder
Like I said earlier : THIS WORKED in BERLIN 1 !! So what has changed ?? Has anyone come across this one ??
ProTip: whenever you install an update make a backup of the Delphi source folder so you can run a diff after you installed the update.
ReplyDeleteStefan Glienke Which is fine! but we have not modified anything in the VCL or any other part of the Delphi library files; certainly NOT system.pas. A dif would show us what has changed for sure, but what would I do with that information if I was not the person who had made changes ? Also, maybe is naive of me, but I wouldn't expect the LoadLibrary() function to have broken between versions !
ReplyDeleteI don't know of any error with LoadLibrary at all - that would break any number of things.
ReplyDeleteWhat is the exact error - an AV when calling LoadLibrary? You mention an AV and "doesn't work" but I'm not sure what exactly it's doing.
David Millington Yeah neither Am I;
ReplyDeleteand stupidly I told it to ignore this exception whilst I was debugging as it was going nuts and throwing up AV's all over and now I can't seem to "un-ignore" it. I have looked in the Delphi options and can't find this exception
If you call LoadLibrary() in Initialization, isn't it better to use static loading? You need the dll anyway so why use LoadLibrary() manually? http://docwiki.embarcadero.com/RADStudio/Berlin/en/Libraries_and_Packages_(Delphi) Next to check (regarding your problem) is if you use the dllHandle (or function from it) somewhere else in your other units in their Initialization sections. Maybe the run order (optimization) has changed in the compiler. Where are you doing the GetProcAddress() lines?
ReplyDeleteTony Danby Do you get the same error if you lazy load the DLL after the app is running?
ReplyDeleteTony Danby Look in Tools > Options > Debugger Options (at the bottom) > Embarcadero Debuggers and then both suboptions for different types of exceptions.
ReplyDeleteTony Danby One of your questions was "what has changed" and I gave you a hint how to find that out yourself.
ReplyDeleteApart from that with the information you provided we can only poke around in the darkness. Make sure you recompile all related binaries - make sure they are not compiled against runtime packages of different versions. Learn to use tools such as madExcept and EurekaLog to provide more detailed descriptions than just "an AV occurs somewhere in System.pas" - this is not much more helpful tbh than "it does not work".
For someone eager to help it is really frustrating to see that error descriptions and problem analysis skills are often so poor - and that from developers that should know better. Capslock and multiple question marks are not improving anything :)
Does the DLL load other DLLs? Can those be found in the actual search path? Make sure that the update didn't garble your PATH variable.
ReplyDeleteJust covering the simple stuff, but since you didn't mention what bit-ness your application is, and since Cardinal is always 32 bits (http://docwiki.embarcadero.com/RADStudio/Berlin/en/Delphi_Data_Types), if you are compiling for 64 bit, then you are missing half the space required for your dllHandle. I would recommend to use the type HMODULE for dllHandle, as it will be correct for the bit-ness you use.
ReplyDeleteJust to show you what I am saying:
In System.pas: HMODULE is an alias for HINST, which is an alias for THandle which is an alias for NativeUInt, which is either 64 or 32 bit.
Cardinal is only 32 bit.
So, if your application is 64 bit and your DLL is getting loaded above the 32 bit threshold, then all sorts of issues will occur.
Food for thought - ignore if you application is 32 bit. :D