You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Michael McCandless <lu...@mikemccandless.com> on 2013/01/30 00:03:32 UTC
test failures when running under IBM J9
When I run Lucene core tests with IBM J9 1.6, some tests fail with
zombie threads that could not be killed, eg:
[junit4:junit4] ERROR 0.00s J2 | TestIndexWriterDelete (suite) <<<
[junit4:junit4] > Throwable #1:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked
from SUITE scope at org.apache.lucene.index.TestIndexWriterDelete:
[junit4:junit4] > 1) Thread[id=102, name=Thread-44,
state=TIMED_WAITING, group=TGRP-TestIndexWriterDelete]
[junit4:junit4] > at java.lang.Object.wait(Native Method)
[junit4:junit4] > at java.lang.Object.wait(Object.java:196)
[junit4:junit4] > at java.util.Timer$TimerImpl.run(Timer.java:247)
[junit4:junit4] > at __randomizedtesting.SeedInfo.seed([C9014BCB129899BF]:0)
[junit4:junit4] > Throwable #2:
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still
zombie threads that couldn't be terminated:
[junit4:junit4] > 1) Thread[id=102, name=Thread-44,
state=TIMED_WAITING, group=TGRP-TestIndexWriterDelete]
[junit4:junit4] > at java.lang.Object.wait(Native Method)
[junit4:junit4] > at java.lang.Object.wait(Object.java:196)
[junit4:junit4] > at java.util.Timer$TimerImpl.run(Timer.java:247)
[junit4:junit4] > at __randomizedtesting.SeedInfo.seed([C9014BCB129899BF]:0)
It looks like this is a JVM thread ... is there an "exceptions list"
somewhere to ignore this thread? Or some other solution?
Second, strangely, I see the "who tests the tester tests" hit real failures, eg:
[junit4:junit4] FAILURE 0.01s J2 |
TestReproduceMessage.testFailureBeforeClass <<<
[junit4:junit4] > Throwable #1: java.lang.AssertionError
[junit4:junit4] > at org.junit.Assert.fail(Assert.java:92)
[junit4:junit4] > at org.junit.Assert.assertTrue(Assert.java:43)
[junit4:junit4] > at org.junit.Assert.assertTrue(Assert.java:54)
[junit4:junit4] > at
org.apache.lucene.util.junitcompat.TestReproduceMessage.testFailureBeforeClass(TestReproduceMessage.java:173)
[junit4:junit4] > at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit4:junit4] > at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
[junit4:junit4] > at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
[junit4:junit4] > at java.lang.reflect.Method.invoke(Method.java:611)
[junit4:junit4] > at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
[junit4:junit4] > at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
[junit4:junit4] > at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
[junit4:junit4] > at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
[junit4:junit4] > at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
[junit4:junit4] > at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
[junit4:junit4] > at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
[junit4:junit4] > at org.junit.rules.RunRules.evaluate(RunRules.java:18)
[junit4:junit4] > at
org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
[junit4:junit4] > at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
[junit4:junit4] > at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
[junit4:junit4] > at
org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
[junit4:junit4] > at
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
[junit4:junit4] > at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
[junit4:junit4] > at
org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
[junit4:junit4] > at
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
[junit4:junit4] > at
org.junit.runners.ParentRunner.run(ParentRunner.java:300)
[junit4:junit4] > at
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:180)
[junit4:junit4] > at
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:275)
[junit4:junit4] > at
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:12)
These are tests that intentionally set up a failure, and then confirm
that the test framework catches that failure ... yet for some reason
with J9 this turns into a real failure ... any ideas?
Mike McCandless
http://blog.mikemccandless.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: test failures when running under IBM J9
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Wed, Jan 30, 2013 at 2:43 AM, Dawid Weiss
<da...@cs.put.poznan.pl> wrote:
> CC me directly if you can, Mike -- I have been terribly busy and
> wouldn't want to miss questions that relate directly to what I can
> answer. :)
OK will do!
>> [junit4:junit4] > 1) Thread[id=102, name=Thread-44,
>> state=TIMED_WAITING, group=TGRP-TestIndexWriterDelete]
>> [junit4:junit4] > at java.lang.Object.wait(Native Method)
>> [junit4:junit4] > at java.lang.Object.wait(Object.java:196)
>> [junit4:junit4] > at java.util.Timer$TimerImpl.run(Timer.java:247)
>
> The question is what starts these Timer threads? I mean: we can
> exclude such threads but I'd do some digging first to see if it's not
> an error. The thread's name looks suspiciously un-VM-like to me (it's
> too generic).
I'll open an issue and try to do some digging ...
>> It looks like this is a JVM thread ... is there an "exceptions list"
>> somewhere to ignore this thread? Or some other solution?
>
> There are several ways to ignore threads. You can annotate a method
> (or class) so that it ignores thread-checking entirely, you can add
> the known offenders to ignored filters. Take a look at
> SolrIgnoredThreadsFilter for real-life examples; Lucene uses
> QuickPatchThreadsFilter (it's currently empty).
>
> If you can name the J9 version and test/seed that causes this I'll
> take a look at the root of the problem first.
I'm using this J9 version, on Linux:
java version "1.6.0"
Java(TM) SE Runtime Environment (build
pxa6460sr9fp2ifix-20111111_05(SR9
FP2+IV03622+IV02378+IZ99243+IZ97310+IV00707))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64
jvmxa6460sr9-20111111_94827 (JIT enabled, AOT enabled)
J9VM - 20111111_094827
JIT - r9_20101028_17488ifx45
GC - 20101027_AA)
JCL - 20110727_04
>> Second, strangely, I see the "who tests the tester tests" hit real failures, eg:
>>
>> [junit4:junit4] FAILURE 0.01s J2 |
>> TestReproduceMessage.testFailureBeforeClass <<<
>
> This looks like a different initialization order on J9; again -- can
> you file a Jira issue and provide J9 version/ environment? I'll dig.
> Thanks!
OK, will do. Thanks!
Mike McCandless
http://blog.mikemccandless.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: test failures when running under IBM J9
Posted by Dawid Weiss <da...@cs.put.poznan.pl>.
CC me directly if you can, Mike -- I have been terribly busy and
wouldn't want to miss questions that relate directly to what I can
answer. :)
> [junit4:junit4] > 1) Thread[id=102, name=Thread-44,
> state=TIMED_WAITING, group=TGRP-TestIndexWriterDelete]
> [junit4:junit4] > at java.lang.Object.wait(Native Method)
> [junit4:junit4] > at java.lang.Object.wait(Object.java:196)
> [junit4:junit4] > at java.util.Timer$TimerImpl.run(Timer.java:247)
The question is what starts these Timer threads? I mean: we can
exclude such threads but I'd do some digging first to see if it's not
an error. The thread's name looks suspiciously un-VM-like to me (it's
too generic).
> It looks like this is a JVM thread ... is there an "exceptions list"
> somewhere to ignore this thread? Or some other solution?
There are several ways to ignore threads. You can annotate a method
(or class) so that it ignores thread-checking entirely, you can add
the known offenders to ignored filters. Take a look at
SolrIgnoredThreadsFilter for real-life examples; Lucene uses
QuickPatchThreadsFilter (it's currently empty).
If you can name the J9 version and test/seed that causes this I'll
take a look at the root of the problem first.
> Second, strangely, I see the "who tests the tester tests" hit real failures, eg:
>
> [junit4:junit4] FAILURE 0.01s J2 |
> TestReproduceMessage.testFailureBeforeClass <<<
This looks like a different initialization order on J9; again -- can
you file a Jira issue and provide J9 version/ environment? I'll dig.
Thanks!
Dawid
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: test failures when running under IBM J9
Posted by Michael McCandless <lu...@mikemccandless.com>.
OK I opened LUCENE-4736 and LUCENE-4737. Thanks Dawid!
Mike McCandless
http://blog.mikemccandless.com
On Tue, Jan 29, 2013 at 6:03 PM, Michael McCandless
<lu...@mikemccandless.com> wrote:
> When I run Lucene core tests with IBM J9 1.6, some tests fail with
> zombie threads that could not be killed, eg:
>
> [junit4:junit4] ERROR 0.00s J2 | TestIndexWriterDelete (suite) <<<
> [junit4:junit4] > Throwable #1:
> com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked
> from SUITE scope at org.apache.lucene.index.TestIndexWriterDelete:
> [junit4:junit4] > 1) Thread[id=102, name=Thread-44,
> state=TIMED_WAITING, group=TGRP-TestIndexWriterDelete]
> [junit4:junit4] > at java.lang.Object.wait(Native Method)
> [junit4:junit4] > at java.lang.Object.wait(Object.java:196)
> [junit4:junit4] > at java.util.Timer$TimerImpl.run(Timer.java:247)
> [junit4:junit4] > at __randomizedtesting.SeedInfo.seed([C9014BCB129899BF]:0)
> [junit4:junit4] > Throwable #2:
> com.carrotsearch.randomizedtesting.ThreadLeakError: There are still
> zombie threads that couldn't be terminated:
> [junit4:junit4] > 1) Thread[id=102, name=Thread-44,
> state=TIMED_WAITING, group=TGRP-TestIndexWriterDelete]
> [junit4:junit4] > at java.lang.Object.wait(Native Method)
> [junit4:junit4] > at java.lang.Object.wait(Object.java:196)
> [junit4:junit4] > at java.util.Timer$TimerImpl.run(Timer.java:247)
> [junit4:junit4] > at __randomizedtesting.SeedInfo.seed([C9014BCB129899BF]:0)
>
> It looks like this is a JVM thread ... is there an "exceptions list"
> somewhere to ignore this thread? Or some other solution?
>
> Second, strangely, I see the "who tests the tester tests" hit real failures, eg:
>
> [junit4:junit4] FAILURE 0.01s J2 |
> TestReproduceMessage.testFailureBeforeClass <<<
> [junit4:junit4] > Throwable #1: java.lang.AssertionError
> [junit4:junit4] > at org.junit.Assert.fail(Assert.java:92)
> [junit4:junit4] > at org.junit.Assert.assertTrue(Assert.java:43)
> [junit4:junit4] > at org.junit.Assert.assertTrue(Assert.java:54)
> [junit4:junit4] > at
> org.apache.lucene.util.junitcompat.TestReproduceMessage.testFailureBeforeClass(TestReproduceMessage.java:173)
> [junit4:junit4] > at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit4:junit4] > at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
> [junit4:junit4] > at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> [junit4:junit4] > at java.lang.reflect.Method.invoke(Method.java:611)
> [junit4:junit4] > at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> [junit4:junit4] > at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> [junit4:junit4] > at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> [junit4:junit4] > at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> [junit4:junit4] > at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> [junit4:junit4] > at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
> [junit4:junit4] > at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
> [junit4:junit4] > at org.junit.rules.RunRules.evaluate(RunRules.java:18)
> [junit4:junit4] > at
> org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> [junit4:junit4] > at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> [junit4:junit4] > at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> [junit4:junit4] > at
> org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> [junit4:junit4] > at
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> [junit4:junit4] > at
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> [junit4:junit4] > at
> org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> [junit4:junit4] > at
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> [junit4:junit4] > at
> org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> [junit4:junit4] > at
> com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:180)
> [junit4:junit4] > at
> com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:275)
> [junit4:junit4] > at
> com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:12)
>
> These are tests that intentionally set up a failure, and then confirm
> that the test framework catches that failure ... yet for some reason
> with J9 this turns into a real failure ... any ideas?
>
> Mike McCandless
>
> http://blog.mikemccandless.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org