Bug 284856 - NPE when trying to overwrite changed file with content from local history
Summary: NPE when trying to overwrite changed file with content from local history
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Team (show other bugs)
Version: 3.6   Edit
Hardware: PC Windows XP
: P5 normal (vote)
Target Milestone: 3.6 M1   Edit
Assignee: Krzysztof Daniel CLA
QA Contact:
URL:
Whiteboard:
Keywords: bugday
Depends on: 107082
Blocks:
  Show dependency tree
 
Reported: 2009-07-28 09:20 EDT by Markus Keller CLA
Modified: 2009-12-10 06:30 EST (History)
3 users (show)

See Also:


Attachments
Patch (1.90 KB, patch)
2009-08-03 06:06 EDT, Natalia Bartol CLA
no flags Details | Diff
Patch_2.0 (3.47 KB, patch)
2009-08-04 08:01 EDT, Natalia Bartol CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Keller CLA 2009-07-28 09:20:18 EDT
HEAD (including fix for bug 107082)

In the History view, show local history for a file, select an old version, and choose 'Get Contents' from the context menu.
=> NPE below.
=> Expected: confirmation dialog

The problem is that org.eclipse.team.internal.ui.history.LocalHistoryPage.confirmOverwrite() creates an IconAndMessageDialog in a non-UI thread, which worked fine before but is now blocked (with the fix for bug 107082).


!ENTRY org.eclipse.team.ui 4 0 2009-07-28 15:03:24.700
!MESSAGE Internal error occurred.
!STACK 0
org.eclipse.core.runtime.AssertionFailedException: null argument:Invalid access from non-UI thread.
	at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:85)
	at org.eclipse.jface.dialogs.IconAndMessageDialog.getSWTImage(IconAndMessageDialog.java:271)
	at org.eclipse.jface.dialogs.IconAndMessageDialog.getQuestionImage(IconAndMessageDialog.java:260)
	at org.eclipse.jface.dialogs.MessageDialog.<init>(MessageDialog.java:189)
	at org.eclipse.team.internal.ui.history.LocalHistoryPage.confirmOverwrite(LocalHistoryPage.java:641)
	at org.eclipse.team.internal.ui.history.LocalHistoryPage.access$6(LocalHistoryPage.java:636)
	at org.eclipse.team.internal.ui.history.LocalHistoryPage$5.run(LocalHistoryPage.java:360)
	at org.eclipse.team.internal.ui.history.LocalHistoryPage$12.run(LocalHistoryPage.java:605)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
Comment 1 Szymon Brandys CLA 2009-07-29 08:00:28 EDT
Briefly looking at the code I think we could run whole LocalHistoryPage#confirmOverwrite in the UI thread. Krzysztof if you are still keen on the issue, assign the bug to yourself. Thanks!
Comment 2 Krzysztof Daniel CLA 2009-07-30 03:27:22 EDT
NPE should not happen anymore as bug 107082 has been fixed in non-breaking way. However the code in LocalHistoryPage.confirmOverwrite could be improved (MessageDialog should be created in UI thread).
Comment 3 Dani Megert CLA 2009-07-30 03:35:15 EDT
It doesn't make too much sense to mark a bug as 'helpwanted' if it is already assigned to a person ;-)
Comment 4 Szymon Brandys CLA 2009-07-30 05:32:21 EDT
Helpwanted removed cause Helpreceived ;-) Thanks Krzysiek for looking at this.
Comment 5 Natalia Bartol CLA 2009-08-03 06:06:50 EDT
Created attachment 143251 [details]
Patch

Problem is caused by the fact, that in line 602 of LocalHistoryPage method run is given the boolean fork parameter as true, so it is executed in a separate thread. 
Moving only the creation of new MessageDialog into UI thread inside LocalHistoryPage#confirmOverwrite did not solve the problem if user closes window before the operation is finished (parentSite.getShell() will return null). Changing boolean fork to false ensures that LocalHistoryPage#confirmOverwrite runs whole in the UI thread. This change will not affect any other cases -  LocalHistoryPage#getContextMenuAction is private and is called only once for LocalHistoryPage_GetContents message. 
Final variables, array of integers and running UI thread in LocalHistoryPage#confirmOverwrite are no more needed.
Comment 6 Markus Keller CLA 2009-08-03 10:18:48 EDT
(In reply to comment #5)
Have you verified that the operation is still cancelable and shows progress when you run it in the UI thread (e.g. with a slow or broken network connection)?
Comment 7 Natalia Bartol CLA 2009-08-04 08:01:29 EDT
Created attachment 143381 [details]
Patch_2.0

Better patch. Now LocalHistoryPage#confirmOverwrite runs whole in UI thread because it is called before fork in getProgressService() method. Progress bar is shown only after confirmation of file overwiriting, when process really starts. I removed array of integers, final variables and running UI thread from LocalHistoryPage#confirmOverwrite because they are no longer needed.
Comment 8 Szymon Brandys CLA 2009-08-05 11:26:53 EDT
I believe it works now with the fix for bug 107082. Krzysztof, please look at it, thanks.
Comment 9 Szymon Brandys CLA 2009-08-17 03:50:55 EDT
It is fixed along with bug 107082.
Comment 10 Krzysztof Daniel CLA 2009-12-10 06:30:13 EST
this bug is connected to bug 107082, and was fixed by it.
Marking this as verified also.