Call to DLL works only once

[wally_666]

I'm trying a turn a Delphi pascal program into a dll with the minimum changes to the Delphi code.

I'm using LoadLibrary() and GetProcAddress() to load the DLL explicitly (dodges the issue of making the C .lib file in Delphi).

I have minimal knowledge of Delphi, the code comes from a domain expert who seems to have come up with something potentially very useful, but he is self taught and basically only knows Delphi in a monkey see, monkey do sense.

My problem is it works exactly once when I call the exported dll entry point (which simply runs the pacal equivalent of main), my cvi process blocks until the Delphi code exits (ultimately I'd make the dll call in a seperate thread) and the remainder of my CVI code seems to work fine.  The Delphi code appears to run fine.  I get the return value from the dll call OK.  But then the problems begin 😞

If I repeat the call to the dll I get a General Protection Fault.

If I try to unload the dll after the one successful call I get a GPF on FreeLibrary(hInstLibrary).

Poking around with CVI's debugger the memory at the dll base address and the function pointer address seems the same before and after and remains "editable" in the memory view window.

I'm really stumped by what might be causing this and looking for suggestions of how to  continue with debugging.

--wally.

[GuenterMueller]

What happens if you immediately return in your DLL function (and do not execute any further code)? Can you then call the function twice without getting a GPF? Does FreeLibrary() then run without a GPF?
If this works, the problem is in the Delphi code. If not, it might be a parameter issue.
Guenter

[wally_666]

If I load and unload the DLL without calling the exported function no errors.

If I  make  the dll export function do nothing but return an integer value everything works and I can call it multible times and unload it without error.

Its pretty obvious the issue is in the Delphi code, I'm looking for clues as to what Windows thing the Delphi code might be leaking or lacking that would cause this work once and GPF next time behaviour.

I'm in the process of making a Delphi stub program to call the Delphi DLL so maybe I can get a clue from the Delphi debugger.  Not knowing much about Delphi is a slowdown here but I've found some pretty clear examples with Google.

--wally.

[Snowman 6008]

I'm unfamilliar with Delphi, is there anyway for you to bind the delphi development environment to CVI, so that you can step into the delphi code or somehow debug it when called from CVI. It sounds like the function is getting trapped possibly in some sort of an infinite while loop scenario, and cannot return.

For multithreading in CVI, check out the example finder Help » Find Examples with search keyword multithreading, its a great example once you get the delphi part of the code working. 

[wally_666]

I've been writing multithreade code in CVI since CVI 4. 

Calling the DLL from Delphi doesn't appear to run even once, I get dropped into an assembly level debugger 😞 

Not impressed with Delphi, but if I can figure this out, it'll save everyone involved a lot of rewriting!

I've found some Delphi instructions about attaching the the process while debugging the DLL,  I'm trying to make sense of it.

--wally.

[menchar]

I know this sounds stupid, but could it be calling convention issues?

Are you using stdcall from CVI?  Maybe the Delphi code isn't stdcall.

I believe one way that the various conventions differ is who is responsible for cleaning up the stack after a call.  If the client app thinks the DLL function cleaned up the stack but it didn't, it could well be that it runs the first time OK (leaving the stack dirty) then crashes the second time it's invoked.

And I think I've seen a reference somewhere to the "pascal" calling convention.

Menchar

Message Edited by menchar on 12-04-2009 12:50 PM

[wally_666]

The pascal stdcall keyword was used when declaring the DLL exports.  If the calling convention was wrong, I don't see how it could work the first time.

What is curious is the Delphi stub program I worte to call the DLL is crashing on the first call.  I'm not impressed wtih Delphi, especially its debugger.

--wally.

[menchar]

My thought was that the calling conventions sometimes aren't different "going in" to a function, but rather on the return from the function - stdcall assumes the called function pops the parameters and removes them from the stack, other conventions assume the parameters are still on the stack when the function returns and the client code clears them off the stack.   That's what made me think that it could be this if it works the first time but not the second.

Does it work with only one parameter but not with two?

Pascal calling convention is to push parameters  left to right, stdcall is right to left.

Menchar

[wally_666]

It only returns one parameter.  I get the return value correctly the first time.

--wally.

[menchar]

I guess I'm curious how you're able to call the Pascal code from CVI with the pascal calling convention, unless maybe the Pascal code was written to use the "C" 0x86 stdcall and not the "pascal" stdcall.

The Build Options dialogue in CVI seems to offer only stdcall and cdecl,  and neither of these is the Pascal calling convention.

It would seem to me to be problematic to call any Pascal code using the "Pascal stdcall" from CVI, whether the code was in a DLL or not.

And when you say the function returns one parameter, are you referring to the fuction's return value or are you de-referencing a pointer passed as a parameter?

My apologies if I don't understand your scenario and am just clouding the issue.

Menchar

Message Edited by menchar on 12-04-2009 04:43 PM

Message Edited by menchar on 12-04-2009 04:45 PM