lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dawid Weiss (JIRA)" <>
Subject [jira] [Commented] (LUCENE-4252) Detect/Fail tests when they leak RAM in static fields
Date Wed, 25 Jul 2012 10:53:34 GMT


Dawid Weiss commented on LUCENE-4252:

Static initializers will be very difficult because they're executed before the actual test
begins (a side effect of JUnit architecture). You could roll out each test in a separate class
loader to overcome this but it'd create large overhead on memory (class GCs, reinitializations,

I like this nonetheless - it should catch a lot of common use case scenarios. Things like
initializing static variables in other classes (or thread locals) will remain a problem but
we can probably deal with these later on somehow.

The only thing is that I'd rather move it to a separate class (and add it to the class rule
chain). While it may seem like adding unnecessary complexity putting all the checks in a single
rule will eventually lead to a tangled blob that is hard to read and analyze.

I may do it when I come back, Robert -- assign to me or create a new issue.
> Detect/Fail tests when they leak RAM in static fields
> -----------------------------------------------------
>                 Key: LUCENE-4252
>                 URL:
>             Project: Lucene - Core
>          Issue Type: Test
>          Components: general/test
>            Reporter: Robert Muir
>         Attachments: LUCENE-4252.patch
> We run our junit tests without firing up a JVM each time.
> But some tests initialize lots of stuff in @BeforeClass and don't properly null it out
in an @AfterClass, which can cause a subsequent test in the same JVM to OOM, which is difficult
to debug.
> Inspiration for this was me committing Mike's cool TestPostingsFormat, which forgot to
do this: then we were seeing OOMs in several jenkins runs.
> We should try to detect these leaks in LuceneTestCase with RAMUsageEstimator and fail
the test.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message