Bugzilla – Full Text Bug Listing
| Summary: | Threading flaw with org.eclipse.emf.transaction.util.Lock | ||
|---|---|---|---|
| Product: | [Modeling] EMF Services | Reporter: | Min Idzelis <min123> |
| Component: | Transaction | Assignee: | Boris Gruschko <boris.gruschko> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | ahunter.eclipse, jlescot |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | 283446 | ||
| Bug Blocks: | |||
Retargeting the right Product/Component David, shall I assume that you don't want to fix this bug? (I didn't notice it, sooner, because it is still assigned to you) Initially the bug was open against EMFT Ecore Tools component and was assigned to David by default. While retargeting to EMF Transaction, I did not noticed that David was still assigned, so you were right while reassigning it. Hi Min, If I understand the issue correctly, the fix for 262175 should fix this issue too. Can you confirm this ? Thanks in advance, Boris Yes. This bug seems like a dup of bug 262175. The fix over there should also fix this bug. However, the fix seems a bit excessive. Now the UI will hang anytime any job or any thread with beginRule() has invoked acquire on the ILock. Ideally, we need to get the rule stack associated for the active thread, and see if any one of those rules is non-null, not just the "currentJob". I've opened up bug 283446 to track the ability to get the active rule stack. (In reply to comment #5) > Yes. This bug seems like a dup of bug 262175. The fix over there should also > fix this bug. [...] Can you confirm this was indeed the case, that this issue no longer exists for you? (In reply to comment #6) > (In reply to comment #5) > > Yes. This bug seems like a dup of bug 262175. The fix over there should also > > fix this bug. [...] > > Can you confirm this was indeed the case, that this issue no longer exists for > you? This issue still does exist. Since it is possible to get the rules started within a Job with a null scheduling rule this should be easily fixable. See Job.getJobManager().currentRule() this should replace the existing code at line 276 in Lock.java: final Job currentJob = jobmgr.currentJob(); final ISchedulingRule jobRule; if (currentJob != null) { // running as a job? Cannot use JobManager.beginRule() to show the // "UI blocked" dialog jobRule = null; } else { jobRule = new AcquireRule(); } This is a duplicate of Bug 306987 that has been fixed in Helios M7 (last week in fact). *** This bug has been marked as a duplicate of bug 306987 *** |
Build ID: Eclipse 3.4M6a Steps To Reproduce: in uiSafeAcquire() the following code is used: final Job currentJob = jobmgr.currentJob(); final ISchedulingRule jobRule; if ((currentJob != null) && (currentJob.getRule() != null)) { // running as a job on a scheduling rule? Cannot use // JobManager.beginRule() to show the "UI blocked" dialog jobRule = null; } else { jobRule = new AcquireRule(); } This is used to determine if a Job can be used to acquire the lock. It turns out the currentJob().getRule() may return null when there is a Job active, but it has no rule set on it. Instead, the a rule was acquired within the run() method of the job by using JobManager.beginRule(). I think the only way to solve this is to request API from JobManager to get the active "ruleStack" for the current Thread. A test case not ready yet, but is pending. When it's ready it will be attached to this bug. More information: