[Bug #21170]
st_table reserves -1 as a special hash value to indicate that an entry
has been deleted. So that that's a valid value to be returned from the
hash function, do_hash replaces -1 with 0 so that it is not mistaken for
the sentinel.
Previously, when upgrading an AR table to an ST table,
rb_st_add_direct_with_hash was used which did not perform the same
conversion, this could lead to a hash in a broken state where one if its
entries which was supposed to exist being marked as a tombstone.
The hash could then become further corrupted when the ST table required
resizing as the falsely tombstoned entry would be skipped but it would
be counted in num entries, leading to an uninitialized entry at index
15.
In most cases this will be really rare, unless using a very poorly
implemented custom hash function.
This also adds two debug assertions, one that st_add_direct_with_hash
does not receive the reserved hash value, and a second in
rebuild_table_with, which ensures that after we rebuild/compact a table
it contains the expected number of elements.
Co-authored-by: Alan Wu <alanwu@ruby-lang.org>
[Bug #21172]
This fixes a rare CI failure.
The timeline of the race condition is:
- A `"foo" oid=1` string is interned.
- `"foo" oid=1` is no longer referenced and will be swept in the future.
- Another `"foo" oid=2` string is interned.
- `register_fstring` finds `"foo" oid=1`, but since it is about to be swept,
removes it from `fstring_table` and insert `"foo" oid=2` instead.
- `"foo" oid=1` is swept, since it has the `RSTRING_FSTR` flag,
a `st_delete` is issued in `fstring_table` which removes `"foo" oid=2`.
I don't know how to reproduce this bug consistently in a single test
case.
Fix: https://github.com/ruby/spec/issues/1249
JRuby and TruffleRuby can't implement this behavior.
While quite a lot of code out there relies on it, if it's
not implemented it will simply result in sligthly less efficient
code, so not the end of the world.
http://ci.rvm.jp/results/trunk-gc-asserts@ruby-sp2-noble-docker/5632508
```
1) Error:
TestEval#test_outer_local_variable_under_gc_compact_stress:
Test::Unit::ProxyError: execution of Test::Unit::CoreAssertions#assert_separately expired timeout (10 sec)
pid 1339179 killed by SIGABRT (signal 6) (core dumped)
```
seems that timeout scale doesn't work even though `RUBY_TEST_TIMEOUT_SCALE`
is specified.
This patch tries to print the timeout with scale information.
Compilations actions are flaky and intermittently failing now. This run (https://github.com/ruby/ruby/actions/runs/13572112090) is an example of the issue. The job fails due to exceeding the timeout, resulting in termination. To prevent these intermittent failures, I'm going to increase the timeout.
RUBY_CONST_ID has never been deprecated; `rb_intern` is handy but it
is using non-standard GCC extensions and does not cache the ID with
other compilers.
[Bug #21161]
The `tolower` function provided by the libc is locale dependent
and can behave in ways you wouldn't expect for some value
of `LC_CTYPE`.
https://github.com/ruby/prism/commit/e3488256b4
Co-Authored-By: Nobuyoshi Nakada <nobu@ruby-lang.org>
As reported in <https://github.com/ruby/ruby/pull/12823>,
check_supported_protocol_versions is unstable and occasionally fails
with Errno::ECONNABORTED during SSLSocket#connect on Windows.
When the server-side SSLContext specifies an unsupported SSL/TLS
protocol version, start_server accepts a TCP connection but closes it
without reading ClientHello, as SSLSocket#accept immediately raises an
exception. With Winsock, this can cause the client-side
SSLSocket#connect to raise Errno::ECONNABORTED.
While the simplest fix is to add rescue Errno::ECONNABORTED, this method
can be simplified. Instead, let's set up a server that accepts all
protocol versions and test client connections with different settings.
https://github.com/ruby/openssl/commit/aa7f03e18f
The "pend" are no longer necessary, as they work with all OpenSSL
variants we currently support. They were added in OpenSSL 1.1.1 and
LibreSSL 3.8.0. They are also supported by the current AWS-LC release.
This makes the SHA-3 tests run with AWS-LC correctly. AWS-LC does not
report SHA-3 in OpenSSL::Digest.digests.
https://github.com/ruby/openssl/commit/e1a6e9c081
Starting with LibreSSL 3.5, OpenSSL::X509::ExtensionFactory refuses to
create SAN extensions that are not valid according to RFC 6125. While
this behavior makes sense, we need such invalid extensions to test our
own validation routine. Let's construct SAN extensions manually instead.
https://github.com/ruby/openssl/commit/b420d6d739
As OpenSSL::OPENSSL_FIPS always returns true on OpenSSL >= 3.0.0, we cannot use
this constant as a flag to check whether the OpenSSL is FIPS or not.
See <d725783c5c/ext/openssl/ossl.c (L994-L1004)>.
Skip the test_fips_mode_get_with_fips_mode_set test in AWS-LC case.
Because we don't test `OpenSSL.fips_mode=` on AWS-LC for now. We cannot change
the value of the `OpenSSL.fips_mode` on AWS-LC.
The `OpenSSL.fips_mode` in AWS-LC behaves as follows.
On AWS-LC non-FIPS:
```
$ bundle exec ruby -I ./lib -ropenssl.so -e 'p OpenSSL.fips_mode'
false
$ bundle exec ruby -I ./lib -ropenssl.so -e 'OpenSSL.fips_mode = true; p OpenSSL.fips_mode'
-e:1:in 'OpenSSL.fips_mode=': Turning on FIPS mode failed (OpenSSL::OpenSSLError)
from -e:1:in '<main>'
$ bundle exec ruby -I ./lib -ropenssl.so -e 'OpenSSL.fips_mode = false; p OpenSSL.fips_mode'
false
```
On AWS-LC FIPS:
```
$ bundle exec ruby -I ./lib -ropenssl.so -e 'p OpenSSL.fips_mode'
true
$ bundle exec ruby -I ./lib -ropenssl.so -e 'OpenSSL.fips_mode = false; p OpenSSL.fips_mode'
-e:1:in 'OpenSSL.fips_mode=': Turning off FIPS mode failed (OpenSSL::OpenSSLError)
from -e:1:in '<main>'
$ bundle exec ruby -I ./lib -ropenssl.so -e 'OpenSSL.fips_mode = true; p OpenSSL.fips_mode'
true
```
https://github.com/ruby/openssl/commit/fd3e3e722f
