Weirdest bug ever
Author
Okay, I have this line in my code:
mSystem = inSystem;
Surrounded by break points. Before the line is executed, mSystem = 0, and inSystem is a valid pointer. After the line has executed, nothing has changed, mSystem is still 0. What on earth can cause this to happen? How can a line of code just be completely ignored like this?
are you running in release mode by chance? the debugger frequently lies in release mode.
-me
-me
Author
Thanks that's sorted it right out! Odd thing is it was doing all kinds of other crazy stuff, like assigning wrong values to pointers and literally skipping out lines of code. Now it runs perfect! Thanks again!
In general I don't often find the debugger to be inaccurate during release builds, although I have seen it happen on occasion for no discernable reason. I've found that usually[/] this kind of behaviour is caused by out-of-sync debug information or misconfigured debugging options.
Glad to see you've already got it fixed, but I just wanted to point that out incase you or anyone else run into something similar.
Glad to see you've already got it fixed, but I just wanted to point that out incase you or anyone else run into something similar.
In release mode, due to optimizations, there is not necessarily any kind of ordered correspondence between assembler opcodes and lines of course: you can't meaningfully say "this line is represented by machine code bytes 0..X, then the next line is represented by bytes X+1..Y, etc.". So it should be no surprise that what the debugger tells you is effectively garbage.
That's why the other option besides release mode is called *debug mode*. [smile]
That's why the other option besides release mode is called *debug mode*. [smile]
More often the problem is that you compiled in debug mode yesterday. Then made changes and compiled in release. Then made more changes. Then again. Then you tried to debug, using that debug info generated yesterday. It's no surprise it's out of sync.
When I do systems programming with a lot of SMC, I build in release mode with all optimizations off. This keeps the executables small without all that debugging stuff written to your program and prevents the compiler from removing and ordisplacing your code. Granted your code will run a bit smaller, and at this point it does benefit writing in an optimized style that doesn't rely on the compiler to fix up crappy coding.
Optimizations are not 'fixing up crappy code'. You cannot beat the compiler. Period. It can do things you can't without writing it in assembly, and then it will still write better assembly than you.
Quote:Original post by Deyja
Optimizations are not 'fixing up crappy code'. You cannot beat the compiler. Period. It can do things you can't without writing it in assembly, and then it will still write better assembly than you.
good examples of things it can do that is very hard to do manually is platform specific optimizations,
you can make multiple optimized builds for different hardware architectures such as IA32 and AMD64 without changing a single line of code,
even if you are an asm expert and know everything there is to know about both platforms im pretty sure leaving it to the compiler would be the best option (atleast it saves time)
Quote:Original post by Deyja
You cannot beat the compiler. Period.
Never speak in absolutes. Ever.
It is possible to beat the compiler, even without resorting to ASM. One just shouldn't seek to do so from the start.
CM
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
