Debug in Visual C++

Question

3.00/5 (2 votes)

See more:

In my programs in Visual C++, sometimes when I write new code, build and run,it doesn't work. But when I add break points, run in debugger , it gives the right answers.

Because just couple of minutes back I was showing my work to my manager, where in I was asked to put new values for testing n it never worked n later after he left, I tested in debugger n it worked!!

I'm experiencing this kind of behaviour for the fifth time .Does anyone know why ?

Posted 8-May-12 4:21am

Sumal.V

Updated 8-May-12 4:34am

Sandeep Mewara

Add a Solution

4 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

michaelmel · Answer 1 · 2012-05-08T16:34:00

Solution 3

Most commonly, your problem of Debug build running correctly and Release build not running, is due to using constructs such as:

ASSERT (a = func());

In release version "func" is not called - in fact the whole ASSERT statement is substituted with nothingness.

Execution speed unless you have a very time-sensitive real-time application is NOT likely at all.

Posted 8-May-12 16:34pm

michaelmel

Updated 8-May-12 16:36pm

v2

Comments

[no name] 9-May-12 1:40am

"Execution speed unless you have a very time-sensitive real-time application is NOT likely at all."
This conclusion is not correct. Any RT programmer knows this. Timing is comletely different in debug vs release versions.

http://preshing.com/20110717/the-windows-heap-is-slow-when-launched-from-the-debugger

michaelmel 9-May-12 6:10am

Have you even read the question and my answer?

I am saying it is NOT important UNLESS it is a R/T application.

From the question it doesn't sound at all as a R/T app.

ARopo 10-May-12 6:36am

Solution 3 could indeed be the case, there are many reasons why debug and release can give different outcomes, I've certainly been tripped up by putting vital code into an assert macro.

ARopo · Answer 2 · 2012-05-08T04:36:00

Is it that you break point is holding things up long enough for some precondition to happen?

Is it that it work when you switch active windows to the debbuger?

Are you sure your running the same binaries each time? in this situation I sometimes delete all occurances of my dlls/exe then rebuild and run

If you are running release or debug Could this be the reason:

One common problem is when you build release you can get a different value in variables that are not initialised e.g. the following will behave differently

C++

BOOL myBool

if (myBool)
   // this will be the path in release
else
   // this will be the path in debug

void* pMyPointer

if (pMyPointer)
   // this will be the path in release
else
   // this will be the path in debug

The reason for this is that the debugger zeros memory, in release mode the memory contains previous data this is why it is important to inialise varables

e.g.

C++

BOOL myBool = FALSE;
pMyPointer = nullptr;

Aescleal · Answer 3 · 2012-05-08T04:32:00

Depending on what version of VC++ you're using the debugger might initialise memory differently from when you run it from the shell. So you might be reading/writing somewhere you shouldn't which crashes the release mode version but due to whatever the debuggers throwing in there it happens to be valid...

As a quick set of tips:

- Don't use the debugger 95% of the time, use unit tests to verify your code and run them every time you build
- Fork out for a copy of PClint and use it to check that you're not doing something naughty in your code - like dereferencing an uninitialised pointer
- Use the latest compiler you can get, newer compilers are better at warning about dangerous things

Cheers,

Ash

Reegan Durai.m · Answer 4 · 2012-05-08T19:26:00

Solution 5

these used for debug in vc++ ctrl+shift+b

Posted 8-May-12 19:26pm

Reegan Durai.m

Debug in Visual C++

4 solutions

Solution 3

Solution 2

Solution 1

Solution 5

Add your solution here

Preview 0