0

I'm having a problem with my project where it operates fine when compiled in debug mode, and works fine in release mode while the debugger is attached in Visual Studio, but if I run it in release with no debugger, I get an access violation deep within bullet physics.

The access violation seems to happen at btVoronoiSimplexSolver::updateClosestVectorAndPoints(void) C++, I only now this because Windows gives me the option to debug after the crash. I have the same problem when it's compiled with GCC on Linux, however.

My question is: what changes between having the debugger attached and not attached that could cause this problem? Why doesn't this crash occur when the debugger is attached, and is there any way for me to set the debugger to catch this sort of problem?

Karl Jacques
  • 63
  • 6
  • 1
    The debugger might slow things down, which could protect you from race conditions. If you really want to solve the problem then I recommend reading http://sscce.org/ – David Grayson Jan 14 '15 at 19:12
  • 1
    If you can run it on Linux, try running it with valgrind. It might be able to tell you where the access violation is and possibly all the other violations leading up to the crash. – cup Jan 14 '15 at 19:14
  • You're running the program differently. Doesn't matter if the difference is attach/not attach a debugger, running it by "double-clicking on it from Explorer" or from the command-line, etc -- a program that has bugs can and will exhibit different behavior. – PaulMcKenzie Jan 14 '15 at 19:16
  • 2
    You should also note that in Debug mode memory is automatically 0-initialized; this is not the case in Release mode. If you forgot to properly initialize variables or memory you will be using garbage values in Release mode, which leads to undefined behavior. See [here](http://stackoverflow.com/a/312352/1339615) for more info. – Julian Jan 14 '15 at 19:31
  • You can compile with debug symbols but otherwise in release mode. The stacktrace is sometimes muddled a bit due to the compiler reordering things, but you should be able to figure out what's wrong. – Ulrich Eckhardt Jan 14 '15 at 19:56

1 Answers1

2

In case this can help anybody in the future - this issue was caused by me performing a placement-new in a block of memory that wasn't big enough to hold the object, no doubt overwriting some memory belonging to bullet physics.

Karl Jacques
  • 63
  • 6