Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 492810 - Lockout/Deadlock when continuing to work while committing files
Summary: Lockout/Deadlock when continuing to work while committing files
Status: RESOLVED DUPLICATE of bug 487209
Alias: None
Product: EGit
Classification: Technology
Component: UI (show other bugs)
Version: 4.2   Edit
Hardware: PC Windows 10
: P3 normal (vote)
Target Milestone: 4.4   Edit
Assignee: Thomas Wolf CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-02 07:01 EDT by Ed Willink CLA
Modified: 2016-05-07 05:56 EDT (History)
1 user (show)

See Also:

Attachments
Screenshot of deadlock (264.69 KB, image/png)
2016-05-02 07:01 EDT, Ed Willink CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Willink CLA 2016-05-02 07:01:29 EDT 
Created attachment 261406 [details]
Screenshot of deadlock

The attached screenshot shows a deadlock caused by:

Commit files
<lose patience waiting for conformation>
Select a branch
Delete the branch
<conformation dialog causes deadlock>

I think the problem is that the "Delete Branch" dialog is the active model dialog and it loses focus when the commit conformation pops up. Hence a deadlock. Have to kill Eclipse. Therefore MAJOR.
Comment 1 Ed Willink CLA 2016-05-02 07:05:39 EDT 
Trying again after restarting Eclipse, there is clearly a problem with the Delete Branches Progress Information. It does not acquire focus and so does not support Cancel.
Comment 2 Thomas Wolf CLA 2016-05-02 12:48:38 EDT 
Looks like a duplicate of bug 487209. What EGit UI version did this occur in? Can you reproduce it with the latest nightly build from http://download.eclipse.org/egit/updates-nightly/ ?
Comment 3 Ed Willink CLA 2016-05-02 14:29:50 EDT 
Certainly looks the same.

The fix seems to be a simple fix of a smelly programming idiom. I suggest a search for all similar instances of the smelly idiom and/or a run-time assertion that a ModalDialogShellProvider is in use.
Comment 4 Thomas Wolf CLA 2016-05-02 16:01:40 EDT 
(In reply to Ed Willink from comment #3)
> Certainly looks the same.
> 
> The fix seems to be a simple fix of a smelly programming idiom. I suggest a
> search for all similar instances of the smelly idiom and/or a run-time
> assertion that a ModalDialogShellProvider is in use.

The smelly idiom is throwing a dialog at the user from a background job. Unfortunately there's no simple grep for that. As far as I'm aware of only the push and fetch result dialogs cause this, and all instances where those are opened asynchronously have been fixed in bug 487209.

Could you please answer my two questions from above?
Comment 5 Ed Willink CLA 2016-05-04 08:11:35 EDT 
(In reply to Thomas Wolf from comment #2)
> What EGit UI version did this occur in?

4.2.0 / 4.3.0 - seems my two installations picked up different versions

> Can you reproduce it with the latest nightly build from
> http://download.eclipse.org/egit/updates-nightly/ ?

4.4.0-20160426 seems much better.
Comment 6 Thomas Wolf CLA 2016-05-07 05:56:04 EDT 
Feel free to re-open or to report a new bug if it occurs again with EGit 4.4.0 or later.

*** This bug has been marked as a duplicate of bug 487209 ***