Sign in to follow this  
BrentBarrett

Very, very difficult DrawPrimitive bug.

Recommended Posts

Basically, I've got a vector where each element represents a texture. I have a loop that cycles through the vector and sends its texture and vertex buffer through a render loop. The render loop will draw whatever textures the vector is initialized with, but if I resize the vector to contain more, it won't draw those, and crashes. What's really odd is the way it crashes. It goes through every function and returns S_OK. As far as I can tell there's no bad data being passed around. Yet, when it gets down to DrawPrimitive, it crashes before DrawPrimitive can even return. It gives the following error: Unhandled exception at 0x006e81c6 in Kabuki.exe: 0xC0000005: Access violation reading location 0xfeeeff06. And: The thread 'WinMain' (0xac0) has exited with code 128 (0x80). So, it's exiting on a 128 Error Code. I looked that up and it says: There are no child processes to wait for. I don't really understand what that means. I've been trying to solve this for a couple days now, so please don't feel I'm wasting your time without having already given my best.

Share this post


Link to post
Share on other sites
Hmm, i've got too some problem with dip. You can see may topic named by dip parameter and xp restart. But in your case the problem seems something else. Without saw any code i bet the problem with the size of vb. If the fvf is wrong it would be cause only render bugs. I would firstly check the sizes of vbs.

Share this post


Link to post
Share on other sites
I'm pretty sure that the WinMain exit error can be completely ignored. The real problem is with "0xC0000005: Access violation reading location 0xfeeeff06". Somewhere you're somehow giving DX a bad parameter or something. I'd like to see some of your code, mainly the resizing and filling in of the vector, and the call to DrawPrimitive. I was thinking that memory location 0xfeeeff06 might just be a negative index into an array, but it works out to -17891578, which doesn't sound as likely as -4 or something. But maybe you're reading beyond the bounds of your vector, or not setting some values in your resized vector elements correctly.

Share this post


Link to post
Share on other sites
Ah, freed memory. I shoulda realized that it was a modification of a debug memory value. Which means that it is likely adding 24 (bytes) to 0xFEEEFEEE, thinking that there is a pointer stored there, and then trying to access that pointer (0xFEEEFF06).

Since it is freed memory, and a vector resize is involved, maybe you are trying to use pointers after you resized the vector that you obtained before resizing the vector. When you resize a vector, all pointers/iterators to elements in the vector are likely to become invalid, since if the vector needs to actually reallocate memory, it moves all information to a totally different location, and thus different pointer/iterator values. Is that by any chance your problem?

(By the way, nice thinking Namethatnobodyelsetook.)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this