Need help debuging (part II)
Author
Ok, here is the story:
I am trying to hack together some code for a particle system (using DirectX 8). I have most of the code written and I figured I would test it. When I try to run the actual rendering loop of my program while debugging, it gives me an access violation and jumps right into the assembly code. This is a bit of a problem, as I do not know assembly. I need a bit of help tracking this down. You can find the code at:
http://www20.brinkster.com/tyrannica/debug3.zip
EDIT - updated source again.
Moe's Site
Edited by - Moe on February 18, 2002 7:27:50 PM
Run your app in debug mode, make it crash, press retry to go into debug mode, right click on the border of one of the debug windows so the list of debug windows comes up, click on call stack, this will bring up the call stack window (in case is not already visible) now, click on the first (from top to bottom) function name you recognise as yours, there it will be, a nice green arrow right over the line that has the function call that has the bug.
Good luck.
Good luck.
Ctrl+F10 is one of the best features of MSVS. if you kinda know where the offending code is then run to the line before it and step into (F11) or over (F10) until you get the access violation.
now, once you get the violation, close the disassembly window and the "->" will pointing to the source file line that caused the violation. now you may want to stop the debuger and use "Ctrl+F10" again to run to the line before the acess violation. at this point you want to examine variables for correct values, etc.
To the vast majority of mankind, nothing is more agreeable than to escape the need for mental exertion... To most people, nothing is more troublesome than the effort of thinking.
now, once you get the violation, close the disassembly window and the "->" will pointing to the source file line that caused the violation. now you may want to stop the debuger and use "Ctrl+F10" again to run to the line before the acess violation. at this point you want to examine variables for correct values, etc.
To the vast majority of mankind, nothing is more agreeable than to escape the need for mental exertion... To most people, nothing is more troublesome than the effort of thinking.
Author
Ok, I tried doing what you said.
The only functions that were there weren''t mine. I played around by commenting out pieces of the code until I narrowed it down to my rendering function, and one thing in that - when I call DrawPrimitive. I think it has something to do with the way that I am filling the vertex buffer, and it chokes because I haven''t initialized the values of the vertices or something.
Moe''s Site
The only functions that were there weren''t mine. I played around by commenting out pieces of the code until I narrowed it down to my rendering function, and one thing in that - when I call DrawPrimitive. I think it has something to do with the way that I am filling the vertex buffer, and it chokes because I haven''t initialized the values of the vertices or something.
Moe''s Site
ok, I checked it, the problem is in void PARTICLE_EFFECT::UpdateEffect(float delta)
you see, in void PARTICLE_MANAGER::UpdateEffects(float delta)
you have this:
you cycle through all the effects, even non initialized ones, you should keep an effect count that gets increased in CreateEffect and decreased in Destroy effect, you should then use that value instead of MAXEFFECTS in the previews code, OR you can change PARTICLE_EFFECT::UpdateEffect(float delta) to check if Array is Valid (and hence the effect is initialized)
you see, in void PARTICLE_MANAGER::UpdateEffects(float delta)
you have this:
void PARTICLE_MANAGER::UpdateEffects(float delta){ //cycle through the number of effects and update them for(int i = 0; i<MAXEFFECTS; i++) { Effects[i].UpdateEffect(delta); }} you cycle through all the effects, even non initialized ones, you should keep an effect count that gets increased in CreateEffect and decreased in Destroy effect, you should then use that value instead of MAXEFFECTS in the previews code, OR you can change PARTICLE_EFFECT::UpdateEffect(float delta) to check if Array is Valid (and hence the effect is initialized)
void PARTICLE_EFFECT::UpdateEffect(float delta){if (Array==NULL) return;//variable that keeps track of the particle that should be drawn int Active = 0;......}
Author
Ok, I did a little more playing around by watching the variables. I checked out all the variables that are used to create the vertex buffer and everything seems ok there, so that means it has to be something with the way that I am filling the vertex buffer. I just can''t put my finger on it!
Moe''s Site
Moe''s Site
Author
Ok, thanks, I will make the changes and see how it goes!
EDIT - Ok, I made the changes, but it still isn't stopping the access violation. Even if it didn't fix the problem, it was still a good thing to do.
Moe's Site
Edited by - Moe on February 16, 2002 3:10:51 PM
EDIT - Ok, I made the changes, but it still isn't stopping the access violation. Even if it didn't fix the problem, it was still a good thing to do.
Moe's Site
Edited by - Moe on February 16, 2002 3:10:51 PM
First of all, you should be running debug runtime of DX. If you didn't select debug runtime when you installed DXSDK, reinstall and select it. Then go to Control Panel->DirectX. You can choose between debug and retail runtimes and set thte debug output level. Always run your DX apps with debug DX runtime.
Even before your program crashes, I get the following:
Direct3D8: (ERROR) :Need to call BeginScene before rendering.
Which is absolutely true. Move BeginScene() call in ENGINE::EngineRenderMainScene to before font.Draw call.
Direct3D8: (WARN) :Ignoring redundant SetTextureStageState Stage: 0, State: 1
You apparently are setting your render and texture stage states over and over again to the same values. You should fix this.
You might consider using precompiled headers through stdafx.h, which will give you faster build times.
Why do you need CS_OWNDC when you never acquire a DC? Also, why use CS_HREDRAW and CS_VREDRAW when you never use GDI for drawing?
in PARTICLE_MANAGER::AddEffect, you don't handle the case of overflow. You will write past the array bounds if it is full.
I would also stay away from public data, because it makes it hard to know where a certain variable is modified if it suddenly becomes corrupted.
Instead of using error codes, you might want to use exceptions. Their beauty is that you don't have to check for error returns until you are ready to handle them, and you only check once.
Kwizatz is correct: you are referencing uninitialized data, which MSVC debug runtime kindly initializes to 0xcccccccc.
Add this to PARTICLE_MANAGER:
int NumEffects;
to PARTICLE_MANAGER::Initialize:
NumEffects = 0;
to PARTICLE_MANAGER::AddEffect:
++NumEffects;
to PARTICLE_MANAGER::RemoveEffect:
--NumEffects;
in PARTICLE_MANAGER::UpdateEffects change for loop to:
The access violation you receive after the fix comes from another place, you should have said that. You should also have updated the zip file, so that I didn't have to fix the bug already fixed by Kwizatz.
This one is in PARTICLE_MANAGER::RenderPointSprite, at DrawPrimitive call. 'j' that you are passing is 0. That's because you don't have any particles in your effect. I noticed this a long time ago (ever since effect creation, it has no particles). If you use this:
then the second access violation goes away, but the screen is gray. To my disappointment, I don't see any particles. If there should have been particles, I guess your logic is buggy.
I can email you the fixed project, if you want. And please update the zip files you are posting! I'm curious to see your particle system in action when it's fixed.
Press Alt+7 to see call stack when your program is broken (I mean debug break). From there you can go to the function in your code that called the assembly that crashed.
EDIT: Can't get source code to show up properly.
Edited by - IndirectX on February 16, 2002 7:03:30 PM
Even before your program crashes, I get the following:
Direct3D8: (ERROR) :Need to call BeginScene before rendering.
Which is absolutely true. Move BeginScene() call in ENGINE::EngineRenderMainScene to before font.Draw call.
Direct3D8: (WARN) :Ignoring redundant SetTextureStageState Stage: 0, State: 1
You apparently are setting your render and texture stage states over and over again to the same values. You should fix this.
You might consider using precompiled headers through stdafx.h, which will give you faster build times.
Why do you need CS_OWNDC when you never acquire a DC? Also, why use CS_HREDRAW and CS_VREDRAW when you never use GDI for drawing?
in PARTICLE_MANAGER::AddEffect, you don't handle the case of overflow. You will write past the array bounds if it is full.
I would also stay away from public data, because it makes it hard to know where a certain variable is modified if it suddenly becomes corrupted.
Instead of using error codes, you might want to use exceptions. Their beauty is that you don't have to check for error returns until you are ready to handle them, and you only check once.
Kwizatz is correct: you are referencing uninitialized data, which MSVC debug runtime kindly initializes to 0xcccccccc.
Add this to PARTICLE_MANAGER:
int NumEffects;
to PARTICLE_MANAGER::Initialize:
NumEffects = 0;
to PARTICLE_MANAGER::AddEffect:
++NumEffects;
to PARTICLE_MANAGER::RemoveEffect:
--NumEffects;
in PARTICLE_MANAGER::UpdateEffects change for loop to:
for(int i = 0; i<NumEffects; i++) The access violation you receive after the fix comes from another place, you should have said that. You should also have updated the zip file, so that I didn't have to fix the bug already fixed by Kwizatz.
This one is in PARTICLE_MANAGER::RenderPointSprite, at DrawPrimitive call. 'j' that you are passing is 0. That's because you don't have any particles in your effect. I noticed this a long time ago (ever since effect creation, it has no particles). If you use this:
if (j) if(device->DrawPrimitive( D3DPT_POINTLIST, 0, j) != D3D_OK) return PARTICLESYSTEM_BAD; then the second access violation goes away, but the screen is gray. To my disappointment, I don't see any particles. If there should have been particles, I guess your logic is buggy.
I can email you the fixed project, if you want. And please update the zip files you are posting! I'm curious to see your particle system in action when it's fixed.
Press Alt+7 to see call stack when your program is broken (I mean debug break). From there you can go to the function in your code that called the assembly that crashed.
EDIT: Can't get source code to show up properly.
Edited by - IndirectX on February 16, 2002 7:03:30 PM
Author
About running DirectX in Debug:
Simply put, I can''t do this. I have the DirectX 8.0 SDK installed, but the DirectX 8.1 runtimes installed as well (it wasn''t my fault - the stupid guys at the computer shop updated it and I didn''t tell them not to). When I go the control panel->DirectX, the area that lets me set it to debug is shaded out. It looks like I need the debug version of DirectX 8.1. Is it possible to download the 8.1 debug version without the whole SDK? I am on dial-up, and it takes anything forever....
Ok, now about the code:
I did all the fixes to the code that you did, but I haven''t had the chance to upload it yet. As you saw, it is still not rendering anything. I think this can be traced to the value of ''j'' in the rendering code. For some reason it seems to be getting set to zero, and it should be equal to the number of vertices that are supposed to be drawn. Any ideas on what''s messing up here?
Moe''s Site
Simply put, I can''t do this. I have the DirectX 8.0 SDK installed, but the DirectX 8.1 runtimes installed as well (it wasn''t my fault - the stupid guys at the computer shop updated it and I didn''t tell them not to). When I go the control panel->DirectX, the area that lets me set it to debug is shaded out. It looks like I need the debug version of DirectX 8.1. Is it possible to download the 8.1 debug version without the whole SDK? I am on dial-up, and it takes anything forever....
Ok, now about the code:
I did all the fixes to the code that you did, but I haven''t had the chance to upload it yet. As you saw, it is still not rendering anything. I think this can be traced to the value of ''j'' in the rendering code. For some reason it seems to be getting set to zero, and it should be equal to the number of vertices that are supposed to be drawn. Any ideas on what''s messing up here?
Moe''s Site
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
