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

Bug 355828

Summary:	[breakpoints] Thread filter extension does not clean up old containers
Product:	[Tools] CDT	Reporter:	Marc Khouzam <marc.khouzam>
Component:	cdt-debug-dsf-gdb	Assignee:	Marc Khouzam <marc.khouzam>
Status:	RESOLVED FIXED	QA Contact:	Marc Khouzam <marc.khouzam>
Severity:	normal
Priority:	P3	CC:	cdtdoug, john, nobody, pawel.1.piech, shaijupnairp
Version:	8.0
Target Milestone:	8.0.1
Hardware:	PC
OS:	Linux
Whiteboard:

Description Marc Khouzam

2011-08-25 09:05:53 EDT

From Bug 349736 comment 3:

Shaiju wrote:
When debugging I found that if user applies/removes  the break-point filter the
on any break-point  ' IContainerDMContext  ' objects  of that debug session is
stored inside the   filter extension object (IDsfBreakpointExtension object )
corresponding to that break-point.  When the debug session (or launch ) is
terminated  these objects are not cleared from the filter extension object , it
holds these IContainerDMContext   object which in turns holds reference to
session, gdb process etc  all of which are actually dead.

This is cleared only when we exit the workbench. It may not be causing any
trouble at the moment but seems incorrect .

Comment 1 Marc Khouzam

2011-09-01 07:46:34 EDT

I was thinking that we do want some persistence about thread filters.  If the user limits a breakpoint to some threads, re-launching the program should have the breakpoint still limited to the threads.

The problem is that we compare the full context, which expects the same CommandControlDmc, which is not the case.  We probably just have to compare contexts more loosely.

Comment 2 John Dallaway

2011-09-01 08:56:59 EDT

(In reply to comment #1)

> I was thinking that we do want some persistence about thread filters.  If the
> user limits a breakpoint to some threads, re-launching the program should have
> the breakpoint still limited to the threads.

Is this possible in the general case?

We know that GDB will number threads in the order that it comes across them. We cannot assume that the target operating system will provide a thread name or thread ID which is both unique and constant across multiple launches. Some threads may not be created on every launch. Some applications may create large numbers of short-lived threads over time.

Comment 3 Marc Khouzam

2011-09-01 09:52:10 EDT

(In reply to comment #1)
> I was thinking that we do want some persistence about thread filters.  If the
> user limits a breakpoint to some threads, re-launching the program should have
> the breakpoint still limited to the threads.
> 
> The problem is that we compare the full context, which expects the same
> CommandControlDmc, which is not the case.  We probably just have to compare
> contexts more loosely.

CDI does not seem to have such persistence.

Any opinions on if we should try to persist the filter or not?  I vote for trying to persist.

Comment 4 Marc Khouzam

2011-09-01 11:52:59 EDT

(In reply to comment #2)
> (In reply to comment #1)
> 
> > I was thinking that we do want some persistence about thread filters.  If the
> > user limits a breakpoint to some threads, re-launching the program should have
> > the breakpoint still limited to the threads.
> 
> Is this possible in the general case?
> 
> We know that GDB will number threads in the order that it comes across them. We
> cannot assume that the target operating system will provide a thread name or
> thread ID which is both unique and constant across multiple launches. Some
> threads may not be created on every launch. Some applications may create large
> numbers of short-lived threads over time.

In the simple scenario I had imagined, the program was creating the threads always in the same order, so GDB would give the same id.

But you are right that this may not always be the case, and a breakpoint that makes sense for thread 10 of one run, may be relevant to thread 11 on the next run.  So, it would seem that with our current scheme, persistence is not really possible.

I personally feel that having to reset the thread filters each time is not user-friendly.  We should have a more deterministic scheme for the filter.  For example, using a user-given name to identify the threads (if such a name exists for the thread).

I think this is an enhancement on our current solution though.  I've opened bug 356491 to track that.

For the current time, I'll attempt to fix the current bug without any persistence.

Comment 5 Nobody - feel free to take it

2011-09-01 12:59:02 EDT

(In reply to comment #3)
> (In reply to comment #1)
> > I was thinking that we do want some persistence about thread filters.  If the
> > user limits a breakpoint to some threads, re-launching the program should have
> > the breakpoint still limited to the threads.
> > 
> > The problem is that we compare the full context, which expects the same
> > CommandControlDmc, which is not the case.  We probably just have to compare
> > contexts more loosely.
> 
> CDI does not seem to have such persistence.
> 
> Any opinions on if we should try to persist the filter or not?  I vote for
> trying to persist.

+1. I didn't do that for CDI because I thought that persisting thread ids could be confusing.

Comment 6 John Dallaway

2011-09-01 16:31:10 EDT

(In reply to comment #4)

> I personally feel that having to reset the thread filters each time is not
> user-friendly.

I agree that the current DSF behaviour is not user friendly. The CDI implementation re-enables breakpoints for all threads when an application is relaunched (as if the breakpoint had just been created). In the absence of a robust thread filter persistence mechanism, I think the DSF implementation should match the behaviour of the CDI implementation.

Comment 7 Marc Khouzam

2011-09-02 14:29:55 EDT

Resolved by the fix to Bug 355833.

Shaiju, if you have time, can confirm that you see things fixed as you expected.