On Wed, Aug 24, 2022 at 11:40 AM Uwe Schindler wrote:
>
> Hi,
>
> this is the MacOS virtualbox. This one often hast timeshifts caused by
> Virtualbox and the NTP daemon of OSX is bullshit (no chrony).
>
> Actually earlier versions of MacOS had a bug in their OS libc
> segfaulting the app to crash
Hi,
this is the MacOS virtualbox. This one often hast timeshifts caused by
Virtualbox and the NTP daemon of OSX is bullshit (no chrony).
Actually earlier versions of MacOS had a bug in their OS libc
segfaulting the app to crash on backwards jumps of wall time, which was
fixed a few years
If we look at the 7687 issue, there's definitely some that can be
explained by unruly tests randomly behaving badly. But a few of those
(such as simple stemmer tests) look suspicious to me.
I've fought the issue with my own tests (non-java) and its amazing how
much stuff can break, if it relies on
Damn. I know about it but never had it happen to me. You're right in
that it could be a reason and it's definitely one of the aspects I can
take off the checklist. It looks strange because those timeouts are
fairly high - the time correction would indeed have to be significant
for this to fail
Hi Dawid, I looked at this and also https://github.com/apache/lucene/issues/7687
If you look at the instances and how sporadic they are, the problem
could be caused by TimeoutSuite using wall-clock time in
com.carrotsearch.randomizedtesting? Especially in virtual machines,
wall-clock time can be
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
