Member Avatar for disc

Hi all,
This is my problem:

void StartRun( void )
{
    std::auto_ptr<Validate> val ( new Validate( "input.txt" ) );
    val->DoIt( );
}
// Destructor
Validate::~WValidate( )
{
  if( mFileIn.is_open())
  {
    mFileIn.close();
  }
  if( mFileOut.is_open() )
  {
    mFileOut.flush();
    mFileOut.close();
  }
}

The function DoIt() makes use of a DLL. Now heres the problem:
When there is an exception thrown by the DLL, I should say the
mFileOut should always be closed but it doesn't. I can't delete
the outputfile until I close my application because it says the
file is still open.
It only closes in the 'Debug Build' but not in the 'Release Build'.
Anyone has an idea ??
I use the Borland Developer Studio 2006.

  • 4 Contributors
  • 4 Replies
  • 101 Views
  • 10 Hours Discussion Span
  • Latest Post Latest Post by WaltP

Dani AI

Generated

A few focused diagnostics and fixes that go beyond generic "add a try/catch" suggestions from and the crash hypothesis from .

Practical next steps

  • Run the Release build under a debugger (or create a tiny wrapper process) so the DLL crash is caught and you can see whether unwinding happens. If the DLL uses SEH or an incompatible exception model, consider isolating it in a separate process and use IPC, so the main process can always clean up files.
  • Check that EXE and DLL use compatible runtime/exception settings (same compiler/RTL and EH model). If exceptions are propagated across module boundaries, both sides must agree or behavior is undefined.
  • Ask the vendor what kind of errors their DLL raises and whether it holds file handles open on error.

One more note: the posted destructor signature looks inconsistent with the class name (check for a typo). That kind of mismatch can hide problems in real code.

Recommended Answers

All 4 Replies

Member Avatar for ithelp

Can you not catch all exceptions from DoIt ?

Member Avatar for Ancient Dragon

My guess is that your program is crashing sooooo bad that the destructor is not getting called, the program is just dumping back to the os without doing any cleanup. You really need to find out what is causing the exception and fix it. Lacking that you should implement exceptions (try/catch blocks) as ithelp suggested.

Member Avatar for disc

My guess is that your program is crashing sooooo bad that the destructor is not getting called, the program is just dumping back to the os without doing any cleanup. You really need to find out what is causing the exception and fix it. Lacking that you should implement exceptions (try/catch blocks) as ithelp suggested.

The try/catch block is already implemented in the DoIt function but that's not the solution because the exception is caused by a third party DLL.
It's still a fact that in the 'Debug Build' the destructor is called, and the file can be deleted, but in the 'Release Build' it isn't.
So suggestions are still welcome....

Member Avatar for WaltP

The try/catch block is already implemented in the DoIt function but that's not the solution because the exception is caused by a third party DLL.

Talk to the third party. They have a better chance of figuring out what's going wrong.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.