TRACEBACKQQ question

[rahzan]

Is there any reason why (after an exception has occured) a call to TRACEBACKQQ within a DLL can cause the DLL to stay stuck in the memory.

I know that it is stuck in memory because it is not possible to copy over the DLL with the corrected version while the caller app is still open eventhough the caller app has unloaded all "unused libraries". Also that if an exception does not occur (and TRACEBACKQQ is not called), this is not a problem.

I also know it is the TRACEBACKQQ call because not calling it in the exception handler allows overwriting the dll while the caller app is still open.

Tim

[Steven_L_Intel1]

I asked the TRACEBACKQQ expert and he says he doesn't know why this should be. TRACEBACKQQ loads imagehlp.dll and unloads it before it returns.

What happens if you call TRACEBACKQQ directly from non-exception code?

Steve

[rahzan]

Good idea, I should have thought of it....

The result is the SAME. just calling the TRACEBACKQQ without an exeception still hangs the DLL in memory.

In case it helps here is the arrangement:

VBA calls a CVF com-server (inprocess) which in turn calls the DLL with suspect code in it (provided by 3rd/4th parties). Until I close the VBA app the user is NOT able to overwrite the DLL. This is NOT a problem with or without an exception as long as TRACEBACKQQ is not called.

TSH

[Steven_L_Intel1]

A stumper, to be sure...

Try this experiment. Replace the call to TRACEBACKQQ with a call to LoadLibrary and Free Library of IMAGEHELP.DLL. What happens?

Steve

[rahzan]

I REPLACED the call to TRACEBACKQQ with
hndl=loadlibrary('IMAGEHELP.DLL'C)
res=freelibrary(hndl)

i) The DLL is rewritable, i.e. not "stuck in memory"
ii) the handle returned by loadlibrary is 0! and free library returns false.


I also tried:

call TRACEBACKQQ(...) ! w/no execption
hndl=GetModuleHandle('IMAGEHELP.DLL'C)
res=freelibrary(hndl)

i) the DLL IS "stuck in memory": non rewritable.
ii) hndl on 'IMAGEHELP.DLL'C is still ZERO.

Further hints will be appreciated.

tim

[Steven_L_Intel1]

Are you linked against DFORRT.DLL or DFORMD.DLL? I'm guessing that some DLL reference count is not going to zero, but I think I've exhausted my ideas. Someone who knows more about COM and Windows might be able to help.

Steve

[rahzan]

I use:
df.exe /check:bounds /arch:host /threads /warn:all /traceback /dll /link wrapper.obj

Which methinks means use Multithreaded DLL.

I did so because I thought the c-wrapper will probably spawn in a different thread.

Did I forget to mention the c wrapper? it is joined in by linking in its obj file.

Could it be that I need more switches other than
/link wrapper.obj
to link the cwrapper against the correct libraries ?

Though, I've checked that if no exception is made cwrapper is not called but the problem persists.

Tim

[Steven_L_Intel1]

Yes, you're getting DFORMD.DLL there, which is fine as far as Fortran goes. What C libraries are you using? It would be interesting to specify /libs:static for the Fortran piece and /MT for the C piece and see what changes.

You have a lot going on here which complicates the environment.

Steve

[rahzan]

The full DLL is made via command line which I have listed, but the c wrapper is pre-compiled into an obj.

The project settings under the c tab is "Multithreaded DLL" (/MD) which is why I thought the cvf dll should match. (also that for some reason there is no "singlethread DLL" option available for c).

Assuming that /MD is applied to cwrapper.obj, then are you suggesting that I simply take out /threads/dll and add /libs:static to the commands line I showed?

Also did you mean to say /MD instead of /MT for c?

[Steven_L_Intel1]

If your C code is compiled /MD, then leave the Fortran as it is.

Steve

[gfthomas8]

> Though, I've checked that if no exception is made
> cwrapper is not called but the problem persists.
>

1. How do you know that the cwrapper isn't called?
2. Isn't TRACEBACK called because the cwrapper goes looking for a handler? If, as you claim, the cwrapper is never called then neither is TRACEBACK so this is not the source of the DLL 'getting stuck in memory.'
3. Why not post your exception handler.
4. Give the DLL an explicit DllMain in Fortran or C and use it to keep tabs on the life and times of the DLL by issuing messages to a console window.

The usual response to an exception is the graceful termination of the app whereupon Windows will unload the DLL although you can assist via FreeLibrary. Any other response will likely hang your app.

Ciao,
Gerry T.