Dear Jaapio,
I must agree with the others and say that it definitely is NOT a fault in your vfptr table.
Those tables just work. The algorithms behind those tables were written by people who validated and debugged their code thousands of times before releasing it.
What I think is that your texture is not a valid Direct3DTexture8!
Have you checked the return codes of DirectX when creating the texture? It happened to me once that I got a pointer returned when creating a texture object BUT the return code told me that the function failed!
Basically what I want to say is, check the error codes you get from DirectX and try to find out if any function failed.
The vfptr table won't be bugged nor could you do anything about it if it was bugged.
Merry christmas y'all :)
Jan
How to check virtual functions(vfptr)
Quote:Original post by Jaapio
So I readlly need to find some way to check if the v-table.
No you don't. Believe me. Assuming you are using Visual C++, the byte offset of the vtable pointer in a polymorphic object (using single inheritance) is 0. The offset of a function pointer in this vtable is n*4, where n is the index of the function. To have a valid vtable, the object to which the vtable refers should be valid, and if the vtable is not valid then it means that the object is not valid.
The memory layout looks like:
address P <---- thisaddress P + 0 <---- vtbl pointer = Taddress P + sizeof(pointer) <---- non static members of thisaddress T + 0 <---- pointer to the first virtual functionaddress T + sizeof(pointer) * N <---- pointer to the Nth virtual function
In your case, you gave us a number: a nearly NULL pointer. This is the address the called virtual function, and it means that the vtable pointer is NULL. If the address of the vtable is the NULL pointer (which is an invalid value for the vtable pointer), what does this tells us about the object itslef?
So instead of searching to test the vtable (whose size is unknown, and whose position should not be known as well), you'd better search why your object is invalid - because it is invalid, whatever you think about it. YOU have a bug, and the vtable exception is just another reminder.
Think to what you are doing: you want to verify if the functions are in the vtable? If not, that would mean that either you have a bug, or the compiler have a bug. And this would be rather huge for a compiler bug, don't you think? With such a huge bug, it's quite hard to believe that only you were able to hit it. Since there are no report for this bug on the whole web, you can safely assume that it's your fault.
Toorvhyk, Enigma and others already pointed out some problems in your code but you chosed to ignore them instead of checking them. This is not very wise [smile].
Thanks for the help, the but actually size of the v-table is know.
I check what I know how to check, but I dont know a way to check if Texture has been released.
Ill post the full code soon.
I check what I know how to check, but I dont know a way to check if Texture has been released.
Ill post the full code soon.
Quote:Original post by RogalDorn
Dear Jaapio,
I must agree with the others and say that it definitely is NOT a fault in your vfptr table.
Those tables just work. The algorithms behind those tables were written by people who validated and debugged their code thousands of times before releasing it.
What I think is that your texture is not a valid Direct3DTexture8!
Have you checked the return codes of DirectX when creating the texture? It happened to me once that I got a pointer returned when creating a texture object BUT the return code told me that the function failed!
Basically what I want to say is, check the error codes you get from DirectX and try to find out if any function failed.
The vfptr table won't be bugged nor could you do anything about it if it was bugged.
Merry christmas y'all :)
Jan
The problem is that I dont create the texture myself, that is done by an other application which is not writen by me.
I dont have a way to check if the Texture has been released which is the problem right now.
Quote:Original post by MaulingMonkey
This is incorrect for 99.999% of projects in your situation. The 0.001% that this would hold for would have programmers that already knew of SEH exceptions and their ilk, and wouldn't be anything that would use DirectX, and would definately use assert on top of SEH exception handlers. You're trying to patch the symptom, not the problem, and it's bound to fail horribly.
Than how do you suppose I should check if Texture has been released?
No I cant write a layer over that interface, I tried it but it blew up in my face.
Try explaining what you're doing in more detail (i.e. where the texture comes from), preferably with copious amounts of relevant code.
Σnigma
Σnigma
Quote:Original post by JaapioQuote:Original post by MaulingMonkey
This is incorrect for 99.999% of projects in your situation. The 0.001% that this would hold for would have programmers that already knew of SEH exceptions and their ilk, and wouldn't be anything that would use DirectX, and would definately use assert on top of SEH exception handlers. You're trying to patch the symptom, not the problem, and it's bound to fail horribly.
Than how do you suppose I should check if Texture has been released?
No I cant write a layer over that interface, I tried it but it blew up in my face.
Typically, you don't programmatically. All the data area of a Texture that has been released is free for reuse by a new allocation which would reuse the memory for something totally different, using potentially any value, and thus there is no way to safely check if a raw pointer points to a released object programmatically. [Edit: Many C++ implementations will even clobber the aforementioned memory area intentionally with fill patterns as a dangling pointer debuging aid.] Instead, one typically notifies everything that would need to know about Texture's destruction of it's destruction upon it's destruction instead (tell, don't ask).
That said, it is possible to automate the above process behind a facade that allows you to in effect check if a Texture has been released -- you need an external mechanism of some sort, though.
For example, if you're using the boost library, if you use boost::shared_ptr<T>s, you can use boost::weak_ptr<T>s for objects which should not force the Texture to stick around. weak_ptr.lock() will return a shared_ptr that's implicitly convertable to false if the underlying object has been released (i.e. all the shared_ptrs to the Texture have been destroyed, causing Texture's destruction).
This is accomplished by keeping some counters:
1) A counter of the number of shared_ptrs pointing to the object (refered to object deleted/released when this hits 0)
2) A counter of the number of weak_ptrs pointing to the object (when this and the number of shared_ptrs both hit 0, the counters are deleted/released).
It looks roughly like:
template < typename T > struct shared_allocation { T * pointer; unsigned shared_count, weak_count; shared_allocation( T * pointer ) : pointer(pointer) , shared_count(0) , weak_count(0) {}};template < typename T >void add_shared_ref( shared_allocation<T>* alloc ) { assert(alloc); ++alloc->shared_count;}template < typename T >void add_weak_ref( shared_allocation<T>* alloc ) { assert(alloc); ++alloc->weak_count;}template < typename T >void release_shared_ref( shared_allocation<T>* alloc ) { if (!alloc) return; //no-op release(NULL) like delete --alloc->shared_count; if ( !alloc->shared_count ) { delete alloc->pointer; alloc->pointer = 0; if ( !alloc->weak_count ) { delete alloc; } }}template < typename T >void release_weak_ref( shared_allocation<T>* alloc ) { if (!alloc) return; //no-op release(NULL) like delete --alloc->weak_count; if ( !(alloc->shared_count || alloc->weak_count) ) { assert(!alloc->pointer); //should have already been deleted delete alloc; }}template < typename T > class shared_ptr { shared_allocation<T>* alloc;public: explicit shared_ptr( T * pointer ) { alloc = new shared_allocation<T>( pointer ); add_shared_ref( alloc ); } shared_ptr( const shared_ptr<T>& other ) { release_shared_ref( alloc ); alloc = other.alloc; add_shared_ref( alloc ); } ~shared_ptr() { release_shared_ref( alloc ); } shared_ptr<T>& operator=( const shared_ptr<T>& other ) { release_shared_ref( alloc ); alloc = other.alloc; add_shared_ref( alloc ); return *this; } T* operator->() { return alloc->pointer; } const T* operator->() const { return alloc->pointer; }};template < typename T >class weak_ptr { ...similar code to shared_ptr...};
This is a vast oversimplification with bits of functionality missing (you can customize shared_ptr to use something other than delete, for example, and I'm missing most of the operators) but it should rougly describe how they do it.
Obviously, it isn't simple.
(fortunately, the boost library is freely available for download and installation)
[boost]: http://boost.org/more/getting_started.html
[Edited by - MaulingMonkey on December 23, 2006 12:09:32 AM]
How are you communicating with this other application? Sockets? Windows messages? via DLL? Memory mapped files?
It sounds like whatever process you are using to get these Textures isn't giving you valid memory behind your pointer. You might want to start looking at the system that passes you these created textures for flaws.
It sounds like whatever process you are using to get these Textures isn't giving you valid memory behind your pointer. You might want to start looking at the system that passes you these created textures for flaws.
Quote:Original post by Anonymous Poster
How are you communicating with this other application? Sockets? Windows messages? via DLL? Memory mapped files?
It sounds like whatever process you are using to get these Textures isn't giving you valid memory behind your pointer. You might want to start looking at the system that passes you these created textures for flaws.
I have a dll called d3d8.dll
Which is loaded by the application as if it is the real d3d8 dll.
I found out what the problem was, it turns out that the textures where released.
But I found a workaround...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement