Is there a way to forcefully return a call made in a dll?

Question

I have to use a library without source which also does not handle exceptions. Whenever an exception occurs inside it, effectively many of the destructors included never return. In the app, I have included a flag in the exception handlers to detect the erroneous state of the DLL.

I need something so that my program doesn't get stuck in the DLL at destruction while trying to destroy the objects contained as the destructors never return nor throw exceptions.

OR

Should I leave out the destruction when such scenario arises and hope for the OS to cleanup the zombies?

It sounds like you only have your second option at your disposal. — 500 - Internal Server Error, Jan 29 '14 at 14:26
Perhaps the real problem is in your code. Nothing you discuss here sounds like it will result in a good end product. — David Heffernan, Jan 29 '14 at 15:29
@DavidHeffernan the same DLL has worked 184 out of 200 times in same conditions, I am really at a loss in figuring out the problem. Its still an alpha build, with a beta still months away, I need an intermittent problem hider of sorts so I can ignore this till it gets to the top echelon of our bugs to be fixed priority queue or we buy the source of the dll. — Umair Ahmed, Jan 29 '14 at 15:51
Could easily be problems in your code. The fact that the error is intermittent proves nothing. — David Heffernan, Jan 29 '14 at 15:54
What is a little odd about your question is that you say that you have no source for the DLL, and then you talk about it raising exceptions, and the code that executes in its destructors. How can you know any of that? — David Heffernan, Jan 29 '14 at 16:47
you might make a special program, that would only work with dll and communicate with your main app using CromisIPC. Then if your worker app wit hDLL fails - it can be restarted by the main app, which itself would not be crashed — Arioch 'The, Jan 29 '14 at 17:01
@DavidHeffernan I don't know what happens in the dll, I am just making conjectures. I have placed try excepts around all the exported methods which catch the exception inside the dll with a call stack having addresses and assembler output as location. The destructors never return. — Umair Ahmed, Jan 30 '14 at 10:24

score 0 · Answer 1 · answered Jan 29 '14 at 17:06

Both options are possible.

1- try do destroy the objects
If you want to speculatively call a routine inside the DLL you'll have to put it inside a separate thread. put the mean thread to sleep and if the call does not return within the stated time assume that it hung.

2- just end the program
Windows will clear up all memory and GDI objects that a program used when it is terminated.
If you have open files where data has not been flushed out, lose data there, so depending on the nature of the application this may be a bad idea.

Here's how to do the cleanup in a separate thread:

interface

....

TCleanUpThread = class(TThread)
  procedure Execute; override;
end;

implementation

procedure TCleanUpThread.Execute;
var
  Status: integer;
begin
  Status:= FirstDllCleanUp;
  LogProgress('first cleanup is done, statuscode: '+IntToStr(Status));
  Status:= SecondDllCleanUp;
  LogProgress('Second cleanup is done, statuscode: '+IntToStr(Status));
  ....
end;

procedure TForm1.TryCleanup;
const
  StartNow = false;
var
  CleanUpThread: TCleanUpThread;
begin
  CleanUpThread:= TCleanUpThread.Create(StartNow);
  Sleep(1000); // wait a while to see if clean exit occurs
  if not(CleanUpThread.Terminated) then begin
    //Take measures if needed, depending on the logged data.
  end;
end; //Continue with the shutdown from here.

Warning
Note that you cannot call synchronize or your thread will not run in parallel anymore. Also note that you cannot more thread unsafe calls in your code. All of GDI and all user interface stuff is out, those need to be handled in the main thread (i.e. the program itself).

Is there a way to forcefully return a call made in a dll?

1 Answers1