Cool, after days and days of debugging, I’m ready to release my work!
Yeah nice, but what if your ‘release build’ crashes? Well read on, to see what might have changed.
Before knowing the differences between Debug and Release build, you should know that they are really different. I learned it the hard way. Just today, I wanted to show someone my half cooked software, so I quickly told my Visual Studio 2010 to make a release build for a demo. And I was really going to upload it on sourceforge, for anyone and everyone to download. Sweet, my system hanged.
Imagine what would have happened had it not crashed on my system (crashes are random, at the worst they don’t happen during testing), but on users computer. Uh oh, disaster.
So lets see what changes when you change from Debug configuration of build to Release build.
Also note that, there can be many more configurations, like “Debug DLL”, “Universal Release” etc. Its just how you configure it, and what name you give to your configuration.
This is the main reason you package your final software with “Release” build. While debugging there are debugging symbols, extra lines of code, and the IDE’s book keeping attached with your software. So naturally your debug build is slower and heavier by several orders. For instance my debug executable was 6.15 MB while release executable is only 2.74 MB. See how it has doubled.
In fact there is an option in IDE to turn off optimization, as optimization by compiler, modifies code in unpredictable manner, something which can make debugging hard or even impossible.
2. The protective cover is gone
If you are facing the trouble, “software crashes in release, while in debug it was running fine”, your trouble spot is most probably this one.
In debug mode, the compiler is gentle on you and provides a protection against your um.. erroneous code, by
- allocating extra memory before and after, each block of storage. And this extra space is initialized with values like 0 for integers. Thus your attempts to access beyond array size won’t let you corrupt some other data structure.
- it also initializes variables to some safe value. Like the pointers are initialized with NULL value, or some ridiculous value that will cause segfault, if you try to access it. Thus the problem of wild pointers would not appear in debug, but cause troubles in release build.
So if your release build is crashing, you should first check for out of bound access and uninitialized variables.
3. Use Release Library for Release build and Debug Library for Debug build
Well, this is where I faulted. I was using debug library, of framework my program was dependent upon for Linking. While configuring project settings, I made these settings default, and thus they were used for both Debug and Release build. As long as I was debugging, everything went fine, but my release build, well crashed…
Most third party libraries support different builds, like Release or Debug, Static or Dynamic and so on. So while, you are developing code, and will be debugging actively, it is appropriate to have debug libraries linked to your project. This will aid debugging as, the library will provide much more detailed messages for warnings and errors.
But in case of release, only use Release version of library for linking. Release build of libraries are optimized, and fail silently in case of error (you don’t want to show your users a scary message, right?!).
4. Test your program on various systems
Another major difference in debug and release, is that while debug build was playing in small backyard (your computer), the release build will be playing in open fields (users computer, or even smartphones, tablets etc.). You spend extra time, configuring your environment to ensure, your program runs. But on users system, you can’t do it. Can you?
You should test your program on different types of computers, and different operating systems, if your program is multi-platform. On some computers you find that there is some DLL missing. You may discover that your Swing application, looking beautiful on Ubuntu, looks messed up on Windows. You may notice that your software takes ages to open up, or that your game is running to fast, on some computers.
All this just increases your work. You may have to go back, add code or files to ensure that everything goes fine. But this extra effort just increases the usability of your software, which is very important.
That’s all for the differences. Best of Luck for your release build!
Courtesy of Tech Blog.