Hi, I've got a parent class with a pure virtual function which is inherited by a child class and the body was defined by the child class. The problem is why does the application sometimes crashes when I want to access that particular function? And when I look at the debug values, the __vfptr was 0xfeefee. What does that mean? And how do I fix it? Thanks a lot in advance.
Try showing a small bit of actual code which exhibits your concern. In code tags, otherwise it will be hard to read in the forums.
The meaning of __vfptr would be specific to your compiler. I suspect it is unrelated to your problem though.
__vfptr is the internal Virtual Table Pointer, created at compile time. It points to a table (also known as vtable) which is essentially an array that contains the addresses of all virtual functions within a object hierarchy. The 0xfeefee is simply the start address of that vtable.
While you cannot directly access __vfptr from your code (it is only created at compile time), you can however indirectly access it:
Will give you at runtime the same address of __vptr in a 32 bit machine. This works because the compiler places __vptr in the first 4 bytes of the object.Code:int* vptr = *(int**)foo;
From here on, you can inspect the vtable at runtime. It's not straightforward, it requires a little bit of assembly to ease the work and its hard to know what we are looking, but essentially we will be able to traverse an array in memory that starts at vptr address and ends at the last virtual function of an hierarchy of objects.
...
Now, I guess you can start to see that the fact your application crashes probably has nothing to do with __vfptr. This is simply a mechanism of the compiler for an application to keep tracks of what member functions to call within an hierarchy of objects.
Instead your error is probably somewhere else. In your code.
Win32 Debug CRT Heap Internals
0xFEEEFEEE is what memory is filled with (in debug builds) after memory has been freed.
You're using something after it has been deallocated.
Didn't it (back in the day) get filled with 0xDEADBEEF? Or am I thinking of some other compiler?Quote:
Originally Posted by Salem
Sorry for the late reply. Ok, a little bit of codes now:
Parent class
The faulty codeCode:/*
*
*/
class CaptureBufferManager {
public:
virtual ~CaptureBufferManager(){}
/*
*
*/
virtual CAPTURE_BUFFER_HANDLE getBuffer(
void** ppvBuffer,
unsigned* puPitch,
unsigned uFlags
) = 0;
/*
*
*/
virtual void returnBuffer(
CAPTURE_BUFFER_HANDLE captureBufferHandle
) = 0;
/*
*
*/
virtual IDirect3DTexture9* getTexture( bool zOnlyIfUpdated = false ) = 0;
/*
*
*/
virtual void returnTexture( IDirect3DTexture9* ) = 0;
};
More codes:Code:bool DemoScreen::onAnimate() //Always called on every loop
{
...
if (AviStreamer::isComplete())
{
AviStreamer::endStreaming();
AviStreamer::uninitialize(); //Delete and uninitialize all, including the capture buffer manager
AviStreamer::initialize(&(*m_iterAviParams)); //Reinitialize all including the capture buffer manager
AviStreamer::startStreaming(
AviStreamer::getCaptureBufferManager() //This one is faulty because the __vfptr is 0xfeefee.While the getCaptureBufferManager() returned a normal pointer. So using "if (AviStreamer::getCaptureBufferManager() != NULL)" doesn't solve it because it never NULL.
);
}
...
}
Ok this is the code. I hope you guys can help me with this because I'm lost right now. :(Code:bool AviStreamer::initialize(AVI_STREAM_PARAMS* pParams)
{
if( !_initStreamGraph( pParams ) ) {
uninitStreamGraph( ) ;
return false;
}
if( !_initBuffers( pParams->m_pDevice ) ) {
uninitBuffers( );
return false;
}
if( !_initBufferManager( ) ) {
uninitBufferManager( ); //I first assume that it will go inside this block when the __vfptr = 0xfeefee. But I was wrong and it didn't go here.
return false;
}
}
/*
*
*/
BOOL AviStreamer::_initBufferManager( ) {
m_pCaptureBufferManager = new XCaptureBufferManager(
m_pTextures[0],
m_pTextures[1],
m_pTextures[2]
); // CaptureBufferManager* pCaptureBufferManager. And XCaptureBufferManager = the child of CaptureBufferManager.
if( !m_pCaptureBufferManager ) {
m_pCaptureBufferManager = NULL ;
delete m_pCaptureBufferManager;
return false;
}
return true;
}
Thanks a lot in advance.
You say the problem is in the call to
But you don't provide the code for those 2 methods? We're not mind readers you know :)Code:AviStreamer::startStreaming(AviStreamer::getCaptureBufferManager());
We need actual code that crashes.
Create a clone of your project and start removing any code which doesn't run at all, and then carefully removing code which doesn't affect the crashing behaviour.
Whilst doing this, you might actually figure out the problem yourself.
If not, you'll have a small complete example to post.
Oh, right. I forgot about that. :DQuote:
Originally Posted by _Mike
The getCaptureBufferManager() is the usual getter function that will return the m_pCaptureBufferManager from an AviStreamer object.Code:/*
*
*/
HRESULT AviStreamer::startStreaming(
CaptureBufferManager* pCaptureBufferManager
) {
HRESULT hResult;
m_pAviTextureRenderer->setBufferManager( pCaptureBufferManager ); //It crashes here. FYI m_pAviTextureRenderer = the filter that was added to the graph.
hResult = m_pMediaControl->Run(); //the usual IMediaControl::Run()
return hResult;
}
FYI, it's a part of my project that will play movies with DirectShow before someone inputted something to the project. And it usually crashes when I finished playing one movie and then replaying another one.Quote:
Originally Posted by Salem
Well, recreating a simple project out of this one is tedious because this project has become one giant pile of codes. Also there is no code that didn't run at all. Even the faulty ones will only emerge occasionally, maybe 1 out of 5 calls. And to make things worse (or better depending on how you see it), it didn't crash... yet. I even played it a whole day and it didn't crash at all on release. But on debug, it will certainly crash every now and then.
For any given build, and a crash, is the address (or object) reasonably constant?
If it is, then you could set a data write breakpoint in the debugger on the address which is being corrupted.
That way, you can find who's releasing it.
Even if the address isn't constant debugging where it gets freed is reasonably easy.Quote:
Originally Posted by Salem
Set an execution breakpoint in the class constructor to get the this pointer.
Set a write breakpoint on the mem location pointed to by 'this'
Run the app, wait for the breakpoint to trigger, and check the call stack.
Quote:
Originally Posted by Salem
From MSDN:Quote:
Originally Posted by _Mike
AFAIK, DShow uses another thread to stream & run the media file. So according to the MSDN, I can't use data breakpoints here, right? CMIIW.Quote:
Data breakpoints do not work under these conditions: if a process that is not being debugged writes to the memory location or if the memory location is shared between two or more processes. Data breakpoints do not work if the memory location is updated within the kernel. For example, if memory is passed to the 32-bit Windows ReadFile function, the memory will be updated from kernel mode and the debugger does not break on the memory write.
BTW, I think I know what the cause is. Maybe :P. Actually the "AviStreamer::endStreaming();" line wasn't there in the first place and I've just added it recently. And also after I add that line, the crash has never occurred again. Not yet anyway. Maybe it's because the thread to play the media file still continues streaming while it was de-initialized. Well, gonna double check it again and run the app the whole day. If the crash is still there, I'll revisit this thread again. Thanks guys.
> AFAIK, DShow uses another thread to stream & run the media file.
A thread is not a process.
Two threads would exist within a single process (so you should be OK)