Community
Participate
Working Groups
There seem to be several places where Eclipse freezes up, even after what would seem to be common operations (saving). Some GUI functionality remains, such as being able to select a Menu, however the menu options that were tried do not work. (including exit). On the project which I am working on it occurrs regularly, but unpredictably. I'm unable to replicate the bug on a consistant basis. Pressing Cancel on the dialog boxes (some have progress meters some don't) has no effect other than sometimes (but not always) greying out the cancel button. Unfortunatly, there is no output to stdout to supply. This is a very annoying bug considering that eclipse doesn't update state with multiple editor panels being opened and such. Any additional information I can supply I will.
We are currently investigating several deadlock problems. See bug 31530, bug 33243 and bug 32905. Could you please clarify what you mean by "considering that eclipse doesn't update state with multiple editor panels being opened and such". Also, please indicate the eclipse build number when entering bug reports. For diagnosing deadlock and hang problems, it's useful to run with a console VM. Run with: eclipse -vm {yourJRELocation}\bin\java -data {yourWorkspaceLocation} Normally eclipse uses javaw.exe. Specifying java.exe gives you a console window. If eclipse becomes unresponsive, you can press Ctrl+Break in the console window to obtain a VM dump, including stack traces of all active threads. It's also useful to use a CPU monitor to determine whether a hang is due to a deadlock or a busy wait condition. Any additional info on the hang problems you're seeing would be most appreciated.
My apologies for neglecting to state the Build. It's the RC1 GTK build for linux, though I've had problems on it on all versions from M3 on (I haven't tried the motif one recently). As for "considering that eclipse doesn't update state with multiple editor panels being opened and such", what I meant is if you don't explicitly close out Eclipse through the exit menuitem in the File menu, which files had editor's open is not saved. When you restart eclipse, whichever files had editors at the last successful quit are restored. I consider this to be a separate issue to the one in this bug report, however. I will give more information after running Eclipse as you suggested with an exterior VM.
For the freeze problem, is there anything in your .log file (in the .metadata folder of your workspace)? Could this be a dup of bug 33187? For the editors not being saved on close, are you saying that closing by using the close icon does not prompt you to save unsaved changes? If so, this is definitely a bug. Which version of GTK are you using?
By "whichever files had editors at the last successful quit are restored" do you mean that they're are re-opened, but to the last saved state (i.e. your unsaved changes are still lost)?
I really do not think that this is a dup of 31530, bug 33243 or bug 32905. Those appear to involve CVS issues. I'm not doing any CVS operations out of Eclipse to my knowledge. These particular freezeups occur when doing anything from 'Save' to 'Run' I will be attaching stack traces as soon as I can generate them. There is a chance this this is a dup of 33187, but I definitly seem to be getting to it in a different method if that is so. Also the behavior after the error occurs is different (i.e. I am unable to properly exit eclipse and have to kill it rudely from commandline) As for the 'editor's' issue, My apologies again for not clarifying enough. That particular issue seems to be related to the workspace only appearing to save when quitting, rather than at any point incrementally. Again, not related to this bug. GTK Version 2.2.1 (or if a 2.0+ isn't used 1.2.10) Hopefully next information I get will confirm whether or not this is a dup.
The SWT team tells me there are several stability issues with GTK 2.2.1, which they are looking into. See bug 32204, bug 33017 and bug 32603. Apparently 2.2.0 works a bit better. Also, note that CVS can be involved even if you're not doing explicit CVS operations, if your project is under CVS version control and you have CVS label decorations turned on (Window > Preferences > Workbench > Label Decorations). If you don't have any projects under CVS version control, then we can discount the CVS deadlocks. If you do, could you try running with CVS decorations turned off?
I've since reconstructed my project without 'sharing' it, in an attempt to narrow down and actually hopefully classify this as a dup. There had been, in the .log file a few instances of an error revolving around a complaint that a certain file wasn't synchronized to the CVS, but that is all. I am still having lockups at random times, and nothing is produced in the .log file. Even if it's an unstable GTK problem, the program itself is not crashing and no error messages are reported to stdout or anywhere else I can find. Further note, from checking 'top' when this occurrs, X and the java process seem to share the entire CPU (with X taking a greater share, generally around 60% and java 35% or so). Killing the java processes eliminates the cpu use on X as well. Other GTK possible dups mentioned. Negative on all counts. Those are crashes, this is going into deadlock of some sort. Also, with respect to label decorations. I'm running the default ones, which do not include CVS. It's deselected.
Robert, could you try running under a console VM and hitting Ctrl+Break in the console when it hangs? Thanks for your help with this.
Sorry for the delay in response. I wasn't at a machine where I could further test. I'll do this, if I can figure out how to run it without the 'eclipse' executable, unless there's another way that I'm unaware of (the -vm argument? I didn't have much luck with that.). I'll also try sending a kill -QUIT to it and see if I can generate some stack traces.
try either: eclipse -vm {pathToYourJRE}/bin/java -data {pathToYourWorkspace} or (in the directory with the eclipse executable): java -classpath startup.jar org.eclipse.core.launcher.Main -data {pathToYourWorkspace} Be sure to specify java rather than javaw to get a console.
Reassigning to SWT after discussion with Veronika. This is on GTK 2.2.1 and shows X server CPU usage.
We fixed several freezes in GTK 2.2.1 yesterday in HEAD. This looks like one of them (able to select menus, but no code ran). Tell me, if you expand or collapse a tree, does it start working again? Never mind. Please get the latest from HEAD and retry. Assigning to FH. Close if you think this is the one you fixed, provided it no longer happens to Robert.
I know what you are saying Robert. I've exactly the same kind of problem a few times every day. But just like you I not able to reproduce it consistently. One of "classic" freeze problems I have is the "Launching App" Dialog. Let's wait and see if this problem happens in RC2 build.
This maybe be the same as Bug#33836.
*** Bug 34194 has been marked as a duplicate of this bug. ***
Robert, which Linux are you using ? Debian ? Redhat ?
I was getting this on debian/unstable and RC1. Haven't been doing much eclipse since RC2 came out, so I don't know if it's any better.
I'd also like to add that while file/exit didn't work, closing the window view the windowmanager decorations does seem to get eclipse to exit.
*** Bug 33836 has been marked as a duplicate of this bug. ***
*** Bug 34623 has been marked as a duplicate of this bug. ***
Approved for RC3 by Veronika.
Investigate for RC3.
Question, are you guys using the option CVS Label Decorator ? (is Preferences->Workbench->Label Decorations->CVS checked ?)
"Linked Resources" is the only one I have checked. But the freeze using the new file/folder was in a cvs shared project. Ashley Collins (from Bug#: 34194)
As well as in previous comment in my Eclipse only the checkbox for "Linked Resources" is selected. Seems to be the the default setting. But since using Eclipse( RC2 ) i've got no more problems with eclipse freezing in :-) This is really nice.
I believe this is not a SWT-GTK problem related (it is more often in GTK cause of the thread model though). I've talked to Tod and I almost sure this is a dupe of Bug#28343. Please, update your eclipse to the build 20030313 or later. If anyone gets this problem in RC3 please reopen this problem report. *** This bug has been marked as a duplicate of 28343 ***
*** Bug 35266 has been marked as a duplicate of this bug. ***
