Community
Participate
Working Groups
Hi, This is happening on my laptop and is driving me crazy: When typing and using content assist, sometimes (well, fairly often), the Eclipse freezes for about 10-15 seconds (sometimes more). After that, a dialog appear that informs me that some proposal computer took too long to complete and more. This happens when I use the content assist with few words, f.e. I have this: List<Object> foo; [constructor](){ foo = new C| <-- caret is after the 'C' } (I have an implementation of List called ComparableList, which I want to use here.) When I use the content assist at this point, the bug will appear. During this whole period, the LED indicator of my harddrive is blinking like crazy. Another problem is with the quick fix. Imagine I already typed the command foo = new ComparableList<Object>(); Now the ComparableList is underlined, because it is not imported. When I hover the cursor above the error to show he quick fix and import, again, the Eclipse freezes for up to 30 seconds, however, this time with no exception thrown. Also, harddrive is going mad. This one is particuraly nasty, I have to be careful not to put cursor on unimported declarations. When I at last get the content assist window, the ComparableList is at the top (which is fine), but along with it, I receive tons of useless rubbish from packages I never used and thousands of other classes beginning with 'C' (like Calendars form sun.util.resources and other obscure classes), irrelevant in the given context. Even raising the Eclipse memory to overkilling 1GB did not relieve me of this problem (before that Eclipe was taking about 100MB, after that, it was about 115MB). Disc is 5400 rpm. I have a desktop in my home with the same platform (but slightly better harware) and this is not happening there. CLEAN install of Windows somewhat shortened the time, but when I added Office, Visual Studio, Firefox, ICQ and other needed software, the problem was back. I am using Eclipse to teach Java, and when I and my students has to wait 30 seconds for the proposal, it is a real problem. I am serisly considering switching to NetBeans. Athough they are ugly and crippled, at least they do not freeze.
>I am using Eclipse to teach Java, and when I and my students has to wait 30 >seconds for the proposal, it is a real problem. 30s is way too long. Can you provide a workspace so we can try to reproduce it? Also, please try 3.6 M2. Does it only happen with constructor proposals?
(In reply to comment #1) > >I am using Eclipse to teach Java, and when I and my students has to wait 30 > >seconds for the proposal, it is a real problem. > 30s is way too long. Can you provide a workspace so we can try to reproduce it? > Also, please try 3.6 M2. > > Does it only happen with constructor proposals? Hello, thanks for your attention to the problem. You can find the workspace in the attachment, however, this would be a system specific bug, as I am using the same version of Eclipse with the same workspace on my desktop (linked through client-side caching), so I don't think it's necessary. You can also find my preferences exported, just for the case they are needed. I will try the 3.6 version ASAP, but it happened with 3.5 and 3.4 as well. I think Europa was OK on the laptop, but it was a long time ago and I dont remember it correctly. No, it doesn't happen only with constructors, but with all kinds of code assist (intellisense, unknown type quickfix, etc...). Even when I have a local variable named activeTransactionTypes, typing aTT (which is pretty much specific) and then Ctrl+Space would trigger the lag. My laptop is: Core 2 duo 2GHz, 2GB RAM, 160GB 5400 rpm HDD, Intel X3100 graphics, 12". (Fujitsu-Siemens Esprimo Mobile U9200)
Created attachment 149546 [details] Eclipse preferences
> You can find the workspace in the attachment. I am sorry, but the zipped attachment was over 7 MB large, so I could not upload it. The link to it should be here: http://uloz.to/2807297/java-workspace.zip
>I am sorry, but the zipped attachment was over 7 MB large, so I could not upload >it. It should work if you check the "Big file" check box when attaching the file.
Jay, please investigate.
(In reply to comment #4) > > You can find the workspace in the attachment. > > I am sorry, but the zipped attachment was over 7 MB large, so I could not > upload it. The link to it should be here: > http://uloz.to/2807297/java-workspace.zip Sorry, I am unable to download from the site. Could you please try it with the 'Big File' option?
Created attachment 150223 [details] workspace where the bug occurs
(In reply to comment #8) > Created an attachment (id=150223) [details] > workspace where the bug occurs No luck with reproducing the bug. Can you please provide a thread dump when the content assist operation is in progress? That should give us some idea as to where the problem may lie. One way to get this is to run eclipse from equinox launcher with a command like: java -jar eclipse/plugins/org.eclipse.equinox.launcher_1.0.0.v20070606.jar Note you will have to change the jar file name as you find in your build.
(In reply to comment #9) > (In reply to comment #8) > > Created an attachment (id=150223) [details] [details] > > workspace where the bug occurs > > No luck with reproducing the bug. Can you please provide a thread dump when the > content assist operation is in progress? That should give us some idea as to > where the problem may lie. > > One way to get this is to run eclipse from equinox launcher with a command > like: > > java -jar eclipse/plugins/org.eclipse.equinox.launcher_1.0.0.v20070606.jar > > Note you will have to change the jar file name as you find in your build. Hello, I tried 3.6 M2, but it seems to be even more unresponsive than 3.5. I run the eclipse via the command you provided, but don't know how to obtain the thread dump afterwards. The command prompt window I launched eclipse from remains empty (no stack traces or else). Can u plase provide me with more info about geeting the dump, please? Jakub
You can use Ctrl-\ keys (on Solaris OS or Linux) or the Ctrl-Break keys (on Windows) to obtain the thread dump. For more details, you may refer to this page: http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/hangloop.html#gbzay
>I run the eclipse via the command you provided, but don't know how to obtain >the thread dump afterwards. See: http://wiki.eclipse.org/index.php/How_to_report_a_deadlock#Getting_a_stack_trace_on_Windows
Created attachment 151222 [details] Thread dumps The file contains 4 dumps, 3 from QuickFix, taken in roughly one-minute intervals, and 1 from the Content Assist (when the Eclipse was frozen, before the exception). I also made a video demonstrating the bug. Feel free to watch it: http://www.youtube.com/watch?v=WkkYqU_PW4s
(In reply to comment #13) > Created an attachment (id=151222) [details] > Thread dumps > > The file contains 4 dumps, 3 from QuickFix, taken in roughly one-minute > intervals, and 1 from the Content Assist (when the Eclipse was frozen, before > the exception). Thanks for the dumps. Though I found no deadlocks in the dumps, I notice that a particular thread is at the same execution point through out - i.e. in all the dump files. I don't know the cause yet, but this could be a problem. Now I have a couple of questions for you. 1. Does it happen only with the ComparableList type? 2. Have you, by any chance, tried with any OS other than Windows Vista?
Hello, 1) No, this type was only for demonstration. All unknown types will trigger the bug. Same for the content proposal (Ctrl+Space), though it got better a bit with the latest release. 2) Unfortunately, no. This happens only on my 12" laptop with Vista pre-installed. I don't particulary feel like installing other OS just for the debug. Did u watch the video I made? There are subtitles available for it with additional info about the bug, specifically about its progress. I have some more info for you: Using the jvisualvm, the eclipse process was provided with about 40 MaxPermGen size and used about 37 just after launch. When the bud was triggered, it rose up to the limit. However, when I increased it to something like 256, it also used 37 after launch and 40 during the bug. I noticed that the dumps all ends in native method 'open()' in FileInputStream class, i.e. something is going on in I/O. This corresponds with the HDD led flashing frantically when the Eclipse is frozen. The disk is 5400 rpm 160 GB, WesternDigital i believe. Defragmentating has no impact on the Eclipse performance (or the disk defragmentation was negligible when I run it). If you needed any additional info, feel free to ask. Jakub
(In reply to comment #15) > Using the jvisualvm, the eclipse process was provided with about 40 MaxPermGen > size and used about 37 just after launch. When the bud was triggered, it rose > up to the limit. However, when I increased it to something like 256, it also > used 37 after launch and 40 during the bug. > Just wondering - Is it MaxPermSize or MaxPermGen?
(In reply to comment #16) > Just wondering - Is it MaxPermSize or MaxPermGen? My eclipse.ini: -startupplugins/org.eclipse.equinox.launcher_1.0.300.v20090911.jar --launcher.library plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.0.300.v20090908 -showsplash org.eclipse.platform --launcher.XXMaxPermSize 256m -vmargs -XX:PermSize=256M -XX:MaxPermSize=512M -Xms40m -Xmx384m
Jakub, Deleting the index files (workspace\.metadata\.plugins\org.eclipse.jdt.core\*.index) could probably help. Please take a backup of these files before deleting it. The workspace you had attached doesn't contain these files.
(In reply to comment #18) > Jakub, > Deleting the index files > (workspace\.metadata\.plugins\org.eclipse.jdt.core\*.index) could probably > help. Please take a backup of these files before deleting it. The workspace you > had attached doesn't contain these files. I did as you suggested, but it was no help. I saw no difference in performance. The index files were recreated, though.
Satyam, As discussed, assigning this bug to you.
Jakub, As you have mentioned all the dumps are waiting on open, which I am unable to understand. Can you try out the following and give details around it, which can be helpful? 1. Is F3 or references also slow? 2. Create a fresh workspace and try out. 3. Use a different JVM with eclipse. 4. Try to use eclipsec.exe instead of eclipse.exe. 5. Can you try out running procmon.exe of http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx (Include the eclipse process and monitor only the file accesses) and provide it's output?
Jakub,Do you have answers for any of my questions in comment #21?
I am sorry it took me so long, but I have been rather preoccupied recently and did not have the time. I downloaded most recent nighly build (30.1.2010 Eclipse Helios) and the problems seems to be gone. Content assist responds quickly even when the word is very ambiguous. Quick Fix also does not freeze the program. I will try the new build out more in real work and if there are any problems, rest assured I will let you know. BTW I want to thank you for your help and willingness in resolving the issue. Jakub
Hi Jakub, As it works for you now, I am closing this defect. Please reopen this bug if you run into this problem again.
Verified for 3.6M6 using build I20100305-1011
