Community
Participate
Working Groups
Created attachment 237198 [details] crash dump This cripplingly frequent crash makes Kepler barely usable on this Arch linux 64bit box. Ubuntu is apparently affected too: https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/1223181 Most recent dump attached.
I can reliably reproduce this debugging applications on Kepler and Kubuntu 13.04. I am happy to provide dumps or to try out possible fixes.
Please everyone affected duly add votes for this bug.
Can someone give a pure SWT reproducer? Does it happen with 4.4 M3 or if you run SWT_GTK3=1 eclipse with Kepler?
We need help from reporters to investigate issues. If this doesn't happen there is no other action to be done but to close it with insufficient data.
This stopped happening to me a week or two after reporting it. I had tried changing my KDE theme as suggested in another report of this bug (possibly on kde.org) and there had also been some Kubuntu updates which I had applied. I am now using my original theme and the crash no longer happens. I'm guessing some KDE update fixed it but I can't tell for certain. I didn't change anything in Eclipse.
this crash started to plague me too, please continue work on this. it happens, when i try to move mouse over Variables view during debugging. my system: SuSE Linux 13.1 Linux 3.11.6-4-desktop #1 SMP PREEMPT (e6d4a27) x86_64 Stack: [0x00007f728f199000,0x00007f728f29a000], sp=0x00007f728f296a80, free space=1014k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libgtk-x11-2.0.so.0+0x22a52a] gtk_tree_view_get_background_area+0x8a Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) J org.eclipse.swt.internal.gtk.OS._gtk_main_do_event(J)V J org.eclipse.swt.internal.gtk.OS.gtk_main_do_event(J)V j org.eclipse.swt.widgets.Display.eventProc(JJ)J+157 v ~StubRoutines::call_stub J org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(JZ)Z J org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(JZ)Z J org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run()V
Created attachment 238604 [details] crash dump of VM
(In reply to Thomas Frühbeck from comment #6) > this crash started to plague me too, please continue work on this. > it happens, when i try to move mouse over Variables view during debugging. > my system: > SuSE Linux 13.1 > Linux 3.11.6-4-desktop #1 SMP PREEMPT (e6d4a27) x86_64 > > > Stack: [0x00007f728f199000,0x00007f728f29a000], sp=0x00007f728f296a80, > free space=1014k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native > code) > C [libgtk-x11-2.0.so.0+0x22a52a] gtk_tree_view_get_background_area+0x8a > > Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) > J org.eclipse.swt.internal.gtk.OS._gtk_main_do_event(J)V > J org.eclipse.swt.internal.gtk.OS.gtk_main_do_event(J)V > j org.eclipse.swt.widgets.Display.eventProc(JJ)J+157 > v ~StubRoutines::call_stub > J org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(JZ)Z > J org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(JZ)Z > J org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run()V Thomas, what is your eclipse version? Have you tried running with GTK 3 as I asked for in comment 3? Can you come up with instructions how can I reliably reproduce? Any chance for pure SWT code reproducing the problem? I can not reproduce such a crash yet so unless someone comes with a reproducer I can not do much.
Kepler also crashes on a smaller Swing application while debugging. I've set four breakpoints. On stepping through the program Kepler crashes. I've used also SuSE 13.1: Linux 3.11.6-4-desktop #1 SMP PREEMPT (e6d4a27) x86_64 > rpm -qf /usr/lib64/libgtk-x11-2.0.so.0 libgtk-2_0-0-2.24.22-2.1.x86_64 eclipse.buildId=4.3.0.M20130911-1000
(In reply to Jörg Dippel from comment #9) > Kepler also crashes on a smaller Swing application while debugging. > I've set four breakpoints. On stepping through the program Kepler crashes. > > I've used also SuSE 13.1: > Linux 3.11.6-4-desktop #1 SMP PREEMPT (e6d4a27) x86_64 > > > rpm -qf /usr/lib64/libgtk-x11-2.0.so.0 > libgtk-2_0-0-2.24.22-2.1.x86_64 > > eclipse.buildId=4.3.0.M20130911-1000 Any chances for giving a snippet that reproduces the crash?
https://sourceforge.net/projects/chess383/files/Eclipse-421073-src.tar.gz/download Eclipse seems to crash only on debugging, but that's not confirmed. I've extracted some code to reproduce the behavior. The application is started by GameExample (that is in a state of refactoring), the relevant break point is set in BoardView, line 254. The project is related to a Maven project (maybe the prefixes main/java and test/java are to be removed and junit4 has to be added). What should happen: On start a chess board is displayed, on next-Button there should be changes on the chess board, which are not implemented yet.
This performance (crashes on debugging) is annoying. I cannot remember crashes on debugging while I get them often now. The performance is repeatable on a fresh installed SuSE-13.1 with all updates available (from today). If I use a SuSE-12.2 installation I cannot reproduce the crashes. The SuSE-12.2 installation uses: > rpm -qf /usr/lib64//libgtk-x11-2.0.so.0 libgtk-2_0-0-2.24.10-3.1.2.x86_64
I just upgraded from openSuSE 12.3 to 13.1 and now I am getting this same crash, always during a Java debug session. I never saw it in 12.3 Starting eclipse with "SWT_GTK3=1" gives me an unusable IDE (no source text is drawn, lots of blank windows).
I can confirm that setting "SWT_GTK3=1" provides an unusable IDE. First I get an "In pixman_region32_init_rect: Invalid rectangle passed Set a breakpoint on '_pixman_log_error' to debug" error", but after I set the ulimit command, I cannot reproduce that again. But because I can reproduce the crash with my small project, I've tried it nevertheless. The crash doesn't appear, but another problem occurs, notified by a popup: Asynchronous viewer input update has encountered a problem. An internal error has occurred. On details, only the number '4' is returned. Because I use Kepler with a former libgtk-x11-2.0.so.0, using 12.2, my first candidate would be that library.
I tried replacing the /usr/lib64/libgtk-x11-2.0.so.0.2400.22 with the version from openSuSE 12.3 (libgtk-x11-2.0.so.0.2400.18), updating the symlinks, and doing a full restart (just-in-case) but it made no difference. Still crashes. I noticed that a crash is always after I bring the mouse into the variables window during a debug. Not every entry into the variables window results in a crash but the crash only occurs when I've done that. I tried changing my focus policy from follows mouse to click-to-focus: made no difference (still crashes).
Curious, I cannot reproduce this with two older 12.3 SuSEs, one Gnome and the other LXDE, but both with the named lib libgtk-x11-2.0.so.0.2400.18. My crash happens on KDE. Thus I've installed a 13.1 LXDE with all updates and there is no crash. Back to 13.1 KDE the crash can be repeated.
(In reply to Jörg Dippel from comment #16) > Curious, I cannot reproduce this with two older 12.3 SuSEs, one Gnome and > the other LXDE, but both with the named lib libgtk-x11-2.0.so.0.2400.18. > > My crash happens on KDE. Thus I've installed a 13.1 LXDE with all updates > and there is no crash. > Back to 13.1 KDE the crash can be repeated. This reminds me of a series of bug with oxygen-gtk theme. Is this what you use on KDE? Can you try changing the gtk theme from KDE settings?
I take the default - this is KDE Plasma Desktop. Normally I only need an xterm ... Executing ps -ef, I get 'kdeinit4: plasma-desktop [kdeinit]'. In KDE System Settings->Application Appearance->GTK Styles and Fonts the GTK-Style is set to 'oxygen-gtk' for GTK2. If I choose another predefined selection for GTK2 like Adwaita I can no longer reproduce the crash, going back to oxygen-gtk the crash can be reproduced again.
(In reply to Jörg Dippel from comment #18) > I take the default - this is KDE Plasma Desktop. Normally I only need an > xterm ... > > Executing ps -ef, I get 'kdeinit4: plasma-desktop [kdeinit]'. > In KDE System Settings->Application Appearance->GTK Styles and Fonts the > GTK-Style is set to 'oxygen-gtk' for GTK2. > > If I choose another predefined selection for GTK2 like Adwaita I can no > longer reproduce the crash, going back to oxygen-gtk the crash can be > reproduced again. I myself consider this as bug in oxygen-gtk too. Even if SWT is doing something weird a theme should not crash gtk applications. This doesn't mean SWT part of the problem shouldn't be looked at but SWT is pretty low on resources now. So if you can either help oxygen-gtk or swt projects it would be more than welcome.
I'm seeing this same bug as well on Fedora 20. It has crashed on me 5 times in the past hour. The most recent gave me the following error: # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000003cf36570c2, pid=16843, tid=140722662307584 # # JRE version: OpenJDK Runtime Environment (7.0_51-b02) (build 1.7.0_51-mockbuild_2014_01_17_13_38-b00) # Java VM: OpenJDK 64-Bit Server VM (24.45-b08 mixed mode linux-amd64 compressed oops) # Problematic frame: # C [libgtk-x11-2.0.so.0+0x2570c2] gtk_tree_view_get_background_area+0xb2 # # Core dump written. Default location: /home/ken/eclipse/core or core.16843 # # An error report file with more information is saved as: # /tmp/jvm-16843/hs_error.log # # If you would like to submit a bug report, please include # instructions on how to reproduce the bug and visit: # http://icedtea.classpath.org/bugzilla # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # The past few times it has occurred to me was when I was attempting to step through some Java code in the Debug view. I can attach the code I'm trying to debug if that would help.
Created attachment 240341 [details] hs_err_pid32677 error log Frequent crashes when viewing variables in the debugger. I am running Fedora 20 and Keplar 64 bit.
Created attachment 240533 [details] Attached full crash log Eclipse crashes frequently in debug mode, no exact steps to reproduce but happens within minutes of debugging. Seems to be happening now in libgtk-x11-2.0.so.0+0x2202aa
Today there has been an updated package for oxygen theme gtk2-theme-oxygen-1.4.4-2.4.1.x86_64 for SuSE 13.1. Because my installed package for > rpm -qi libgtk-2_0-0-2.24.22-2.1.x86_64 Name : libgtk-2_0-0 Version : 2.24.22 Release : 2.1 Architecture: x86_64 Install Date: Mi 06 Nov 2013 21:01:02 CET Build Date : Fr 01 Nov 2013 12:07:48 CET has not changed, the crash should be reproduced again. The crash can be reproduced with GTK-Design oxygen-gtk with the currently updated system. With a change of GTK design there is no crash - that's my workaround.
(In reply to Mass Dosage from comment #22) > Created attachment 240533 [details] > Attached full crash log > > Eclipse crashes frequently in debug mode, no exact steps to reproduce but > happens within minutes of debugging. Seems to be happening now in > > libgtk-x11-2.0.so.0+0x2202aa Exactly, I can confirm this information. Also Java Perspective crashes when drawing some background, but it is not so early.
It seems it is fixed in newer GTK, but after my recent experiences I am not so optimistic. But after upgrade to 1.3.5 and also GTK 3.10 and restarting the system Eclipse still did not crash (9 hours now, switching git branches on massive project, debugging, refactoring). Can you try it someone too? (package is big, you need fast connection) sudo add-apt-repository ppa:gnome3-team/gnome3 sudo apt-get install libgtk-3-0 Download 1.3.5: https://launchpad.net/ubuntu/+source/oxygen-gtk3 Unpack and see instructions in the file INSTALL.
This used to be incredibly annoying, to the point of making debugging unusable, until I discovered a simple workaround. The crash almost always happens when you move the mouse into the left edge of the variables view. Where you have to go to expand or compress tree nodes in the variable display. Moving the mouse into this area is extremely dangerous, I was averaging about one crash for every 4 times I tried to expand a variable node. Then, I discovered you could expand or unexpand variable nodes by double clicking the node in the center of the variable view. Since I no longer have to move into the dangerous left edge of the variable view, eclipse has been almost problem free. This isn't a perfect answer. The crash still does happen at seemingly random when I move the mouse in the Java perspective. But this only happens once every couple weeks. I can live with that. Eclipse version: Kepler Service Release 1 Build id: 20139019-8919 OS: OpenSuse 13.1
Also happens with brand new Kubuntu 14.04 LTS Eclipse version: Kepler SR1 + J8 Using gtk2 with oxygen-gtk (since Eclipse on gtk3 isn't usable at all on this box). Most likely related to the Variables view, too.
Installing Oracle Java JDK on Kubuntu Linux 14.04 LTS (x86_64) seems to work with eclipse kepler (4.3.2) downloaded and installed directly from eclipse site instead of using the kubuntu repositories : You download the eclipse .tar.gz package and install eclipse like below (all instructions preceded with sudo, of course) mv /Downloads/eclipse /opt ln -s /opt/eclipse/eclipse /usr/local/bin/eclipse cd /opt chown -R root:root eclipse chmod -R g-w eclipse Then, you can find how to perform Oracle JDK installation here : http://www.wikihow.com/Install-Oracle-Java-JDK-on-Ubuntu-Linux Let me know if it works please. Regards.
(In reply to lazare lazare from comment #28) Thanks for the hint! What you describe is pretty much the setup I use all the time (except I install everything as a regular user, into a place where I have the permission). BUT when I reported comment 27 I was indeed using /usr/bin/java, which identifies itself as java version "1.7.0_55" OpenJDK Runtime Environment (IcedTea 2.4.7) (7u55-2.4.7-1ubuntu1) OpenJDK Server VM (build 24.51-b03, mixed mode) Going back to an original jdk (1.8.0 in my case) seems to fix this issue for me. Thanks again.
My problem is unfortunately not yet solved even though the crash occurs a little less frequently. Debugging becomes a tedious task as often having arrived at a breakpoint , simply move the mouse over the window without clicking anything is enough to cause the crash.
In case people aren't aware, the workaround for this bug is to go to System Settings -> Appliation Appearance -> GTK And then change the GTK2 theme from 'oxygen-gtk' to something else. I've been using Clearlooks myself, and it completely eliminates the bug.
Great ! Thanks a lot. I'd never have guessed it. I hope it fixes the problem for good.(In reply to Daniel Armbrust from comment #31)
With all the suggestions about themes: is anybody on this bug aware of a working gtk3 theme that is suitable for KDE? I'm primarily concerned about the button order, which seems to be defined by the theme. E.g., on KDE the correct order for a standard dialog is [ OK ] [ Cancel ] With unthemed GTK3 as well as themes like Clearlooks it's: [ Cancel ] [ OK ] which is like driving on the left side of the road :) and will be responsible for many accidents... So far, oxygen-gtk is the *only* correct gtk3 theme for KDE in this regard, that I've come across. Any hints?
(In reply to Stephan Herrmann from comment #27) > Also happens with brand new Kubuntu 14.04 LTS > > Eclipse version: Kepler SR1 + J8 > Using gtk2 with oxygen-gtk > (since Eclipse on gtk3 isn't usable at all on this box). > > Most likely related to the Variables view, too. I tried to reproduce this crash with no success. Ubuntu 14.04 KDE plasma desktop + oxygen-gtk both Kepler SR2 and Luna I20140512-2000 both OpenJDK 1.7.0_55 and Oracle Java 1.8.0_05 I'm using GTK2 I'm debugging code in ToolItem.java (SWT) and clicking in the Variables view as a test.
Created attachment 243376 [details] Variables view screenshot This is what my variables view looks like. I'm not that familiar with KDE and its themes so let me know if this looks wrong.
(In reply to Marc-Andre Laperle from comment #34) (In reply to Marc-Andre Laperle from comment #35) > Created attachment 243376 [details] > Variables view screenshot > > This is what my variables view looks like. I'm not that familiar with KDE > and its themes so let me know if this looks wrong. Thanks for trying. Looks familiar to me :) The Kubuntu 14.04 box is not my primary machine, and since avoiding the ubuntu-version of of OpenJDK I have not again seen the crash. But so far I have too little data to draw any conclusions from.
Posting core file and hs_err as well. The issue started occurring recently on Fedora 20.
Unable to upload a 200mb crash dump, here's the link: http://public-bug-report-attachments.s3-website-us-east-1.amazonaws.com/hs_err_pid88816.tar.gz
*** Bug 437348 has been marked as a duplicate of this bug. ***
*** Bug 441003 has been marked as a duplicate of this bug. ***
I still had eclipse crashing when I have switched to Oracle Java 1.8. However, switching GTK2 theme in KDE from "oxygen-gtk" seemed to have fixed the problem.
I have this crash every half hour or so in LiClipse 1.0.0 on Kubuntu 13.10 64-bit.
Hi, Environment: * Fedora 20 - 3.15.10-200.fc20.x86_64 * Java 1.7.0_60 * Eclipse Luna Version: Luna Release (4.4.0) Build id: 20140612-0600 I have had Eclipse crash fairly regularly for me whilst debugging. The following seems to have resolved it for me: Fedora 20, KDE, System Settings -> Application Appearance -> Changing Widget style from "Oxygen" to "GTK+ Style" has solved it for me. References: * https://issues.apache.org/jira/browse/DIRSTUDIO-962
(In reply to Daniel Armbrust from comment #31) > In case people aren't aware, the workaround for this bug is to go to System > Settings -> Appliation Appearance -> GTK > > And then change the GTK2 theme from 'oxygen-gtk' to something else. > > I've been using Clearlooks myself, and it completely eliminates the bug. Changing the theme also resolved the problem for me. It seems that oxygen is severly broken. The bug has been posted in the KDE bugzilla: https://bugs.kde.org/show_bug.cgi?id=338012
Created attachment 248041 [details] Gdb core backtrace Parts of the gdb core backtrace with lots of oxygen calls. Frames < 8 are just the usual java crash signal handling. This is from an Rcp 3.8.2 application crashing on OpenSuse 13.1 with oxygen-gtk theme.
(In reply to Stephan Herrmann from comment #29) > (In reply to lazare lazare from comment #28) > ...when I reported comment 27 I was indeed using /usr/bin/java, which > identifies itself as > > java version "1.7.0_55" > OpenJDK Runtime Environment (IcedTea 2.4.7) (7u55-2.4.7-1ubuntu1) > OpenJDK Server VM (build 24.51-b03, mixed mode) > > Going back to an original jdk (1.8.0 in my case) seems to fix this issue for > me. Wrong, it just happend on oracle jre 8: # JRE version: Java(TM) SE Runtime Environment (8.0-b132) (build 1.8.0-b132) # Java VM: Java HotSpot(TM) Server VM (25.0-b70 mixed mode linux-x86 ) # Problematic frame: # C [libgtk-x11-2.0.so.0+0x239faf] gtk_tree_view_get_background_area+0x8f If have two similarly configured systems (Kubuntu 14.04.1, Eclipse running on java 8, using gtk2 with theme QtCurve, *not* oxygen-gtk). So far I've seen the crash only on one of the machines. So if there's more things worth comparing, I'd be happy to provide more information.
Occurs with Luna, opendjdk 1.7.0, KDE, and OpenSuse in my case.
More crashes while (accidentally) using: OpenJDK Runtime Environment (IcedTea 2.5.4) (7u75-2.5.4-1~trusty1) When: on clicking into a Java editor ... Switching back to Oracle jre 8, since crashes seemed to be less frequent on that JVM (but see comment 46).
People using oxygen-gtk: have you tried to upgrade to oxygen-gtk2 1.4.6? I was getting an assertion/crash and after installing it, it solved it. The new version is here: https://projects.kde.org/news/276 Version 1.4.6 is part of Ubuntu 15.04 but on Ubuntu 14.04, I just compiled it and swapped the old one [kept a back up of course ;) ] The file is located here (on x86_64): /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/engines/liboxygen-gtk.so Stephan: About QtCurve, I tried to reproduce the crash with it unsuccessfully. It looks like there could be a similar issue with this theme. In /usr/share/themes/QtCurve/gtk-2.0/gtkrc can you try changing: From GtkComboBoxEntry::appears-as-list = 1 GtkComboBoxText::appears-as-list = 1 to GtkComboBoxEntry::appears-as-list = 0 GtkComboBoxText::appears-as-list = 0 See https://bugs.launchpad.net/ubuntu/+source/gtk2-engines-oxygen/+bug/1242801/comments/7 https://bugzilla.gnome.org/show_bug.cgi?id=736323
I did a quick C++ debug session using eclipse 4.4.2, eclipse-cdt 8.6.0 and oxygen-gtk2 1.4.6 on ArchLinux 64 bit. No crash occurred, and even if the debug session has been rather short I'd say this is a good result since I remember that the crash used to happen within a very short time when debugging. I will continue to test and eventually report back in case of a crash.
Created attachment 253404 [details] Crash log with oxygen-gtk2 1.4.6 It crashed again a minute ago while debugging C++. ArchLinux 64 bit, eclipse 4.4.2-1, eclipse-cdt 8.6.0-1, oxygen-gtk2 1.4.6-1.
*** Bug 458922 has been marked as a duplicate of this bug. ***
Created attachment 257741 [details] Crash log By your request for more crash dumps, I'm adding mine here. I was stepping around in some regular PHP code, and inspecting some variables, when this crash occurred. The last thing I did before the crash happened is I changed from one variable to another in the variable view window. I hope this helps understanding this bug. Best regards, Paul
Created attachment 257742 [details] Crash log By your request for more crash dumps, I'm adding mine here. I was stepping around in some regular PHP code, and inspecting some variables, when this crash occurred. The last thing I did before the crash happened is I changed from one variable to another in the variable view window. I hope this helps understanding this bug. Best regards, Paul
Just repeating some info that's already in here: The root of the problem seems to be https://bugs.kde.org/show_bug.cgi?id=338012 Doesn't look likely to be fixed, though. A workaround that reportedly works is to change the GTK2 theme to anything else than oxygen-gtk.
Many comments here seem to point to oxygen-gtk as the culprit. If this is the case, there is nothing we can do. If someone is able to reproduce the issue using a pure SWT snippet, please feel free to re-open this bug against Oxygen.
