Invalid Address specified to RtlValidateHeap in openDev

[qwda]

I've created a wrapper class to contain a worker thread to fire up and stream images to my main application.

Compiling in Debug or Release there's a Microsoft ASSERT kicking in! Looks quite low level and beyond my limited knowledge.

My offending block of code:



if ( aok )
{
DEBUGCOMMENT("DA::DAFWCam::_threadCamWork: Grabber Open: open the first device listed.\n");
aok = pGrabber->openDev( pVidCapDevList->at( 0 ) );
if ( !aok ) strcpy(szErrMsg, "openDev failed.");
}


And what I get in DEBUG Output:



.\DAFWCam.cpp(175) : DA::DAFWCam::_threadCamWork: Grabber Open: open the first device listed.
DShowLib Function : enter Grabber::openDev
Opening device : 1394 Desktop Video Camera
CSourceFilterType : rebind called for 1394 Desktop Video Camera
Building new graph
'MotorolaV3Interactive_Debug.exe': Loaded 'C:\WINDOWS\system32\xpsp2res.dll', No symbols loaded.
First-chance exception at 0x7c81eb33 in MotorolaV3Interactive_Debug.exe: Microsoft C++ exception: DShowLib::CDShowError @ 0x0ae5ece0.
c:\ic 1.5\core\tisudshl\grabberpimpl.cpp(656) : Could not add CLSID_YUVTransform to the filter cache, due to Error = Filter could not be built from CLSID.
CLSID="{4CB4FBB2-1342-48FE-8129-5A7C4706D60C}" pName="YUVTransform" pInstanceName="IAT YUV"

In file : ".\DShowFilter.cpp" at line : 47

.
New graph built
Error value set : No value for this setting is currently available
DShowLib Function : enter Grabber::getAvailableVideoFormats()
DShowLib Function : returns successful Grabber::getAvailableVideoFormats()
CurSink was not yet applied. This may be either, because no valid VideoFormat or MemBufferCollection is set, after you have done that, the sink will be applied.
CurSink was not yet applied. This may be either, because no valid VideoFormat or MemBufferCollection is set, after you have done that, the sink will be applied.
DShowLib Function : returns successful Grabber::openDev
HEAP[MotorolaV3Interactive_Debug.exe]: Invalid Address specified to RtlValidateHeap( 00C50000, 00C4AC10 )
Unhandled exception at 0x7c901230 in MotorolaV3Interactive_Debug.exe: User breakpoint.


and f.y.i.:



bool aok = true;
Grabber* pGrabber = NULL;
char szErrMsg[2048];
Grabber::tVidCapDevListPtr pVidCapDevList = NULL;


Grabber has created okay and returned a list of devices as expected.

Any ideas?

Thanks,
Q

[qwda]

Okay, back in the morning (fresh new day, etc..!)... anyway... it appears the assert is not failing in the openDev itself. Added some extra debug lines:



if ( aok )
{
DEBUGCOMMENT("DA::DAFWCam::_threadCamWork: Grabber Open: open the first device listed.\n");
aok = pGrabber->openDev( pVidCapDevList->at( 0 ) );
DEBUGCOMMENT("DA::DAFWCam::_threadCamWork: Post openDev Point A.\n");
if ( !aok ) strcpy(szErrMsg, "openDev failed.");
DEBUGCOMMENT("DA::DAFWCam::_threadCamWork: Post openDev Point B.\n");
}

DEBUGCOMMENT("DA::DAFWCam::_threadCamWork: Post openDev Point C.\n");

// we're now done with the list of devices
pVidCapDevList = NULL;

DEBUGCOMMENT("DA::DAFWCam::_threadCamWork: Post openDev Point D.\n");

pVidFmtList = NULL;

DEBUGCOMMENT("DA::DAFWCam::_threadCamWork: Post openDev Point E.\n");

if ( aok )
{
DEBUGCOMMENT("DA::DAFWCam::_threadCamWork: Grabber Open: enumerate the formats available.\n");
pVidFmtList = pGrabber->getAvailableVideoFormats();
aok = ( pVidFmtList != NULL );
if ( !aok ) strcpy(szErrMsg, "getAvailableVideoFormats failed.");
}


and the new Debug output:



...
CurSink was not yet applied. This may be either, because no valid VideoFormat or MemBufferCollection is set, after you have done that, the sink will be applied.
DShowLib Function : returns successful Grabber::openDev
.\DAFWCam.cpp(177) : DA::DAFWCam::_threadCamWork: Post openDev Point A.
.\DAFWCam.cpp(179) : DA::DAFWCam::_threadCamWork: Post openDev Point B.
.\DAFWCam.cpp(182) : DA::DAFWCam::_threadCamWork: Post openDev Point C.
HEAP[MotorolaV3Interactive_Debug.exe]: Invalid Address specified to RtlValidateHeap( 00C50000, 00C4AC18 )
Unhandled exception at 0x7c901230 in MotorolaV3Interactive_Debug.exe: User breakpoint.


so, it appears the failure is in the deconstructor for the list of devices:



// we're now done with the list of devices
pVidCapDevList = NULL;

[qwda]

I've now got it running with success.

But only by commenting out the two 'clean up' bits which I had put in my code:



// we're now done with the list of devices
// COMMENTED OUT FOR NOW BECAUSE WAS CAUASING RtlValidateHeap Invalid Address ASSERT failure
// pVidCapDevList = NULL;


and



// we're done with the list of video formats
// COMMENTED OUT FOR NOW BECAUSE WAS CAUASING RtlValidateHeap Invalid Address ASSERT failure
// pVidFmtList = NULL;


I've now got to work out why the callbacks are not getting to me (probably just a matter of plumbing in my code).

But I'm still wondering why I'm not able to clean up these two object pointers. Is this going to become a memory leak in my code?

[Stefan Geissler]

Hello,

did you check, whether your application is created “Multithreaded DLL”? Also are you sure, you are linking the correct debug DLLs to the debug version and release DLLs to the release version of your program?
In you post, the project files are missing, to i was not able to check this out.

I just forgot: If you use .NET, then only .NET 7.1 can be used. .NET 7.0 has some problems with memory handling.

[qwda]

I guess that might be the issue...
[Will try shortly once I've finished debugging thru something completely different (have not got time to start forking this code! :)).]

For my Debug project I am indeed set to "Multi-threaded Debug (/MTd)" as opposed to "Multi-threaded Debug DLL (/MTDd)" as you suggest.
Not sure what the difference is or what the implications might be for my the rest of my application which is using DirectX for screen writing (1024x768@75Hz on nVidia 6600) and possibly DirectShow for AVI playback.

My Linker / Input / Additional Dependencies are indeed pointing to the correct file as far as I'm aware (DEBUG is to "..\..\SDK\IC21\ClassLib\Debug\TIS_UDSHL06_vc71d.li b").

I'm using Visual C++ Remote Debugging (Pipe Mode) from my dev machine to the actual testbed machine. I've got seperate DEBUG and RELEASE binary folders on that machine wherein are, yet again, the appropriate runtime DLL and other (??) files for your codebase.

[qwda]

We're on MSDN Universal and I've got the latest incarnation installed.

Quoting from my About dialogue...

Microsoft Development Environment 2003 v. 7.1.3088

Microsoft .NET Framework 1.1
(not that that's applicable here! - e.g. my app is native code)

[Stefan Geissler]

Hello,



For my Debug project I am indeed set to "Multi-threaded Debug (/MTd)" as opposed to "Multi-threaded Debug DLL (/MTDd)" as you suggest.


The "Multi-threaded Debug DLL (/MTDd)" means that the Microsoft Runtime DLLs are not linked statically to the executable. They must be delivered as DLL files with your application.

Also we reognized, that the YUV Transform filter is not correctly registered on your target computer. This does not affect your problem, but i just wanted to mention this.