Jump to content
  • Advertisement
Sign in to follow this  
TheOddMan

Weirdest bug ever

This topic is 4476 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
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!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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)

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!