harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [jira] Updated: (HARMONY-3224) [drlvm][gc] VM hangs or crashes after a lot of System.gc() invocations
Date Thu, 17 May 2007 07:42:12 GMT
Gregory, is this bug still existent? Actually It doesn't fail in my
tests. I stopped it after 200000 iterations.

Thanks,
xiaofeng

On 5/16/07, Gregory Shimansky (JIRA) <jira@apache.org> wrote:
>
>      [ https://issues.apache.org/jira/browse/HARMONY-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
>
> Gregory Shimansky updated HARMONY-3224:
> ---------------------------------------
>
>     Summary: [drlvm][gc] VM hangs or crashes after a lot of System.gc() invocations 
(was: [drlvm] VM hangs or crashes after a lot of System.gc() invocations)
>
> > [drlvm][gc] VM hangs or crashes after a lot of System.gc() invocations
> > ----------------------------------------------------------------------
> >
> >                 Key: HARMONY-3224
> >                 URL: https://issues.apache.org/jira/browse/HARMONY-3224
> >             Project: Harmony
> >          Issue Type: Bug
> >          Components: DRLVM
> >         Environment: Windows and Linux
> >            Reporter: Vera Petrashkova
> >
> > This test demonstrates the following issue in GC behavior. When System.gc() is invoked
then VM hangs or crashes.
> > ---------------test1.java---------------------
> > public class test1 {
> >     public static long cnt=0;
> >     public static void main(String args[]) {
> >         int flagGC = 0;
> >         try {
> >             flagGC = Integer.parseInt(args[0]);
> >         } catch (Exception e) {
> >         }
> >         System.out.println("Start: flagGC="+flagGC);
> >         Runtime r = Runtime.getRuntime();
> >         long maxMem = r.maxMemory();
> >         try {
> >             for (long i = 0; ; i++) {
> >                 long m1 = r.freeMemory();
> >                 ((test1_1)Class.forName("test1_1").newInstance()).test();
> >
> >                 if (flagGC == 1) {
> >                     System.gc();
> >                 }
> >                 long m2 = r.freeMemory();
> >                 if (i % 10000 == 0) {
> >                     System.err.println("Iteration: "+i+"  cnt: "+cnt+"   freeMem:
"+m1+" "+m2);
> >                 }
> >             }
> >         } catch (Throwable e) {
> >             e.printStackTrace();
> >         }
> >     }
> > }
> > class test1_1 {
> >     public void test() {
> >         test1.cnt++;
> >     }
> > }
> > -------------------------------------
> > When I run this test without GC invocation
> >      java -cp test1 0
> > than I stopted it after 15000000 iterations.
> > But in case of using GC
> >      java -cp test1 1
> > - sometimes this test hangs.
> > - otherwise it crashes after 130000 iterations.
> > A lot of tests from reliability test suite (https://issues.apache.org/jira/browse/HARMONY-2918)
use the scheme from "test1".
> > These tests repeat some actions and  invoke System.gc() afteter each iteration.
> > As the result they hang or VM  crashes and reports error message.
> > On Linux output is:
> > Start: flagGC=1
> > Iteration: 0  cnt: 1   freeMem: 14260128 14260128
> > Iteration: 10000  cnt: 10001   freeMem: 5592048 5592048
> > Iteration: 20000  cnt: 20001   freeMem: 10410884 10410884
> > Iteration: 30000  cnt: 30001   freeMem: 2861300 2861300
> > Iteration: 40000  cnt: 40001   freeMem: 7893908 7893908
> > Iteration: 50000  cnt: 50001   freeMem: 13765496 13765496
> > Iteration: 60000  cnt: 60001   freeMem: 6215956 6215956
> > Iteration: 70000  cnt: 70001   freeMem: 10969120 10969120
> > Iteration: 80000  cnt: 80001   freeMem: 3419512 3419512
> > Iteration: 90000  cnt: 90001   freeMem: 9291132 9291132
> > Iteration: 100000  cnt: 100001   freeMem: 15087472 15087472
> > Iteration: 110000  cnt: 110001   freeMem: 6774168 6774168
> > Iteration: 120000  cnt: 120001   freeMem: 12645720 12645720
> > Iteration: 130000  cnt: 130001   freeMem: 5096284 5096284
> > SIGSEGV in VM code.
> > SIGSEGV in VM code.
> > Stack trace:
> > Stack trace:
> >         1: hythread_monitor_try_enter (??:-1)
> >         2: monitor_wait_impl (??:-1)
> >         3: hythread_thin_monitor_try_enter (??:-1)
> >         4: IP is 0x56EB55B1 <native code>
> >         5: ?? (??:-1)
> > <end of stack trace>
> > Segmentation fault
> > On Windows output is:
> > Start: flagGC=1
> > Iteration: 0  cnt: 1   freeMem: 14260140 14260140
> > Iteration: 10000  cnt: 10001   freeMem: 5591808 5591808
> > Iteration: 20000  cnt: 20001   freeMem: 9854568 9854568
> > Iteration: 30000  cnt: 30001   freeMem: 2864096 2864096
> > Iteration: 40000  cnt: 40001   freeMem: 7617464 7617464
> > Iteration: 50000  cnt: 50001   freeMem: 13488960 13488960
> > Iteration: 60000  cnt: 60001   freeMem: 5379920 5379920
> > Iteration: 70000  cnt: 70001   freeMem: 10971940 10971940
> > Iteration: 80000  cnt: 80001   freeMem: 3422152 3422152
> > Iteration: 90000  cnt: 90001   freeMem: 9293992 9293992
> > Iteration: 100000  cnt: 100001   freeMem: 14373960 14373960
> > Iteration: 110000  cnt: 110001   freeMem: 7056664 7056664
> > Iteration: 120000  cnt: 120001   freeMem: 12089460 12089460
> > Iteration: 130000  cnt: 130001   freeMem: 4539920 4539920
> > An unhandled error (4) has occurred.
> > HyGeneric_Signal_Number=00000004
> > ExceptionCode=c0000005
> > ExceptionAddress=100022D9
> > ContextFlags=0001003f
> > Handler1=00401130
> > Handler2=11110A50
> > InaccessibleAddress=0000000C
> > EDI=00000000
> > ESI=00000000
> > EAX=00000000
> > EBX=00000000
> > ECX=00417E00
> > EDX=10410020
> > EIP=100022D9
> > ESP=0013F4F4
> > EBP=00417E00
> > Module=<DRL_VM_location>\bin\HYTHR.dll
> > Module_base_address=10000000
> > Offset_in_DLL=000022d9
> > This application has requested the Runtime to terminate it in an unusual way.
> > Please contact the application's support team for more information.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>


-- 
http://xiao-feng.blogspot.com

Mime
View raw message