Thread: What does a __vfptr with 0xfeefee value mean (and how to solve it)?

  1. #1
    In the Land of Diddly-Doo g4j31a5's Avatar
    Join Date
    Jul 2006
    Posts
    476

    What does a __vfptr with 0xfeefee value mean (and how to solve it)?

    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.
    ERROR: Brain not found. Please insert a new brain!

    “Do nothing which is of no use.” - Miyamoto Musashi.

  2. #2
    Registered User
    Join Date
    Jun 2005
    Posts
    6,815
    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.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Buttercup, and read this, this, and this before posting again.

  3. #3
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    __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:

    Code:
    int* vptr =  *(int**)foo;
    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.

    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.
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  4. #4
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  5. #5
    Registered User jeffcobb's Avatar
    Join Date
    Dec 2009
    Location
    Henderson, NV
    Posts
    875
    Quote Originally Posted by Salem View Post
    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?
    C/C++ Environment: GNU CC/Emacs
    Make system: CMake
    Debuggers: Valgrind/GDB

  6. #6
    In the Land of Diddly-Doo g4j31a5's Avatar
    Join Date
    Jul 2006
    Posts
    476
    Sorry for the late reply. Ok, a little bit of codes now:

    Parent class
    Code:
    /*
     *
     */
    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;
    };
    The faulty code
    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.
    		);
    	}
    ...
    }
    More codes:
    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;
    }
    Ok this is the code. I hope you guys can help me with this because I'm lost right now.

    Thanks a lot in advance.
    ERROR: Brain not found. Please insert a new brain!

    “Do nothing which is of no use.” - Miyamoto Musashi.

  7. #7
    Registered User
    Join Date
    Jan 2010
    Posts
    412
    You say the problem is in the call to
    Code:
    AviStreamer::startStreaming(AviStreamer::getCaptureBufferManager());
    But you don't provide the code for those 2 methods? We're not mind readers you know

  8. #8
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  9. #9
    In the Land of Diddly-Doo g4j31a5's Avatar
    Join Date
    Jul 2006
    Posts
    476
    Quote Originally Posted by _Mike View Post
    You say the problem is in the call to
    Code:
    AviStreamer::startStreaming(AviStreamer::getCaptureBufferManager());
    But you don't provide the code for those 2 methods? We're not mind readers you know
    Oh, right. I forgot about that.

    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;
    }
    The getCaptureBufferManager() is the usual getter function that will return the m_pCaptureBufferManager from an AviStreamer object.

    Quote Originally Posted by Salem View Post
    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.
    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.

    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.
    ERROR: Brain not found. Please insert a new brain!

    “Do nothing which is of no use.” - Miyamoto Musashi.

  10. #10
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  11. #11
    Registered User
    Join Date
    Jan 2010
    Posts
    412
    Quote Originally Posted by Salem View Post
    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.
    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.

  12. #12
    In the Land of Diddly-Doo g4j31a5's Avatar
    Join Date
    Jul 2006
    Posts
    476
    Quote Originally Posted by Salem View Post
    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.
    Quote Originally Posted by _Mike View Post
    Even if the address isn't constant debugging where it gets freed is reasonably easy.
    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.
    From MSDN:
    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.
    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.

    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.
    Last edited by g4j31a5; 02-19-2010 at 03:43 AM.
    ERROR: Brain not found. Please insert a new brain!

    “Do nothing which is of no use.” - Miyamoto Musashi.

  13. #13
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    > 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)
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

Popular pages Recent additions subscribe to a feed