Bugzilla – Full Text Bug Listing
| Summary: | [launcher] Application becomes unresponsive when code completion tooltip shows | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | teo.red90 | ||||||
| Component: | Framework | Assignee: | equinox.framework-inbox <equinox.framework-inbox> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | critical | ||||||||
| Priority: | P3 | CC: | amj87.iitr, aniefer, christian.pontesegger, eclipse.felipe, erostarbe, ettoretommasomarchetti, grant_gayed, marcel.svitalsky, marcus90, Michael.Gaber, mscott3564, mvyskocil, Olivier_Thomann, remy.suen, ron.duplain, scottd.nerd, sven.koehler, tjwatson | ||||||
| Version: | 3.5.2 | Flags: | aniefer:
review+
|
||||||
| Target Milestone: | 3.6.2 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
teo.red90
(In reply to comment #0) > 1. Install Android Plugin > 2. Create an Android project > 3. Open the main .java file and use the code completion feature And what if you make a regular Java files in a Java project instead of an Android project? Same behavior with an empty java project (In reply to comment #2) > Same behavior with an empty java project Please provide thread dumps of Eclipse being in the hung state. http://wiki.eclipse.org/index.php/How_to_report_a_deadlock Please also try with Eclipse 3.6. http://download.eclipse.org/eclipse/downloads/drops/R-3.6-201006080911/index.php (In reply to comment #0) > Build Identifier: M20100211-1343 > > I tried to use Eclipse to develop for Android, so I installed Android > development plugin. > Whenever I use the code completion feature on the java code the tooltip shows, > but the application becomes unresponsive and I have to force the shutdown. > > Reproducible: Always > > Steps to Reproduce: > 1. Install Android Plugin > 2. Create an Android project > 3. Open the main .java file and use the code completion feature I have been working on Android projects inside eclipse with Android Dev Tools (ADT) installed. Content assist works flawlessly in all places - in the java files as well as the xml files. I would like to point out that ADT is only compatible with Eclipse 3.4 or 3.5 (as specified in http://d.android.com/sdk/eclipse-adt.html). Also you need to have JRE 1.5 atleast. Please make sure you fulfill these criterias. If you can still reproduce this on 3.5, attaching a reproducible testcase will help us investigate further. Thanks! (In reply to comment #3) > Please also try with Eclipse 3.6. > http://download.eclipse.org/eclipse/downloads/drops/R-3.6-201006080911/index.php As i mentioned, ADT is not compatible with 3.6 yet. :) (In reply to comment #5) > As i mentioned, ADT is not compatible with 3.6 yet. :) Well, Teo claims it is broken with a regular Java project in comment 2 so retrying with a simple Java file with a clean 3.6 SDK would be worthwhile I think. Created attachment 173750 [details]
Stack trace
I tried with a clean install from Ubuntu package (version 3.5.2-2ubuntu4.2, I'm running Ubuntu Lucid x86_64) and I still experience the crash. I've attached the stacktrace obtained with kill -3. I then tried with version 3.6. With this version the code completion works better, but if I doubleclick a suggestion, eclipse crashes with the following message: JVM terminated. Exit code=1 /usr/bin/java -Dosgi.requiredJavaVersion=1.5 -XX:MaxPermSize=256m -Xms40m -Xmx384m -jar /home/matteo/eclipse/plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar -os linux -ws gtk -arch x86_64 -showsplash -launcher /home/matteo/eclipse/eclipse -name Eclipse --launcher.library /home/matteo/eclipse/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.1.0.v20100503/eclipse_1307.so -startup /home/matteo/eclipse/plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar -exitdata 145801d -product org.eclipse.epp.package.java.product -vm /usr/bin/java -vmargs -Dosgi.requiredJavaVersion=1.5 -XX:MaxPermSize=256m -Xms40m -Xmx384m -jar /home/matteo/eclipse/plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar (In reply to comment #8) > I then tried with version 3.6. With this version the code completion works > better, but if I doubleclick a suggestion, eclipse crashes Check if you have an hs_err_pidXXXX.log file lying around. It's possibly in ~/ or wherever you installed Eclipse. Or just run slocate and find it. Isn't this a problem with the XulRunner? Moving to Platform/SWT for comment. the bug is still happening with the latest version and android sdk. eclipse crashes when a class is selected for autocompletion (In reply to comment #11) > the bug is still happening with the latest version and android sdk. eclipse > crashes when a class is selected for autocompletion Sorry I forgot to mention that it crashes with java projects too. This is not just Linux. In fact I have exactly the same problem when using the curent Helios release (with the default installation) in Windows, and when just creating a simple project to edit a single Java class (the only one in a new Java project). As soon as the skeleton code is generated in the editor, the first type I try to create its default constructor, it hangs immediately when I type the open parenthese : automatically the close parenthese is inserted, and when I start typing a parameter type and a space and then an identifier with just the first letter, the autosuggestion tries to scan the typed code, and will try to report that it is still missing braces (for the constructor code) or semi-colon. It should open a window, but I can't type further. Eclipse hangs immediately and I loose the text typed in the editor. As such, Eclipse is completely unusable even for the most basic project, and too unreliable for typing any kind of Java code (all the edits are lost because Eclipse hangs completely, the native window stops reponding even to resizes, and Windows blanks it transparently to show that the application is hang. Eclipse is then running with 100% CPU time used in Java (using JRE 1.6, latest version from Oracle/Sun for Windows Seven 64-bit), most probably within an infinite event loop, where Java stops completely to respond to Windows. The only thing I can do is to force the window to close, and Windows will start reporting the Java.exe process for analysis, with a complete crash dump, unless I stop it. There's NO java crashdump generated. Reproducible : always in just a few seconds after starting Eclipse... CRITICAL ! I can no longer work with Eclipse on Windows for my projects. Note : all my PCs are now 64-bit (system version: NTamd64.6.1). The processor is Intel Core 2 Duo (on notebooks) or better. All system drivers are certified WHQL (including the nVidia display driver, that I also checked to be sure that it was up-to-date). (This is most probably an issue in SWT for Windows Seven, where it does not work properly with its DWM user mode model for display drivers, or where it expects from Windows to receive some events in a precise order). Note that I have NO problem on any other Java applications (including JRE, Swing, Java2D, Java3D, or 100% pure java) but I have constant issues in all SWT applications such as Eclipse. The bug must be within one of the native libraries for SWT (using the current version of SWT shipped with Eclipse). (In reply to comment #13) > In fact I have exactly the same problem when using the > curent Helios release Do you get the same problem if you try with the Galileo release? > Eclipse is then running with 100% CPU time used in Java (using JRE 1.6, latest > version from Oracle/Sun for Windows Seven 64-bit) Please try using a Java 5 VM or try using HotSpot 6u20 (latest is 6u21 as far as I know). (In reply to comment #14) > (In reply to comment #13) > > In fact I have exactly the same problem when using the > > curent Helios release > > Do you get the same problem if you try with the Galileo release? > > > Eclipse is then running with 100% CPU time used in Java (using JRE 1.6, latest > > version from Oracle/Sun for Windows Seven 64-bit) > > Please try using a Java 5 VM or try using HotSpot 6u20 (latest is 6u21 as far > as I know). Java 5 is NOT an option. I need the V6 features for my project. Note: the problems also occurs with lower VM versions (I had already added the -XX:MaxPermSize=256m parameter after --vmargs, this has no visible effect on this bug. Anyway, the Sun BugDatabase is now almost always inacessible, since that Oracle has tried to unify the site: the logon never terminates, or I constantly get HTTP error 500. Oracle has completely broken what was working very well when it was separate from Sun. and now the issue with its unneeded desire to rename the VM is stupid... Oracle did not need to do that given that it still owns the Sun trademark, and that trademark was directly linked to Java. Visibly Oracle has completely broken the existing Sun IDs, ut unfortunateley I can no longer subscribe it withe the same email address (and I won't use a temporary email address that will expire in 1 month). This has occured because Oracle has mixed the settings that I had previous in my Oracle account, and incorrectly merged the parameters with the Sun online ID which was registered with the same email address.... Sorry then, I cannot vote for this bug resolution, as my account now can only access to the old Oracle acccount and I can't enter to the new system. I have also lost my JCP susbscription. Damned Oracle ! (In reply to comment #15) > (In reply to comment #14) > Java 5 is NOT an option. I need the V6 features for my project. For referencing purposes, the Java runtime you use to launch Eclipse does _not_ need to align with the requirements of the Java projects you work on. > Note: the problems also occurs with lower VM versions (I had already added the > -XX:MaxPermSize=256m parameter after --vmargs, this has no visible effect on > this bug. To be clear, it's -vmargs with one hyphen. However, since you claim to have the problem on other VM versions, it doesn't sound like this is the problem in question. Please get a thread dump of the state of Eclipse when it is hung (see comment 3). > > Note: the problems also occurs with lower VM versions (I had already added the
> > -XX:MaxPermSize=256m parameter after --vmargs, this has no visible effect on
> > this bug.
>
> To be clear, it's -vmargs with one hyphen. However, since you claim to have the
> problem on other VM versions, it doesn't sound like this is the problem in
> question.
Oups! I had inadvertantly added the second hyphen in the "eclipse.ini" file... Once corrected, now Eclipse works. Thanks for pointing it.
I'm not sure that teo.red90 and Philippe Verdy are having the same problem. Ted, does increasing the heap size (or -XX:MaxPermSize) solve the problem for you too ? I don't think these are the same problem. Comment 8 indicates that with eclipse 3.6 the crash happens when double-clicking an item from content assist list. I don't think that this would give the same trace as is in comment 7. teo.red90 does this scenario create an hs_* file when it crashes? *** Bug 322143 has been marked as a duplicate of this bug. *** i experience this issue using windows 7(x64) and the latest helios build. Even for simple java projects, code completion displays a list at when i go to select an option is halts for a good 20 seconds before recovering program functionality. I suffer the same problem on two of my machines both running the latest jdk + jre (x86) *** Bug 322714 has been marked as a duplicate of this bug. *** https://bugs.eclipse.org/bugs/show_bug.cgi?id=322714#c3 makes an interesting observation, perhaps libraries from multiple xulrunner versions are being loaded. Can someone that sees this problem on linux run the following snippet and paste the output here? The snippet will likely freeze, but it should get its useful output written out first. Note that if you're using 64-bit swt then you'll need to change the "int" to a "long" in the 5th line. public static void main(String[] args) { Device.DEBUG = true; Display display = new Display(); byte[] bytes = Converter.wcsToMbcs (null, "MOZILLA_FIVE_HOME", true); int /*long*/ ptr = C.getenv (bytes); if (ptr == 0) { System.out.println("no MOZILLA_FIVE_HOME"); } else { int length = C.strlen (ptr); byte[] buffer = new byte[length]; C.memmove (buffer, ptr, length); char[] chars = Converter.mbcsToWcs (null, buffer); System.out.println("MOZILLA_FIVE_HOME: " + new String (chars)); } bytes = Converter.wcsToMbcs (null, "LD_LIBRARY_PATH", true); ptr = C.getenv (bytes); if (ptr == 0) { System.out.println("no LD_LIBRARY_PATH"); } else { int length = C.strlen (ptr); byte[] buffer = new byte[length]; C.memmove (buffer, ptr, length); char[] chars = Converter.mbcsToWcs (null, buffer); System.out.println("LD_LIBRARY_PATH: " + new String (chars)); } Shell shell = new Shell(display); System.out.println(">>>Snippet creating SWT.MOZILLA-style Browser"); try { new Browser(shell, SWT.MOZILLA); System.out.println(">>>succeeded"); } catch (Error e) { System.out.println(">>>This failed with the following error:"); e.printStackTrace(); System.out.println("\n\nSnippet creating SWT.NONE-style Browser"); try { new Browser(shell, SWT.NONE); System.out.println(">>>succeeded"); } catch (Error e2) { System.out.println(">>>This failed too, with the following error:"); e2.printStackTrace(); } } display.dispose(); } Grant, I would gladly try to run that code, I just need some advice from where should I import or what library do I need for it. Nevertheless, I tried the same what Marco writes in bug 322714 that he did, i.e. removed xulrunner 1.9.1, and the buggy behaviour disappeared as well. OK, that was very stupid question indeed; sorry for that (not enough caffeine in my blood yet). I tried to run the code after reinstalling xulrunner 1.9.1, it worked OK and didn't freeze, but neither does my Eclipse now even with two different versions of xulrunner present!
So I went to some other machine, where only 1.9.1 version of xulrunner was installed, I installed fresh new eclipse there and tried them: all worked fine. I added xulrunner 1.9.2, reran eclipse and they got nicely frozen exactly at the point they were supposed to.
So then I tried your code within eclipse, they printed this on stdout:
MOZILLA_FIVE_HOME: /usr/lib64/xulrunner-1.9.2.10pre
LD_LIBRARY_PATH: /usr/local/java/jdk1.6.0_21/jre/lib/amd64/server:/usr/local/java/jdk1.6.0_21/jre/lib/amd64:/usr/local/java/jdk1.6.0_21/jre/../lib/amd64:/usr/lib64/xulrunner-1.9.2.10pre
>>>Snippet creating SWT.MOZILLA-style Browser
XULRunner path: /usr/lib/xulrunner-1.9.1.13pre/libxpcom.so
and then, after some time of doing nothing discernible, got frozen again.
Hope it helps.
(In reply to comment #25) > So I went to some other machine, where only 1.9.1 version of xulrunner was > installed, I installed fresh new eclipse there and tried them: all worked fine. > I added xulrunner 1.9.2, reran eclipse and they got nicely frozen exactly at > the point they were supposed to. On Ubuntu 10.04, I had both xulrunner 1.9.1 and xulrunner 1.9.2 installed, experiencing the bug listed in comment #0. Removing xulrunner 1.9.1 fixed the issue. Details: After weeks of stable Eclipse development with ADT, I suddenly had the same bug as comment #0, where all of Eclipse would become unresponsive on display of content assist's code completion for a class in the Android lib. Looking at my system configuration, the only change was a recent upgrade for Firefox (and on further inspection, xulrunner) via apt. With no direct changes to my development environment, I took the hint "perhaps libraries from multiple xulrunner versions are being loaded" via Grant Gayed and removed an unused old version of xulrunner. e.g. sudo apt-get remove xulrunner-1.9.1 xulrunner-1.9.1-gnome-support Eclipse is stable again and the content assist freeze bug is gone. Platform: Ubuntu 10.04.1 Lucid Lynx x86_64 Linux 2.6.34 Eclipse 3.5.2-2ubuntu4 (Ubuntu package) Bug on both: Android SDK r6 w/ADT 0.97 Android SDK r7 w/ADT 0.98 Solution in my case: Remove unused versions of xulrunner. Thanks for the bug thread, very helpful. Ron Thanks for a feedback Marcel and Ron. Sorry I didn't follow up earlier, I hope that someone still has a reproducable case of this. :) I believe the problem is that the eclipse launcher is adding a value to the LD_LIBRARY_PATH that's causing the libs from two different xulrunner installs to become confused with each other. This should be testable simply by setting the value of Linux environment variable "MOZILLA_FIVE_HOME" (without the quotes) to a value like "/dev/null" before launching eclipse. If someone that sees this hang can confirm that setting this environment variable does "fix" it for them then the nature of the required fix will be clear. (In reply to comment #27) > I believe the problem is that the eclipse launcher is adding a value to the > LD_LIBRARY_PATH that's causing the libs from two different xulrunner installs > to become confused with each other. This should be testable simply by setting > the value of Linux environment variable "MOZILLA_FIVE_HOME" (without the > quotes) to a value like "/dev/null" before launching eclipse. If someone that > sees this hang can confirm that setting this environment variable does "fix" it > for them then the nature of the required fix will be clear. Grant, I tried it on my test system and ran Eclipse first without the environment variable set, simply issuing the command: $ eclipse and it got frozen, I killed it and reran it like this: $ MOZILLA_FIVE_HOME=/dev/null eclipse and it worked OK. Thanks for confirming this, targetting for 3.6.2. Created attachment 178981 [details]
patch
*** Bug 323913 has been marked as a duplicate of this bug. *** *** Bug 315670 has been marked as a duplicate of this bug. *** Andrew can you apply this patch to the launcher in the 3.7 stream and rebuild (affects linux and solaris)? This is an important fix, and if it proves to work well in 3.7 then I'd like it to eventually go into 3.6.2. I released this last week but forgot to recompile. Everything is now in HEAD for the next I Build. Haven't released anything to 3.6.2 This has been released to 3.6.2, the following fragments are affected and have had their versions increments (generally 1.1.1 -> 1.1.2) gtk.linux.ppc gtk.linux.ppc64 gtk.linux.x86 gtk.linux.x86_64 gtk.solaris.sparc gtk.solaris.x86 motif.linux.x86 *** Bug 340374 has been marked as a duplicate of this bug. *** *** Bug 340402 has been marked as a duplicate of this bug. *** (In reply to comment #37) > *** Bug 340402 has been marked as a duplicate of this bug. *** Agreed Installed new version, all works Sorry for not trying this before and not finding the previous bug report Ettore *** Bug 341547 has been marked as a duplicate of this bug. *** I'm seeing a similar problem in 3.7 using the Android plugin on Ubuntu 11.04. The tooltip window stays up but is unresponsive. The rest of the system seems fine. It seems like the tooltip window is blocking the other eclipse windows and has become unresponsive. The only fix is to kill eclipse but that appears to have completely corrupted the install. |