• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 714
  • Last Modified:

Exception Handling doesn't work in Release with Memory Access Violation in DLL

Hi!

I have an application where I create an object and give it to a DLL, the DLL deletes the object.
When I want to work with the object in the application, this causes a Memory Access Violation,
because the object was deleted in the DLL.

Everything's fine...
BUT:

There'S a try-catch block around this, which doesn't work in the Release-Version.
The application just exits.  

When started under a debugger it works in Release and Debug version.
When I try to reuse the object in the DLL after it has been deleted, the Exceptin Handling works.
When I try to reuse memory which has been deleted in my application the Exception Handling works.

Used Environment: Microsoft Visual Studio 2003

Thanks for any hint!

// APPLICATION
 
try
{
   MyObject* pObj = new MyObject();
   pDllObject->AddObject(pObj);
 
   pObj->Clone();
}
catch (...)
{
   AfxMessageBox(_T("got you!"));
}
   
 
 
// DLL
 
class MyObject
{
// ...
 
   void AddObject (MyObject* pObj) {
      delete pObj;
   }
// ...
}

Open in new window

0
humergu
Asked:
humergu
2 Solutions
 
ZoppoCommented:
Hi humergu,

does it work in DEBUG-build even if you start it from outside the IDE/Debugger?

If so maybe you use different compile-switch for exception handling in DEBUG and RELEASE build. Check if they are identical (i.e. /EHa)

ZOPPO
0
 
humerguAuthor Commented:
Hi Zoppo,
Yes it works in the DEBUG-Build, if started outside Debugger...

The flag is the same for all configurations.
Enable C++ Exception: Yes (/EHsc)
0
 
alexcohnCommented:
You need "structured exceptions" too, therefore use /EHa. See http://accu.org/index.php/journals/245 for detailed discussion (if you are interested in the underlying details).
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
humerguAuthor Commented:
I haven't had time to read the article yet,
but why does it work for debug and for release only if started under a debugger
if the flag is the same?
0
 
jkrCommented:
The problem you are facing here is that

   pObj->Clone();

after

      delete pObj;

causes a SEH exception, not a C++ exception. When you provide a translator function using '_set_se_translator()' (http://msdn.microsoft.com/en-us/library/5z4bw5h5(VS.80).aspx), you should bet that to work, e.g.


// compile with: /EHa
#include <windows.h>
#include <eh.h>
 
void SEFunc();
void trans_func( unsigned int, EXCEPTION_POINTERS* );
 
class SE_Exception
{
private:
    unsigned int nSE;
public:
    SE_Exception() {}
    SE_Exception( unsigned int n ) : nSE( n ) {}
    ~SE_Exception() {}
    unsigned int getSeNumber() { return nSE; }
};
 
void trans_func( unsigned int u, EXCEPTION_POINTERS* pExp )
{
       throw SE_Exception(u);
}
 
//...
 
// APPLICATION
 
_set_se_translator( trans_func );
 
try
{
   MyObject* pObj = new MyObject();
   pDllObject->AddObject(pObj);
 
   pObj->Clone();
}
catch (...)
{
   AfxMessageBox(_T("got you!"));
}

Open in new window

0
 
itsmeandnobodyelseCommented:
>>>> pObj->Clone();

that statement must not necessarily throw an exception at all. In Release mode the memory allocated by pObj was freed but not cleared (that is the difference to starting it with the debugger). So, if the memory wasn't reused by some other part of the process, the data are still available for the Clone. In Debug mode, the Debugger would set all members of the MyObject class object pointed to by pObj to some special values - strings to char(255) what appears as a y with 2 dots above or pointers to something like dcdcdcdc. That way the chance to die after using an already deleted object is 99% or more if running in the debugger. In Release mode you explicitly should set all pointers to NULL and members to empty values after delete and in the destructor (though that might not help for the case above).

A further remark. If you always delete pointers in the same context as they were created, you won't have that issue. Never delete a pointer created in one executable in a second executable. Especially if dealing with static members, it is a sure way to crash.
0
 
humerguAuthor Commented:
thanks for the fast help!
i will review it next week and then give you the points...

a last question:

without EHa catch(...) also catches SEH Exceptions with pre-Visual C++ 2005 compilers!!
we use visual c++ 2003.

but the SEH Exception should be caught by the UnhandledExceptionFilter.
we have such a filter set with SetUnhandledExceptionFilter, but this filter didn't work!!

can somebody explain that?
0

Featured Post

Hire Technology Freelancers with Gigs

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now