-
Notifications
You must be signed in to change notification settings - Fork 6.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmake compiler cache failures in CI #9992
Comments
Will get this fixed. Any information / half-baked-theories would be useful ... |
Possible causes:
|
I see from those logs that there is a new symptom (or a new root cause). CMake runs the command
and fails with the error:
I cannot yet explain how this can happen. But I can say that it is not a permission issue, as I have tested what happens when you have insufficient permissions, and the error message is different (Permission denied). Note that file(APPEND should create the file when it doesn't exist, so there is no user-error here. Will continue investigating ... |
Have added more debug information in PR #11027 . Will investigate when it triggers with the same symptoms again (AFAICT it has not triggered for a week now). |
CI sometimes fails with a temporarily corrupted toolchain capabilitiy database file. Although not proven, there is evidence that CMake's file(APPEND does not work atomically when there are concurrent writes and reads of a certain size. To avoid file appending, we re-write the key-value database implementation to store keys in filenames and values in individual single-byte files. This is (most likely) fixes zephyrproject-rtos#9992. NB: Users that have been overriding the database file location with the CMake variable ZEPHYR_TOOLCHAIN_CAPABILITY_CACHE must now specify a directory with the variable ZEPHYR_TOOLCHAIN_CAPABILITY_CACHE_DIR. Signed-off-by: Sebastian Bøe <[email protected]>
CI sometimes fails with a temporarily corrupted toolchain capabilitiy database file. Although not proven, there is evidence that CMake's file(APPEND does not work atomically when there are concurrent writes and reads of a certain size. To avoid file appending, we re-write the key-value database implementation to store keys in filenames and values in individual single-byte files. This is (most likely) fixes #9992. NB: Users that have been overriding the database file location with the CMake variable ZEPHYR_TOOLCHAIN_CAPABILITY_CACHE must now specify a directory with the variable ZEPHYR_TOOLCHAIN_CAPABILITY_CACHE_DIR. Signed-off-by: Sebastian Bøe <[email protected]>
While this race seems unlikely and harmless let's play it safe and implement the usual solution: temporary file + atomic rename. The race is unlikely and maybe even harmless because: - Only sanitycheck seems to invoke cmake concurrently. - Users rarely delete their ~/.cache/zephyr/ToolchainCapabilityDatabase/ - All concurrent cmake processes write the same, single byte to the same files. - Creating a single byte is at least very fast, so extremely short window for others to read an empty file. For additional background see links in issue zephyrproject-rtos#9992 Signed-off-by: Marc Herbert <[email protected]>
While this race seems unlikely and harmless let's play it safe and implement the usual solution: temporary file + atomic rename. The race is unlikely and maybe even harmless because: - Only sanitycheck seems to invoke cmake concurrently. - Users rarely delete their ~/.cache/zephyr/ToolchainCapabilityDatabase/ - All concurrent cmake processes write the same, single byte to the same files. - Creating a single byte is at least very fast, so extremely short window for others to read an empty file. For additional background see links in issue #9992 Signed-off-by: Marc Herbert <[email protected]>
see https://app.shippable.com/github/zephyrproject-rtos/zephyr/runs/22294/4/console
The text was updated successfully, but these errors were encountered: