Assert on "_mutex.RecursionCount" is failing

[marksj]

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

[bernard]

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

[marksj]

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:perator<() + 0x37c
- ice13d.dll!Ice:perator<() + 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

[bernard]

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

[marksj]

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<I ceUtil::Mutex>(const IceUtil::Mutex & mutex={...}) Line 55 C++

- ice13d.dll!IceInternal::ServantManager::removeServ ant(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++

...

[marc]

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.

[bernard]

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

[marksj]

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

[bernard]

Hi John,

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

Cheers,
Bernard

[bernard]

Please try this patch.

Bernard

[marksj]

Thanks Bernard, very much. It worked.

You guys are great!