tags:

views:

999

answers:

11

Hi

I am a c++ programmer , I know little bit about java. I know that java programmers do not have to work with memory directly like C++. I also know that most crashes in C++ appliations are due to memory corruptions.

So can an application written in Java crash due to a memory related issue?

Thanks

+16  A: 

java can crash.

The cause can be..

OutOfMemoryError
StackoverFlowError
OutOfMemoryError: PermGen space.

OutOfMemoryError Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector.

StackoverFlowError StackOverflowException is thrown for execution stack overflow errors, typically in case of a very deep or unbounded recursion.

OutOfMemoryError: PermGen space The detail message PermGen space indicates that the permanent generation is full. The permanent generation is the area of the heap where class and method objects are stored. If an application loads a very large number of classes, then the size of the permanent generation might need to be increased using the -XX:MaxPermSize option.

The question was about memory problems that can cause a crash.

Other issues that can cause a crash, but can be caught by the program and recovered from posibilty are any runtimeExceptions. i.e.

ArithmeticException, ArrayStoreException, BufferOverflowException, BufferUnderflowException, CannotRedoException, CannotUndoException, ClassCastException, CMMException, ConcurrentModificationException, DOMException, EmptyStackException, IllegalArgumentException, IllegalMonitorStateException, IllegalPathStateException, IllegalStateException, ImagingOpException, IndexOutOfBoundsException, MissingResourceException, NegativeArraySizeException, NoSuchElementException, NullPointerException, ProfileDataException, ProviderException, RasterFormatException, SecurityException, SystemException, UndeclaredThrowableException, UnmodifiableSetException, UnsupportedOperationException

I wont go into these here. but have a look at... link text

jeff porter
+1 for Stackoverflow:)
Petar Minchev
You've Forgot: NullPointerException that almost alway come from nowhere....
Kedare
There's no such thing as a PermGenSpaceException
Michael Borgwardt
Your program can still run even if you have NullPointerException.
Snehal
Kedare: an uncaught NullPointerException, even more than the rest of these, is *not* a crash in the sense of the question. There is no memory corruption, and the JVM is shut down in an orderly manner (running shutdown hooks, etc.)
Michael Borgwardt
"A fatal error has been detected by the Java Runtime Environment: SIGSEGV (0xb) at pc=0x8fffa62d, pid=22963, tid=3065453424." It can crash in rather unkind ways.
Dave Jarvis
There's no such thing as an `OutOfMemoryException`. There is `OutOfMemoryError`, however. Likewise there is no `StackoverFlowException` - but `StackOverflowError`. It's important to be accurate.
Jesper
@jeff , Thanks for a detailed explanation
sat
A minor note you could also have JNI code corrupt the memory, though this wouldn't be considered a "100% pure java" application.
M. Jessup
Type on my part with OutOfMemoryException vs OutOfMemoryError. thanks for pointing that out! :-)
jeff porter
+1  A: 

Java programs crash all the time. The most common causes I come across are memory exhaustion and unhandled exceptions.

Marcelo Cantos
+7  A: 

yes it can :)

public void test() {
    test();
}

this will crash with a StackoverFlowError. there are a few others too - eg running out of memory will cause a crash (OutOfMemoryError) too.

oedo
+1 yep although this stack overflow is very different from a C++ buffer oveflow.
Rook
`StackOverflowError`, not `StackoverFlowException`.
Jesper
nice one jesper, thanks
oedo
Again you can catch this error and safely continue on as if it didn't happen if you choose too.
Peter Lawrey
A: 

So an application written in Java will never crash due to memory relate issue.

OutOfMemoryError is certainly a memory related issue. Furthermore, you can get a "real" crash (segfault) when a bug in the JVM is encountered (which is typically written in C or C++), or when there is a hardware problem (such as bad RAM). Possibly also when you run invalid bytecode on a JVM that does not validate it (such as JVMs for embedded systems).

But normally, yes, Java programs don't segfault.

Michael Borgwardt
A: 

No. Java Applications can crash due to memory issues. While Java does have built-in memory management, it's by no means perfect. It's just that a lot of the hard work is done for you.

As mentioned in some of the other answers, Java does have a fairly particular memory allocation system which does involve quite a bit of manual management and it's actually quite easy to exhaust this allocation if you're not careful and don't have it set up correctly for your application.

(See the -Xmx and -Xms parameters to Java)

AllenJB
A: 

While it's unlikely the JVM itself will crash it's perfectly possible for your program to crash through memory related issues, e.g from memory leaks via objects that never go out of scope.

(edit: the JVM is a highly optimised platform, and although bugs are very rare, they still crop up occasionally, plus of course, as others have mentioned here, if you have hardware issues like corruped I/O or RAM, the JVM can and will die)

Richard
+2  A: 

Memory corruptions in C++ don't just happen. They're caused by software errors, like writing past the end of an array. Doing that will lead to a crash in Java as well. (No language will take source code that contains an error and produce a program that does what you intended originally.) The difference is that in C++ you get "undefined behavior", i.e. the program might crash somewhere else. The Java program will crash the moment you try to write past the end of the array, which makes it much easier to find the bug.

nikie
+37  A: 

Contrary to some other answers I’ll claim that Java programs will crash as often, or possibly even more often than C++ programs.

By “crash” most people understand that a program encounters an error that isn’t properly handled, causing the application to terminate. Well, this of course happens and has got nothing to do with the way Java treats memory.

This is a good thing. What makes C++ so dangerous, and Java comparatively safe, is the precisely the fact that Java will crash in cases where C++ will happily continue running, albeit doing very wrong and potentially dangerous things (such as writing to uninitialized memory, overflowing buffers, …). Java’s crashing (e.g. throwing exceptions) prevents worse damage. C++ applications, on the other hand (due to the failure to terminate on errors), may do damage to external data or the system. Or they may just deliver a wrong (but seemingly plausible) result.

It’s against these dangers that Java guards, not against crashes per se.

Konrad Rudolph
+1 Undefined behavior is not a good thing to have in a program.
AraK
thanks for your answer , It help me in better understanding
sat
On the other side, if you don't want the program to continue running, and you absolutely want to throw an exception for any potential error in the calculations, you take the risk to explode rockets. See first Ariane 5 launch.
Didier Trosset
+1 A crash is better than undefined behaviour. But, a compile error is better than both, and I think C++ has better semantics to create compile time errors.
Viktor Sehr
@Viktor Sehr: Oh, I absolutely agree.
Konrad Rudolph
+1  A: 

This program will throw OutOfMemoryException and crash.

void crash(List list) {
   while (true) {
      list.add(new Object());
   }
}
fastcodejava
`OutOfMemoryError`, not `OutOfMemoryException`.
Jesper
You can catch the OutOfMemoryError, and clear the list and keep running as if it never happened. So even something which could crash the program can be recovered in Java.
Peter Lawrey
A: 

Of course they do crash :)

In addition to all the fine, answers, there's also the plain and simple JVM crash. For example, here's a question I asked concerning a case of a broken JVM which I can reliably crash using a particular data set (and it's not my fault: this "should not" happen... But it does ;)

I've seen server-side JVM crashes under some weird circumstances (Tomcat+Hibernate+Sun VM issue, back in the days, which were fixed, back in the days, by changing either Tomcat or the Sun VM).

I've seen JVM on the desktop side crashing when they should not (shipping commercial Java software to lots of desktop machine tend to rise the probability of you witnessing such a thing).

And the best I've seen is a JVM plain broken that I can reliably crash at work on several machines and, no, the machines ain't all having issues, they are rock-stable-solid workstations (since that post, I've tried on several machines and I can reproduce it):

http://stackoverflow.com/questions/2299250/java-vm-reproducable-sigsegv-on-both-1-6-0-17-and-1-6-0-18-how-to-report

(note that there a lot of other JVM that are fine on the same machines, with the same software/dataset).

The first thing I do when witnessing a JVM crash is change one of the software component: typically upgrading the JVM to the latest version.

Webinator
I have to mention that I'm by no mean implying Java ain't stable: I've got production servers with uptime of two years (hardened Debian Linux systems tend to not need many "critical" patches mandating a reboot ;) on which there are Java server running that barely ever need to be restarted (they're restarted, but not because of crashes and/or memory related issues).
Webinator
A: 

A serious crash looks like that:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00000000, pid=3387, tid=166603048020
#
# JRE version: 6.0_14-b08
# Java VM: Java HotSpot(TM) Server VM (14.0-b16 mixed mode linux-x86 )
# Problematic frame:
# C  0x00000000
#
# An error report file with more information is saved as:
# .....hs_err_pid3387.log

It's not the java programm that causes this, it's the code of the vm itself. It's very rare since a few years.

stacker