Epic keeps crashing my eclipse

starwhisperer wrote on Sat Sep  6 08:53:51 MEST 2008:

There're a lot of times when I try to open a relatively large perl file
(sometimes it's not even large), the eclipse crashes with no error messages
in the log file.  I guess epic crashes my eclipse even before it gets a
chance to flush the error.

I'm pretty sure the other editors are fine, so it maybe epic's problem.

jploski wrote on Wed Sep 10 18:24:15 MEST 2008:

The only ways how EPIC could crash Eclipse are
1) through a JVM bug (in which case it's not EPIC's problem - in this case
you'd get a hotspot error log in the working directory of Eclipse)
2) memory exhaustion (followed by the OS killing the process)

Is the hotspot JVM error log dumped to the working directory? Do you see
anything relevant in the workspace/.metadata/.log? Can the problem be reproduced
with some input file?

technaton wrote on Fri Oct 24 13:07:10 MEST 2008:

I've got a simliar problem, and I guess it could have the same source. I'll
provide some log files to make a bughunt possible. :-) 

First of all I've to note that this crash only happens with Perl projects.
When using CDT or PyDev, Eclipse runs just stable.

I do get an hs_err*.log file, which contains the following (I snipped a
bit, hopefully I didn't cut out relevant things):

#
# An unexpected error has been detected by Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fa552ad9e1a, pid=3720, tid=1096800592
#
# Java VM: OpenJDK 64-Bit Server VM (1.6.0-b09 mixed mode linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x200e1a]
#
# If you would like to submit a bug report, please 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.
#

(... snip ...)

Current CompileTask:
C2:922      org.eclipse.core.internal.dtree.DataTreeNode.forwardDeltaWith([Lorg/eclipse/core/internal/dtree/AbstractDataTreeNode;[Lorg/eclipse/core/internal/dtree/AbstractDataTreeNode;Lorg/eclipse/core/internal/dtree/IComparator;)[Lorg/eclipse/core/internal/dtree/AbstractDataTreeNode;
(469 bytes)

(... snip ...)

---------------  P R O C E S S  ---------------

Java Threads: ( => current thread )
  0x00000000033eb400 JavaThread "EPIC:StringReader:ProcessExecutor:stdout"
[_thread_new, id=3872, stack(0x0000000
000000000,0x0000000000000000)]
  0x00007fa528890c00 JavaThread "Worker-10" [_thread_in_vm, id=3867, stack(0x0000000040499000,0x000000004059a000)
]
  0x00000000033c7c00 JavaThread "Provisioning Event Dispatcher" daemon [_thread_blocked,
id=3790, stack(0x0000000
040fc7000,0x00000000410c8000)]
  0x0000000000e5b000 JavaThread "Timer-1" [_thread_blocked, id=3784, stack(0x00000000408df000,0x00000000409e0000)
]
  0x00007fa528afb400 JavaThread "Timer-0" [_thread_blocked, id=3783, stack(0x00000000421b9000,0x00000000422ba000)
]
  0x00000000008d1800 JavaThread "DLTK indexing" daemon [_thread_blocked,
id=3778, stack(0x00000000420b8000,0x0000
0000421b9000)]
  0x00000000007f6400 JavaThread "Worker-9" [_thread_blocked, id=3777, stack(0x0000000041fb7000,0x00000000420b8000
)]
  0x0000000000c04400 JavaThread "Worker-6" [_thread_blocked, id=3774, stack(0x0000000041eb6000,0x0000000041fb7000
)]
  0x00000000007f1400 JavaThread "Worker-5" [_thread_blocked, id=3773, stack(0x0000000041901000,0x0000000041a02000)]
  0x00007fa5293f1c00 JavaThread "org.eclipse.cdt.internal.ui.text.CReconciler"
daemon [_thread_blocked, id=3761,stack(0x0000000041b80000,0x0000000041c81000)]
  0x00007fa5282a5000 JavaThread "Start Level Event Dispatcher" daemon [_thread_blocked,
id=3741, stack(0x0000000041800000,0x0000000041901000)]
  0x00007fa528275400 JavaThread "Framework Event Dispatcher" daemon [_thread_blocked,
id=3740, stack(0x0000000040398000,0x0000000040499000)]
  0x00007fa528252c00 JavaThread "State Data Manager" daemon [_thread_blocked,
id=3739, stack(0x00000000406dd000,0x00000000407de000)]
  0x00007fa528093c00 JavaThread "Low Memory Detector" daemon [_thread_blocked,
id=3730, stack(0x00000000415fe000,0x00000000416ff000)]
=>0x00007fa528091000 JavaThread "CompilerThread1" daemon [_thread_in_native,
id=3729, stack(0x00000000414fd000,0x00000000415fe000)]
  0x00007fa52808f800 JavaThread "CompilerThread0" daemon [_thread_blocked,
id=3728, stack(0x00000000413fc000,0x00000000414fd000)]
  0x00007fa52808e000 JavaThread "Signal Dispatcher" daemon [_thread_blocked,
id=3727, stack(0x00000000412fb000,0x00000000413fc000)]
  0x00007fa528065000 JavaThread "Finalizer" daemon [_thread_blocked, id=3726,
stack(0x0000000040297000,0x00000000
  0x00007fa528063800 JavaThread "Reference Handler" daemon [_thread_blocked,
id=3725, stack(0x0000000040196000,0x0000000040297000)]
  0x0000000000613c00 JavaThread "main" [_thread_in_native, id=3721, stack(0x00000000411fa000,0x00000000412fb000)]

Other Threads:
  0x00007fa52805e800 VMThread [stack: 0x0000000040cc4000,0x0000000040dc5000]
[id=3724]
  0x00007fa528096000 WatcherThread [stack: 0x00000000416ff000,0x0000000041800000]
[id=3731]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread:  ([mutex/lock_event])
[0x0000000000610350/0x00000000006103a0] Threads_lock - owner thread: 0x00007fa528890c00


(... snip ...)

OS:openSUSE 11.0 (X86-64)
VERSION = 11.0

uname:Linux 2.6.25.16-0.1-default #1 SMP 2008-08-21 00:34:25 +0200 x86_64
libc:glibc 2.8 NPTL 2.8
rlimit: STACK 8192k, CORE 0k, NPROC 24502, NOFILE 8192, AS 7506880k
load average:0,64 0,59 0,38

CPU:total 2 (2 cores per cpu, 1 threads per core) family 6 model 15 stepping
13, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3

Memory: 4k page, physical 3086044k(1695028k free), swap 6297472k(6297472k
free)

vm_info: OpenJDK 64-Bit Server VM (1.6.0-b09) for linux-amd64 JRE (1.6.0-b09),
built on Jun  7 2008 08:55:27 by "abuild" with gcc 4.3.1 20080507 (prerelease)
[gcc-4_3-branch revision 135036]

time: Fri Oct 24 11:35:24 2008
elapsed time: 363 seconds


HTH

jploski wrote on Fri Oct 24 20:21:08 MEST 2008:

1) Is this reproducible or does it happen from time to time only? This is
obviously a bug in the JVM (Java programs should never be able to crash
JVM), but perhaps some workarounds that could be implemented in EPIC exist.
2) Have you tried with the 32-bit version of Sun's JVM (running a 32-bit
version of Eclipse)? I've had stability problems using 64-bit Java+Eclipse
on OpenSuSE myself.

technaton wrote on Fri Oct 24 13:08:41 MEST 2008:

P. S. I already tried switching my Java VM to the stock Sun version, but
that didn't help.

technaton wrote on Fri Oct 31 23:15:35 CET 2008:

I did some investigations.

First thing: Its absolutely reproducable. Eclipse completely crashes whenever
the file tree view sidebar is upgraded, but *only* if an EPIC project is
involved. E. g. CDT projects don't crash. It happens with all types of update
actions, e. g. manually by pressing F5, when opening a new project, when
expanding a folder, ...

First thing I notice is that it only occurs with EPIC projects, so I guess
it might by worth digging there a bit.

Switching to a 32-bit Eclipse/Java environment solved the problem. But it
would definetly be nice if x86_64 Eclipse and EPIC would work together,
too.

One thing I suspect: It was introduced with the latest or the version before;
I was successfully using Eclipse x86_64 and EPIC before. But I am not sure,
and have no proof.

technaton wrote on Fri Oct 31 23:36:13 CET 2008:

More news: Just before calling a day, I ran my amd64 Eclipse with -Xint,
which magically stabilizes Eclipse.

See:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6659207
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6614100
http://everflux.de/amd-64-java-6-crahes-workaround-und-losungen-535/ (German)

Basically, it's a bug in the JVM, as you already pointed out. Sorry for
blaming EPIC :-( That neither CDT nor PyDev didn't crash Eclipse seemed
to be just coincedence...

jploski wrote on Fri Oct 31 23:51:59 CET 2008:

Thanks for investigating. Did upgrading to jdk6u10 fix it?