Home Bug Reports

Assert on "_mutex.RecursionCount" is failing

marksjmarksj Member John MarksOrganization: HPProject: RGS Software
We just upgraded to ICE V1.3.0 and are seeing the asserts in IceUtil::Mutex::lock() and IceUtil::Mutex::unlock() failing in our debug builds. The assert that fails is "assert(_mutex.RecursionCount == 1)". If we link against ICE V1.1.0, we don't see the error.

Our Release build works just fine (since the asserts are not executed). We are using recursive mutex throughout our code. But the crash seems to occur in ICE private routines (such as _adapter->remove(...)), which use regular non-recursive mutex.

This occurs on Windows XP using ICE 1.3.0.

Thanks

Comments

  • bernardbernard Jupiter, FLAdministrators, ZeroC Staff Bernard NormierOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi John,

    This assert suggests that your application is using an Ice::Mutex as a recursive mutex ... this works on Windows (as Critical sections are recursive), but would not be portable to POSIX platforms.

    Of course, a small test case that shows this problem would be the best. If it's not practical, could you post a full stack trace of one of these asserts?

    Thanks,
    Bernard
  • marksjmarksj Member John MarksOrganization: HPProject: RGS Software
    Hi Bernard,

    I've checked our source code, and we never use IceUtil::Mutex, but rather IceUtil::RecMutex. As far as I can tell, we always use recursive mutex.

    So, here is the stack trace. It is stopping in the system assert caused by the assert mentioned previously in IceUtil/Mutex.h. Here is the call stack:

    - msvcr71d.dll!_assert(const char * expr=0x10119630, const char * filename=0x1011964c, unsigned int lineno=140) Line 306 C
    - ice13d.dll!IceUtil::Monitor<IceUtil::Mutex>::lock() + 0x92
    - ice13d.dll!IceInternal::decRef() + 0xa220
    - ice13d.dll!Ice::operator<() + 0x37c
    - ice13d.dll!Ice::operator<() + 0x5aba
    - rwsender.exe!Sender::SenderImpl::~SenderImpl() Line 83 C++
    - rwsender.exe!Sender::SenderImpl::`vbase destructor'() + 0xf C++
    ...

    The Sender::SenderImpl::~SenderImpl() contains
    {
    IceUtil::RecMutex::Lock siLock(*this);
    _adapter->remove(_sdiId);
    }

    The SenderImp class inherits from IceUtil::RecMutex, so when we lock our routines, we just use *this, as shown in the destructor.

    So, as mentioned before, if I use the 1.1.0 ICE libraries, all is well. The only real IceUtil::Mutex variables that I can find are those used within the Ice code - as shown above in ice13d.d used in the Monitor.

    Any more ideas?

    Thanks,
    John
  • bernardbernard Jupiter, FLAdministrators, ZeroC Staff Bernard NormierOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi John,

    From this stack trace it appears to be another mutex, used in a IceUtil::Monitor.

    I don't know why there is no line numbers for the ice13d.dll; did you remove the corresponding ice13d.pdb file?

    Cheers,
    Bernard
  • marksjmarksj Member John MarksOrganization: HPProject: RGS Software
    Hi Bernard, here is the stack tracing using the pdbs:

    - msvcr71d.dll!_NMSG_WRITE(int rterrnum=10) Line 195 C

    - msvcr71d.dll!abort() Line 44 + 0x7 C

    - msvcr71d.dll!_assert(const char * expr=0x10119630, const char * filename=0x1011964c, unsigned int lineno=140) Line 306 C

    - ice13d.dll!IceUtil::Mutex::lock() Line 140 + 0x20 C++

    - ice13d.dll!IceUtil::LockT<IceUtil::Mutex>::LockT<IceUtil::Mutex>(const IceUtil::Mutex & mutex={...}) Line 55 C++

    - ice13d.dll!IceInternal::ServantManager::removeServant(const Ice::Identity & ident={...}) Line 50 + 0x2d C++

    - ice13d.dll!Ice::ObjectAdapterI::remove(const Ice::Identity & ident={...}) Line 319 C++

    - rwsender.exe!Sender::SenderImpl::~SenderImpl() Line 83 C++

    - rwsender.exe!Sender::SenderImpl::`vbase destructor'() + 0xf C++

    - rwsender.exe!Sender::SenderImpl::`scalar deleting destructor'() + 0xf C++

    ...
  • marcmarc FloridaAdministrators, ZeroC Staff Marc LaukienOrganization: ZeroC, Inc.Project: The Internet Communications Engine ZeroC Staff
    This looks to me like a memory management problem. Do you perhaps use regular pointers for servants, or perhaps even allocate a servant on the stack? Or do you call delete on any reference-counted object?

    I'm afraid without a self-contained example that demonstrates the problem, it will be difficult to find out what's going wrong.
  • bernardbernard Jupiter, FLAdministrators, ZeroC Staff Bernard NormierOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi John,

    I suspect it's a bug in Ice: this internal mutex is locked earlier in the ... part of the call trace, maybe by the removal of another object. It will be fixed in Ice 1.4.0, to be released in a few days.

    Cheers,
    Bernard
  • marksjmarksj Member John MarksOrganization: HPProject: RGS Software
    Bernard, thanks for helping me with this problem. We just recently upgraded to ICE 1.3 on all of our supported platforms - not a trivial task. Other than this small problem that we see, ICE seems to be pretty solid. Would you recommend that we ship with ICE 1.3, or is it best to upgrade to V 1.4?

    Thanks again
  • bernardbernard Jupiter, FLAdministrators, ZeroC Staff Bernard NormierOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi John,

    I'll post a binary-compatible patch for 1.3.0 later today to address this issue.

    Cheers,
    Bernard
  • bernardbernard Jupiter, FLAdministrators, ZeroC Staff Bernard NormierOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Please try this patch.

    Bernard
  • marksjmarksj Member John MarksOrganization: HPProject: RGS Software
    Thanks Bernard, very much. It worked.

    You guys are great!
Sign In or Register to comment.