Unexpected "Invalid Memory Access"

[Andrzej_S_]

Hello,

Intel Inspector 2015 working at Windows 7 64 bits points me a memory issue "Invalid memory access" that is a kind of strange and may be false positive, but I am not sure and I am looking for someone that could acknowledge it (or negate it:).

The problem touches my COM server ComMemoryIssues, that has a class memoryIssueClass, that provides API method called Multiply - when I call Multiply method, it calls another function called doSth with following body:

BOOL doSth(const wchar_t* filePath)
{
	HRESULT hr;
	CComPtr<ITypeLib> pTypeLib;
	hr = LoadTypeLib(filePath, &pTypeLib);
 
	CComBSTR bstrLibName;
	hr = pTypeLib->GetDocumentation( -1, &bstrLibName, NULL, NULL, NULL );

	return S_OK;
}

and during Locate Memory Problems with Debugger enabled, I get 'Invalid Memory Access' issue with following stack:

My last visible code is at the ComMemoryIssues.dll!~CComPtrBase<struct ITypeLib> - atlcomcli.h:162 at the:

159     ~CComPtrBase() throw()
160     {
161         if (p)
162             p->Release();
163     }

On the other hand, when I ran this code in the Debug mode with a Debugger turn on, there is no problem. Additionally if I change a little bit the code, to make the function looks as following:

BOOL doSth(const wchar_t* filePath)
{
	HRESULT hr;
	ITypeLib* rawTypeLib;
	hr = LoadTypeLib(filePath, &rawTypeLib);
	long ref_count = rawTypeLib->AddRef();
 
	pTypeLib.Attach(rawTypeLib);
 
	CComBSTR bstrLibName;
	hr = pTypeLib->GetDocumentation( -1, &bstrLibName, NULL, NULL, NULL );
 
	return S_OK;
}

Than everything works perfectly, no issues. Can anyone tell me if this is actual problem with oleaut32.dll or Intel Inspector is not able to handle some weird COM caching mechanisms?

I attach the ComMemoryIssues VS2010 project with problematic COM server and TestComMemoryIssues VS2010 project, that calls ComMemoryIsses classes and triggers the problem seen above. If you want to reproduce it locally, please don't forget to register the server using regsvr32 - issue is reproducible both at 32 and 64 bits.

Keep well,
Andrzej

[Peter_W_Intel]

It is hard to say that this is the bug of inspector...I experienced similar issues, which reported invalid memory access in MS Dlls. So, my opinion is to focus on user code only, like to do:

>inspxe-cl -collect mi2 -module-filter-mode=include -module-filter=TestCOMMemoryIssues.exe -- TestCOMMemoryIssues.exe

Filter issues from 3rd-party libraries, since I don't know if it is the issue for not. 

[Andrzej_S_]

Hi Peter,

thanks for answer, but I am a little bit against such a total filtering out the issues, as it may happen, that we are just wrongly using the library and ends up with some significant memory issues or some undefined behaviour. Is there are any systematic approach for such situations? some special options to use, except just filtering out the problematic modules?

In general, is there also any information about the areas Intel Inspector is having difficulties to find memory issues or reports false positives?

Keep well,

Andrzej

[Peter_W_Intel]

Hi Andrzej,

I realize that you want to test code in COM, and have no interest of profiling TestComMemoryIssues.exe. Yes. I can reproduce this on my side, it reported invalid memory access at "p->Release()" line 162 of atlcomcli.h, which was called in user code doSth().

I talked with developer about COM/ATL support. It seems if tester directly calls functions in COM, it should work, and cross process call or remote call are not supported, since Inspector only supports single process, and target process should be launched by Inspector (do not support of profiling a running process).

COM/ATL APIs should be instrumented, I have escalated this with your test case to developer. Will get back to you soon.

Thanks, Peter

[Andrzej_S_]

Hi,

ok, I am waiting for your response!

Keep well,

Andrzej

[Peter_W_Intel]

I was told that this problem has been fixed completely in new VTune(TM) Amplifier XE 2016 Update 1, which is ready today:-)