[Bug 520] Crash with big mutli dimesnional arrays works in Sun(Oracle)JRE

[bugzilla-daemon at icedtea.classpath.org]

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=520


jon.vanalten at redhat.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |INVALID




------- Comment #3 from jon.vanalten at redhat.com  2010-07-12 19:38 -------
 (In reply to comment #2)
> The problem is that it definitely shouldn't crash with a segemntation fault and
> without meaningfull error messages. 

A seg fault, depending on when it happens, may or may not be detectable by the
JVM, so it might not be possible for any meaningful error messages.  Although,
as noted, the lack of meaningful messages is only in the case of running from
your jar.  When compiled class file is used, the OOM error is given (not a seg
fault at all).  I have also now tried making new jar from the source and this
runs fine on my system (where by "runs fine" I mean runs to completion if
enough heap space is available and gives OOM error if not).  Maybe there is
something odd about this jar file?  When it segfaults, it does so immediately
as if it is not even getting to the point of running the program.

> Also I've discovered that it is with 99% certainty a HotSpot bug. 
> The exact same jar file runs on my Mobile Phone (Nokia N900 with OpenJDK
> 1.6.018 with ZeroVM)  and that thing has 240 megs of RAM. I can also reproduce
> the crash on Ubuntu.

This indicates a Hotspot *difference* yes, not necessarily a bug.  Running out
of heap is running out of heap.  There are potential differences in how max
heap size is determined by different VMs, and the amount of physical RAM
available (as your N900 example) is not necessarily a limiting factor (the OS
could easily be swapping out JVM memory from under it).  And again, different
VMs will not be equal with respect to garbage collection.  Do you have any
information that this problem is caused by something other than running out of
heap space?

> Maybe it will crash for your rebuilt version on a further run, as I mentioned
> it happens that it works for several and and then not for other runs.

Yes I perhaps was not perfectly clear.  I tested this numerous times, building
your program with several different numbers of elements.  I found that,
consistently, there was a point at which each JDK started running out of heap. 
That point was higher for the closed JDK.  I did not increase the number of
elements by 1, it was more like 20 or 50, so there is probably a number of
elements where, on my system, some runs will complete while others will run out
of heap, based on variations of how garbage collection is scheduled or other
factors.  I did not spend time finding this range.  When I found the point on
each JVM where it failed consistently, I tried tinkering with the MaxHeapSize,
and was able to determine that for both Icedtea and closed JDK that I could
consistently run the program to completion by specifying a sufficiently high
value.  Have you attempted this workaround?

> This is definitely not expected behaviour!

Yes, an OOM error is the expected behavior when there is no heap space
available.  And this can vary from run to run, depending on precisely how
garbage collection ends up being scheduled around the rest of the activity at
runtime.

> Also the difference between HotSpot and Zero makes me think there is something
> more deep in there broken. 
> I mean come on if it runs absolutely perfect (tested over a dozen runs each
> taking about 1.6 seconds) on my Phone but not on my Laptop with 4 Gigs of RAM
> it's definitely broken. Also note that it crashes with as little as 50 Elements
> on current OpenJDK, 

It is not a matter of physical memory.  And OpenJDK can handle as many as 1000
elements or more, as I have noted, by specifying an appropriate amount of heap
space.  Please take this suggestion and try it out.  For example:

$ java -XX:MaxHeapSize=1G -jar rucksack.jar

OR

$ java -XX:MaxHeapSize=1G main.Rucksack

> maybe the source in the jar has more and therefor doesn;t
> correspond to the class files. 

Why would you package class file in a jar along with source that does not match
it?  This is misleading to those of us who would like to help.

Please reopen this if you believe there to be a problem other than the program
running out of heap.


-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.