Question about destructors

I am facing a very strange issue: A mutex object is being owned by some thread, but the mutex object is managed through a class, and the destructor should be releasing it. That's the summary. The following is the details.

NOTE: The following code is simplified.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
class CHandle
{
public:
    virtual ~CHandle()
    {
        if (_handle)
        {
            ::CloseHandle(_handle);
            _handle = NULL;
        }
    }
};

class CWaitableHandle : public CHandle
{
public:
    virtual ~CWaitableHandle()
    { }
};

class COSMutex : public CWaitableHandle, protected CPairedCallTracker
{
public:
    virtual ~COSMutex()
    {
        //CPairedCallTracker simply provides a counter that must be balanced (must be zero in the end).
        if (Wait(0) & WaitObjectSignaled)
        {
            for (int i = 0; i < _pairedCount; i++)
            {
                ::ReleaseMutex(_handle);
            }
        }
    }
};


The question is: Is there a way any of the destructors are simply not running? Do I need to explicitly call the other class' destructors from ~COSMutex()? I would set a test project but this is tied to a BHO for Windows 7/IE8+ and it is real pain to test, plus I have my IE frozen right now with an apparent deadlock on a mutex and I don't really want to terminate this process. Since this forum has lots of C++ purists, I thought it would be possible to get an answer.

Now, I know it is highly unlikely that the destructors aren't running, but I have evidence that the freezing incident started when one IE got destroyed (destroying the BHO, but the cleanup requires the acquisition of the construction mutex), especifically stopping on the mutex wait. If I launch more IE's, they all freeze when SetSite() is called because SetSite() acquires the construction mutex as well. This construction mutex is only acquired during SetSite() or when processing the OnQuit event from IE, and all mutex acquisition is done via the COSMutex class.

So as impossible as it may seem, the construction mutex is being owned by an IE window somewhere, even though the destructor should release it.

The problem doesn't happen often, but does happen.

More information: Specifically, the instance that got destroyed was being destroyed because I initiated navigation from a website that runs under Protected Mode Off to a website that runs under Protected Mode On. Since the integrity level of a process cannot be changed, IE destroys the current window and produces a new one with the new integrity level.

I know you'll most likely tell me "set a breakpoint". I wish I could reproduce the issue at will, but the truth is that I can't. Therefore it is incredibly hard for me to debug the traditional way and I rely on log files.

Suggestions are highly appreciated.
Last edited on
Topic archived. No new replies allowed.