Debug/Release mayhem

I also got this problem. Some procs crashes when compiler optimize them. Try to switch off optimizing. It helped me. Or play around settings in Linker tab.

hi.

in your big program you hasn´t threads, or process. The problem that you report is like that you have some threads without synchronized, and in the faster execution(pc) the threads maybe cause dead lock, and when you do debug a program the time slice end and give oprtunity to another thread to run, with threads do debug with printlines is better.

i hope so that help you

[edited by - h0bbes on May 25, 2004 6:04:09 AM]

H0bbes: no, my application does not contain threads. I''m experienced with the problems that can occur when one uses threads, and that''s why I only use them when there''s really no other way. But in this case, there are no threads - aside from the main thread ofcourse

put logging calls in until you are blue in the face... find the last point your app was in control before the crash.

The "external library" is OpenGL or DirectX. But my calls to OpenGL are just fine, I know that. Because when I use the Direct3D version of my engine, it crashes in a similar DirectX call. But the data these functions receive is just fine as well. So I guess the memory is invalid (freed to early or something).

And ASSERT's like that do not occur in my app

[edited by - Marc aka Foddex on May 25, 2004 7:29:33 AM]

compare with a previous version of the code which doesn''t exhibit the problem as look at what the differences are.

Are you deliberately supressing any compiler warnings? Or have done anything to force it to compile and link?

What is the external library? How do you know that''s where it''s crashing? Expand, please.

You can compile release with debug info too. Try that.

quote:

---

compare with a previous version of the code which doesn''t exhibit the problem as look at what the differences are.

---

Unfortunately, the program is so big (consisting of two huge static libraries and the main program), it''s impossible to determine since when the problem occurs. And I don''t use CVS, too. Maybe I should''ve... :-/

quote:

---

Are you deliberately supressing any compiler warnings? Or have done anything to force it to compile and link?

---

I''m not surpressing any compiler warnings if you mean #pragma statements. I''m an experienced coder, I know when to use them and when not

quote:

---

What is the external library? How do you know that''s where it''s crashing? Expand, please.

---

OpenGL and Direct3D, mentioned earlier

quote:

---

You can compile release with debug info too. Try that.

---

Hmm haven''t thought of that! I''ll try that!

In what way are the "Use of uninitialized memory" errors that Bounds Checker is pointing out, incorrect?

I don't think pure OpenGL and DirectX would crash like that. Maybe a third-party wrapper would, but those two are tested very well.

Put some print statement at the start of each call, and see what's happening before it crashes. Print out variable values as well in important parts of the code. Write everything to a text file (make sure to fflush() so that everything is written before the crash). Then run diff to see where the outputs from the debug and release versions differ. (Of course you'll need the same random seed, etc.)

Once you find the general area, if you're still not sure what the problem is, comment out various parts of the code until the problem stops.

[edited by - Matei on May 25, 2004 8:23:42 AM]

quote:

---

In what way are the "Use of uninitialized memory" errors that Bounds Checker is pointing out, incorrect?

---

Check the following code. It''s purely illustrative.

char* block = malloc(4096);
memset(block, 0, 4096);
for (int i=0; i<4096; i++) {
  // do something with block[i]

}

Now boundschecker would tell me that somewhere random in the range 0-4095 there''s usage of unitialized memory (where the pointer it specifies points to somewhere inside ''block''). Since the entire block is ''memsetted'', this is pure nonsense. At least as far as I can tell

quote:

---

I don''t think pure OpenGL and DirectX would crash like that. Maybe a third-party wrapper would, but those two are tested very well.

---

Exactly, and I do not blame these libraries (that''s why I simply said ''external library'' in my opening post). My renderer engine is a wrapper around OpenGL and DirectX, but even in there I do not expect the error to be. I suspect some serious stack/memory corruption somewhere. A call to free which shouldn''t be happening, or something similar.

quote:

---

Put some print statement at the start of each call, and see what''s happening before it crashes. Print out variable values as well in important parts of the code. Write everything to a text file (make sure to fflush() so that everything is written before the crash). Then run diff to see where the outputs from the debug and release versions differ. (Of course you''ll need the same random seed, etc.)

---

I''ve done something like that. Just debugging to where the problem occurs. Normally that helps me with fixing the problem. But here it would for example crash in a call to glColor3ub, while all the data that that function receives is correct.

quote:

---

Once you find the general area, if you''re still not sure what the problem is, comment out various parts of the code until the problem stops.

---

Yeah I''ve done that as well. But while I know the problem shows up somewhere in the renderer engine, I have to comment out stuff that''s totally unrelated to the renderer engine if I want to crash not to occur. I really am flabbergasted about this one...

You can get a spoofing DLL for D3D (thats probably the wrong name, but anyway...). You put the DLL in your applications directory (its called d3d9.dll) and your app will use this DLL rather than the ''real'' D3D dll. The spoofing DLL just makes calls to the readl D3D library.
If you compile the spoof DLL in debug mode, you''ll be able to see what functuion the crash occurs in, and you''ll be able to check the parameters and stack in the debugger.

YES!

Finally, finally, finally, after weeks of headaches, I found the solution to my problem! A nasty little bug it was, I had to move one line of code in order to fix it, but since the fix no crashes have occured!

For those who are interested: My project has an abstract renderer class, implemented for both OpenGL and Direct3D. In that way coding for either library is very easy. The functions involved were:

SetMultiTextureLevel - set the amount of textures for each face
SetArrayData - set strided array data for vertices/normals/texture coordinates

The function SetArrayData checks the multi texture setting to determine how many texture coordinate texture pointers need to be set (using glTexCoordPointer in OpenGL). The problem with my code was that SetMultiTextureLevel was at one point being called AFTER SetArrayData. This is ofcourse a possible bug situation:

- suppose the MTL is set to 1
- then SetArrayData is called, setting the TexCoordPointer for one texture
- then SetMultiTextureLevel is called, setting the MTL to 2
- then some draw function is called

What''s wrong now? The problem is that the texture coordinate pointer for the second texture level isn''t set. In stead, some old setting for the second texture level is used. This ofcourse *can* cause problems! One ASSERT to assure SetMultiTextureLevel is never called after SetArrayData and these problems won''t occur again w00t!



Hopefully anybody understood what I just tried to explain

Congratulations. The only feeling more intense than the frustration of a bug you can''t find is the feeling you get when you expose and fix it.