-
Notifications
You must be signed in to change notification settings - Fork 561
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
SHA3 randomlly crashes on GitHub MacOS x64 action runner #3843
Comments
I don't see anything wrong with your usage. The interesting thing here is that you say it fails only randomly or occasionally. Otherwise I would immediately suspect a miscompilation of some kind. Are you able to get a backtrace?
could this be related to a SIGILL? I'm wondering if we are somehow jumping to the BMI2 enabled codepath on a machine that doesn't support it. |
here's the backtrace I'm able to get. I added a signal handler to catch SIGILL. But don't have the debug symbols for Botan. Looks it jumped to NULL?
|
I noticed that you're using a sort-of strong type to write the output value to. The type is defined as: struct Hash256
{
unsigned char bytes[32];
}; ... and you're using it like so: template <typename Hash>
inline bool attemptHash(const std::string_view& name,
Hash& hash,
const void* data,
size_t len)
{
auto hashFunction = Botan::HashFunction::create(name);
// [...]
hashFunction->update((const unsigned char*)data, len);
hashFunction->final((unsigned char*)&hash);
// ~~~ assumes that address of object is equal to address of buffer ~~~
return true;
}
Hash256 sha3(const void* data, size_t len)
{
Hash256 hash;
if (attemptHash("SHA-3(256)", hash, data, len))
return hash;
// [...]
return hash
} You're assuming that the address of the member Maybe explicitly take the address of |
You are right but I think it is unrelated. Even under extreme conditions, the object size cannot be smaller then the data I declared. Even if there's a huge buffer between the beginning of the object and the data, it will still be valid memory. |
I successfully reproduced the crash in my fork, and after fixing the UB I pointed out, the crash seems to go away. Even running the unit tests many times in a single build job and/or restarting the build job several times didn't trigger the crash anymore. When I re-introduce the UB it comes back quite consistently.
Technically, I agree with you. And unfortunately, I can't explain why this UB seems to cause these spurious crashes. I'm going to blame some compiler optimizations going rogue. Please try the fix in your branch. |
@marty1885 Any news here? Otherwise, I'd like to close the issue |
Hey, sorry for the delay. It was CNY and stuff. I made a new branch and applied the changes. Still having the issue. PR is on the following link |
Hi,
A library that I maintain optionally depends on Botan-3. We have been finding that the SHA3 test randomly crashes on our CI runs with the following error. And only SHA3 is failing. All other hashes we test (MD5, SHA256, SHA1, BLAKE2b) and OS (Linux) runs as expected. I've also verified this is not a null dereference on my side as the returned hasher is null-checked. Nor the input parameter is invalid.
You can find the full CI run here. https://github.com/an-tao/trantor/actions/runs/7224966423/job/19687414958?pr=309
And the code in question: an-tao/trantor#309
The text was updated successfully, but these errors were encountered: