-2

I have to set up remote debugging for a multi threaded application running on a embedded device. C++ is the language.

I've gotten so far and got the remote debugging working for a simple application, but when applying the same procedures on the multi threaded giant just don't work (the application starts behaving unpredictably when built with debug). There was no stopping of the execution (no breakpoints), just a continuous standard run, just with debug symbols.

What would cause a failure in debug mode in this environment? (once again, no breakpoints in debug mode, just continuous running)

Improve this question
1
  • 1
    I edited your question to be more focused and on-topic, but it still needs more information in general to be objectively answerable. Please consider editing to add more details.
    – user22815
    Commented Oct 2, 2014 at 2:17

2 Answers 2

Reset to default
1

Not really enough information to go on, but anyway...

First and foremost, properly written and bug-free code does not fail when build in debug mode. The likelihood is that you have uncovered bugs you didn't know where there.

Generically, across all kinds of applications, the commonest reason for a debug build failing is the difference in memory layout (triggering an otherwise silent bug). Different initialisation values (debug code often fills unused space with strange bit patterns) or different spacing or placement will all do it. A less common reason is the different level of optimisation.

Specifically, for multi-threaded applications, the commonest reason is timing. Debug code runs slower and either exposes or covers up race conditions.

Bottom line: you've got bugs to fix. Be thankful that debug mode has exposed them for you.

Improve this answer
2

Since it's in C++, it could be a lot of things.

First and foremost, in debug mode, in most compilers, uninitialized variables will be filled with zeroes. In release mode, in most compilers, your uninitialized variables are filled with random garbage.

Another likely possibility is that a buffer overflow or other pointer malady (perhaps caused by uninitialized behavior above) is corrupting slightly different code due to the optimization differences between debug and release.

There's a bunch of others, but without more info it will be tough to say.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.