0xC0000005: Access Violation with CCriticalSection
Benny Lee -- Benny_Lee@countrywide.com
Thursday, January 09, 1997
Environment: VC++ 4.2b, NT 4.0
Whenever I instantiate a CCriticalSection object, the debugger displays
"0xC00000005: Access Violation".
In AFXMTL.INL (line 37), a CCritialSection object is constructed as:
_AFXMT_INLINE CCriticalSection::CCriticalSection() : CSyncObject(NULL)
{ ::InitializeCriticalSection(&m_sect); }
In MTCORE.CPP (line 23), CSyncObject is initialized as:
CSyncObject::CSyncObject(LPCTSTR pstrName)
{
UNUSED(pstrName); // unused in release builds
m_hObject = NULL;
#ifdef _DEBUG
m_strName = pstrName;
#endif
}
It seems that "m_strName = pstrName" causes the access violation. This is not
a too big of a problem. However, it would be nice if I can get this access
violation to go away so that I would have more time tracking my own access
violation - unless of course, I am doing something wrong.
Thanks!
Benny
Mike Blaszczak -- mikeblas@nwlink.com
Saturday, January 11, 1997
At 16:29 1/9/97 EDT, Benny Lee wrote:
>Environment: VC++ 4.2b, NT 4.0
>Whenever I instantiate a CCriticalSection object, the debugger displays
>"0xC00000005: Access Violation".
[...]
>It seems that "m_strName = pstrName" causes the access violation.
Someone else reported this problem to me, but I was never able to reproduce
it. (They ended up saying that they thought a third-party library they
were using was causing the problem, but I can't understand how that would
be. And they didn't respond when I wrote back, so that's that.)
Where, exactly, does the access violation occur? Did you trace into
the implementation of CString's assignment operator? What part of
that implementation ends up throwing the exception, specifically?
What pointer is off to cause the violation?
CString should be able to handle an assignment of NULL, so if there's
a bug it really isn't in CCriticalSection's (or CSyncObject's)
constructor. If you can provide a more complete description of what's
happening, I adjust the code.
The code above should call CString::operator=(LPCTSTR), which will call
CString::AssignCopy() to actualy perform the assignment. AssignCopy()
receives the NULL pointer and the result of a call to SafeStrlen(), which
returns zero if it is passed a NULL pointer.
The CString object allocates enough memory to hold zero bytes, and then
tries to copy the source string into the CString's internal buffer.
While the code indiscriminantly calls memcpy() on the NULL pointer, the
call is benign because the length passed to memcpy() is zero.
>I am doing something wrong.
There's certainly nothing wrong with creating a CCriticalSection.
Benny Lee -- Benny_Lee@countrywide.com
Monday, January 13, 1997
Environment: VC++ 4.2b, NT 4.0
If I remembered correctly, the access violation occurs at strcore.cpp (line
250) when it attempts to perform a memcpy of length 0. It seems that the "bug"
is not a MFC bug but the implementation of memcpy.
When you said a third party software, something click in my mind. I have
bounds checker installed on my machine and wondering if that has anything to do
with it.
Thanks for your help, Mike.
Benny
Karl Krasnowsky Excell -- a-karlkr@MICROSOFT.com
Tuesday, January 14, 1997
[Mini-digest: 2 responses]
Benny,
Make sure you're net mixing debug and retail versions of the MFC library
in your project. I had a problem very similar to yours and found that I
had inadvertently included a retail built (dynamically linked) MFC dll
into my debug project (or was it the other way around?).
Hope this helps.
>----------
>From: Benny Lee[SMTP:Benny_Lee@countrywide.com]
>Sent: Monday, January 13, 1997 9:34 AM
>To: mfc-l
>Subject: Re: 0xC0000005: Access Violation with CCriticalSection
>
>Environment: VC++ 4.2b, NT 4.0
>
>If I remembered correctly, the access violation occurs at strcore.cpp (line
>250) when it attempts to perform a memcpy of length 0. It seems that the
>"bug"
>is not a MFC bug but the implementation of memcpy.
>
>When you said a third party software, something click in my mind. I have
>bounds checker installed on my machine and wondering if that has anything to
>do
>with it.
>
>Thanks for your help, Mike.
>
>Benny
>
>
-----From: Mike Blaszczak
At 13:34 1/13/97 EDT, Benny Lee wrote:
>Environment: VC++ 4.2b, NT 4.0
>If I remembered correctly, the access violation occurs at strcore.cpp (line
>250) when it attempts to perform a memcpy of length 0. It seems that the
"bug"
>is not a MFC bug but the implementation of memcpy.
It's pretty easy to see that memcpy() doesn't have any bugs, either. The
source code is on the Visual C++ CD; you can trace into it, too. You'd
see this code (after eliminating some preprocessor directives):
void * __cdecl memcpy(void * dst, const void * src, size_t count)
{
void * ret = dst;
while (count--) {
*(char *)dst = *(char *)src;
dst = (char *)dst + 1;
src = (char *)src + 1;
}
return(ret);
}
If you remember the CString code, CString::SafeStringLen() returns zero
when offered a NULL pointer. So, count is 0 here, which means the loop
never executes even once. And that means that neither the source or
the destination pointer is dereferenced.
.B ekiM
http://www.nwlink.com/~mikeblas/
Why does the "new" Corvette look like a 1993 RX-7?
These words are my own. I do not speak on behalf of Microsoft.
dgraham@xypoint.com
Saturday, January 18, 1997
Environment VC 4.2 with patch, NT 4.0
Since upgrading to NT 4.0 from Win95 I have been getting the
"0xC0000005: Access Violation" when exiting any database related app.
It did not matter if I was using ODBC or DAO. After upgrading my VC
with the patch this error has not occured.
HTH
| Вернуться в корень Архива
|