You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Pavel Rebriy (JIRA)" <ji...@apache.org> on 2008/02/28 08:05:51 UTC

[jira] Commented: (HARMONY-5447) [drlvm] Hang in ThreadSuspendResume test from the reliability test suite

    [ https://issues.apache.org/jira/browse/HARMONY-5447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12573164#action_12573164 ] 

Pavel Rebriy commented on HARMONY-5447:
---------------------------------------

I've investigated a deadlock in ThreadSuspendResume and found the following problem:

On the first iteration of suspending loop VM loads classes to execute tests methods. Main thread could suspend tested thread within synchronization section of ClassLoader. After successful suspension main thread calls System.gc(). To do it VM should load System class. If tested thread is suspended within synchronized section of ClassLoader loading System class falls to infinite loop on monitorenter instruction. This leads to deadlock of the test.

As to my point of view it is the test problem. Using deprecated suspend/resume methods it is unsafe operation.

To avoid test deadlock I've created a patch to the test. The patch loads System class before suspension loop and thus System.gc() call doesn't require to run ClassLoader.

> [drlvm] Hang in ThreadSuspendResume test from the reliability test suite
> ------------------------------------------------------------------------
>
>                 Key: HARMONY-5447
>                 URL: https://issues.apache.org/jira/browse/HARMONY-5447
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>         Environment: Linux x86 r615453
>            Reporter: Andrey Yakushev
>
> There is hang in cruise control test run:
> http://people.apache.org/~smishura/r615453/Linux_x86/reliability/api/kernel/thread/ThreadSuspendResume/20_ThreadSuspendResume.html
> I was trying to reproduce it and have obtained 1 hung from 208 test run 12-15 minutes each. Total test  run time was ~24 hours. So don't expect easy catching of this bug :)  :(

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