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

Bug 303926

Summary:

[breakpoints] proxyDisposed causes a deadlock

Product:

[Eclipse Project] Platform

Reporter:

Patrick Chuong <pchuong>

Component:

Debug

Assignee:

Pawel Piech <pawel.1.piech>

Status:

RESOLVED FIXED

QA Contact:

Severity:

critical

Priority:

CC:

darin.eclipse, pawel.1.piech, pchuong

Version:

3.6

Flags:

pawel.1.piech: review? (darin.eclipse)

Target Milestone:

3.6 M6

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
deadlock stackframe	none

Description Patrick Chuong

2010-02-25 11:16:43 EST

Build Identifier: HEAD

see the attached deadlock file.

Reproducible: Always

Comment 1 Patrick Chuong

2010-02-25 11:17:14 EST

Created attachment 160203 [details]
deadlock stackframe

Comment 2 Pawel Piech

2010-02-25 12:32:48 EST

Tisk tisk on me for calling fireModelChanged() inside a sync. section.  I would like to fix this along with the considerable refactoring in bug 301825.

Comment 3 Pawel Piech

2010-02-25 19:08:48 EST

I fixed this along with bug 301825, but it turned out to be more of a headache than I expected.  

The problem is that the model inside the BPM content provider needs to be protected with a lock, since with every change to it a correct delta needs to be created.  However, the firing of the deltas also needs to be protected by the same lock to make sure that the deltas are fired in the correct order.  So in order to avoid fireModelChanged() while holding this lock, I had to create a separate queue where the deltas are put into while holding the model lock, and are then posted by a separate job.

I still have one remaining concern about the integrity of the model data.  While there are (add/remove) deltas pending to be fired to the viewer, the viewer may come and retrieve data from the model.  If this happens then the delta will operate in the viewer on data based on a model that is different than when the delta was created.... leading to corrupted data in the viewer.  I'm not sure if there's much we can do about this actually, because the viewer updates themselves are posted to the viewer with some skid, so even if we were to synchronized updates with deltas in the content provider we may not solve the problem.  I think I'll just open a separate bug to investigate this issue by first writing some tests to reproduce, then work on a solution.