Eclipse crashes, rendering all system useless

[Oxyd]

I've got a fresh FreeBSD 8-Stable AMD64 install. I need to run Eclipse, so I installed diablo-jdk and Eclipse from Ports. When I start Eclipse, I can see the splash screen, then a message appears on console saying that Java has experienced a segfault in native code.

Things go haywire from there on: Eclipse splash screen just hangs on screen, as does the Java process. According to top, Java wants 43 Gigs of memory ("SIZE" column), is in "STOP" state and slowly eats my physical memory, including swap. kill doesn't work, kill -9 doesn't work, kill -9 as root doesn't work either -- the process just hangs on there, slowly eating my memory. Reboot is the only option I have found.

I tried disabling swap before trying again: the system quickly ran out of memory, and then started killing random processes but leaving the Java process alone.

Java is apparantely trying to dump a core:

> ls -lh ~/java.core
-rw-------  1 oxyd  oxyd    43G May 13 21:15 /usr/home/oxyd/java.core

I don't know if that is the whole coredump or just a part of it as I have always rebooted so far and never let the process quit on its own.

Java itself seems to work okay. I made a small Hello World program in Java:

[starlight] /tmp > javac Hello.java 
realpath: : No such file or directory
[starlight] /tmp > java Hello
realpath: : No such file or directory
Hello!

No crash here. I got the "No such file or directory" message while trying to run Eclipse as well. I guess that indicates something being wrong there.

Anyway, suggestions? I need to get Eclipse running. I'd also like to know what I can do if some other process in the future decides to dump a 43-Gig core, rendering the system useless in the process. Besides a reboot, that is.

 

[graudeejs]

# echo "kern.coredump=0" >> /etc/sysctl.conf
will disable core dumps after reboot

# sysctl kern.coredump=0
and no need to reboot

that 43G monstrosity is not normal

 

[Oxyd]

# echo "kern.coredump=0" >> /etc/sysctl.conf
will disable core dumps after reboot

# sysctl kern.coredump=0
and no need to reboot

Cool, thanks!

that 43G monstrosity is not normal

I agree -- never seen anything like that in my life.

My working theory is that for some reason -- a bug in the JRE -- Java asks the OS to allocate it 43 GB of memory -- since this is 64-bit system, that should fit within the available virtual memory for one process (or not?). Java then crashes, trying to dump a core -- since it's got 43 GB allocated, all of that needs to go to the coredump. The process gets stuck in kernel as the system is trying mightily to commit and dump all of that memory, rendering the process unkillable.

Does that sound plausible? Any way to verify? I'm kinda afraid to load the coredump in GDB -- I mean, I've never met anything that huge. (That's not what she said.)

Also, I just installed java/jdk16. It also gives the "realpath: : No such file or directory" message when running Hello World or just simple java -version. Googling for it reveals this very thread. (Google is indexing quite fast, isn't it?)

Edit: More info:

[starlight] ~ > java -version
realpath: : No such file or directory
java version "1.6.0_03-p4"
Java(TM) SE Runtime Environment (build 1.6.0_03-p4-root_13_may_2010_21_53-b00)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_03-p4-root_13_may_2010_21_53-b00, mixed mode)
[starlight] ~ > eclipse
realpath: : No such file or directory
#
# An unexpected error has been detected by Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000000825d6d985, pid=11170, tid=0xa0ae40
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.6.0_03-p4-root_13_may_2010_21_53-b00 mixed mode)
# Problematic frame:
# C  [libglib-2.0.so.0+0x18985]  g_base64_encode_step+0xe5
#
# An error report file with more information is saved as hs_err_pid11170.log
#
# Please submit bug reports to freebsd-java@FreeBSD.org
#

I guess I file a bug report then.

 

[graudeejs]

I don't think there is a point in loading that dump file....
Does your system have enough resources to allocate 43G? I doubt...
Maybe some bug in FreeBSD coredumping was triggered?

 

[Oxyd]

*sigh* So how many bugs and where have I triggered? Should I bug the Java team? The Eclipse team? The FreeBSD team?

My system is concretely this:

FreeBSD starlight 8.0-STABLE FreeBSD 8.0-STABLE #0 r207959: Wed May 12 14:25:58 CEST 2010     root@starlight:/usr/obj/usr/src/sys/STARLIGHT  amd64

(Yeah, that's from SVN.) STARLIGHT config differs from GENERIC only in name and that "device ulpt" is disabled in STARLIGHT.

And no, I don't have 43 Gigs of memory.

 

[graudeejs]

You don't need 43G or Ram, if you have 40G of swap and 3G of Ram (or something like that )

Perhaps try to reproduce this bug again. (if you have had this at least 2x times, then skip this)
and mail to some generic FreeBSD mailing list (at least that's what I'd do, I do not think anyone here will be able to help you)

 

[Oxyd]

That's why I said "memory", not "RAM". I only have like 5 GB total RAM + Swap.

Yeah, I just e-mailed questions and java mailing lists. I'll report back if I get somewhere, so that Google has something more useful to index than the question.

 

[Oxyd]

Okay, a little update.

Regarding the "realpath: : No such file or directory" message. According to the freebsd-java mailing list, I'm not the only one who has hit that. It appears to be a bug in java/javavmwrapper -- a fixed version should be in ports already. (I'm at school now, haven't tested yet.)

The crash itself appears to be due to a bug in Glib that was introduced with the Gnome upgrade to 2.30. I'll toy around with the Gnome & Glib & Eclipse & Java combo.

I still don't know what made Java dump a 43 GB core.