breakpoint traps on wrong line (msvc 7.1)

  • Thread starter Thread starter Jay
  • Start date Start date
J

Jay

Guess this has probably been reported already. Seems if you don't use {}
with for/while etc., the debugger stops at the wrong line. In the example
below, I had a breakpoint at line 6 but the debugger stopped in every
iteration of the loop.

Jay



1. for (int index=0; index < line_buffer.Length (); index++)

2. if (line_buffer [index] == '\t')

3. line_buffer [index] = ' ';


4. // }}}

5. //


6. terminator_holding_chars = ""; // <- breakpoint here
 
Guess this has probably been reported already. Seems if you don't use {}
with for/while etc., the debugger stops at the wrong line. In the example
below, I had a breakpoint at line 6 but the debugger stopped in every
iteration of the loop.
Click to expand...

Jay,

Are you debugging a debug or release build of your code?

You should certainly expect strange behaviour debugging a release
(optimised) build.

Dave
 
David Lowndes said:
Jay,

Are you debugging a debug or release build of your code?

You should certainly expect strange behaviour debugging a release
(optimised) build.

Dave
Click to expand...

This is definitely the debug configuration. Sure I'd expect an optimizing
compiler to do very peculiar things to the code (I know, I write them :-).
This isn't a serious problem, but I noticed in previous versions, when using
single step the debugger appeared to go to strange places sometimes,
particularly with switch statements. I think what's happening is that the
compiler inserts an extra 'dummy' statement at the end of a for loop so that
you can see the consequences of the last statement

e.g. in

for (;;)
{
bool ok = f (x);
}

you wouldn't be able to see the 'ok' value (with single step) unless there
was some other statement following it.

Now, in the example above, you can put a breakpoint on the '}' which works
fine. The problem is if you don't use {}, the debugger gets confused where
this dummy statement is e.g.

1. for (;;)
2 bool ok = f (x);
3.
4. int a=1;

The debugger *should* recognise that it's ok to put the dummy statement (and
indeed a breakpoint) at line 3 (i.e. at the *end* of line 2) but I guess it
has certain rules that prevent this. So it moves it to line 4. Consequently,
if you really intended to put the breakpoint at line 4, the compiler tests
it for a breakpoint in the loop and traps there by mistake.

Anyway, I don't know how the compiler team have implemented this so I'm
guessing a bit and if you ask them, you might well get the answer it's 'by
design' as it might be quite awkward to change.

Jay
 
Jay,

You're right.

As a proponent of always putting in the curly brackets, I've never
noticed this myself.

Let's see if someone from MS spots your post and gives us the nitty
gritty, if they don't, I'll try to raise your question with them.

As you say, it's probably "by design", but it's best to be sure.

Dave
 
Yes, this is a known issue, it should be fixed in the Whidbey release. I'll
have someone verify that it is.

Ronald Laeremans
Visual C++ team
 
Back
Top