5

我的程序在我可以重现的小场景中随机崩溃，但它发生在 ntdll.dll 的 mlock.c（这是一个 VC++ 运行时文件）中，我看不到堆栈跟踪。不过，我确实知道它发生在我的一个线程函数中。

这是程序崩溃的 mlock.c 代码：

void __cdecl _unlock (
        int locknum
        )
{
        /*
         * leave the critical section.
         */
        LeaveCriticalSection( _locktable[locknum].lock );
}

错误是“指定的句柄无效”。如果我查看 locknum，它是一个大于 _locktable 大小的数字，所以这是有道理的。

这似乎与关键部分的使用有关。我确实在我的线程中使用了 CRITICAL_SECTIONS，通过 CCriticalSection 包装类及其关联的 RAII 保护 CGuard。在这里对两者进行定义以避免更加混乱。

这是崩溃的线程函数：

unsigned int __stdcall CPlayBack::timerThread( void * pParams ) {
#ifdef _DEBUG
    DRA::CommonCpp::SetThreadName( -1, "CPlayBack::timerThread" );
#endif
    CPlayBack * pThis = static_cast<CPlayBack*>( pParams );
    bool bContinue = true;
    while( bContinue ) {
        float m_fActualFrameRate = pThis->m_fFrameRate * pThis->m_fFrameRateMultiplier;
        if( m_fActualFrameRate != 0 && pThis->m_bIsPlaying ) {
            bContinue = ( ::WaitForSingleObject( pThis->m_hEndThreadEvent, static_cast<DWORD>( 1000.0f / m_fActualFrameRate ) ) == WAIT_TIMEOUT );
            CImage img;
            if( pThis->m_bIsPlaying && pThis->nextFrame( img ) )
                pThis->sendImage( img );
        }
        else
            bContinue = ( ::WaitForSingleObject( pThis->m_hEndThreadEvent, 10 ) == WAIT_TIMEOUT );
    }
    ::GetErrorLoggerInstance()->Log( LOG_TYPE_NOTE, "CPlayBack", "timerThread", "Exiting thread" );
    return 0;
}

从哪里CCriticalSection进来？每个CImage对象都包含一个CCriticalSection通过CGuardRAII 锁使用的对象。此外，每个都CImage包含一个CSharedMemory实现引用计数的对象。为此，它还包含两个CCriticalSection，一个用于数据，一个用于引用计数器。这些交互的一个很好的例子可以在析构函数中看到：

CImage::~CImage() {
    CGuard guard(m_csData);
    if( m_pSharedMemory != NULL ) {
        m_pSharedMemory->decrementUse();
        if( !m_pSharedMemory->isBeingUsed() ){
            delete m_pSharedMemory;
            m_pSharedMemory = NULL;
        }
    }
    m_cProperties.ClearMin();
    m_cProperties.ClearMax();
    m_cProperties.ClearMode();
}

CSharedMemory::~CSharedMemory() {
    CGuard guardUse( m_cs );
    if( m_pData && m_bCanDelete ){
        delete []m_pData;
    }
    m_use = 0;
    m_pData = NULL;
}

有人遇到过这种错误吗？有什么建议吗？

编辑：我看到了一些调用堆栈：调用来自〜CSharedMemory。所以那里一定有一些竞争条件

编辑：更多 CSharedMemory 代码在这里

4

3 回答 3

5

“指定的无效句柄”返回代码清楚地表明您的临界区对象已被释放；当然，假设它一开始就被正确分配。

您的 RAII 课程似乎是罪魁祸首。如果你退后一步想一想，你的 RAII 类违反了Sepration Of Concerns原则，因为它有两个工作：

  1. 它为 CRITICAL_SECTION 提供分配/销毁语义
  2. 它为 CRITICAL_SECTION 提供获取/释放语义

我见过的大多数 CS 包装器的实现都以同样的方式违反了 SoC 原则，但这可能是有问题的。尤其是当您必须开始传递类的实例以获取获取/释放功能时。在 psudocode 中考虑一个简单的、人为的示例：

void WorkerThreadProc(CCriticalSection cs)
{
  cs.Enter();
  // MAGIC HAPPENS
  cs.Leave();
}

int main()
{
  CCriticalSection my_cs;
  std::vector<NeatStuff> stuff_used_by_multiple_threads;

  // Create 3 threads, passing the entry point "WorkerThreadProc"
  for( int i = 0; i < 3; ++i )
    CreateThread(... &WorkerThreadProc, my_cs);

  // Join the 3 threads...
  wait(); 
}

这里的问题CCriticalSection是传值，所以析构函数被调用了4次。每次调用析构函数时，都会释放 CRITICAL_SECTION。第一次工作正常，但现在它消失了。

您可以通过将引用或指针传递给临界区类来解决这个问题，但随后您会因所有权问题而混淆语义水域。如果“拥有”暴击秒的线程在其他线程之前死掉怎么办？您可以使用 a shared_ptr，但现在没有人真正“拥有”临界区，并且您已经放弃了对区域的一点控制，以便在另一个区域获得一点。

这个问题的真正“修复”是分离关注点。有一类用于分配和释放：

class CCriticalSection : public CRITICAL_SECTION
{
public:
  CCriticalSection(){ InitializeCriticalSection(this); }
  ~CCriticalSection() { DestroyCriticalSection(this); }
};

...和另一个处理锁定和解锁...

class CSLock
{
public:
  CSLock(CRITICAL_SECTION& cs) : cs_(cs) { EnterCriticalSection(&cs_); }
  ~CSLock() { LeaveCriticalSection(&cs_); }
private: 
  CRITICAL_SECTION& cs_;
};

现在，您可以传递原始指针或对单个 CCriticalSection 对象（可能是 const）的引用，并让工作线程在其上实例化自己的 CSLock。CSLock 由创建它的线程拥有，这是应该的，但 CCriticalSection 的所有权显然由某个控制线程保留；也是一件好事。

于 2011-08-19T15:47:59.333 回答
1
  • 确保关键部分对象不在#pragma包装 1 中（或任何非默认包装）。
  • 确保没有其他线程（或同一个线程）正在破坏 CS 对象。运行一些静态分析工具来检查任何缓冲区溢出问题。
  • 如果您有运行时分析工具，请运行它来查找问题。
于 2011-08-19T16:01:45.587 回答
1

我决定坚持KISS原则摇滚通宵简化事情。我想我会CSharedMemoryClass用 astd::tr1::shared_ptr<BYTE>和 a替换CCriticalSection它来保护它免受并发访问。恕我直言，两者都是现在的成员，CImage现在最好分开关注点。

这解决了奇怪的关键部分，但现在看来我有一个由 引起的内存泄漏std::tr1::shared_ptr，你可能很快就会看到我发布它......它永远不会结束！

于 2011-08-25T19:54:59.930 回答