[ https://issues.apache.org/jira/browse/LUCENE-6546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14580908#comment-14580908 ]
Dawid Weiss commented on LUCENE-6546: ------------------------------------- bq. Although the repro line doesn't include all of them - Dawid Weiss is this expected? The "repro line" is not part of the randomizedtesting package. In fact, RR doesn't print anything at all -- it's the report listeners that should do it. In Lucene the "repro line" is put together by a class listener attached on LuceneTestCase: {code} @Listeners({ RunListenerPrintReproduceInfo.class, FailureMarker.class }) {code} If you look for {{RunListenerPrintReproduceInfo}} it just emits (our) properties that (we think) lead to fully reproducible test case. It would be nice to have a "real" repro -- full forked JVM command line, including the JVM and any switches attached to it, but it's not there (yet). > Test2BPostingsBytes sometimes OOMs even with -Dtests.heapsize=30g > ----------------------------------------------------------------- > > Key: LUCENE-6546 > URL: https://issues.apache.org/jira/browse/LUCENE-6546 > Project: Lucene - Core > Issue Type: Bug > Components: general/test > Reporter: Steve Rowe > Priority: Minor > > Here's an example: > [http://jenkins.sarowe.net/job/Lucene-core-nightly-monster-5.x-Java7/22/console]; > the seed still OOMs for me when {{-Dtests.heapsize=60g}}: > {noformat} > ant test -Dtestcase=Test2BPostingsBytes -Dtests.method=test > -Dtests.seed=F99606D852DB1420 -Dtests.nightly=true -Dtests.slow=true > -Dtests.locale=sr_RS_#Latn -Dtests.timezone=America/Port-au-Prince > -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 > {noformat} > (Although the repro line doesn't include all of them - [~dawid.weiss] is this > expected? - the above-linked job runs with {{-Dtests.jvms=4 > -Dtests.nightly=true -Dtests.monster=true -Dtests.heapsize=30g}}.) > I narrowed the problem down to {{CompressingCodec}} - any of the 4 subclasses > - with {{maxDocsPerChunk * blockSize}} less than 16. The other variable > randomized in {{CompressingCodec.randomInstance()}} is {{chunkSize}}, which > doesn't seem to be implicated in the OOMs. > I guess we could suppress {{CompressingCodec}}, or just expect OOMs from time > to time (the above condition happens fairly rarely). But I'd rather continue > to exercise {{CompressingCodec}} as much as possible. > Here are the OOMs I saw with {{-Dtests.heapsize=30g}} and > {{-Dtests.codec=CompressingCodec}}: > ||compressionMode||chunkSize||maxDocsPerChunk||blockSize|| > |DUMMY|3|2|1| > |DUMMY|7|1|1| > |FAST_DECOMPRESSION|10|9|1| > |FAST_DECOMPRESSION|31614|3|4| > |FAST|21879|1|9| > |DUMMY|3|3|1| > |HIGH_COMPRESSION|4167|10|1| > |HIGH_COMPRESSION|12437|2|5| > |DUMMY|4|3|2| > |HIGH_COMPRESSION|3|3|2| > |FAST_DECOMPRESSION|3339|10|1| > |DUMMY|2|5|3| > Here are some that did *not* OOM: > ||compressionMode||chunkSize||maxDocsPerChunk||blockSize|| > |DUMMY|4|4|4| > |DUMMY|4|2|246| > |FAST|30677|907|2| > |FAST_DECOMPRESSION|15165|2|10| > |FAST_DECOMPRESSION|28633|67|1| > |DUMMY|7|3|9| > |DUMMY|2835|9|3| > |DUMMY|25785|4|7| -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org