You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Apache Jenkins Server <je...@builds.apache.org> on 2012/04/19 08:42:33 UTC
[JENKINS] Lucene-trunk - Build # 1899 - Failure
Build: https://builds.apache.org/job/Lucene-trunk/1899/
All tests passed
Build Log (for compile errors):
[...truncated 26892 lines...]
Re: [JENKINS] Lucene-trunk - Build # 1899 - Failure
Posted by Dawid Weiss <da...@cs.put.poznan.pl>.
This is probably a better idea as it allows fine-grained control (i.e.
excluding just tight loops)?
Dawid
On Thu, Apr 19, 2012 at 10:15 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
> To disable clover for heavy tests, we can use (its just a code comment to be included, that tells the instrumenter to disable coverage for this code part between the comments):
>
> http://goo.gl/ZohAv
>
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
>> -----Original Message-----
>> From: Uwe Schindler [mailto:uwe@thetaphi.de]
>> Sent: Thursday, April 19, 2012 9:47 AM
>> To: dev@lucene.apache.org
>> Subject: RE: [JENKINS] Lucene-trunk - Build # 1899 - Failure
>>
>> Hi,
>>
>> Maybe TestNRQ does not like SimpleText (it seeks heavily), so maybe thats the
>> reason (we should check that with the seed) and add assume. Do other MTQ
>> tests allow SimpleText (like Fuzzy, which is also heavy)? With Clover the NRQ
>> tests then gets *very* slow. Compare with TestNRQ32, which succeeded in a
>> few seconds on the same run, just because of different random settings.
>>
>> Because of the instrumentation level per statement, all tight loops take forever
>> with clover. But changing to "method" level removes all the interesting
>> information for us. We could also add a @NoClover annotation. We would need
>> no sysprops for that, it would be enough to do a Class.forName on any of the
>> clover classes to find out if clover is "active" for the current test run.
>>
>> Maybe we should raise the JVM setting for the code cache when running with
>> clover, because clover-instrumented class files are a lot more "complex" for
>> hotspot.
>>
>> -----
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, D-28213 Bremen
>> http://www.thetaphi.de
>> eMail: uwe@thetaphi.de
>>
>>
>> > -----Original Message-----
>> > From: dawid.weiss@gmail.com [mailto:dawid.weiss@gmail.com] On Behalf
>> > Of Dawid Weiss
>> > Sent: Thursday, April 19, 2012 9:38 AM
>> > To: dev@lucene.apache.org
>> > Subject: Re: [JENKINS] Lucene-trunk - Build # 1899 - Failure
>> >
>> > I'll try to inspect later today why these are so slow in that run:
>> >
>> > [junit4] <JUnit4> says g'day! Master seed: C26BAC36B9BF265D
>> >
>> > [junit4] Suite: org.apache.lucene.index.TestByteSlices
>> > [junit4] Completed in 1852.84s, 1 test
>> >
>> > [junit4] Suite: org.apache.lucene.search.TestNumericRangeQuery64
>> > [junit4] Completed in 4251.28s, 34 tests
>> >
>> > Dawid
>> >
>> > On Thu, Apr 19, 2012 at 9:28 AM, Dawid Weiss
>> > <da...@cs.put.poznan.pl> wrote:
>> > >> I have seen this on jenkins several times (especially with Clover
>> > instrumentation). In this case instrumentation was running.
>> > >
>> > > Clover is a hog, we've experienced that too.
>> > >
>> > >> I think its caused by too many instrumentation (per statement) in
>> > >> heavy tests
>> > like TestNRQ or similar. Unfortunately we don’t see here, which test
>> > exactly was leading to this output.
>> > >
>> > > I don't think you'd be able to see that precisely anyway because
>> > > these are printed to two different stream buffers -- it bypasses
>> > > Java's PrintStreams and dumps directly to the original file descriptor.
>> > >
>> > > Dawid
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
>> > additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
>> commands, e-mail: dev-help@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: [JENKINS] Lucene-trunk - Build # 1899 - Failure
Posted by Uwe Schindler <uw...@thetaphi.de>.
To disable clover for heavy tests, we can use (its just a code comment to be included, that tells the instrumenter to disable coverage for this code part between the comments):
http://goo.gl/ZohAv
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Uwe Schindler [mailto:uwe@thetaphi.de]
> Sent: Thursday, April 19, 2012 9:47 AM
> To: dev@lucene.apache.org
> Subject: RE: [JENKINS] Lucene-trunk - Build # 1899 - Failure
>
> Hi,
>
> Maybe TestNRQ does not like SimpleText (it seeks heavily), so maybe thats the
> reason (we should check that with the seed) and add assume. Do other MTQ
> tests allow SimpleText (like Fuzzy, which is also heavy)? With Clover the NRQ
> tests then gets *very* slow. Compare with TestNRQ32, which succeeded in a
> few seconds on the same run, just because of different random settings.
>
> Because of the instrumentation level per statement, all tight loops take forever
> with clover. But changing to "method" level removes all the interesting
> information for us. We could also add a @NoClover annotation. We would need
> no sysprops for that, it would be enough to do a Class.forName on any of the
> clover classes to find out if clover is "active" for the current test run.
>
> Maybe we should raise the JVM setting for the code cache when running with
> clover, because clover-instrumented class files are a lot more "complex" for
> hotspot.
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
> > -----Original Message-----
> > From: dawid.weiss@gmail.com [mailto:dawid.weiss@gmail.com] On Behalf
> > Of Dawid Weiss
> > Sent: Thursday, April 19, 2012 9:38 AM
> > To: dev@lucene.apache.org
> > Subject: Re: [JENKINS] Lucene-trunk - Build # 1899 - Failure
> >
> > I'll try to inspect later today why these are so slow in that run:
> >
> > [junit4] <JUnit4> says g'day! Master seed: C26BAC36B9BF265D
> >
> > [junit4] Suite: org.apache.lucene.index.TestByteSlices
> > [junit4] Completed in 1852.84s, 1 test
> >
> > [junit4] Suite: org.apache.lucene.search.TestNumericRangeQuery64
> > [junit4] Completed in 4251.28s, 34 tests
> >
> > Dawid
> >
> > On Thu, Apr 19, 2012 at 9:28 AM, Dawid Weiss
> > <da...@cs.put.poznan.pl> wrote:
> > >> I have seen this on jenkins several times (especially with Clover
> > instrumentation). In this case instrumentation was running.
> > >
> > > Clover is a hog, we've experienced that too.
> > >
> > >> I think its caused by too many instrumentation (per statement) in
> > >> heavy tests
> > like TestNRQ or similar. Unfortunately we don’t see here, which test
> > exactly was leading to this output.
> > >
> > > I don't think you'd be able to see that precisely anyway because
> > > these are printed to two different stream buffers -- it bypasses
> > > Java's PrintStreams and dumps directly to the original file descriptor.
> > >
> > > Dawid
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
> > additional commands, e-mail: dev-help@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: [JENKINS] Lucene-trunk - Build # 1899 - Failure
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi,
Maybe TestNRQ does not like SimpleText (it seeks heavily), so maybe thats the reason (we should check that with the seed) and add assume. Do other MTQ tests allow SimpleText (like Fuzzy, which is also heavy)? With Clover the NRQ tests then gets *very* slow. Compare with TestNRQ32, which succeeded in a few seconds on the same run, just because of different random settings.
Because of the instrumentation level per statement, all tight loops take forever with clover. But changing to "method" level removes all the interesting information for us. We could also add a @NoClover annotation. We would need no sysprops for that, it would be enough to do a Class.forName on any of the clover classes to find out if clover is "active" for the current test run.
Maybe we should raise the JVM setting for the code cache when running with clover, because clover-instrumented class files are a lot more "complex" for hotspot.
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: dawid.weiss@gmail.com [mailto:dawid.weiss@gmail.com] On Behalf Of
> Dawid Weiss
> Sent: Thursday, April 19, 2012 9:38 AM
> To: dev@lucene.apache.org
> Subject: Re: [JENKINS] Lucene-trunk - Build # 1899 - Failure
>
> I'll try to inspect later today why these are so slow in that run:
>
> [junit4] <JUnit4> says g'day! Master seed: C26BAC36B9BF265D
>
> [junit4] Suite: org.apache.lucene.index.TestByteSlices
> [junit4] Completed in 1852.84s, 1 test
>
> [junit4] Suite: org.apache.lucene.search.TestNumericRangeQuery64
> [junit4] Completed in 4251.28s, 34 tests
>
> Dawid
>
> On Thu, Apr 19, 2012 at 9:28 AM, Dawid Weiss
> <da...@cs.put.poznan.pl> wrote:
> >> I have seen this on jenkins several times (especially with Clover
> instrumentation). In this case instrumentation was running.
> >
> > Clover is a hog, we've experienced that too.
> >
> >> I think its caused by too many instrumentation (per statement) in heavy tests
> like TestNRQ or similar. Unfortunately we don’t see here, which test exactly
> was leading to this output.
> >
> > I don't think you'd be able to see that precisely anyway because these
> > are printed to two different stream buffers -- it bypasses Java's
> > PrintStreams and dumps directly to the original file descriptor.
> >
> > Dawid
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [JENKINS] Lucene-trunk - Build # 1899 - Failure
Posted by Dawid Weiss <da...@cs.put.poznan.pl>.
I'll try to inspect later today why these are so slow in that run:
[junit4] <JUnit4> says g'day! Master seed: C26BAC36B9BF265D
[junit4] Suite: org.apache.lucene.index.TestByteSlices
[junit4] Completed in 1852.84s, 1 test
[junit4] Suite: org.apache.lucene.search.TestNumericRangeQuery64
[junit4] Completed in 4251.28s, 34 tests
Dawid
On Thu, Apr 19, 2012 at 9:28 AM, Dawid Weiss
<da...@cs.put.poznan.pl> wrote:
>> I have seen this on jenkins several times (especially with Clover instrumentation). In this case instrumentation was running.
>
> Clover is a hog, we've experienced that too.
>
>> I think its caused by too many instrumentation (per statement) in heavy tests like TestNRQ or similar. Unfortunately we don’t see here, which test exactly was leading to this output.
>
> I don't think you'd be able to see that precisely anyway because these
> are printed to two different stream buffers -- it bypasses Java's
> PrintStreams and dumps directly to the original file descriptor.
>
> Dawid
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [JENKINS] Lucene-trunk - Build # 1899 - Failure
Posted by Dawid Weiss <da...@cs.put.poznan.pl>.
> I have seen this on jenkins several times (especially with Clover instrumentation). In this case instrumentation was running.
Clover is a hog, we've experienced that too.
> I think its caused by too many instrumentation (per statement) in heavy tests like TestNRQ or similar. Unfortunately we don’t see here, which test exactly was leading to this output.
I don't think you'd be able to see that precisely anyway because these
are printed to two different stream buffers -- it bypasses Java's
PrintStreams and dumps directly to the original file descriptor.
Dawid
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: [JENKINS] Lucene-trunk - Build # 1899 - Failure
Posted by Uwe Schindler <uw...@thetaphi.de>.
I have seen this on jenkins several times (especially with Clover instrumentation). In this case instrumentation was running.
I think its caused by too many instrumentation (per statement) in heavy tests like TestNRQ or similar. Unfortunately we don’t see here, which test exactly was leading to this output.
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: dawid.weiss@gmail.com [mailto:dawid.weiss@gmail.com] On Behalf Of
> Dawid Weiss
> Sent: Thursday, April 19, 2012 9:05 AM
> To: dev@lucene.apache.org
> Subject: Re: [JENKINS] Lucene-trunk - Build # 1899 - Failure
>
> Whoa... never seen this one before --
>
> [junit4] >>> error stream from forked JVM (verbatim) ----
> [junit4] OpenJDK 64-Bit Server VM warning: CodeCache is full.
> Compiler has been disabled.
> [junit4] OpenJDK 64-Bit Server VM warning: Try increasing the code cache
> size using -XX:ReservedCodeCacheSize=
> [junit4] <<< EOF ----
>
> FYI, this doesn't get printed through regular Java's System.* streams
> -- it is printed from the JVM internals directly (via original, un-redirected
> stream descriptors). <junit4> currently considers ANYTHING that is printed to
> these streams as a potential JVM failure
> -- I wonder if I should alter this behavior.
>
> On the second thought... this does seem abnormal to me. Thoughts?
>
> Dawid
>
> On Thu, Apr 19, 2012 at 8:42 AM, Apache Jenkins Server
> <je...@builds.apache.org> wrote:
> > Build: https://builds.apache.org/job/Lucene-trunk/1899/
> >
> > All tests passed
> >
> > Build Log (for compile errors):
> > [...truncated 26892 lines...]
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
> > additional commands, e-mail: dev-help@lucene.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [JENKINS] Lucene-trunk - Build # 1899 - Failure
Posted by Dawid Weiss <da...@cs.put.poznan.pl>.
Whoa... never seen this one before --
[junit4] >>> error stream from forked JVM (verbatim) ----
[junit4] OpenJDK 64-Bit Server VM warning: CodeCache is full.
Compiler has been disabled.
[junit4] OpenJDK 64-Bit Server VM warning: Try increasing the code
cache size using -XX:ReservedCodeCacheSize=
[junit4] <<< EOF ----
FYI, this doesn't get printed through regular Java's System.* streams
-- it is printed from the JVM internals directly (via original,
un-redirected stream descriptors). <junit4> currently considers
ANYTHING that is printed to these streams as a potential JVM failure
-- I wonder if I should alter this behavior.
On the second thought... this does seem abnormal to me. Thoughts?
Dawid
On Thu, Apr 19, 2012 at 8:42 AM, Apache Jenkins Server
<je...@builds.apache.org> wrote:
> Build: https://builds.apache.org/job/Lucene-trunk/1899/
>
> All tests passed
>
> Build Log (for compile errors):
> [...truncated 26892 lines...]
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org