RE: [PATCH] D80293: [clangd] Run PreambleThread in async mode behind a flag

[Pieb, Wolfgang via cfe-commits]

The test failed 7-8 times in a row on the same build machine and then started 
passing for about 10 runs, and then started failing again for 4 more runs, 
after which we disabled it.
The configuration is nothing special, simply a Release+Asserts build on 
Windows. We tried to reproduce it by hand on the same machine, but weren’t able 
to. The test ran in less than half a second when we tried it (the timeout is 
10s).

Sorry I can’t be of more help. Perhaps we can turn on some tracing output that 
would help diagnosing the problem?

  *   wolfgang

From: Kadir Çetinkaya 
Sent: Tuesday, June 2, 2020 1:20 PM
To: reviews+d80293+public+6cba1e506b8b4...@reviews.llvm.org
Cc: Sam McCall ; Pieb, Wolfgang ; 
Ilya Biryukov ; jav...@graphcore.ai; Fangrui Song 
; Jan Korous ; Aleksei Lorenz 
; jfbast...@apple.com; Utkarsh Saxena ; 
cfe-commits ; Theko Lekena ; 
Nicolas Lesser ; Han Shen ; Haojian 
Wu 
Subject: Re: [PATCH] D80293: [clangd] Run PreambleThread in async mode behind a 
flag

thanks for letting me know. it is annoying that the test is flaky, but I don't 
see that flakiness on any other buildbot I've access to.

Is there any chance that you are running in a custom build configuration that I 
can try to repro the failure? Also what's the falkiness ratio?

On Tue, Jun 2, 2020 at 1:43 AM Wolfgang Pieb via Phabricator 
mailto:revi...@reviews.llvm.org>> wrote:
wolfgangp added a comment.

Hi!

Shortly after this patch went in, we started to see intermittent failures with 
the unittest TUSchedulerTests.ManyUpdates. The build server (Windows) we're 
running it on is quite powerful and our own hand-run tests only take about 400 
ms, so we don't really understand what could be happening. Any help would be 
appreciated.

Here is an excerpt from the log:

Note: Google Test filter = TUSchedulerTests.ManyUpdates

[==] Running 1 test from 1 test case.

[--] Global test environment set-up.

[--] 1 test from TUSchedulerTests

[ RUN  ] TUSchedulerTests.ManyUpdates

C:\j\w\...\clang-tools-extra\clangd\unittests\TUSchedulerTests.cpp(508): error: 
Value of: S.blockUntilIdle(timeoutSeconds(10))

  Actual: false

Expected: true

[  FAILED  ] TUSchedulerTests.ManyUpdates (10576 ms)

[--] 1 test from TUSchedulerTests (10576 ms total)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D80293/new/

https://reviews.llvm.org/D80293


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: r276361 - Reverting r275115 which caused PR28634.

[Pieb, Wolfgang via cfe-commits]

Yes, it should. I'm just now realizing that the original change got into 3.9.

Thanks,
Wolfgang

> -Original Message-
> From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf Of
> Hans Wennborg
> Sent: Monday, July 25, 2016 9:56 AM
> To: Pieb, Wolfgang
> Cc: cfe-commits
> Subject: Re: r276361 - Reverting r275115 which caused PR28634.
> 
> Should this revert be merged to 3.9?
> 
> Thanks,
> Hans
> 
> On Thu, Jul 21, 2016 at 4:28 PM, Wolfgang Pieb via cfe-commits  comm...@lists.llvm.org> wrote:
> > Author: wolfgangp
> > Date: Thu Jul 21 18:28:18 2016
> > New Revision: 276361
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=276361&view=rev
> > Log:
> > Reverting r275115 which caused PR28634.
> > When empty (forwarding) basic blocks that are referenced by user
> > labels are removed, incorrect code may be generated.
> >
> >
> > Removed:
> > cfe/trunk/test/CodeGen/forwarding-blocks-if.c
> > Modified:
> > cfe/trunk/lib/CodeGen/CGStmt.cpp
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits