Very frustrating bug in VS2005 headers

  • Thread starter Thread starter PLS
  • Start date Start date
P

PLS

This problem is entirely in Microsoft's VS2005 C++ headers, so I'm
hoping someone has hit it before and knows the fix.

I am convertied a medium size (400k lines) C++ program over to VS2005
native C++, rewriting it's COM stuff to ATL. I have crtdbg.h in the
global include file and have _CRT_MAP_ALLOC turned on at the project
level.

I'm getting a crash at line 707 in the function
_com_ptr_t::CreateInstance in file comip.h. The crash was an assertion
failure caused by a memory allocation problem.

I finally had to look at the disassembly to see what the difficulty was.

There are two line from this function that cause the problem:
clsidStringW = static_cast<LPWSTR>(_malloca(destSize * sizeof(WCHAR)));
and
_freea(clsidStringW);

According to the disassembly, the first is converted to
clsidStringW = static_castM<LPWSTR>(_malloc_dbg(...));
and the second is compiled to
_freea(clsidStringW);
and _freea fails trying to free a memory area that wasn't allocated with
_malloca.

Here is the function after preprocessing:

HRESULT CreateInstance(LPCSTR clsidStringA, IUnknown* pOuter = 0,
DWORD dwClsContext = (CLSCTX_INPROC_SERVER| CLSCTX_INPROC_HANDLER|
CLSCTX_LOCAL_SERVER| CLSCTX_REMOTE_SERVER)) throw()
{
if (clsidStringA == 0) {
return ((HRESULT)0x80070057L);
}

int size = lstrlenA(clsidStringA) + 1;
int destSize = MultiByteToWideChar(0, 0, clsidStringA, size, 0,
0);

if (destSize == 0) {
return ((HRESULT)(GetLastError()) <= 0 ? ((HRESULT)
(GetLastError())) : ((HRESULT) (((GetLastError()) & 0x0000FFFF) | (7 <<
16) | 0x80000000)));
}

LPWSTR clsidStringW;
clsidStringW = static_cast<LPWSTR>(_malloc_dbg(destSize * sizeof
(WCHAR), 1, "c:\\program files\\microsoft visual studio 8\\vc\\include
\\comip.h", 695));

if (clsidStringW == 0) {
return ((HRESULT)0x8007000EL);
}

if (MultiByteToWideChar(0, 0, clsidStringA, size, clsidStringW,
destSize) == 0) {
_freea(clsidStringW);
return ((HRESULT)(GetLastError()) <= 0 ? ((HRESULT)
(GetLastError())) : ((HRESULT) (((GetLastError()) & 0x0000FFFF) | (7 <<
16) | 0x80000000)));
}

HRESULT hr=CreateInstance(clsidStringW, pOuter, dwClsContext);
_freea(clsidStringW);
return hr;
}




With a quick look at the crtdbg.h, I looks like _freea() should be
converted to _free_dbg, which would work fine.

Any ideas how to fix this?

It's probably useless to file a bug report on this, given that ATL is no
longer supported.

++PLS
 
PLS said:
Any ideas how to fix this?
Click to expand...

Are you using VS2005 SP1? Have you tried VS2008?
It's probably useless to file a bug report on this, given that ATL is
no longer supported.
Click to expand...

ATL is absolutely still supported. Only ATL Server has gone open source.

Aside from that, _com_ptr_t isn't part of ATL at all - it's part of the
Visual C++ support library that's used by the code generated by #import.

I'd suggest that you open a bug report on
http://connect.microsoft.com/VisualStudio/Feedback

-cd
 
Are you using VS2005 SP1? Have you tried VS2008?


ATL is absolutely still supported. Only ATL Server has gone open source.

Aside from that, _com_ptr_t isn't part of ATL at all - it's part of the
Visual C++ support library that's used by the code generated by #import.

I'd suggest that you open a bug report on
http://connect.microsoft.com/VisualStudio/Feedback

-cd
Click to expand...
I am using VS2005 SP1. I do not have 2008 to try it. I now have a very
small test project that illustrates the problem. I'll send it to anyone
who asks. Please mail me directly and Paul dot Schauble at ticketmaster
dot com.

The problem is that malloc.h #undef's the #define for _freea that crtdbh
puts into place. My test program works if malloc.h preceeds crtdbg.h,
but not vice versa.

Order dependencies in header files are best avoided. When they can't be
avoided, they really should be checked. In this case, malloc.h needs to
test _CRTDBG_MAP_ALLOC and doesn't. I will be filing a bug.

++PLS
 
Please show a snippet of _your_ code, and how you are using ATL. The problem more likely lies in the way you are calling the ATL
code, not the headers themselves.

Brian
 
PLS said:
I will be filing a bug.
Click to expand...

Please do - you can attach your minimal repro solution as a ZIP file to the
bug report. Once you've created the bug report, please post a link to it
back here so that others who find this thread can validate/vote for the bug
(both of which increase the level attention that it'll get internally)..

-cd
 
I am having the same issue !! Can any one help please ... Few times it
works .. few times it bails !!!

AnilG
 
Back
Top