Comments on: Rant ^ 3 (Debug vs Release)

By: Lumooja

Lumooja — Mon, 15 Jun 2009 10:47:21 +0000

The only difference between Debug and Release mode in BlitzMax I am aware of is that BlitzMax calculates Floats with different accuracy in Debug and Release mode.
To fix this bug, don’t use Floats, but Doubles (remember to put each constant number also as double, for example 9:Double, or 12.0:Double). They are also faster, as my various tests have shown.

By: ASk

ASk — Sun, 14 Jun 2009 16:36:26 +0000

Seriously, any programmer who’s worth something has to know how to debug code running in release mode. Whether that means reading -O3 assembly dumps or using printfs to their full capacity (beware of stack layout changes!) – one should do it.

Regardless, if your code works in debug mode but not in release mode, first, try to build in release mode without optimizations, and if it works then, somebody is playing not nice with memory, and that somebody is you.

Since you are on Windows, your only real option is CrtMemoryDebug or BoundsChecker.

By: Ovogame

Ovogame — Sat, 13 Jun 2009 20:16:11 +0000

FYI, in release the machine code is optimize big time. This is why the code is completely different from the debug version. Like everybody said, it is 95% a certainty that you are doing something bad with memory. It could range from unitializade variable (debug set the memory to zero, release don’t) to writing out of bounds. I’m surprised you never seen this kind of problems before, it’s pretty commun.

BTW, once (about 10 years ago) I had a bug in release mode that I couldn’t identify in debug. Surprisingly it was the compiler (MSDEV) that was just creating bugged code in release. I was very lucky that it was happening in a very simple and short function, I was able to track it down in asm code. That was really surprising and scary… but it only happen once in 25 years programming.

By: Anonymous

Anonymous — Fri, 12 Jun 2009 21:08:20 +0000

hi,

not so long ago i had your problem with a HUGE game (about 40 projects in visual studio, each project a considerable amount of code).
No warnings, no errors. Game just crashed or worked weird in release and perfect in debug.
The biggest part of the problem is to identify the source.
From experience i can tell you that visual studio is somewhat more permissive with what it lets you to do with the memory in debug. For ex
in debug u can do this: memcpy(dest, source, size_of_source+1).
And it won’t crash in debug. EVER :)
In release it will crash from time to time, depending where source+1 memory points at :).
So check your memory operations.
If you use multithreading use one of intel’s tool to find problems (i believe that this is not the case with your problem ). Most defenetly something that you do with the memory is bad :). That is my view about it at this moment now.

By: Jake Birkett

Jake Birkett — Fri, 12 Jun 2009 18:40:51 +0000

Can you get the source for the module and compile that with Print commands in it instead? (it’s what I do with my framework, which is not a module yet)

By: Juuso

Juuso — Fri, 12 Jun 2009 17:51:23 +0000

Printf… (of course one problem with this is the fact that collision stuff also happens “inside” Leadwerks modules, so I have to do trial/error for various parts in my code).

@Marco: and to add… naturally I do stuff in chunks… but I always have tested only “does it work without errors/warnings in debug mode”. I guess that needs to change too…

By: Juuso

Juuso — Fri, 12 Jun 2009 17:49:27 +0000

Thanks guys for the support. Psycho’s statement was especially inspiring: “Let us know where the problem was. So we can laugh too… ;)”

@Marco: To be honest, I had never known that debug & release modes would work differently. (Oddly enough, I’ve been doing debug/releases for like half a decade and had never heard anyone having problem like this)

Btw – I have no threads.

(And btw II, I’m using Leadwerks with BlitzMax / Blide)

By: Val

Val — Fri, 12 Jun 2009 16:55:14 +0000

long live printf debugging!

By: Brian 'Psychochild' Green

Brian 'Psychochild' Green — Fri, 12 Jun 2009 09:55:38 +0000

The way to find this type of problem is to go old-school: “printf debugging”. It’s ugly, but it often works to narrow down the problem. Go to your collision code and have it spit out values relating to collision. Figure out where your bad values are, then trace back to the source of the problem. It’ll probably be an uninitialized variable or out-of-bounds array reference.

If adding print statements seems to fix the problem, then you probably have a timing or threading issue, as people have mentioned above.

Hope that helps. Sometimes the ugly method works. :)

By: psycho

psycho — Fri, 12 Jun 2009 09:40:35 +0000

Unitialized variable, obviously.

The good news is that it always comes out, however hopeless you may feel.
I’ve been through hundreds of these situations, but never it has remained hidden when I tried hard to find it.

Let us know where the problem was. So we can laugh too… ;)