Bugzilla – Full Text Bug Listing
| Summary: | Shell.setVisible is extremely slow on Linux | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Deepak Azad <deepakazad> | ||||||
| Component: | SWT | Assignee: | Bogdan Gheorghe <gheorghe> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | major | ||||||||
| Priority: | P3 | CC: | andrew.eisenberg, arunkumar.thondapu, charleso, daniel_megert, digulla, eclipse.felipe, gheorghe, julek.kopczewski, ndjensen, remy.suen, rwinch, Silenio_Quarti, steffen.pingel, tparker | ||||||
| Version: | 3.7 | ||||||||
| Target Milestone: | 3.8 M3 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux-GTK | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Deepak Azad
Deepak, is this a regression compared to 3.6? (In reply to comment #1) > Deepak, is this a regression compared to 3.6? Nope, same behavior in 3.6. Is it possible for Shell.setVisible(boolean) to be fast sometimes on linux ? I ask this because the performance test under question in bug 343242 sometimes runs very fast and sometimes runs slowly. And this behavior is observed only on RHEL, the test is consistently slow on SLED. I believe I am having a very similar issue on Ubuntu with Spring Tool Suite. I have logged a JIRA to them at https://issuetracker.springsource.com/browse/STS-1954 I want to be upfront that I have not had this happen with the standard Eclipse distribution, but believe that I am having the same issue. For your convenience I have copied what I believe to be the relevant information to this bug. Please let me know if I can be of further assistance in getting this issue resolved. At times using the Code Suggest will cause Eclipse to hang for what appears to be an indefinite amount of time (I know at one point it lasted at least 19 min). This cause Eclipse to freeze, the suggest box will not go away (even when bringing Firefox or other applications to focus), and near 100% CPU usage. I have taken a thread dump and obtained a YourKit snapshot with CPU profiling enabled. The results of which imply that the native call to _g_main_context_iteration(Native Method) triggered by Shell.setVisible is responsible. Below you can find some information about my environment: $ java -version java version "1.6.0_24" Java(TM) SE Runtime Environment (build 1.6.0_24-b07) Java HotSpot(TM) Server VM (build 19.1-b02, mixed mode) $ uname -a Linux rwinch 2.6.38-8-generic-pae #42-Ubuntu SMP Mon Apr 11 05:17:09 UTC 2011 i686 i686 i386 GNU/Linux If there is anything else I can do to be of assistance, please let me know. Regards, Rob Created attachment 200047 [details]
Thread Dump and Screenshot of Issue
Attached zip of Thread Dump and Screenshot of Issue
Created attachment 200048 [details]
YourKit Snapshot of issue
Attached YourKit Snapshot of the issue
I have seen the same problem with Eclipse SDK I20110719-0800 on Ubuntu 11.04 when invoking content assist. The UI thread stalls in native code for a considerable time before the popup becomes visible. Arun, please investigate. Possibly related: bug 353101 - "SWTException: Widget is disposed" when right clicking in Java editor window Which version of Gtk is this? I have gtk2-engines-qtcurve 1.8.5-1 gvfs 1.8.0-0ubuntu2 libasound2 1.0.24.1-0ubuntu5 libaspell15 0.60.6-6 libatk1.0-0 2.0.0-0ubuntu1 libc6 2.13-0ubuntu13 libcairo2 1.10.2-2ubuntu2 libcanberra0 0.28-0ubuntu3 libcanberra-gtk0 0.28-0ubuntu3 libcanberra-gtk-module 0.28-0ubuntu3 libenchant1c2a 1.6.0-2 libfontconfig1 2.8.0-2.1ubuntu3 libfreetype6 2.4.4-1ubuntu2 libgail18 2.24.4-0ubuntu2 libgdk-pixbuf2.0-0 2.23.3-0ubuntu1 libglib2.0-0 2.28.6-0ubuntu1 libgstreamer0.10-0 0.10.32-3ubuntu3.1 libgstreamer-plugins-base0.10-0 0.10.32-1ubuntu5 libgtk2.0-0 2.24.4-0ubuntu2 libgvfscommon0 1.8.0-0ubuntu2 libhunspell-1.2-0 1.2.14-4 libice6 2 libicu44 4.4.2-2 libjpeg62 6b1-1ubuntu1 libltdl7 2.2.6b-2ubuntu3 libnspr4 4.8.7-0ubuntu1 libnss3 3.12.9+ckbi-1.82-0ubuntu2 libogg0 1.2.0~dfsg-1 libpango1.0-0 1.28.4-0ubuntu1 libpixman-1-0 0.20.2-0ubuntu1 libsm6 2 libsoup2.4-1 2.34.0-0ubuntu1 libsqlite3-0 3.7.4-2ubuntu5 libstartup-notification0 0.10-1build1 libstdc++6 4.5.2-8ubuntu4 libtdb1 1.2.9-1fakesync1 libvorbis0a 1.3.2-1ubuntu1 libvorbisfile3 1.3.2-1ubuntu1 libwebkitgtk-1.0-0 1.3.13-0ubuntu2 libx11-6 2 libxau6 1 libxcb1 1.7-2ubuntu2 libxcb-atom1 0.3.6-1build1 libxcb-aux0 0.3.6-1build1 libxcb-event1 0.3.6-1build1 libxcb-render0 1.7-2ubuntu2 libxcb-shm0 1.7-2ubuntu2 libxcomposite1 1 libxcursor1 1 libxdamage1 1 libxdmcp6 1 libxext6 2 libxfixes3 1 libxi6 2 libxinerama1 2 libxml2 2.7.8.dfsg-2ubuntu0.1 libxrandr2 2 libxrender1 1 libxslt1.1 1.1.26-6build1 libxt6 1 libxtst6 2 xulrunner-1.9.2 1.9.2.18+build2+nobinonly-0ubuntu0.10.10.1 I have these versions: ii libgtk2.0-0 2.24.4-0ubuntu2 The GTK+ graphical user interface library ii libgtk2.0-bin 2.24.4-0ubuntu2 The programs for the GTK+ graphical user interface library ii libgtk2.0-cil 2.12.10-1ubuntu1 CLI binding for the GTK+ toolkit 2.12 ii libgtk2.0-common 2.24.4-0ubuntu2 Common files for the GTK+ graphical user interface library I have the following versions installed: libgtk2.0-0 libgtk2.0-bin libgtk2.0-cil libgtk2.0-common libgtk2.0-dev PS: I noticed that Aaron has xulrunner installed. When I first posted to this issue I was using webkit. I have since (on 7-27) switched to xulrunner and at times have observed some slugishness when using the content assist. However, since then I have not experienced the IDE completely locking up due to setVisible consuming the CPU. This very well could be coincidental, but I thought I would post on here just in case it was beneficial. (In reply to comment #12) > I have the following versions installed: > > libgtk2.0-0 > libgtk2.0-bin > libgtk2.0-cil > libgtk2.0-common > libgtk2.0-dev Please use "dpkg --status" with the package name to determine the version of the library. > PS: I noticed that Aaron has xulrunner installed. When I first posted to this > issue I was using webkit. I have since (on 7-27) switched to xulrunner and at > times have observed some slugishness when using the content assist. However, > since then I have not experienced the IDE completely locking up due to > setVisible consuming the CPU. This very well could be coincidental, but I > thought I would post on here just in case it was beneficial. I also have libwebkitgtk loaded. I'm not sure how to switch between the two. > (In reply to comment #12) > Please use "dpkg --status" with the package name to determine the version of > the library. Apologies for my carelessness. libgtk2.0-0 2.24.4-0ubuntu2 libgtk2.0-bin 2.24.4-0ubuntu2 libgtk2.0-cil 2.12.10-1ubuntu1 libgtk2.0-common 2.24.4-0ubuntu2 libgtk2.0-dev 2.24.4-0ubuntu2 > I also have libwebkitgtk loaded. I'm not sure how to switch between the two. You can determine which is being used by following the instructions on the FAQ [1]. There is also a FAQ for how to run using WebKit [2] and Mozilla [3]. For me using Mozilla involved installing the latest 1.x xulrunner (2.x will not work with Eclipse). To be honest, I do not know much about how Eclipse works behind the scenes. The reason I tried this was because a while back I had an issue where Eclipse content assist did not work with xulrunner 2.x and I was able to fix it by explicitly setting the version. I thought I would try to explicitly set the version again and came upon the fact that I was using WebKit. My guess is that xulrunner was removed since Firefox now uses an internal xulrunner which meant I had been using WebKit. Explicitly installing xulrunner switched me over. To emphasize, I really do not know if this is even on the right track. I'm really just taking a stab in the dark with this. [1] http://www.eclipse.org/swt/faq.php#printmozillapath [2] http://www.eclipse.org/swt/faq.php#browserwebkitgtk [3] http://www.eclipse.org/swt/faq.php#howusemozilla I just experienced the same issue with Mozilla XULRunner 1.9.2.17 - 20110424120753 that I was having when using WebKit. This implies that switching to WebKit does not prevent eclipse from totally locking up (in this instance I waited 15 min before killing the process). I gathered a thread dump along with a YourKit snapshot, but they look pretty much the same as last time. If you would like I can post them though. Bumping up the severity, as Shell.setVisible is used frequently and a number of people have experienced the problem now. I've experienced a similar bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=358037 Don't know if this is the same issue, but it's incredibly annoying, had to switch from using Eclipse altogether. A duplicate bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=349287 Not to complain, but I see this bug every day without fail. :( Please let me know if there is anything I can do to help. I should add for completeness that this started happening when I switched from Ubuntu 10.10 to 11.04, and occurs on both 3.6 and 3.7. I don't use Unity. Does any one know of a work around for this issue? (In reply to comment #19) > I should add for completeness that this started happening when I switched from > Ubuntu 10.10 to 11.04, and occurs on both 3.6 and 3.7. I don't use Unity. > > Does any one know of a work around for this issue? I've observed the same thing. I don't remember seeing this before I switched to 11.04. I use Gnome3 so no Unity either. There seems to be 2 problems here:
1) shell.setVisible is slow on GTK
We believe the test case is not realistic as does not spin the event loop. The event queue is being flooded with undispatched events. If you were to move the readAndDispatch into the loop, the performance goes from 2 minutes to less than 10 seconds:
for (int i = 0; i < 1000; i++) {
shell.setVisible(false);
//shell.setText("shell" + i); //$NON-NLS-1$
shell.setVisible(true);
while (display.readAndDispatch()) {
}
}
A normal application will always spin the loop, so we believe issue 1 is not a real problem. However, it might be the case that the JDT junits are not running the event loop. (Deepak, is this true?) On setVisible, we are currently dispatching a set of events until GDK_MAP is received. If we add (GDK_VISIBILITY_NOTIFY, GDK_PROPERTY_NOTIFY, GDK_WINDOW_STATE) to the set, the queue will no longer be flooded and the performance is reasonable. We will release a fix for this.
2) shell.setVisible hangs
We were not able to reproduce this but we could see how you could get stuck in the loop if a mapped event is not received. Unfortunately without a reproducible case, we can't do much more. We'll leave Bug 349287 to track this issue. If anyone has any steps for us, please post it there.
Thanks!
Fixed in master > 20111003 Please give it a try and let us know if there are any problems. Closing as fixed. (In reply to comment #21) > real problem. However, it might be the case that the JDT junits are not running > the event loop. (Deepak, is this true?) Yes, that is correct. Note that we have had issues on linux in the past by running the event loop inside the for loop, for example e.g. see bug 330353 comment 9. On other platforms this does not seem to matter. I verified with I20111005-0925 that the snippet from comment 0 now runs fast, and our performance test from bug 343242 also works better on my linux machine (this still needs to be verified on the build machines) Thanks for the fix! The bug does not have a target milestone set. In which release will this fix be available? (In reply to comment #26) > The bug does not have a target milestone set. In which release will this fix be > available? Ping. Is this patch applied to the 3.7.2 release, or only to 3.8? (In reply to comment #27) > Ping. Is this patch applied to the 3.7.2 release, or only to 3.8? A target milestone is set on this bug. The fix was released to the 3.8 stream and is not in 3.7.x. Eclipse hangs/crashes for me at least once a week since 3.7 because of this bug and two others. Can you please seriously consider to backport it to 3.7.2? |