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

Bug 319897

Summary:

delete project hangs, hogs 2 CPUs

Product:

[Technology] Subversive

Reporter:

John Kristian <jmkristian>

Component:

Core

Assignee:

Igor Burilo <igor.burilo>

Status:

RESOLVED WORKSFORME

QA Contact:

Severity:

normal

Priority:

CC:

amj87.iitr

Version:

0.7

Target Milestone:

---

Hardware:

Macintosh

OS:

Mac OS X - Carbon (unsup.)

Whiteboard:

Bug Depends on:

Bug Blocks:

287559

Attachments:

Description	Flags
first thread dump, taken while hung	none
second thread dump, taken while hung	none

Description John Kristian

2010-07-14 14:30:46 EDT

Build Identifier: 20100218-1602

I closed a Java project (successfully) and then attempted to delete it.  A dialog popped up, saying 'The user operation is waiting for background work to complete.'  I saw no further changes in the UI, and it stopped responding to mouse clicks.  The Eclipse process was using 2 CPUs (out of 8).  After roughly 15 minutes, the dialog changed to 'Are you sure you want to remove project XXX from the workspace?'; I clicked OK and the project was deleted.

I'll attach two thread dumps and a heap dump, which I got using jvisualvm while Eclipse was hogging CPU.

This is a large Java project, with more than a thousand source directories.  It was imported.  It's shared using Subversive.

Reproducible: Couldn't Reproduce

Comment 1 John Kristian

2010-07-14 14:36:02 EDT

Created attachment 174326 [details]
first thread dump, taken while hung

Comment 2 John Kristian

2010-07-14 14:36:34 EDT

Created attachment 174327 [details]
second thread dump, taken while hung

Comment 3 John Kristian

2010-07-14 14:37:19 EDT

Sorry to say I lost the heap dump.

Comment 4 Ayushman Jain

2010-07-15 03:46:23 EDT

This seems more like an SVN related issue. Most threads are blocked on SVN/Core. So moving to SVN/Core for comment

Comment 5 Alexander Gurov

2011-06-17 13:31:24 EDT

Dump #1:
at org.eclipse.ltk.ui.refactoring.RefactoringWizardOpenOperation$1.run(RefactoringWizardOpenOperation.java:123)

Dump #2:
at org.eclipse.ltk.ui.refactoring.RefactoringWizardOpenOperation$1.run(RefactoringWizardOpenOperation.java:123)

In both cases there was some refactoring process running. In many cases refactoring takes its time when it comes to large projects and, obviously, if project where refactor was running was connected to SVN there would be SVN-support code in stack traces. So, as it seems there takes place a case when ProgressMonitor cancellation state wasn't taken into account by some part of code participating in refactor. Unfortunately there is no way to tell for sure where the problem is located: in refactoring code (most likely, because I cannot imagine project so big, that refresh of its refactored bit would take the whole 15 minutes) or in the SVN-support code.

As for now I will close the report because descriptions points to long running code that is most likely refactoring support code. But if there are some steps that will allow me to pinpoint the problem as related to Subversive, I will reopen the report (please note, that described steps does not allow to reproduce the issue, and it is obvious why: there are nothing mentioned regarding refactoring).

P.S.
The only time consuming parts of the Subversive code that could be related to the situation are reworked in more optimal manner now (see bug #259287).

Comment 6 Alexander Gurov

2011-06-17 13:41:17 EDT

(In reply to comment #5)
And there is another moment: it is possible that refactoring cannot be canceled in order to keep the project consistent and that is why it is performed even if it is asked for project to be closed. In that case improvement related to bug #259287 should really help in this case too.