Name: clC74495 Date: 01/15/99


When the GC heap area is exhausted, java causes SIGSEGV on Solaris and
an application error on Win32.
 
Following code demonstrates the problem.
 
class obj {
        public obj next;
        public long id;
        private static long nextid = 0;
 
        obj() {
                id = nextid++;
        }
}
 
class list {
        public obj top;
 
        list() {
                top = null;
        }
 
        public void push () {
                obj temp = new obj();
                temp.next = top;
                top = temp;
        }
        public void pop () {
                if (top != null) {
                        obj temp = top;
                        top = top.next;
                }
        }
}
 
class crtobj {
        public static void main(String[] args) {
                Runtime rt = Runtime.getRuntime();
                System.out.println("total memory " + rt.totalMemory());
                list list1;
 
                list1 = new list();
                System.out.println("free memory " + rt.freeMemory());
                try {
                        for(;;)
                                list1.push();
                } catch (OutOfMemoryError e) {
                        System.out.println("OutOfMemoryError");
                        System.out.println("free memory " + rt.freeMemory());
                        for(;list1.top != null;)
                                list1.pop();
                        rt.gc();
                        System.out.println("free memory " + rt.freeMemory());
                        rt.runFinalization();
                }
                System.out.println("free memory " + rt.freeMemory());
        }
}
 
On Solaris,
%java -mx64k -ms4k crtobj
causes SIGSEGV with the following message.
 
SIGSEGV 11* segmentation violation
    si_signo [11]: SIGSEGV 11* segmentation violation
    si_errno [0]: Error 0
    si_code [1]: SEGV_MAPERR [addr: 0x0]
 
        stackbase=EFFFF2C0, stackpointer=EFFFF068
 
Full thread dump:
    "Finalizer thread" (TID:0xef793200, sys_thread_t:0xef390db8, state:R) prio=1
    "Async Garbage Collector" (TID:0xef793248, sys_thread_t:0xef3c0db8, state:R) prio=1
    "Idle thread" (TID:0xef793290, sys_thread_t:0xef3f0db8, state:R) prio=0
    "Clock" (TID:0xef793088, sys_thread_t:0xef420db8, state:CW) prio=12
    "main" (TID:0xef7930b0, sys_thread_t:0x434d0, state:R) prio=5 *current thread*
        java.lang.System.initializeSystemClass(System.java)
Monitor Cache Dump:
Registered Monitor Dump:
    Thread queue lock: <unowned>
    Name and type hash table lock: <unowned>
    String intern lock: <unowned>
    JNI pinning lock: <unowned>
    JNI global reference lock: <unowned>
    BinClass lock: <unowned>
    Class loading lock: <unowned>
    Java stack lock: <unowned>
    Code rewrite lock: <unowned>
    Heap lock: <unowned>
    Has finalization queue lock: <unowned>
    Finalize me queue lock: <unowned>
    Dynamic loading lock: <unowned>
    Monitor IO lock: <unowned>
    Child death monitor: <unowned>
    Event monitor: <unowned>
    I/O monitor: <unowned>
    Alarm monitor: <unowned>
        Waiting to be notified:
            "Clock" (0xef420db8)
    Sbrk lock: <unowned>
    Monitor registry: owner "main" (0x434d0, 1 entry)
Thread Alarm Q:
 
On Win32, java with the same argument causes an application error
saying the instruction at "0x1000b166" referred memory at "0x00000000".
This problem has been confirmed in JDK 1.1.6 to 1.1.8E.
 
In share/java/runtime/gc.c, an error handling should be added to the
realObjAlloc() function when the cacheAlloc() function is returned
with an error in the realObjAlloc() function.
Java 2 includes the initial and maximum heap size consistency check.
At least, similar check should be ported back to JDK 1.1.x source code.
(Review ID: 52470)
======================================================================