469,572 Members | 1,281 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,572 developers. It's quick & easy.

CSingleLock() Assertion failure

I have some C++ code that uses the CSingleLock( CCriticalSection *)
constructor. In visual C++ 6.0, this code compiles and runs fine in both
Debug and release modes. However, in Visual Studio .Net, when I run this
code I get an Assertion failure. The error appears to be exactly the same as
that seen with CSingleLock in VC++ version 4.0. I can get around this by
using the Lock method of the CCriticalSection object but the accepted way to
do this is to use the CSingleLock object. Why do I get the Assertion failure?
Nov 17 '05 #1
5 5276
Ron Louzon wrote:
I have some C++ code that uses the CSingleLock( CCriticalSection *)
constructor. In visual C++ 6.0, this code compiles and runs fine in both
Debug and release modes. However, in Visual Studio .Net, when I run this
code I get an Assertion failure. The error appears to be exactly the same as
that seen with CSingleLock in VC++ version 4.0. I can get around this by
using the Lock method of the CCriticalSection object but the accepted way to
do this is to use the CSingleLock object. Why do I get the Assertion failure?


What's the text of the assertion?

--
Doug Harrison
Microsoft MVP - Visual C++
Nov 17 '05 #2
Doug,

Here is the assertion failure that I get:

================

Debug Assertion Failed!

Program: C:\Mydata\NetApps\Cmp\Debug\Cmp.exe
File: f:\vs70builds\3077\vc\MFCATL\ship\atlmfc\include\a fxmt.inl
Line: 81

For information on how your program can cause an assertion failure, see the
Visual C++ documentation on asserts.

=========================

"Doug Harrison [MVP]" wrote:
Ron Louzon wrote:
I have some C++ code that uses the CSingleLock( CCriticalSection *)
constructor. In visual C++ 6.0, this code compiles and runs fine in both
Debug and release modes. However, in Visual Studio .Net, when I run this
code I get an Assertion failure. The error appears to be exactly the same as
that seen with CSingleLock in VC++ version 4.0. I can get around this by
using the Lock method of the CCriticalSection object but the accepted way to
do this is to use the CSingleLock object. Why do I get the Assertion failure?


What's the text of the assertion?

--
Doug Harrison
Microsoft MVP - Visual C++

Nov 17 '05 #3
Doug,

After the assertion failure, the debugger jumps to this code and shows the
failure as being on the line

"ASSERT(!m_bAcquired);"

BOOL CSingleLock::Lock(DWORD dwTimeOut /* = INFINITE */)
{
ASSERT(m_pObject != NULL || m_hObject != NULL);
--> ASSERT(!m_bAcquired);

m_bAcquired = m_pObject->Lock(dwTimeOut);
return m_bAcquired;
}
"Doug Harrison [MVP]" wrote:
Ron Louzon wrote:
I have some C++ code that uses the CSingleLock( CCriticalSection *)
constructor. In visual C++ 6.0, this code compiles and runs fine in both
Debug and release modes. However, in Visual Studio .Net, when I run this
code I get an Assertion failure. The error appears to be exactly the same as
that seen with CSingleLock in VC++ version 4.0. I can get around this by
using the Lock method of the CCriticalSection object but the accepted way to
do this is to use the CSingleLock object. Why do I get the Assertion failure?


What's the text of the assertion?

--
Doug Harrison
Microsoft MVP - Visual C++

Nov 17 '05 #4
Ron Louzon wrote:
Doug,

Here is the assertion failure that I get:

================

Debug Assertion Failed!

Program: C:\Mydata\NetApps\Cmp\Debug\Cmp.exe
File: f:\vs70builds\3077\vc\MFCATL\ship\atlmfc\include\a fxmt.inl
Line: 81

For information on how your program can cause an assertion failure, see the
Visual C++ documentation on asserts.


It didn't give you the text of the assertion? Oh well, here's what I find in
VC7.1:

_AFXMT_INLINE BOOL CCriticalSection::Lock(DWORD dwTimeout)
{ ASSERT(dwTimeout == INFINITE); (void)dwTimeout; return Lock(); }

From this, it appears you must be trying to use a non-INFINITE timeout,
which doesn't work with CRITICAL_SECTION objects. There are a number of
similar gotchas in the MFC synchronization classes, which are the result of
trying to make CRITICAL_SECTION look to C++ like a kernel object such as the
mutex. Another example would be passing a CCriticalSection to CMultiLock,
which ASSERTs because you cannot WaitForMultipleObjects on CRITICAL_SECTION.

--
Doug Harrison
Microsoft MVP - Visual C++
Nov 17 '05 #5
Doug,

That is exactly what I am trying to do. I have a timeout specified for the
CSingleLock call. Since that is a problem, I will pull it out and use and
infinite timeout. Thanks.

"Doug Harrison [MVP]" wrote:
Ron Louzon wrote:
Doug,

Here is the assertion failure that I get:

================

Debug Assertion Failed!

Program: C:\Mydata\NetApps\Cmp\Debug\Cmp.exe
File: f:\vs70builds\3077\vc\MFCATL\ship\atlmfc\include\a fxmt.inl
Line: 81

For information on how your program can cause an assertion failure, see the
Visual C++ documentation on asserts.


It didn't give you the text of the assertion? Oh well, here's what I find in
VC7.1:

_AFXMT_INLINE BOOL CCriticalSection::Lock(DWORD dwTimeout)
{ ASSERT(dwTimeout == INFINITE); (void)dwTimeout; return Lock(); }

From this, it appears you must be trying to use a non-INFINITE timeout,
which doesn't work with CRITICAL_SECTION objects. There are a number of
similar gotchas in the MFC synchronization classes, which are the result of
trying to make CRITICAL_SECTION look to C++ like a kernel object such as the
mutex. Another example would be passing a CCriticalSection to CMultiLock,
which ASSERTs because you cannot WaitForMultipleObjects on CRITICAL_SECTION.

--
Doug Harrison
Microsoft MVP - Visual C++

Nov 17 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Todd Miller | last post: by
4 posts views Thread by Etayki | last post: by
2 posts views Thread by Craig Klementowski | last post: by
reply views Thread by scorpion06 | last post: by
1 post views Thread by =?Utf-8?B?SWxpYW4=?= | last post: by
2 posts views Thread by rsr | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.