Can't even find an upstream compiler bug report not to mention a confirmation/patch. Doesn't look like the compiler output was analyzed at all either, they are just going by "-O3 results in valgrind warnings, -O2 doesn't".
It's not like compiler bugs are unheard of but they are rare enough that the base assumption should be that the bug is in your own code.
And not only is this blaming a compiler bug, which like sure, those do happen, it blames two compiler bugs in different programming languages. That's a red flag to me.
I remember that PR for similarly interesting reasons:
Someone on the pgsql-hackers@ mailing list noticed that, with a then-recent OpenSSL version on graviton, there were issues validating the "control file" of a PostgreSQL instance [0] (control files contain some basic ground truths about a cluster).
The report included a lot of detailed information about the program state, sufficient for me to figure out that one of the registers was definitely getting clobbered during the pg_strong_random() calls[1], but without access to the environment I couldn't prove whether it was the OpenSSL library, or a compiler bug.
A few days later an Apt developer was debugging the same issue from another direction, eventually figured out that this was caused by a typo in openssl's register restoration code (which was written in ASM introduced in the PR linked by parent post), and then submitted a PR to OpenSSL to fix the issue [2], now (presumably) for good.
Looks like a valid new optimization to me, which only fails on valgrind, which is a bit too strict with uninitialized values. In openssl's strlcpy. They'll deal with that.
Not actually confirmed as compiler bugs yet.
Here’s a similar bug where OpenSSL’s inline asm was wrong and probably only GCC was smart enough to try to exploit the bug:
https://github.com/openssl/openssl/pull/23233
Same for rust - could be UB in quiche that is getting exposed.
Can't even find an upstream compiler bug report not to mention a confirmation/patch. Doesn't look like the compiler output was analyzed at all either, they are just going by "-O3 results in valgrind warnings, -O2 doesn't".
It's not like compiler bugs are unheard of but they are rare enough that the base assumption should be that the bug is in your own code.
And not only is this blaming a compiler bug, which like sure, those do happen, it blames two compiler bugs in different programming languages. That's a red flag to me.
turns out it was just valgrind not handling a valid optimization correclty.
I remember that PR for similarly interesting reasons:
Someone on the pgsql-hackers@ mailing list noticed that, with a then-recent OpenSSL version on graviton, there were issues validating the "control file" of a PostgreSQL instance [0] (control files contain some basic ground truths about a cluster).
The report included a lot of detailed information about the program state, sufficient for me to figure out that one of the registers was definitely getting clobbered during the pg_strong_random() calls[1], but without access to the environment I couldn't prove whether it was the OpenSSL library, or a compiler bug.
A few days later an Apt developer was debugging the same issue from another direction, eventually figured out that this was caused by a typo in openssl's register restoration code (which was written in ASM introduced in the PR linked by parent post), and then submitted a PR to OpenSSL to fix the issue [2], now (presumably) for good.
[0] https://postgr.es/m/Z4VjonBTm6IG8mGa%40msg.df7cb.de
[1] https://postgr.es/m/CAEze2WiRijBaoeFgi1JvsZeO6qXvpYkh4ax1bUV...
[2] https://github.com/openssl/openssl/pull/26469
The social post links to this bug https://github.com/curl/curl/issues/23237
Thank you
Looks like a valid new optimization to me, which only fails on valgrind, which is a bit too strict with uninitialized values. In openssl's strlcpy. They'll deal with that.