🔒 Locked

Basic debugging in Visual Studio

Started by MauMan Sep 1, 2005 at 11:25 AM 6 replies 1.8k views

Original Post

Sep 1, 2005 at 11:25 AM

I hate the Visual Studio debugger with a passion. Other than setting static breakpoints and browsing primitive data types it seems to fall down. I was trying to set a conditional data breakpoint and it never triggered. So I wrote a simple program that I felt should not fail to break:

#include <string>

int
main( int, char** )
{
  std::string s = "String";

  s = "Longer string";

  s = "Even longer string";

  s = "A super duper really long string";

  return 0;
}

I then set a conditional data breakpoint on s to break if it's size is greater than 10. I set it by highlighting s, RMC/New Breakpoint..., select the Data tab, hit the "Condition..." button and entered the expression s.size() > 10: Simple breakpoint

I run the program and it never breaks. If I'm doing something obviously wrong, other than using Visual Studio, please let me know. BTW, I tried this in VS2003 and VS2005 Aug CTP

brataccas

Sep 1, 2005 at 2:06 PM

Hrm, well, putting a variable watch on s._Mysize and checking the condition s._Mysize > 10 will do what you're looking for. I couldn't get it to break on s.size() > 10 no matter what I tried, even though the debugger docs seem to imply this expression is perfectly okay - it evalutes just fine in the Watch window. If anyone can explain why the s.size() expression in the conditional breakpoint doesn't fire, I'd love to hear it.

MauMan

Author

MauMan

Sep 1, 2005 at 2:25 PM

Thanks for the reply! I know that digging into the internal data structure will work in this case but unfortunately in my "real" case the method does more than simply return a value. I was just trying to cook up a simple case since the complex case seemed to be failing.

The odd thing is that is that it seems to be called. In this simple example with the breakpoint in place it takes about 30 seconds to run the program. With no breakpoints it takes about 5 seconds to run.

MauMan

Author

MauMan

Sep 1, 2005 at 2:29 PM

Even though it's alot slower it does not seem to call it. I set a breakpoint in _String_base::size() and it's never called.

Damn debugger.

brataccas

Sep 1, 2005 at 2:35 PM

Yeah, I figured you probably knew that already (use the internal data structure) but I just wanted to be safe. =) I'm seeing the exact same thing you are and now I'm playing around with some even simpler cases to see if it can be isolated. You've got me very curious...please follow up here if you find anything out!

iliak

Sep 1, 2005 at 2:57 PM

Is Visual evaluating s.size() everytime it hits the break point or not ?

dave

320

dave

Sep 1, 2005 at 2:59 PM

Assuming the expression that the text box expects for the conditional expression is written in C then it might just not be a working feature.

ace

MauMan

Author

MauMan

Sep 1, 2005 at 4:44 PM

I'd come to the same conclusion as brataccas, you cannot set a breakpoint on a class, you have to set it on one of its data members. However, even if you do that it appears that the debugger's conditional evaluator cannot call functions or methods like the other evaluation fields in Visual Studio can.

I find this puzzling as one of the cannonical examples of conditional breakpoints for debuggers in general is a C-style string check like: strcmp(p, "Cool") == 0.

What I'm really looking for (and what started me down this path) is a generic conditional breakpoint. For example real debuggers like dbx allow you to do things like:

stop -if x > 10

or

stop -if myFunc() > 10

which will evaluate on every program statement the expression. It tends to be slow but it allows you to quickly track down certain classes of bugs easily.

It looks like Visual Studio's debugger does not support this or many other useful debugging constructs that other debuggers have had for over a decade.

The Visual Studio debugger is very shallow feature-wise. It epitomizes the "thin veneer on assembly" style of debugger that barely knows anything about what it is debugging. The nice thing about this type of debugger is it's easy to adapt it to different languages quickly. The bad thing is that it tends to not support debugging constructs natural to a language like stopping in a named method in C++

Visual Studio 2005 appears to be no better at the breakpoint level but at least it now has inspectors for the C++ standard library types. A glaringly obvious feature that should have been in VS6 and was inexcusably missing in VS2002 and 2003.

Sorry for the editorializing but I'm a bit miffed.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.