Community
Participate
Working Groups
Build ID: I20090313-0100 Steps To Reproduce: 1. Be me, on my mac laptop (not very useful, I know). 2. Start Eclipse. 3. Try to refresh, close project, or quit. Eclipse will say that it is "Waiting". It will not say what it is waiting on. It is not using much CPU time. It is not using that much memory. If I do a second "quit" from the MacOS Finder doc, a restart will put me back in the same state. A force quit followed by a restart also puts me back in the same state. More information: This is a hard, no-progress-using-Eclipse-for-you, bug. I went looking for a lock file, I found none, I need some way to get out of this state and filing a bug report to get that information is not my idea of fun. I plan to try using a different version of Eclipse in just a minute, and if that fails, to blow away my workspace and start over. I don't think that any part of Eclipse should be permitted to block progress like this and escape identification and blame. I understand that there is a "kill" number I can use to provoke eclipse into giving me more information -- I hope we all agree that this is a major UI fail, especially since I have to file a bug report or use Google to get this information. I looked at the log file, it says practically nothing (it notes that I restarted Eclipse, it notes that a refresh would be a good idea).
Downgrading to 3.4.2 (where I had to also uninstall the 2.8.0 Scala plugin and install the 2.7.4 Scala plugin for unrelated reasons) seemed to clear the problem. "Abandon version 3.5" seems like a pretty harsh workaround, but it did work. I note, independently, that 3.4 is busy downloading jar files from download.eclipse.org, and I told it to cut that out, and it dutifully recorded my request of a cancel, and preceded to ignore me and download more stuff. Is it possible that there had been some update push, and that the problem was that 3.5 was updating but not saying what it was up to? (I note that the update manager seems to have changed somewhat) (I cut off my network access, quit, restarted, that seems to have gotten the message across. So really, when I say "cancel", I'm not kidding.) Oh well, I have work to do, the bug is cleared for me now, I think you should look into the issue of anonymously blocked progress.
Could you please at least provide a thread dump?
Sorry, but the hang is long since gone, and I reverted to 3.4 to get work done. If it's important to have people take a thread dump, it should be mentioned prominently, with instructions how, on the file-a-bug page.
Closing as WORKSFORME. Next time this happens please provide a thread dump.
(In reply to comment #3) > If it's important to have people take a thread dump, it should be mentioned > prominently, with instructions how, on the file-a-bug page. For the records: it's not really on the file-a-bug page but here: http://wiki.eclipse.org/How_to_report_a_deadlock
It's not very useful to have that information NOT in the path of someone filing a bug. There's all sort of chit-chat about look-for-a-duplicate, check the forums, etc, etc. If you want informative bugs filed, you should make it easy for users to file informative bugs. There ought to be a signal that you could drop in Eclipse (documented on the file-a-bug-page, of course) that would cause Eclipse to emit ONE file, containing all the relevant information that you might want with a bug report. Last N lines of the log file, stack traces, plugin versions, etc. How hard could it be? How much time is wasted going back and forth asking for information that you failed to ask for in the first place (on the bug report page) that you could have made easy to collect?
Verified for 3.6M1
