Failing libcxx-libcxxabi-libunwind bots

Runtimes C++
1

Hi,

It looks like several bots assigned to you started failing after e6a39f00e8d0 was committed:

http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-armv8-linux-noexceptions
http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-armv8-linux
http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux
http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions

They all fail on the test libcxx/test/libcxx/modules/stds_include.sh.cpp with the following error:

<…>/libcxx/test/libcxx/modules/stds_include.sh.cpp:28:2: fatal error: file ‘<…>/libcxx/include/type_traits’ has been modified since the module file ‘/ModuleCache/1E92AHT/std-1V9DLRO.pcm’ was built
#include
^
<…>/libcxx/test/libcxx/modules/stds_include.sh.cpp:28:2: note: please rebuild precompiled header ‘/ModuleCache/1E92AHT/std-1V9DLRO.pcm’
1 error generated.

Our other bots are not failing, so I very strongly suspect this is not because of the change itself, but rather some weirdness in your bot configuration. For that reason, I will not revert the change (that would likely not improve the situation anyway). Can you please collaborate with us to understand and fix the issue?

Thanks,
Louis

2

Also, is there a Docker image used to run the bots? That is our preferred way of handling libc++/libc++abi bots, because that means anyone can reproduce the failures locally. If the bots don’t require anything specific beyond the CMake configuration they’re testing, you could even use our existing Docker images based on Debian.

Louis

3

Hi Louis,

Yes the issue due to this directory /ModuleCache not being removed after it is used or cleaned up at the beginning. So it’s on our side or into the test itself which doesn’t remove these files at the end.

All our bots run inside containers, they are available here https://hub.docker.com/u/linaro

Thanks
Yvan

4

Hi Louis,

Yes the issue due to this directory /ModuleCache not being removed after it is used or cleaned up at the beginning. So it’s on our side or into the test itself which doesn’t remove these files at the end.

Are you using some special CMake variable to point the build to that Module cache? If so, then it would be the responsibility of the bot to clean it up.

Louis

5

Hi Louis,

Yes the issue due to this directory /ModuleCache not being removed after it is used or cleaned up at the beginning. So it’s on our side or into the test itself which doesn’t remove these files at the end.

Are you using some special CMake variable to point the build to that Module cache? If so, then it would be the responsibility of the bot to clean it up.

Nope, there is nothing special on cmake command line.

http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-armv8-linux/builds/1512/steps/cmake/logs/stdio

Yvan

6

Nevermind, it seems that this is a Clang bug instead. See:

commit 62f3a9650a9f289a07a5f480764fb655178c2334
Author: Eric Fiselier <eric@efcs.ca>

[libc++] Attempt to workaround module invalidation bug

Cheers,
Louis