Bugzilla – Full Text Bug Listing
| Summary: | >20 error dialogs at once plus > 20MB in .log | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Dani Megert <daniel_megert> |
| Component: | Resources | Assignee: | John Arthorne <john.arthorne> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P1 | CC: | cherie.wong, jared_burns, kai-uwe_maetzel, max_sigalov, wassim.melhem |
| Version: | 3.0 | ||
| Target Milestone: | 3.0 M6 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Dani Megert
This is an issue with the locking mechanism. A number of problems: 1) Deadlock was detected (see bug 46960) 2) Invalid assert was causing failure in finally block 3) Cascading assertion error causing lock states to be invalid Fixed 2) and 3). Deadlock remains and VCM team is investigating. The current fix seems to make it less likely but still possible (we had about 20 parallel checkouts before it failed). *** Bug 46907 has been marked as a duplicate of this bug. *** *** Bug 46960 has been marked as a duplicate of this bug. *** *** Bug 46878 has been marked as a duplicate of this bug. *** I got this on 200311192030 with the following steps: 1. Set up a connection to dev.eclipse.org and begin a checkout of 15 projects. 2. While the projects are being checked out in the background, use the PDE "External Plug-ins and Fragments" to import all plug-ins except the 15 that are being imported from CVS. 3. The CVS checkout fails with a deadlock like the one reported above. Stack traces available. Here are the steps to reproduce:
- Assume rules Root, P1, P2
- Root conflicts with P1 and P2
- P1 and P2 do not conflict with each other
1) Job1 acquires P1
2) Job2 acquires P2
3) Job3 waits on Root (which is conflicting with P1, so Job3 is really waiting
on P1 in the graph). Graph is now:
P1 P2
J1 1 0
J2 0 1
J3 -1 0
4) Job4 waits on P2
5) Job1 releases P1
6) Job2 releases P2
7) Job3 can now proceed. Replaces P1 in graph with Root
Root P2
J3 1 0
J4 0 -1
8) Job5 waits on P2, which conflicts with Root, so Job5 is waiting for Root in graph
Root P2
J3 1 0
J4 0 -1
J5 -1 0
9) Job3 releases Root
10) Job4 acquires P2, but is recorded in graph as Root since they conflict
-> Now graph is in a bad state. It looks like this:
Root P2
J4 1 -1
J5 -1 0
The J4/P2 value is stale and will never be removed!
Leaving open for now because further testing is required. However, a fix and regression tests have been submitted for 3.0 M5. An improved fix has been released and it has been running for a week or so with no further problems. New regression tests have been added to test these conflicting rule cases. |