[Webinar] Streamline your web hosting managementRegister Today

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 480
  • 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
The new generation of project management tools

With monday.com’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.

 
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

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

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