Skip to content
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

Nondeterministic CI failures due to Makefile recompliation checking in heapster-tests #1801

Closed
RyanGlScott opened this issue Jan 17, 2023 · 0 comments · Fixed by #1802
Closed
Labels
tooling: CI Issues involving CI/CD scripts or processes

Comments

@RyanGlScott
Copy link
Contributor

The CI is nondeterministically failing on the heapster-tests job, as seen in this example:

/home/runner/work/saw-script/saw-script/dist/bin/saw rust_data.saw



[11:05:11.859] Loading file "/home/runner/work/saw-script/saw-script/heapster-saw/examples/rust_data.saw"
[11:05:12.146] Stack trace:
"heapster_init_env_from_file" (/home/runner/work/saw-script/saw-script/heapster-saw/examples/rust_data.saw:2:8-2:35)
Unknown type code  25
Are you sure you're using a supported compiler?
Check here: https://github.com/GaloisInc/llvm-pretty-bc-parser

from:
	TYPE_BLOCK
	type symbol table
	MODULE_BLOCK
	Bitstream

At first glance, this seems off, since we have already checked in a rust_data.bc file that is known to work with llvm-pretty-bc-parser. But the output above is only half of the story. Earlier in the CI log, we see this:

rustc --crate-type=lib --emit=llvm-bc rust_data.rs

This is rebuilding the rust_data.bc file, but with a more recent version of rustc than what was used to originally compile it! This is terrible, because (1) this produces different bitcode than what we want to test, and (2) the bitcode that newer rustcs emit will not support llvm-pretty-bc-parser (at least, not in its current state).

@kquick notes that make will rebuild a .bc file if its creation timestamp is different than its modified timestamp. Normally, these timestamps are set to the same time due to the way git clone works, but there can occasionally be ever-so-slight delays during the checkout process that cause the modified time to be later than the created time. That is most likely why rust_data.bc (and only rust_data.bc) is being rebuilt in the CI log above, as it was the one .bc file in the Heapster examples directory that happened to suffer from an ever-so-slight delay during the checkout process.

We should figure out a way to avoid this. One possible solution is to run touch *.bc before running make to ensure that the created and modified timestamps are the same.

@RyanGlScott RyanGlScott added the tooling: CI Issues involving CI/CD scripts or processes label Jan 17, 2023
RyanGlScott added a commit that referenced this issue Jan 17, 2023
This will ensure that all `.bc` files' timestamps are the same before running
`make`, avoiding unwanted recompilation.

Fixes #1801.
RyanGlScott added a commit that referenced this issue Jan 17, 2023
This avoids the potential for spurious rebuilding in certain situations where
the `.bc` files have different created and modified timestamps.

Fixes #1801.
RyanGlScott added a commit that referenced this issue Jan 17, 2023
This avoids the potential for spurious rebuilding in certain situations where
the `.bc` files have different created and modified timestamps.

Fixes #1801.
@mergify mergify bot closed this as completed in #1802 Jan 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tooling: CI Issues involving CI/CD scripts or processes
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant