runnable_binary generated a zero-length wrapper, but succeeded #1267
Comments
novas0x2a
added a commit
to novas0x2a/rules_foreign_cc
that referenced
this issue
Aug 24, 2024
In bazel-contrib#1267 there was an issue where, somehow, the wrapper script ended up as a zero-length file but the action succeeded (resulting in storing a zero-length file instead of the script in the caches). genrules are documented as running inside `-ueo pipefail` so it seems like this should be impossible... In any case, this avoids using >$@ because the > runs before the command itself does, creating a zero-length file before populating it, and is the only way I could think of that this ends up as an empty file. Hopefully, if the problem repeats, genrule will notice that the file didn't get created and fail.
novas0x2a
added a commit
to novas0x2a/rules_foreign_cc
that referenced
this issue
Aug 24, 2024
In bazel-contrib#1267 there was an issue where, somehow, the wrapper script ended up as a zero-length file but the action succeeded (resulting in storing a zero-length file instead of the script in the caches). genrules are documented as running inside `-ueo pipefail` so it seems like this should be impossible... In any case, this avoids using >$@ because the > runs before the command itself does, creating a zero-length file before populating it, and is the only way I could think of that this ends up as an empty file. Hopefully, if the problem repeats, genrule will notice that the file didn't get created and fail.
novas0x2a
added a commit
to novas0x2a/rules_foreign_cc
that referenced
this issue
Aug 24, 2024
In bazel-contrib#1267 there was an issue where, somehow, the wrapper script ended up as a zero-length file but the action succeeded (resulting in storing a zero-length file instead of the script in the caches). genrules are documented as running inside `-ueo pipefail` so it seems like this should be impossible... In any case, this avoids using >$@ because the > runs before the command itself does, creating a zero-length file before populating it, and is the only way I could think of that this ends up as an empty file. Hopefully, if the problem repeats, genrule will notice that the file didn't get created and fail. SH_BINARY_FILENAME also wasn't used, so this skips a step.
novas0x2a
added a commit
to novas0x2a/rules_foreign_cc
that referenced
this issue
Aug 26, 2024
In bazel-contrib#1267 there was an issue where, somehow, the wrapper script ended up as a zero-length file but the action succeeded (resulting in storing a zero-length file instead of the script in the caches). genrules are documented as running inside `-ueo pipefail` so it seems like this should be impossible... In any case, this avoids using >$@ because the > runs before the command itself does, creating a zero-length file before populating it, and is the only way I could think of that this ends up as an empty file. Hopefully, if the problem repeats, genrule will notice that the file didn't get created and fail. SH_BINARY_FILENAME also wasn't used, so this skips a step.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Sorry for how vague this is, still trying to figure out what might have happened. What we observed is:
${name}_wrapper.sh) ended up as a zero-length file, but the action succeeded.oncetwice now.I'm still trying to figure out how it might have happened, but I'm guessing it's somehow Windows-related. I was curious if anyone else had seen this happen. Looking at the code, it seems like the only way this could have happened is if the sed failed and the script didn't notice (the
>$@would have created the output regardless of the sed). Maybeerrexitshould have caught it? I don't understand currently, since genrules are supposed to run with errexit. I don't have a reliable repro or anything, unfortunately, though I'm trying.The text was updated successfully, but these errors were encountered: