Sign in to follow this  

SDL debugging release version

This topic is 3597 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

any tips / tricks / known methods that would cause runing the release build of an SDL app to crash? basically debug build works fine, release build works fine inside visual studio but running the app outside of visual studio (with dll's) causes a black render window for a minuite which ends in the vis sstudio debugger message. now if i could get some kind of output i could trace through where it gets to, but unfortunately this is not the case, any ideas?

Share this post


Link to post
Share on other sites
Create a log file, log many things to it. Always check return values on all SDL functions. Throw exceptions with meaningful information when you encounter errors. Catch the exceptions in main(), print meaningful information and bail.

You should still be able to get some debugging information. I've never debugged a release build, but I would like to think you'd at least be able to get a stack trace. A simple stack trace can go a long way with figuring out where it went wrong.

Share this post


Link to post
Share on other sites
sounds like a file isn't in the right location. When you run in VS the current working directory to find files is the directory with the project file in it. when you double click the exe it is where ever the exe resides. To me it sounds like it isn't finding a file and you are not checking error codes and running with out some data loaded that you expect to be loaded.

Share this post


Link to post
Share on other sites
My understanding is that, when compiling the debug version, the compiler inserts code at the start of each function that sets all local variables to 0. The release version does not include this extra bit of housecleaning code, which means that your local variables will initially contain garbage until they are assigned a value.

Share this post


Link to post
Share on other sites
It would depend on the compiler. Some don't do anything special with the stack in debug mode. In this case, MSVC fills uninitialized stack variables with the 0xCC pattern. So four byte uninitialized variables would look like 0xCCCCCCCC.

Share this post


Link to post
Share on other sites
Quote:
Original post by Stowelly
cheers guys.

turns out it was a variable that i hadnt initialised, but must be some kind of feature in debug that makes it not crash ?? maybe


That can be a tricky bug. Anything that touches the stack can effect the outcome of that. Calling functions in a different order, changing the stack variables in another function called before it, changing the size of a structure or class, etc. Thankfully, there are compiler warnings about this. You are reading your warnings and paying attention to them, aren't you? Your code should be compiling with 0 warnings. Read every warning. Understand every warning. If it's not a problem, cast or whatever you have to do in the code to make it go away. If it is a problem, fix it so the warning goes away.

Share this post


Link to post
Share on other sites

This topic is 3597 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this