Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 473
  • Last Modified:

debug vs non-debug executable

I complie my C/C++ application in 2 ways
1.  make (it creates a file in  ../x86_64/bin/executable)
2) make debug  (it creates a file in  ../x86_64/bin-debug/executable)

When I go to my cluster, I saw the executable that matches  ../x86_64/bin-debug/executable

1) What is the difference between debug and non-debug executables ?
2) why we need two different.
3) I tried overwriting the debug executable on cluster with non-debug one and some results were unpredictable even though its same code flow. not sure why?

Thanks!
0
perlperl
Asked:
perlperl
  • 4
  • 2
3 Solutions
 
ZoppoCommented:
Hi perlperl,

there can be many differences between debug and none-debug built binaries. Which differences exist depends on the compiler and used compile- and link settings.

The main reason to have two different builds is that debug builds can be easily debugged (see below) while none-debug builds offer best performance and maybe use less resources.

Some common difference are:

- debug binaries contain debug info which allows a debugger i.e. to find the line of source code at a breakpoint.
- debug binaries usually don't use any compiler or linker optimizations since those optimizations often make it quite difficult to debug the binaries.
- additional runtime checks may be inserted to debug binaries by the compiler so a debug build can i.e. show an error if pointer to an already released memory area is dereferenced.
- in debug binaries numeric variables which aren't explicit initialized are set to zero.
- usually a preprocessor define is used to ex-/include parts of code depending on the kind of binary. This is often used to i.e. trace messages in debug builds only to make it easier for developers to find bugs.

This list is not complete and may differ between compilers, but I hope this gives you an idea what's it about.

ZOPPO
0
 
ZoppoCommented:
Sorry, I forgot to comment you question 3)

There are different reasons why none-debug builds may give other results than debug builds. For example it can be some code is ex-/included as mentioned in one of the builds which affects the results. But from my experience most often those differences are caused by the mentioned implicit variable initialization. I.e. look at this code:
int c;
for ( int i = 1; i < 10; i++ )
{
 c += i;
}

Open in new window

This code usually works fine in debug builds since c is implicit initialized with 0. But in a none-debug build c is not initialized so before the loop starts it has any arbitrary value.

ZOPPO
0
 
perlperlAuthor Commented:
Thanks! Zoppo

1) so if the debug one
in debug binaries numeric variables which aren't explicit initialized are set to zero.

wouldn't this mask the error in an application while developing the code?

2) so the bottom-line is while developing an application, always run with debug binary to find bugs but ship it to customer with release version? What if there is an issue with release-version which we never tested while developing it
0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
ZoppoCommented:
Hi,

1.) yes, that's often a big problem but in some cases it's even good, especially to detect errors with uninitialized pointers. I.e. look at this code:
int *number;
int value = *number;

Open in new window

In a none-debug build this may work or may not work, this depends on the random address the uninitialized number points to. In a debug build the pointer number is set to NULL in a debug build so the code sureley fails and produces an access vialotion or segment fault.

So it's sometimes good, sometimes it's evil :o)

2.) this is how it's usually done. IMO of course developers should even test release builds. Before the software is released to the customer as release build it should be tested by testers/QA to find those bugs.

If a bug only appears in a release build an iterative method to find the cause it to temporary add some logging little by little to try to locate the error.

Another way I often use is to have a third build which is mostly a release build but doesn't use any compiler-/linker optimizations and adds debug info - I work with MS VisualStudio, there it's easy to configure it this way. With such a build it is at least easy to use a debugger and set breakpoints, but everything else (variable initialization, preprocessor defines, runtime checks) is the same as in the release build.

Maintaining three versions of course means more effort, but the last years I sometimes had problems where I'm sure there were no other way to find them.

ZOPPO
0
 
perlperlAuthor Commented:
That's a detailed and clear explanation. Thanks a lot Zoppo. It really helps.
0
 
ZoppoCommented:
You're welcome, I'm glad when I can help ...
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

  • 4
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now