开发者

One of two destructors is not called during stack unwind

开发者 https://www.devze.com 2023-01-27 04:06 出处:网络
I have an application written on MS Visual C++ 2005. It had failed on client\'s computer. I cannot reproduce the fail; all I have for analysis is log created by the application. In the application I h

I have an application written on MS Visual C++ 2005. It had failed on client's computer. I cannot reproduce the fail; all I have for analysis is log created by the application. In the application I have the following fragment:

class EntranceLoggerForFunc
{
public:
EntranceLoggerForFunc()
{
    WriteToLog("EntranceLoggerForFunc");
}
~EntranceLoggerForFunc()
{
    WriteToLog("~EntranceLoggerForFunc");
}
}

void Func()
{
    EntranceLoggerForFunc logger;
    ....
    if (<some comdition>)
        Func();
    ....
}

void Func2()
{
    try
    {
        Func();
    }
    catch(...)
    {
        WriteT开发者_高级运维oLog("Exception happened");
    }
}

The application is compiled with key /EHa (Enable C++ exceptions with SEH Exceptions'.

In the log I see the following:

EntranceLoggerForFunc EntranceLoggerForFunc ~EntranceLoggerForFunc Exception happened

In other words, an exception happened somewhere inside the Func(); and had been caught in Func2(). But why ONLY ONE destructor of the two objects EntranceLoggerForFunc has been called during stack unwind?

Now I have only the following version: stack was somehow damaged (most probably by the same wrong operation that led to the exception), and this is why one of the destructors did not work.

Any other versions?


Another possibility is that WriteToLog is the method throwing the exception on it's 4th invocation.


If the exception thrown is not a C++ exception, but a Win32 SEH exception (for example, EXCEPTION_STACK_OVERFLOW or EXCEPTION_ACCESS_VIOLATION), the behavior of exception handling can become... err.. strange.

(This is why EHa is no longer the default setting in Visual Studio 2010)

My guess is that the actual exception is a SEH exception, such as an access violation, which was the result of memory corruption (and therefore the program state was hosed to begin with).

0

精彩评论

暂无评论...
验证码 换一张
取 消