Community
Participate
Working Groups
Build Identifier: 20110916-0149 Eclipse EE Indigo crashes every time I try to delete a source file (using right click and clicking delete on menu). The crash happened also when I tried to do some other things such as selecting an existing project in project explorer and trying to open it in (this did not crash Eclipse every time but trying to delete a file does). Eclipse is a 64-bit Java EE Indigo version on Centos & 64-bit OS (Rel 6.0, Kernel Linux 2.6.32-71.el6.x86_64, GNOME 2.28.2), Java is 1.7.0_01-b08 (Oracle). The crashes also happened when using Eclipse Galileo and OpenJDK 1.6. I will attach an error report file after filing this. # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000003035e14da0, pid=3224, tid=140342080034576 # # JRE version: 7.0_01-b08 # Java VM: Java HotSpot(TM) 64-Bit Server VM (21.1-b02 mixed mode linux-amd64 compressed oops) # Problematic frame: # C [ld-linux-x86-64.so.2+0x14da0] # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # //hs_err_pid3224.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # CompilerOracle: exclude org/eclipse/core/internal/dtree/DataTreeNode.forwardDeltaWith CompilerOracle: exclude org/eclipse/jdt/internal/compiler/lookup/ParameterizedMethodBinding.<init> CompilerOracle: exclude org/eclipse/cdt/internal/core/dom/parser/cpp/semantics/CPPTemplates.instantiateTemplate CompilerOracle: exclude org/eclipse/cdt/internal/core/pdom/dom/cpp/PDOMCPPLinkage.addBinding CompilerOracle: exclude org/python/pydev/editor/codecompletion/revisited/PythonPathHelper.isValidSourceFile CompilerOracle: exclude org/python/pydev/ui/filetypes/FileTypesPreferencesPage.getDottedValidSourceFiles -- This is very worrisome because we need to use 64-bit Eclipse on 64-bit CentOS 6 for a time-critical project. Reproducible: Always Steps to Reproduce: 1. Start Eclipse Indigo 2. Open existing EJB project 3. Try to delete a source file or any folder. 4. JVM crashes and Eclipse crashes
Created attachment 206793 [details] Error log Attached an error report file.
Crash in j org.eclipse.swt.internal.gtk.OS._gtk_icon_set_render_icon(JJIIIJJ)J+0 j org.eclipse.swt.internal.gtk.OS.gtk_icon_set_render_icon(JJIIIJJ)J+19 j org.eclipse.swt.widgets.Display.createImage(Ljava/lang/String;)Lorg/eclipse/swt/graphics/Image;+24 j org.eclipse.swt.widgets.Display.getSystemImage(I)Lorg/eclipse/swt/graphics/Image;+91 maybe related to bug 345477 Aarun, please investigate.
*** Bug 368705 has been marked as a duplicate of this bug. ***
I am seeing this crash running Eclipse 3.7.2 on 64-bit RHEL6 Linux kernel 2.6.32-71.el6.x86_64. GDB shows the following native stack after the java call to org.eclipse.swt.internal.gtk.OS._gtk_icon_set_render_icon: #0 0x00000035ad214d70 in _dl_x86_64_save_sse () from /lib64/ld-linux-x86-64.so.2 #1 0x00000035ad20aaea in _dl_lookup_symbol_x () from /lib64/ld-linux-x86-64.so.2 #2 0x00000035ad20dee0 in _dl_fixup () from /lib64/ld-linux-x86-64.so.2 #3 0x00000035ad2147b5 in _dl_runtime_resolve () from /lib64/ld-linux-x86-64.so.2 #4 0x00000035c720a19a in ?? () from /usr/lib64/librsvg-2.so.2 #5 0x00000035c7221bd6 in ?? () from /usr/lib64/librsvg-2.so.2 #6 0x00000035c7222160 in ?? () from /usr/lib64/librsvg-2.so.2 #7 0x00000035c720cfde in ?? () from /usr/lib64/librsvg-2.so.2 #8 0x00000035c7227e4f in ?? () from /usr/lib64/librsvg-2.so.2 #9 0x00000035c72287fb in ?? () from /usr/lib64/librsvg-2.so.2 #10 0x00000035b7a45f8b in xmlParseStartTag () from /usr/lib64/libxml2.so.2 #11 0x00000035b7a4be1f in ?? () from /usr/lib64/libxml2.so.2 #12 0x00000035b7a4cc00 in xmlParseChunk () from /usr/lib64/libxml2.so.2 #13 0x00000035c7226b82 in ?? () from /usr/lib64/librsvg-2.so.2 #14 0x00007f234e32dd91 in ?? () from /usr/lib64/gtk-2.0/2.10.0/loaders/svg_loader.so #15 0x00000035b9e0c16f in gdk_pixbuf_loader_write () from /usr/lib64/libgdk_pixbuf-2.0.so.0 #16 0x00000035b9e0aa1f in ?? () from /usr/lib64/libgdk_pixbuf-2.0.so.0 #17 0x00000035b9e0ab81 in gdk_pixbuf_new_from_stream_at_scale () from /usr/lib64/libgdk_pixbuf-2.0.so.0 #18 0x00000035b9318497 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #19 0x00000035b9318c42 in gtk_icon_info_load_icon () from /usr/lib64/libgtk-x11-2.0.so.0 #20 0x00000035b931adbf in gtk_icon_theme_load_icon () from /usr/lib64/libgtk-x11-2.0.so.0 #21 0x00000035b9315441 in gtk_icon_set_render_icon () from /usr/lib64/libgtk-x11-2.0.so.0 #22 0x00007f23dedbe5d2 in Java_org_eclipse_swt_internal_gtk_OS__1gtk_1icon_1set_1render_1icon () from /home/sellis/eclipse_workspace_83/.metadata/.plugins/org.eclipse.pde.core/run_debug/org.eclipse.osgi/bundles/137/1/.cp/libswt-pi-gtk-3740.so #23 0x00007f254025a8cb in ?? () #24 0x00007f2500000006 in ?? () #25 0x0000000000000000 in ?? () I found that setting the environment variable LD_BIND_NOW to 1 before starting eclipse stops the crash from happening, so apparently some symbol in the PLT is getting crossed.
Oops, here's the stack including the SIGSEGV message: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f2543e18710 (LWP 10317)] 0x00000035ad214d70 in _dl_x86_64_save_sse () from /lib64/ld-linux-x86-64.so.2 (gdb) where #0 0x00000035ad214d70 in _dl_x86_64_save_sse () from /lib64/ld-linux-x86-64.so.2 #1 0x00000035ad20aaea in _dl_lookup_symbol_x () from /lib64/ld-linux-x86-64.so.2 #2 0x00000035ad20dee0 in _dl_fixup () from /lib64/ld-linux-x86-64.so.2 #3 0x00000035ad2147b5 in _dl_runtime_resolve () from /lib64/ld-linux-x86-64.so.2 #4 0x00000035c720a19a in ?? () from /usr/lib64/librsvg-2.so.2 #5 0x00000035c7221bd6 in ?? () from /usr/lib64/librsvg-2.so.2 #6 0x00000035c7222160 in ?? () from /usr/lib64/librsvg-2.so.2 #7 0x00000035c720cfde in ?? () from /usr/lib64/librsvg-2.so.2 #8 0x00000035c7227e4f in ?? () from /usr/lib64/librsvg-2.so.2 #9 0x00000035c72287fb in ?? () from /usr/lib64/librsvg-2.so.2 #10 0x00000035b7a45f8b in xmlParseStartTag () from /usr/lib64/libxml2.so.2 #11 0x00000035b7a4be1f in ?? () from /usr/lib64/libxml2.so.2 #12 0x00000035b7a4cc00 in xmlParseChunk () from /usr/lib64/libxml2.so.2 #13 0x00000035c7226b82 in ?? () from /usr/lib64/librsvg-2.so.2 #14 0x00007f234e32dd91 in ?? () from /usr/lib64/gtk-2.0/2.10.0/loaders/svg_loader.so #15 0x00000035b9e0c16f in gdk_pixbuf_loader_write () from /usr/lib64/libgdk_pixbuf-2.0.so.0 #16 0x00000035b9e0aa1f in ?? () from /usr/lib64/libgdk_pixbuf-2.0.so.0 #17 0x00000035b9e0ab81 in gdk_pixbuf_new_from_stream_at_scale () from /usr/lib64/libgdk_pixbuf-2.0.so.0 #18 0x00000035b9318497 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #19 0x00000035b9318c42 in gtk_icon_info_load_icon () from /usr/lib64/libgtk-x11-2.0.so.0 #20 0x00000035b931adbf in gtk_icon_theme_load_icon () from /usr/lib64/libgtk-x11-2.0.so.0 #21 0x00000035b9315441 in gtk_icon_set_render_icon () from /usr/lib64/libgtk-x11-2.0.so.0 #22 0x00007f23dedbe5d2 in Java_org_eclipse_swt_internal_gtk_OS__1gtk_1icon_1set_1render_1icon () from /home/sellis/eclipse_workspace_83/.metadata/.plugins/org.eclipse.pde.core/run_debug/org.eclipse.osgi/bundles/137/1/.cp/libswt-pi-gtk-3740.so #23 0x00007f254025a8cb in ?? () #24 0x00007f2500000006 in ?? () #25 0x0000000000000000 in ?? ()
We determined this is caused by a bug in glibc. In order to fix the issue: User needs to update their glibc libraries using info in following Red Hat errata: http://rhn.redhat.com/errata/RHBA-2013-0279.html Also, updating RHEL6 to 6.3 or 6.4 will work.
Here is the bug: http://sourceware.org/bugzilla/show_bug.cgi?id=12113
(In reply to Scott Ellis from comment #6) > We determined this is caused by a bug in glibc. In order to fix the issue: > User needs to update their glibc libraries using info in following Red Hat > errata: > http://rhn.redhat.com/errata/RHBA-2013-0279.html > Also, updating RHEL6 to 6.3 or 6.4 will work. This indicates the bug is not in SWT, closing.
