[Bug #21173]
When loading a file using the command line -r, it is processed before
RUBY_FREE_AT_EXIT is checked. So if the loaded file raises an error, it
will cause memory to not be freed with RUBY_FREE_AT_EXIT.
For example `ruby -rtest.rb -e ""` will report a large amount of memory
leaks if `test.rb` raises.
This test occasionally fail because it runs into a String instance
that had its `==` method removed.
I couldn't identify where this String comes from, but in general
when using `each_object` it's best to not assume returned objectd
are functional.
By just inverting the operands of `==` we ensure it's always
`String#==` that is called.
```
1) Error:
TestObjSpace#test_memsize_of_root_shared_string:
NoMethodError: undefined method '==' for #<String:0x00007f9b50e8c978>
/tmp/ruby/src/trunk-random1/test/objspace/test_objspace.rb:35:in 'block in TestObjSpace#test_memsize_of_root_shared_string'
/tmp/ruby/src/trunk-random1/test/objspace/test_objspace.rb:35:in 'ObjectSpace.each_object'
/tmp/ruby/src/trunk-random1/test/objspace/test_objspace.rb:35:in 'TestObjSpace#test_memsize_of_root_shared_string'
```
Currently, the Launchable team is developing a new feature to attach any logs. Attached log can be anything, such as system logs or stdout. Users can find these logs using any text search. Please note that this feature is a work in progress, so we can't use it yet.
I'm going to attach stdout and stderr as attached logs because they will be useful for finding interpreter bugs. When running tests, we sometimes see interpreter itself crash, and the stack is output to stderr. When debugging the cause of the issue, this feature is useful.
TestSetTraceFunc#test_tracepoint_disable is a flaky and failing intermittently. Here is an example of failure logs.
```
1) Failure:
TestSetTraceFunc#test_tracepoint_disable [/home/runner/work/ruby/ruby/src/test/ruby/test_settracefunc.rb:857]:
<[:foo, :disable, :foo, :disable]> expected but was
<[:call, :call, :foo, :disable, :foo, :disable]>.
```
3806620854 (step):12:875
I printed values of TracePoint objects as follows, and checked the values when failing intermittently.
7f9a6fc582/test/ruby/test_settracefunc.rb (L848)
Here is the log when the TestSetTraceFunc#test_tracepoint_disable failed intermittently.
`2025-03-05T09:08:37.4075411Z e: call, f: /home/runner/work/ruby/ruby/src/lib/tempfile.rb, l: 386, i: call, d: Tempfile::FinalizerManager` is an unexpected events. Thus, I modified test code so that we can filter out unexpected trace events.
```
2025-03-05T09:08:37.4075411Z e: call, f: /home/runner/work/ruby/ruby/src/lib/tempfile.rb, l: 386, i: call, d: Tempfile::FinalizerManager
2025-03-05T09:08:37.4085009Z e: call, f: /home/runner/work/ruby/ruby/src/test/ruby/test_settracefunc.rb, l: 808, i: foo, d: TestSetTraceFunc
2025-03-05T09:08:37.4086042Z e: call, f: <internal:trace_point>, l: 295, i: disable, d: TracePoint
2025-03-05T09:08:37.4115693Z e: call, f: /home/runner/work/ruby/ruby/src/test/ruby/test_settracefunc.rb, l: 808, i: foo, d: TestSetTraceFunc
2025-03-05T09:08:37.4116734Z e: call, f: <internal:trace_point>, l: 295, i: disable, d: TracePoint
```
[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 (1357211209) 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.
Commit aa7f03e18f broke test_minmax_version and test_fallback_scsv
on systems using OpenSSL 1.1.1 with a system-wide configuration file
that specifies MinProtocol=TLSv1.2.
20250228T003003Z.fail.html.gz
20250228T003003Z.fail.html.gz
These test cases were already broken before the commit, but they were
being skipped because check_supported_protocol_versions failed to detect
TLS 1.1 support. To avoid affected by the configuration file, explicitly
reset SSLContext#min_version when TLS 1.1 or older is required.
The test cases are also broken with OpenSSL 3.0 or later, but this is
not currently visible because it still fails to detect TLS 1.1 support.
This is caused by the default SSLContext#security_level value, as
OpenSSL 3.0 changed TLS 1.1 to be disabled at level 1.
6d0ea81b5e
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.
