DLL Crash

[Karbon]

When I exit my program I'm getting a crash, and OnError is reporting the error number -1073741819 on the last line of my Windows callback function.

I've seen this before and just like before I've recently added some calls to a DLL. The first time the solution was to use CallCFunction instead of CallFunction but I'm *positive* that they're stdcall functions in the DLL as I actually wrote this one. That, and I've tried CallCFunction and it didn't work

So, is there something not happening in the DLL on shutdown? It's written in Delphi and is a "plain" DLL - not ActiveX or .NET.

Can anyone make a suggestion as to what I should be looking for? The crash only happens when I exit the program *if* I've called a function in that DLL at some point. The DLL is very straight forward though I am passing some strings in I take them in Delphi as a pchar (which is supposed to be 'ok' for DLLs)..

Thanks for any suggestions - this one has be a bit stumped.

[Karbon]

To add something here - if I *don't* call CloseLibrary before I "end" it doesn't crash!

Hrm...

[Dare]

Is it possible that some condition in the app leads to the library being closed before it is used?

Just grabbing at a straw.

[Karbon]

No, that's the funny thing - the calls to the DLL all work just fine - it never crashed except when I exited, and then only if I had CloseLibrary()'d it right before.

[citystate]

my straw to grab is - could you be closing it twice?

[Karbon]

Thought about that too and not AFAIK (both calls to CloseLibrary checked with IsLibrary() before the call was made).

[jack]

my guess is that there's an invalid pointer somwhere.

[Karbon]

That's what I thought too but the only pointers are to the strings passed into the DLLs (and that's 'automatic'), and they all work so they can't be *that* invalid

Perhaps I'm holding on to something in the DLL when I try to close it.. I can't imagine what, though, because the functions are all very straight forward and return clean every time.

I'll find it eventually

[citystate]

Thought about that too and not AFAIK (both calls to CloseLibrary checked with IsLibrary() before the call was made).

you have multiple calls to CloseLibrary?
without seeing the code, it feels like this could be your problem...
can you restructure your code to only use the one CloseLibrary?

[Karbon]

No, closelibrary() only appeared once in the entire code tree - I comment it out and the problem disappears

[Dare]

So the app runs for a while, using the library successfully?

What version of PureBasic? 4.1? 3.94? 4.2a?

Sorry if this sounds silly (and in the absence of source, which I understand you probably cannot release) but:

There are no conditionals that allow an exit (resume processing) or do some sort of similar bypass between "CloseLibrary(#x)" and "End"? That is, your flow on closing down is linear and unconditional. (Just trying to eliminate the potential error being your side).

Also, are there any clean-up calls to the dll made before the close?

And also, does the DLL have the equivalent of PureBasic's DetachProcess(Instance) and DetachThread(Instance)? That is, could something there be jacking up?


Edit:

I am sure you have done this, but if not - is it possible to get the same result doing something like

Code: Select all

Procedure CallBack(..
..
EndProcedure

OpenLibrary(..
CallFunction(..
CallFunction(..
CloseLibrary(..

And see if you get the crash? Or not. Which may help determine if it is in the lib or PB or something harder to find.

[tinman]

that DLL at some point. The DLL is very straight forward though I am passing some strings in I take them in Delphi as a pchar (which is supposed to be 'ok' for DLLs)..

Does Delphi take a copy of the string pointer and use it as a native Delphi string? Then when you call close library, it cleans up it's resources, freeing the strings. Then when your app quits it tries to free strings which are already freed?

Could you give more details of the "crash"? It is an unhandled exception? What is the exception?

[srod]

I am thinking along timan's lines although I wouldn't have thought that the dll could free the strings created by PB because it will have no access to the heap created by PB. I would suspect perhaps something in the dll (perhaps a global pointer) is being made to point at one of the strings passed by PB and at some point the dll is thus attempting to free this memory.

Karbon, does the dll have an entry point function being called when the dll is being detached and does this function free any global pointers etc?

[Dare]

Well, I can't think of anything else to add to the checklist but I am thinking it is going to be something with the equivalent of DetachProcess().

Interested to hear if you got it fixed.