|
Problem |
JVM crash on Solaris. |
|
Cause |
Reference Bug Parade on http://java.sun.com Bug ID
4682937
Hotspot compilers
might use the abort() system call when resources are exhausted; that is,
logging "OutofMemoryError" and calling abort().
In the interests of reliability, however, dynamic code compilation should
not be calling abort().
If a compilation is attempted and cannot be completed, the
Java™ runtime should
revert to interpreted mode.
Logging this fact is beneficial in case performance questions are raised,
and so that tuning parameters can be applied (without the unexpected
downtime caused by an abort() ).
Example stacktrace ( pstack ) : |
|
core 'core.20030507' of 8579:
/opt/WebSphere4/AppServer/java/jre/bin/../bin/sparc/native_threads/jav
----------------- lwp# 4 / thread# 4
--------------------
ff369764 __sigprocmask (ff36bf60, 0, 0, fee0bd70,
ff37e000, 0) + 8
ff35e110 _sigon (fee0bd70, ff385930, 6, fee0a5b4,
fee0bd70, 6) + d0
ff361150 _thrp_kill (0, 4, 6, ff37e000, 4, ff2c0448) +
f8
ff24b9d4 raise (6, 0, 0, ffffffff, ff2c03b4, 4) +
40
ff2358f4 abort (ff2bc004, fee0a708, 0, fffffff8, 4,
fee0a729) + 100 |
|
Solution |
Workaround
Set -XX:MaxPermSize=64m to a larger size if necessary;
for example, 128m.
Solution
This problem is fixed in Sun JDK 1.3.1_08.
Reference Bug ID 4707386 & 462937 |
|
|