This reproduces. Hits wrong exception type?
ant test -Dtestcase=TestFuzzyQuery -Dtests.method=testErrorMessage
-Dtests.seed=CE3DF037C6D29401 -Dtests.slow=true -Dtests.locale=fr-GN
-Dtests.timezone=US/Pacific-New -Dtests.asserts=true
-Dtests.file.encoding=ISO-8859-1
On Fri, Jan 3, 2020 at 1:54
https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-Check-master/179/console
The build passed, actually but something failed later (in jenkins?):
BUILD SUCCESSFUL in 1h 7m 58s
790 actionable tasks: 790 executed
Build step 'Invoke Gradle script' changed build result to SUCCESS
Archiving
This looks like a real concurrency bug somewhere in the test.
On Mon, Sep 28, 2020 at 8:39 AM Apache Jenkins Server
wrote:
>
> Build: https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-Tests-8.x/437/
>
> 1 tests failed.
> FAILED:
These seem to be JVM errors (in test runners).
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGILL (0x4) at pc=0x7f10f70cee26, pid=450437, tid=557573
#
# JRE version: OpenJDK Runtime Environment (12.0.2+10) (build 12.0.2+10)
# Java VM: OpenJDK 64-Bit Server VM
t;instructions" list in hs_err.log
> and figure out what happened (e.g. unavailable avx instruction used or
> whatever went wrong)?
>
> I attached the log, so it isn't lost from jenkins builds.
>
> On Wed, Dec 9, 2020 at 3:52 AM Dawid Weiss wrote:
> >
> > These seem to b
t;often
> used" (LTS).
>
> What do you think?
>
> Uwe
>
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
>
> > -Original Message-
> > From: Dawid Weiss
> > Sent: Friday, Decembe
This is a stack overflow in Solr somewhere; the test framework fails
because it can't really copy with emitting proper messages
on that thread --
[junit4] at
org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:141)
[junit4] at
I've no idea what happened here - EOF everywhere, insane.
Dawid
On Thu, Jun 10, 2021 at 7:57 PM Apache Jenkins Server
wrote:
>
> Build: https://ci-builds.apache.org/job/Lucene/job/Lucene-Coverage-main/69/
>
> 1724 tests failed.
> FAILED:
>
This fails with an interesting internal error. I've no idea what's
happening here.
Internal exceptions (20 events):
Event: 2.364 Thread 0x7fa3d00d5560 Exception (0x139587f0)
Event: 2.379 Thread 0x7fa3d00d5560 Exception
(0x139c5f50) thrown at [/home
Event: 2.380 Thread
This failure does reproduce for me:
> java.lang.AssertionError
> at
__randomizedtesting.SeedInfo.seed([CE7143DCF05C0688:92FF8F07EA35B326]:0)
> at
org.apache.lucene.search.WANDScorer.ensureConsistent(WANDScorer.java:223)
> at
Can't reproduce this.
On Mon, Mar 29, 2021 at 5:54 AM Policeman Jenkins Server <
jenk...@thetaphi.de> wrote:
> Build: https://jenkins.thetaphi.de/job/Lucene-main-Windows/9779/
> Java: 64bit/jdk-13.0.2 -XX:-UseCompressedOops -XX:+UseG1GC
>
> 1 tests failed.
> FAILED:
Can't reproduce this one.
On Thu, Mar 25, 2021 at 11:21 AM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:
> Build: https://ci-builds.apache.org/job/Lucene/job/Lucene-Check-main/1899/
>
> 1 tests failed.
> FAILED:
>
I corrected this - header structure is more strict on newer JDKs
/home/jenkins/workspace/Lucene-main-Linux/lucene/core/src/java/org/apache/lucene/codecs/lucene90/Lucene90VectorFormat.java:32:
error: unexpected heading used: , compared to implicit preceding
heading:
* .vec (vector data) file
This failure does reproduce for me:
gradlew :lucene:test-framework:test --tests
"org.apache.lucene.codecs.lucene90.compressing.TestCompressingTermVectorsFormat.testMergeStability"
-Ptests.jvms=4 -Ptests.haltonfailure=false
-Ptests.jvmargs=-XX:TieredStopAtLevel=1 -Ptests.seed=8CE9FAE1EBCEF1B2
Hmm... this seems odd?
java.lang.UnsupportedOperationException
at
__randomizedtesting.SeedInfo.seed([A33C595E92C558DB:F19E020C3C971DA7]:0)
at
org.apache.lucene.codecs.simpletext.SimpleTextKnnVectorsReader.search(SimpleTextKnnVectorsReader.java:143)
On Fri, Aug 27, 2021 at
I corrected Jenkins job definition to run "assembleRelease" and to
collect artifacts from the right location
(lucene/distribution/build/release/**).
On Fri, Oct 15, 2021 at 12:36 AM Apache Jenkins Server
wrote:
>
> Build: https://ci-builds.apache.org/job/Lucene/job/Lucene-Artifacts-main/391/
>
>
I've cleaned up this test from the source of all leaking threads but this
failure does reproduce - I filed LUCENE-10134.
org.apache.lucene.facet.sortedset.TestSortedSetDocValuesFacets >
testCountAll FAILED
java.lang.AssertionError: Bits are only supposed to be consumed in the
thread in which
This is a test error - allowed an empty array as input and then tried to
pick a random position from it. Corrected the test.
D.
On Wed, Sep 29, 2021 at 6:10 PM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:
> Build:
>
This looks like the binary of java is broken somehow.
On Fri, Dec 17, 2021 at 1:00 PM Apache Jenkins Server
wrote:
>
> Build: https://ci-builds.apache.org/job/Lucene/job/Lucene-NightlyTests-9.0/45/
>
> No tests ran.
>
> Build Log:
> [...truncated 86 lines...]
> ERROR: Step ‘Publish JUnit test
This is a JVM failure:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x7fc59e51c84b, pid=1722975, tid=1723672
#
# JRE version: OpenJDK Runtime Environment (18.0+26) (build 18-ea+26-1787)
# Java VM: OpenJDK 64-Bit Server VM (18-ea+26-1787, mixed
This does reproduce fairly consistently, although is not deterministic at
all. If I force re-runs with beasting, at least one of the runs almost
always ends up with this exception though (I didn't look inside):
gradlew -p lucene/core beast -Ptests.dups=10 --tests
Hi Uwe,
The panama branch no longer reads unsafe so the new test on main fails
after the merge:
org.apache.lucene.core.tests.TestMMap.testUnmapSupported
I've allowed myself to correct it on your branch to shut up jenkins, but
please revert or tune to your liking.
D.
On Wed, Dec 22, 2021 at
Eh. It seems this bug in ECJ is not predictable - it fails on the CI, it
doesn't fail for me locally.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=569833
>* Task :lucene:core:ecjLintMain* FAILED
--
1. ERROR in
vac. It fails with an error in every source
> file.
>
> Uwe
>
> Am 18. Dezember 2021 20:13:09 UTC schrieb Dawid Weiss <
> dawid.we...@gmail.com>:
>>
>>
>> Eh. It seems this bug in ECJ is not predictable - it fails on the CI, it
>> doesn't fa
2021 at 11:02 PM Dawid Weiss wrote:
>
> I see it on Jenkins but can't reproduce this on any system I have access
> to (Linux, Windows). We don't do anything special for javac - the arguments
> there are collected from within gradle... So weird.
>
> D.
>
> On Sat, Dec 18, 20
It's this issue, Mike:
https://issues.apache.org/jira/browse/LUCENE-10088
On Sat, Nov 27, 2021 at 8:11 PM Michael Sokolov wrote:
> I tried reducing 500 full flushes to 250 and 5000 iters to 2500, and
> then the test would fairly reliably finish in 1 minute or so, although
> I did once see
>
>
Temporary glitch, it seems (http 503 on downloading gradle wrapper).
On Mon, Nov 22, 2021 at 7:21 AM Policeman Jenkins Server
wrote:
>
> Build: https://jenkins.thetaphi.de/job/Lucene-main-Linux/31759/
> Java: 64bit/jdk-18-ea+24 -XX:+UseCompressedOops -XX:+UseParallelGC
>
> No tests ran.
>
>
Can we just stop this build entirely?... I don't think anybody is looking
at it. The build took:
5 hr 13 min build duration
and the console output is 150MB...
Dawid
On Mon, Oct 25, 2021 at 6:47 PM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:
> Build: ${BUILD_URL}
>
>
This passed - the error is when publishing artifacts?
ERROR: Step ‘Publish Javadoc’ failed: no workspace for
Lucene/Lucene-Artifacts-9.x #7
ERROR: lucene-solr-2 is offline; cannot locate jdk_11_latest
On Tue, Nov 9, 2021 at 2:01 AM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:
>
This does reproduce occasionally on branch_9x (it seems non-deterministic).
Is it LUCENE-10208, Jim?
Dawid
Dawid
On Tue, Nov 9, 2021 at 6:55 AM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:
> Build:
> https://ci-builds.apache.org/job/Lucene/job/Lucene-NightlyTests-9.x/7/
>
> 4
It's this one, Adrien -
https://issues.apache.org/jira/browse/LUCENE-10190
On Wed, Nov 3, 2021 at 4:01 PM Adrien Grand wrote:
> I ran 100 iterations with ant beast but could not reproduce this failure.
>
> I won't treat this test failure as a blocker for the release, but I
> suspect there's
This thing does reproduce (with the seed and multiplier/ nightly). When it
hits the breakpoint, the temporary folder has over 6k files in it (not all
of them are open file handles, I guess, but still!). I corrected an
unclosed reader in the test but it still seems like too many open files
Ok, I see the discussion here.
https://issues.apache.org/jira/browse/LUCENE-10088
On Wed, Nov 3, 2021 at 10:22 AM Dawid Weiss wrote:
>
> This thing does reproduce (with the seed and multiplier/ nightly). When it
> hits the breakpoint, the temporary folder has over 6k files in it
Some temporary glitch, it seems:
Could not GET
'https://repository.apache.org/content/repositories/snapshots/org/apache/lucene/lucene-analysis-smartcn/maven-metadata.xml'.
> Read timed out
On Sun, Oct 31, 2021 at 4:34 AM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:
> Build:
I looked at it yesterday too - looks like some sort of timeout-induced
failure which sent everything crashing down.
On Wed, Dec 8, 2021 at 4:34 AM Robert Muir wrote:
> To me, it seems like jenkins fails because it can't find an archiving
> file. Perhaps something is up, or maybe it just needs
I've no idea what happened here - script error (perhaps because of jdk18).
D.
On Thu, Jan 13, 2022 at 2:32 AM Policeman Jenkins Server <
jenk...@thetaphi.de> wrote:
> Build: https://jenkins.thetaphi.de/job/Lucene-main-Linux/32237/
> Java: 64bit/jdk-18-ea+29 -XX:+UseCompressedOops
I'm not sure what's happening here - the gradle part finishes but the build
is stalled after that and ultimately expires. Weird.
BUILD SUCCESSFUL in 19m 4s
798 actionable tasks: 798 executed
Build timed out (after 209 minutes). Marking the build as aborted.
Build timed out (after 209 minutes).
gt; which fits very well). When I killed the builds manually, no mail was sent
> so you havent seen this. Happens approximately once per week.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> https://www.thetaphi.de
>
This failure has been fixed (by me) on main and branch_9x but didn't make
it to the release. I can't tell whether this is potentially a problem in
real life but perhaps it's not worth taking a chance?
Dawid
On Tue, Mar 15, 2022 at 1:49 AM Policeman Jenkins Server <
jenk...@thetaphi.de> wrote:
>
ll it off and spin RC2. I will backport your change to branch_9_1.
>
> Julie
>
> On Mon, Mar 14, 2022 at 11:39 PM Dawid Weiss
> wrote:
>
>>
>> This failure has been fixed (by me) on main and branch_9x but didn't make
>> it to the release. I can't tell whether
I changed the condition in the if clause that resulted in an
arithmetic exception here.
D.
On Wed, Mar 9, 2022 at 10:44 AM Apache Jenkins Server
wrote:
>
> Build:
> https://ci-builds.apache.org/job/Lucene/job/Lucene-NightlyTests-main/571/
>
> 2 tests failed.
> FAILED:
JVM crash:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x7fb3d375fcbb, pid=1653920, tid=1654408
#
# JRE version: OpenJDK Runtime Environment (19.0+14) (build 19-ea+14-870)
# Java VM: OpenJDK 64-Bit Server VM (19-ea+14-870, mixed mode,
sharing,
hetaphi.de
> eMail: u...@thetaphi.de
>
> > -Original Message-
> > From: Dawid Weiss
> > Sent: Tuesday, February 1, 2022 10:42 AM
> > To: Lucene Dev ; Uwe Schindler (SD DataSolutions
> > GmbH)
> > Cc: builds@lucene.apache.org
> > Subjec
That's the same validation error as before, Uwe. Strange it only
happens on this server.
D.
On Fri, Feb 4, 2022 at 9:09 AM Policeman Jenkins Server
wrote:
>
> Build: https://jenkins.thetaphi.de/job/Lucene-9.x-Linux/1110/
> Java: 64bit/jdk-17.0.1 -XX:-UseCompressedOops -XX:+UseShenandoahGC
>
>
* What went wrong:
Execution failed for task ':lucene:analysis:icu:validateSourcePatterns'.
> start 1, end 0, length 0
This fails in validate source patterns groovy code, somewhere in this closure:
def isLicense = { matcher, ratDocument ->
licenseMatcher.reset()
return
JVM error (JDK18-ea).
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x7fd436d644fb, pid=1632777, tid=1633280
#
# JRE version: OpenJDK Runtime Environment (18.0+29) (build 18-ea+29-2007)
# Java VM: OpenJDK 64-Bit Server VM (18-ea+29-2007, mixed
I've bumped the timeout here; perhaps the vm is too slow.
D.
On Thu, Jan 20, 2022 at 12:51 PM Policeman Jenkins Server
wrote:
>
> Build: https://jenkins.thetaphi.de/job/Lucene-main-Windows/10405/
> Java: 64bit/jdk-18-ea+29 -XX:-UseCompressedOops -XX:+UseParallelGC
>
> 1 tests failed.
> FAILED:
https://ge.apache.org/s/orksynljk2yp6/tests/task/:lucene:core:test/details/org.apache.lucene.store.TestStressLockFactories/testSimpleFSLockFactory?top-execution=1
This test took 31 seconds... An extremely slow vm, perhaps? I don't know
what the default connection timeouts are... it does look
I'm not even sure how it's possible but this build seems to be using stale
configuration (repo pointing at the commit that informs about project split
between Solr and Lucene). I've disabled the plan.
Dawid
On Fri, Nov 3, 2023 at 10:17 PM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:
I agree - all of it looks very strange indeed. Seems like some of these
jobs were brought back from inactive state.
Dawid
On Fri, Nov 3, 2023 at 10:37 PM Chris Hostetter
wrote:
>
> : I'm not even sure how it's possible but this build seems to be using
> stale
> : configuration (repo pointing
This failed because the thread limit has been exhausted.
[3241.014s][warning][os,thread] Failed to start thread "Unknown
thread" - pthread_create failed (EAGAIN) for attributes: stacksize:
1024k, guardsize: 0k, detached.
[3241.015s][warning][os,thread] Failed to start the native thread for
Filed a security policy correction to allow jacoco to use a custom class
loader, here:
https://github.com/apache/lucene/pull/12684
On Sun, Oct 15, 2023 at 5:05 PM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:
> Build:
>
PM Dawid Weiss wrote:
>
> This actually reproduces (if you download enwiki). I wonder if we
> should tune LineFileDocs so that it avoids trying to add humongous
> terms.
>
> D.
>
> On Wed, Apr 20, 2022 at 3:42 AM Apache Jenkins Server
> wrote:
> >
> > Build
This actually reproduces (if you download enwiki). I wonder if we
should tune LineFileDocs so that it avoids trying to add humongous
terms.
D.
On Wed, Apr 20, 2022 at 3:42 AM Apache Jenkins Server
wrote:
>
> Build: https://ci-builds.apache.org/job/Lucene/job/Lucene-NightlyTests-9.1/42/
>
> 1
> i don't think we should intentionally allow our tests to be flaky, i
> strongly disagree.
I agree with Robert. Tests should pass. Every time a build fails it
takes some time to investigate the root cause and it is disheartening
when you discover that it's a failure that's "allowed" to happen.
This is palantir's version control plugin clashing with spotless, I've
seen this before. Maybe an upgrade of the plugin will help here, don't
know.
https://issues.apache.org/jira/browse/LUCENE-10535
D.
On Tue, Apr 26, 2022 at 1:29 AM Policeman Jenkins Server
wrote:
>
> Build:
> Yeah I agree: unit tests should strive to only and precisely fail for true
> bugs, not false alarms like this. I'm sorry this failure wasted your time
> Dawid!
Time's not wasted if we decide how to proceed on this.
> So we should fix this failure somehow: Remove all too-big terms from all
JDK18, JVM failure.
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x7fe52697007b, pid=2573932, tid=2573944
#
# JRE version: OpenJDK Runtime Environment (18.0+36) (build 18+36-2087)
# Java VM: OpenJDK 64-Bit Server VM (18+36-2087, mixed mode,
This is errorprone-caused failure:
> Task :lucene:core:compileTestJava FAILED
/home/jenkins/jenkins-slave/workspace/Lucene/Lucene-NightlyTests-9.x/checkout/lucene/core/src/test/org/apache/lucene/util/TestSparseFixedBitSet.java:106:
warning: [LongFloatConversion] Conversion from long to float may
JVM failure (on JDK 17.0.2!).
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x7fe6a986f711, pid=1132974, tid=1137900
#
# JRE version: OpenJDK Runtime Environment Temurin-17.0.2+8 (17.0.2+8)
(build 17.0.2+8)
# Java VM: OpenJDK 64-Bit Server VM
>
>
> Not sure why it was configured like that. The sysproo makes no sense to me
> (why only on nightly tests?).
>
Because errorprone is slw.
I would say: Let's add a separate project property like "cibuild=true". I
> can put that into Gradle property file on all nenks, too. So errorprone
>
_9x), sorry for the noise!
>
> On Thu, May 12, 2022 at 11:03 PM Dawid Weiss
> wrote:
>
>> This is errorprone-caused failure:
>>
>> > Task :lucene:core:compileTestJava FAILED
>>
>> /home/jenkins/jenkins-slave/workspace/Lucene/Lucene-NightlyTests-9.x/chec
I've run tidy and committed the cleanup.
D.
On Tue, May 24, 2022 at 8:52 PM Policeman Jenkins Server <
jenk...@thetaphi.de> wrote:
> Build: https://jenkins.thetaphi.de/job/Lucene-9.2-Linux/589/
> Java: 64bit/jdk-17.0.2 -XX:+UseCompressedOops -XX:+UseParallelGC
>
> All tests passed
>
>
I'm not sure what's going on here - the build itself passed but then a
timeout occurred:
BUILD SUCCESSFUL in 18m 14s
799 actionable tasks: 799 executed
Build timed out (after 179 minutes). Marking the build as aborted.
Build timed out (after 179 minutes). Marking the build as failed.
Build was
This seems like a gradle cache problem somehow:
Could not load compiled classes for script
'/home/jenkins/jenkins-slave/workspace/Lucene/Lucene-Check-main/gradle/validation/validate-source-patterns.gradle'
from cache.
I'm not sure how to fix it on those agent machines - I see a jenkins
job with
That script should run gradlew tidy after modifying sources and prior to
committing - then it wouldn't require manual fixes (which I've done in the
past too).
Dawid
On Fri, Jul 29, 2022 at 3:48 PM Ignacio Vera wrote:
> I fixed this. The script that adds new versions to addVersions.java is
>
stabilize this
> test.
>
> On Thu, Apr 28, 2022 at 3:50 AM Dawid Weiss wrote:
> >
> > Failed with simple text codec - perhaps we should disallow it on this test?
> >
> > On Thu, Apr 28, 2022 at 7:58 AM Apache Jenkins Server
> > wrote:
> > >
> &
for the test? (separately that isn't good...)
> > So it could allow you to switch this test to use FSDirectory always,
> > potentially to avoid RAM problems, but I don't think it is the
> > solution to any OOM?
> >
> > On Thu, Apr 28, 2022 at 4:03 AM Dawi
28, 2022 at 4:06 AM Robert Muir wrote:
> > >
> > > That change looks like it only doubles the amount of open files from
> > > 2048 to 4096 for the test? (separately that isn't good...)
> > > So it could allow you to switch this test to use FSDirectory always,
&g
Failed with simple text codec - perhaps we should disallow it on this test?
On Thu, Apr 28, 2022 at 7:58 AM Apache Jenkins Server
wrote:
>
> Build: https://ci-builds.apache.org/job/Lucene/job/Lucene-Check-9.1/454/
>
> 1 tests failed.
> FAILED:
>
JVM crash.
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x7f9bdccff07b, pid=2967600, tid=2967613
#
# JRE version: OpenJDK Runtime Environment (18.0+36) (build 18+36-2087)
# Java VM: OpenJDK 64-Bit Server VM (18+36-2087, mixed mode, sharing,
I looked at the test that failed here -
TestFreeTextSuggester.testLookupsDuringReBuild and for the life of it
I can't see how it's even supposed to work. What it seems to be
testing is a concurrent rebuild of the suggester while suggestions are
still being served. But the code inside
I've cleaned gradle caches on the build server, hope it'll help.
Dawid
On Sun, Aug 21, 2022 at 4:25 AM Apache Jenkins Server
wrote:
>
> Build:
> https://ci-builds.apache.org/job/Lucene/job/Lucene-NightlyTests-main/736/
>
> No tests ran.
>
> Build Log:
> [...truncated 59 lines...]
> BUILD
There should be an additional step in the rel. instructions to run
'tidy'a after modifying the version in Version.java. Otherwise things break
on code formatting (spotless). I've fixed this manually on 9x.
Dawid
On Sat, Sep 3, 2022 at 4:19 PM Apache Jenkins Server <
jenk...@builds.apache.org>
I think Lucene tests killed the job runner. :)
> Task :lucene:analysis:nori:spotlessJavaCheck
> Task :lucene:analysis:nori:spotlessCheck
FATAL: command execution failed
java.io.IOException: Backing channel 'lucene-solr-1' is disconnected.
[...]
ERROR: lucene-solr-1 is offline; cannot locate
A test timed out. I've beasted with the same settings but can't
reproduce. Either JVM bug somewhere or cosmic interference...
Dawid
On Wed, Aug 24, 2022 at 3:32 AM Policeman Jenkins Server
wrote:
>
> Build: https://jenkins.thetaphi.de/job/Lucene-9.x-MacOSX/978/
> Java: 64bit/jdk-18
> I have no proof this is what is happening, except to say, I think it
> would be better if randomizedtesting used monotonic time (nanoTime)
> rather than wall-clock time (currentTimeMillis). It would make it more
> robust.
>
>
> On Wed, Aug 24, 2022 at 4:48 AM Dawid Weiss wrote:
&
It's the known JVM bug -
# V [libjvm.so+0xab507b]
PhaseIdealLoop::build_loop_late_post_work(Node*, bool)+0xdb
On Tue, Aug 23, 2022 at 6:32 AM Policeman Jenkins Server
wrote:
>
> Build: https://jenkins.thetaphi.de/job/Lucene-main-Linux/36559/
> Java: 64bit/jdk-18 -XX:-UseCompressedOops
Hi Mike!
So... I've just tried it with the full reproduce line and it hits the
assertion every time -
./gradlew test --tests TestField.testKnnVectorField
-Dtests.seed=728BEC8F73228AC9 -Dtests.multiplier=3
-Dtests.locale=fr-BE -Dtests.timezone=America/Dawson
-Dtests.asserts=true
This one again:
# SIGSEGV (0xb) at pc=0x7ff8eb125163, pid=2754499, tid=2755109
#
# JRE version: OpenJDK Runtime Environment (19.0+32) (build 19-ea+32-2220)
# Java VM: OpenJDK 64-Bit Server VM (19-ea+32-2220, mixed mode,
sharing, tiered, compressed oops, compressed class ptrs, parallel gc,
/lucene/pull/11725
>
> On Sun, Aug 28, 2022 at 3:51 AM Dawid Weiss wrote:
> >
> > Hi Mike!
> >
> > So... I've just tried it with the full reproduce line and it hits the
> > assertion every time -
> >
> > ./gradlew test --tests TestField.testKnnVector
Seems like merge threads are not keeping up with the load in this test on
slower machines (passes on mine). Should we tone down the nightly threshold
here?
---
a/lucene/core/src/test/org/apache/lucene/index/TestDemoParallelLeafReader.java
+++
This failure does reproduce for me:
./gradlew :lucene:core:test --tests
"org.apache.lucene.util.hnsw.TestHnswGraph.testSortedAndUnsortedIndicesReturnSameResults"
-Ptests.jvms=4 -Ptests.jvmargs=-XX:TieredStopAtLevel=1
-Ptests.seed=F01BB2E647DD2B0 -Ptests.multiplier=2 -Ptests.badapples=false
apper/gradle-wrapper.jar
>
> On Tue, Sep 13, 2022 at 3:20 AM Dawid Weiss wrote:
> >
> > These 500/503s are getting annoying. Let's see if it's something that
> > can be fixed with a simple retry mechanism.
> >
> > https://github.com/apache/lucene/pull/11766
>
These 500/503s are getting annoying. Let's see if it's something that
can be fixed with a simple retry mechanism.
https://github.com/apache/lucene/pull/11766
Dawid
On Tue, Sep 13, 2022 at 7:59 AM Apache Jenkins Server
wrote:
>
> Build:
>
Uwe is, I believe on holidays, but leaving for later since it's his build
server ( :) ). These are strange failures - seems like they happen after
the gradle build - somewhere in the [Checks API] line.
BUILD SUCCESSFUL in 20m 3s
796 actionable tasks: 796 executed
Build timed out (after 150
Failed with this (jdk18).
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x7f2b331a007b, pid=3102138, tid=3102166
#
# JRE version: OpenJDK Runtime Environment (18.0+36) (build 18+36-2087)
# Java VM: OpenJDK 64-Bit Server VM (18+36-2087, mixed
va.exe (with a bunch
> of internal api violations) and othertimes uses javac.exe.
>
> On Wed, Nov 16, 2022 at 4:12 AM Dawid Weiss wrote:
> >
> >
> > I've committed a fix on main and checked that it works with error prone,
> in process compilation and alt javac. But doub
I've committed a fix on main and checked that it works with error prone, in
process compilation and alt javac. But double checking would be probably
good. :)
Dawid
On Wed, Nov 16, 2022 at 12:18 AM Robert Muir wrote:
> It is my fault. I will revert my changes and test with "alternate
>
Looks scary but I can't reproduce it (on JDK19 as well).
D.
On Thu, Nov 17, 2022 at 7:55 AM Policeman Jenkins Server <
jenk...@thetaphi.de> wrote:
> Build: https://jenkins.thetaphi.de/job/Lucene-main-Windows/11672/
> Java: 64bit/jdk-19 -XX:-UseCompressedOops -XX:+UseG1GC
>
> 1 tests failed.
>
Hi Karl,
I fixed the boxing issue errorprone has been complaining about after your
recent commits. Some of those validation checks (errorprone) are slow(er)
and run only on the CI (github and jenkins) so a local gradle check may not
find them all.
Also, is there any reference to the problem your
This failed with an OOM, internally. There's a lot of noise after that...
I'm not sure if there's anything to be done here about it.
Dawid
On Fri, Jan 20, 2023 at 5:17 PM Policeman Jenkins Server <
jenk...@thetaphi.de> wrote:
> Build: https://jenkins.thetaphi.de/job/Lucene-MMAPv2-Windows/310/
>
openj9. Does not reproduce for me.
On Thu, Apr 20, 2023 at 4:50 AM Policeman Jenkins Server
wrote:
>
> Build: https://jenkins.thetaphi.de/job/Lucene-9.x-Linux/9891/
> Java: 64bit/openj9/jdk-17.0.5 -XX:-UseCompressedOops -Xgcpolicy:metronome
>
> 1 tests failed.
> FAILED:
Peter fixed it in 5e0761eab510f695806fdc3b51d0e9ea85497a34
On Sun, Apr 23, 2023 at 6:12 PM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:
> Build: https://ci-builds.apache.org/job/Lucene/job/Lucene-Check-9.x/5171/
>
> 1 tests failed.
> FAILED:
>
FATAL: The Gradle wrapper has not been found in these directories:
/home/jenkins/jenkins-slave/workspace/Lucene/Lucene-NightlyTests-9.x/checkout
This has been going on for a few days - it's not intermittent. It seems
like there is no git clone under there - how's that possible?
Dawid
On Thu,
This one was missing the repository as well:
https://ci-builds.apache.org/job/Lucene/job/Lucene-NightlyTests-9.5/
How odd.
Dawid
On Thu, Mar 30, 2023 at 7:02 AM Dawid Weiss wrote:
>
> I accessed the configuration on Jenkins - weird - shows no git source at
> all:
>
> [i
/
Dawid
On Thu, Mar 30, 2023 at 6:56 AM Dawid Weiss wrote:
>
> FATAL: The Gradle wrapper has not been found in these directories:
> /home/jenkins/jenkins-slave/workspace/Lucene/Lucene-NightlyTests-9.x/checkout
>
> This has been going on for a few days - it's not intermittent.
Corrected the checkout folder and gradle invocation script to top-level
(instead of 'checkout'). I'm a bit confused - has somebody changed these
configurations? What happened there?
Dawid
On Thu, Mar 30, 2023 at 9:13 AM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:
> Build:
>
Seems like something is broken on the executor machine:
/home/jenkins/tools/java/latest19/bin/java: 1: Syntax error: "(" unexpected
On Thu, Mar 30, 2023 at 4:15 PM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:
> Build:
>
Can't reproduce on hotspot. It may be due to a bug in openj9.
D.
On Tue, Mar 28, 2023 at 7:03 AM Dawid Weiss wrote:
> Not sure why the message says otherwise but this actually failed with
> an exception that doesn't look good:
>
> org.apache.lucene.codecs.memory.TestFSTPo
1 - 100 of 114 matches
Mail list logo
