Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 350224

Summary:	Breakpoint conditions validated too late
Product:	[Tools] CDT	Reporter:	Vladimir Prus <vladimir.prus>
Component:	cdt-debug-dsf-gdb	Assignee:	Project Inbox <cdt-debug-dsf-gdb-inbox>
Status:	NEW ---	QA Contact:	Jonah Graham <jonah>
Severity:	normal
Priority:	P3	CC:	cdtdoug, pawel.1.piech
Version:	8.0
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:

Description Vladimir Prus

2011-06-24 06:03:11 EDT

Build Identifier: 

1. Start a debug session, and create a breakpoint anywhere.
2. Edit breakpoint properties, and specify #$$$$ as the condition. Close the breakpoint properties dialog.

Observed effect: none.
Expected effect: since the session is running, and we can validate that condition, user should see an error message immediately. Breakpoint's condition should be reverted to the value it had before.

GDB of course does report the error, however MIBreakpointsManager.breakpointChanged logs it, without any UI feedback. The most straightforward approach, I think, would be throw an unchecked exception here, with the hope that it can be caught CBreakpointPropertyPage.setBreakpointProperties (after suitable modification), and both the error reporting and revert-to-last-value can be done there.

Reproducible: Always

Comment 1 Vladimir Prus

2011-06-24 06:05:55 EDT

In fact, lest my technical proposal obscure the overall picture, I think our goal should be:

    If the user specifies breakpoint condition, and we have a session running,
    and the condition is invalid in the running session, we should immediately
    show an error message.

Comment 2 Marc Khouzam

2011-06-27 09:45:01 EDT

Yes, better error reporting would be very valuable.

My only concern is if there is extra complexity for multiple sessions or even multi-process?  Can GDB report an error on a condition for one process but not for another?  I'm hoping that if the breakpoint installs successfully on more than one process, then an error will be identical for both processes.  Can you see a usecase where GDB would accept the condition for one process but reject it for another?

Comment 3 Vladimir Prus

2011-07-18 07:42:18 EDT

It is certainly possible that GDB will access condition in one process, but reject for another -- like, if you set a breakpoint in shared library, but use global variable specific to one of the processes that uses that shared library. Or, you set a breakpoint which is valid in both processes accidentally -- like two unrelated files with the same name.

But, I think in that case we should not try to do anything fancy. User asks for a breakpoint with some condition to be inserted in two processes, and we fail. The user should either edit the condition, or make the breakpoint specific to one process somehow. Is there ever a point in silently ignoring the problem for one of the processes?