You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Aleksey Ignatenko (JIRA)" <ji...@apache.org> on 2007/06/19 10:33:26 UTC

[jira] Created: (HARMONY-4232) [testing][reliablity] ThreadKillTest hangs

[testing][reliablity] ThreadKillTest hangs
------------------------------------------

                 Key: HARMONY-4232
                 URL: https://issues.apache.org/jira/browse/HARMONY-4232
             Project: Harmony
          Issue Type: Bug
          Components: build - test - ci
         Environment: Win
            Reporter: Aleksey Ignatenko


Reliability test api.kernel.thread.ThreadKill.ThreadKillTest hangs running on drlvm both on release and debug binaries.
I watch the deadlock with the  debugger and saw that several monitors are waiting on "Object" object. I suppose it could be public static Object lock = new Object(); in the test.

Trying to localize the issue I found that:
 - t[k].join(); does not affect test hanging
 - king of threads does not affect test hanging (not matter MathThread or IOThread).

Vera Petrashkova also reported that test hangs sometimes on RI. Therefore I mark it as [testing][reliablity] for now but not [drlvm][threadding].
Need additional investigation by threadding gurus.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (HARMONY-4232) [testing][reliablity] ThreadKillTest hangs

Posted by "Vera Petrashkova (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HARMONY-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511347 ] 

Vera Petrashkova commented on HARMONY-4232:
-------------------------------------------

There is incorrectness in this test:
This test repeats some action several times (CYCLES_COUNT):
         -	creates Thread array and assigns  its elements by MathThread and IOThread
         -	starts these threads and waits that they really start their execution 
              while (started < THREADS_COUNT) {
                    Thread.yield();    
                }

               "started"  variable is increased by started thread.
        ...
        But "started" variable is defined as "static volatile"  and it is initialized  before general cycle starts.

63    public int test(String[] params) {
64        parseParams(params);
65        //table = new int[THREADS_COUNT];
66        started = 0;                                          <<<<<<<<<<<<<<<<<<<
67        for (int i = 0; i < CYCLES_COUNT; i++) {
68            Thread t[] = new Thread[THREADS_COUNT];            
69            for (int k = 0; k < THREADS_COUNT;) {
70                t[k] = new MathThread(k);                    
71                k++;
72                t[k] = new IOThread(k);       
73                k++;
74             }
75            try {                    
76                for (int k = 0; k < THREADS_COUNT; k++) {                 
77                    t[k].start();
78                }                
79                // just wait for all threads started                
80                while (started < THREADS_COUNT) {
81                    Thread.yield();    
82                }
            As the result mentioned while-statement executes only on the first step
            "started" variable initialization should be moved to the for-statement.

But this issue is not the general reason of the test hanging.

The test  hangs when it tries to interrupt created threads randomly.
83                // random murder
84                for (int k = 0; k < THREADS_COUNT*5; k++) {
85                    int j = rand.nextInt(THREADS_COUNT);
86                    t[j].interrupt();
87                }                       


It looks like H-4220 causes the failure of this test.


> [testing][reliablity] ThreadKillTest hangs
> ------------------------------------------
>
>                 Key: HARMONY-4232
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4232
>             Project: Harmony
>          Issue Type: Bug
>          Components: build - test - ci
>         Environment: Win
>            Reporter: Aleksey Ignatenko
>
> Reliability test api.kernel.thread.ThreadKill.ThreadKillTest hangs running on drlvm both on release and debug binaries.
> I watch the deadlock with the  debugger and saw that several monitors are waiting on "Object" object. I suppose it could be public static Object lock = new Object(); in the test.
> Trying to localize the issue I found that:
>  - t[k].join(); does not affect test hanging
>  - king of threads does not affect test hanging (not matter MathThread or IOThread).
> Vera Petrashkova also reported that test hangs sometimes on RI. Therefore I mark it as [testing][reliablity] for now but not [drlvm][threadding].
> Need additional investigation by threadding gurus.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (HARMONY-4232) [buildtest][reliablity] ThreadKillTest hangs

Posted by "Mikhail Markov (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HARMONY-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mikhail Markov updated HARMONY-4232:
------------------------------------

    Summary: [buildtest][reliablity] ThreadKillTest hangs  (was: [testing][reliablity] ThreadKillTest hangs)

> [buildtest][reliablity] ThreadKillTest hangs
> --------------------------------------------
>
>                 Key: HARMONY-4232
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4232
>             Project: Harmony
>          Issue Type: Bug
>          Components: build - test - ci
>         Environment: Win
>            Reporter: Aleksey Ignatenko
>
> Reliability test api.kernel.thread.ThreadKill.ThreadKillTest hangs running on drlvm both on release and debug binaries.
> I watch the deadlock with the  debugger and saw that several monitors are waiting on "Object" object. I suppose it could be public static Object lock = new Object(); in the test.
> Trying to localize the issue I found that:
>  - t[k].join(); does not affect test hanging
>  - king of threads does not affect test hanging (not matter MathThread or IOThread).
> Vera Petrashkova also reported that test hangs sometimes on RI. Therefore I mark it as [testing][reliablity] for now but not [drlvm][threadding].
> Need additional investigation by threadding gurus.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (HARMONY-4232) [testing][reliablity] ThreadKillTest hangs

Posted by "Vladimir Beliaev (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HARMONY-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554760 ] 

Vladimir Beliaev commented on HARMONY-4232:
-------------------------------------------

It looks like the right way to name this JIRA is [buildtes][reliability] - please get this fixed. This will allow to use the filters correctly.

> [testing][reliablity] ThreadKillTest hangs
> ------------------------------------------
>
>                 Key: HARMONY-4232
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4232
>             Project: Harmony
>          Issue Type: Bug
>          Components: build - test - ci
>         Environment: Win
>            Reporter: Aleksey Ignatenko
>
> Reliability test api.kernel.thread.ThreadKill.ThreadKillTest hangs running on drlvm both on release and debug binaries.
> I watch the deadlock with the  debugger and saw that several monitors are waiting on "Object" object. I suppose it could be public static Object lock = new Object(); in the test.
> Trying to localize the issue I found that:
>  - t[k].join(); does not affect test hanging
>  - king of threads does not affect test hanging (not matter MathThread or IOThread).
> Vera Petrashkova also reported that test hangs sometimes on RI. Therefore I mark it as [testing][reliablity] for now but not [drlvm][threadding].
> Need additional investigation by threadding gurus.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.