Home Dashboard Directory Help
Search

Removing breakpoints with F9 in code editor doesn't remove them from breakpoint list by mclagett


Status: 

Closed
 as Won't Fix Help for as Won't Fix


3
0
Sign in
to vote
Type: Bug
ID: 535607
Opened: 2/23/2010 4:41:24 AM
Access Restriction: Public
0
Workaround(s)
view
4
User(s) can reproduce this bug

Description

My project is a C++ project. Although removing breakpoints in the code editor with F9 does remove them from the code editor and allows to continue running the project without them, it does not remove them from the Breakpoints list, so they reappear again the next time the application is run.
Details
Sign in to post a comment.
Posted by Microsoft on 11/25/2013 at 2:02 PM
Hi sdfwill and JackTripper,

Would you mind sharing your repro project with us?

Thanks,
Maria [Visual Studio Debugger]
Posted by sdfwill on 11/25/2013 at 6:45 AM
Problem still persists with VS2013. When is this going to be appropriately handled by the Visual Studio team?
Posted by IanBoyd on 9/30/2013 at 7:37 AM
It's not critical that this be fixed. It's just one of a few dozen other usability nightmares in Visual Studio. And with everyone on the team willing to rationalize it away as not a serious bug, the UI problems just keep hanging around. Year after year.

After year. After year.

Visual Studio's starting to resemble an open source project; each new pet feature goes in, without any regard to the usability or design of the entire system.

Posted by OfekShilon on 4/26/2012 at 1:25 PM
I suspect this might be a related issue:
http://connect.microsoft.com/VisualStudio/feedback/details/739131/commenting-a-c-code-section-with-breakpoints-can-make-them-un-deletable-with-f9
Posted by kipus0ep on 2/10/2012 at 5:02 AM
Just wanted to say this bug is really really annoying the h*ll outta me!
Posted by Microsoft on 4/27/2010 at 11:23 AM
Hi Mike,

I just wanted to let you know that I was able to repro this with the sample you sent, thanks. This will be fixed for the next major release of Visual Studio, although I don't see that it's likely to meet the bar for a servicing fix (QFE, service pack, etc.) for Visual Studio 2010. Would you agree with that? If not, I'll need a description of how this is significantly impacting you (still no promises, but we'll give it more consideration).

Thanks,
~Andrew
Posted by Microsoft on 3/24/2010 at 1:58 PM
Hi Mike,

Sorry I've been busy with other things currently, since we've been finished with bug fixing for 2010 RTM for a little while now. If this turns out to be be a bug it will have to be considered for the service pack. I'm going to be out of office for 8 days, so I'll look at this when I return.

Regards,
~Andrew
Posted by Microsoft on 3/3/2010 at 5:47 PM
Hi Mike,

I would definitely be interested to observe this happening.

Thanks,
~Andrew
Posted by mclagett on 2/28/2010 at 9:59 AM
Okay, actually generally this problem does not occur, I have discovered. I have only been able to consistently produce it in one scenario, which is not the one you suggest below. If I set and delete breakpoints (at either design or run time) on lines of managed code or even lines of C++ code that execute in a native stack frame, it works fine. After further investigation, I discovered that this only happens when I set and try to delete a breakpoint on an inline assembly statement. Actually what happens (and I recall this happening in VS 2008 as well) is that whenever I set a breakpoint on the line of assembler, another breakpoint gets set a few lines down from it (actually in another routine altogether). The phenomeon I was experiencing happened when I would delete the breakpoint itself, but leave the second breakpoint enabled. The breakpoint I deleted went away for the duration of the project (and the other one was never hit, because the code never calls that method). But when I would restart the program, both breakpoints were again enabled.

This can be reproduced in the sample I sent you, if you add back in a couple of routines that I had stripped out. I would be happy to send you the files with this extra code to substitute into the project I already sent, if you would like to see this occurring. I just noticed today that in the breakpoint window, when I set this breakpoint, (on the inline assembly code) the breakpoint that appears in the list has a + to the left of it, which when expanded shows the two breakpoints that were added.

This is not in my mind a severe bug, as I have figured out how to compendate for it. But you might want to be aware of it.
Posted by Microsoft on 2/25/2010 at 5:51 PM
Hi Mike,

It sounds like the issue that you are running into here is hwat we call "pending" vs "bound" breakpoints. When you set a breakpoint in the editor at design time, this is a pending breakpoint because it won't actually be bound to executable code until debug time. When you begin debugging, the debugger binds the breakpoint to each possible instance of that code's execution (this is a "bound" breakpoint).

So if that code is loaded into memory in more than one location (think individual threads, templates, etc.) there will be a bound breakpoint for each instance. When you press F9 in the editor during debugging, it deletes the bound breakpoint for that particular context, but if there are any other bound breakpoints, those will remain, and the pending breakpoint will not be deleted (the only way to delete the pending breakpoint at this point is to delete it from the breakpoints window).

Since this is only occuring when you are debugging, I suspect that you are hitting the pending vs the bound breakpoint issue.

Regards,
~Andrew
Posted by Microsoft on 2/24/2010 at 1:16 AM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Thank you
Posted by Microsoft on 2/23/2010 at 7:04 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.