| Age | Commit message (Collapse) | Author |
|---|
|
[Bug #20995] Protect `IO.popen` block from exiting by exception
|
|
d78ff6a767ca813ac5fa178dd7611f20a993c191: [Backport #20984]
[Bug #20984] ENV.inspect should be encoding aware
[Bug #20984] Fix test with locale encoding
|
|
Crash when malloc during GC
This feature was introduced in commit 2ccf6e5, but I realized that
using rb_warn is a bad idea because it allocates objects, which causes
a different crash ("object allocation during garbage collection phase").
We should just hard crash here instead.
|
|
[Bug #20924] Fix reading with delimiter in wide character encodings
|
|
Fix pointer incompatiblity
Since the subsecond part is discarded, WIDEVAL to VALUE conversion is
needed.
|
|
[Bug #20915] Fix SEGV with `TracePoint#parameters` and aliased C method
The following snippet results with a SEGV:
```ruby
C = Class.new do
alias_method :new_to_s, :to_s
end
TracePoint.new(:c_call, &:parameters).enable { C.new.new_to_s }
```
at MRI 3.3.6 and ruby 3.4.0dev
The root cause of the issue lies in the `rb_tracearg_parameters` function
within the `RUBY_EVENT_C_RETURN` branch. Specifically, when the invoked
method is an alias for a C function,
`rb_method_entry_without_refinements(..., trace_arg->called_id, ...)`
may return NULL. In that case we can fallback to `trace_arg->id`.
|
|
Fix use-after-free in constant cache
[Bug #20921]
When we create a cache entry for a constant, the following sequence of
events could happen:
- vm_track_constant_cache is called to insert a constant cache.
- In vm_track_constant_cache, we first look up the ST table for the ID
of the constant. Assume the ST table exists because another iseq also
holds a cache entry for this ID.
- We then insert into this ST table with the iseq_inline_constant_cache.
- However, while inserting into this ST table, it allocates memory, which
could trigger a GC. Assume that it does trigger a GC.
- The GC frees the one and only other iseq that holds a cache entry for
this ID.
- In remove_from_constant_cache, it will appear that the ST table is now
empty because there are no more iseq with cache entries for this ID, so
we free the ST table.
- We complete GC and continue our st_insert. However, this ST table has
been freed so we now have a use-after-free.
This issue is very hard to reproduce, because it requires that the GC runs
at a very specific time. However, we can make it show up by applying this
patch which runs GC right before the st_insert to mimic the st_insert
triggering a GC:
diff --git a/vm_insnhelper.c b/vm_insnhelper.c
index 3cb23f06f0..a93998136a 100644
--- a/vm_insnhelper.c
+++ b/vm_insnhelper.c
@@ -6338,6 +6338,10 @@ vm_track_constant_cache(ID id, void *ic)
rb_id_table_insert(const_cache, id, (VALUE)ics);
}
+ if (id == rb_intern("MyConstant")) rb_gc();
+
st_insert(ics, (st_data_t) ic, (st_data_t) Qtrue);
}
And if we run this script:
Object.const_set("MyConstant", "Hello!")
my_proc = eval("-> { MyConstant }")
my_proc.call
my_proc = eval("-> { MyConstant }")
my_proc.call
We can see that ASAN outputs a use-after-free error:
==36540==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000049528 at pc 0x000102f3ceac bp 0x00016d607a70 sp 0x00016d607a68
READ of size 8 at 0x606000049528 thread T0
#0 0x102f3cea8 in do_hash st.c:321
#1 0x102f3ddd0 in rb_st_insert st.c:1132
#2 0x103140700 in vm_track_constant_cache vm_insnhelper.c:6345
#3 0x1030b91d8 in vm_ic_track_const_chain vm_insnhelper.c:6356
#4 0x1030b8cf8 in rb_vm_opt_getconstant_path vm_insnhelper.c:6424
#5 0x1030bc1e0 in vm_exec_core insns.def:263
#6 0x1030b55fc in rb_vm_exec vm.c:2585
#7 0x1030fe0ac in rb_iseq_eval_main vm.c:2851
#8 0x102a82588 in rb_ec_exec_node eval.c:281
#9 0x102a81fe0 in ruby_run_node eval.c:319
#10 0x1027f3db4 in rb_main main.c:43
#11 0x1027f3bd4 in main main.c:68
#12 0x183900270 (<unknown module>)
0x606000049528 is located 8 bytes inside of 56-byte region [0x606000049520,0x606000049558)
freed by thread T0 here:
#0 0x104174d40 in free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x54d40)
#1 0x102ada89c in rb_gc_impl_free default.c:8183
#2 0x102ada7dc in ruby_sized_xfree gc.c:4507
#3 0x102ac4d34 in ruby_xfree gc.c:4518
#4 0x102f3cb34 in rb_st_free_table st.c:663
#5 0x102bd52d8 in remove_from_constant_cache iseq.c:119
#6 0x102bbe2cc in iseq_clear_ic_references iseq.c:153
#7 0x102bbd2a0 in rb_iseq_free iseq.c:166
#8 0x102b32ed0 in rb_imemo_free imemo.c:564
#9 0x102ac4b44 in rb_gc_obj_free gc.c:1407
#10 0x102af4290 in gc_sweep_plane default.c:3546
#11 0x102af3bdc in gc_sweep_page default.c:3634
#12 0x102aeb140 in gc_sweep_step default.c:3906
#13 0x102aeadf0 in gc_sweep_rest default.c:3978
#14 0x102ae4714 in gc_sweep default.c:4155
#15 0x102af8474 in gc_start default.c:6484
#16 0x102afbe30 in garbage_collect default.c:6363
#17 0x102ad37f0 in rb_gc_impl_start default.c:6816
#18 0x102ad3634 in rb_gc gc.c:3624
#19 0x1031406ec in vm_track_constant_cache vm_insnhelper.c:6342
#20 0x1030b91d8 in vm_ic_track_const_chain vm_insnhelper.c:6356
#21 0x1030b8cf8 in rb_vm_opt_getconstant_path vm_insnhelper.c:6424
#22 0x1030bc1e0 in vm_exec_core insns.def:263
#23 0x1030b55fc in rb_vm_exec vm.c:2585
#24 0x1030fe0ac in rb_iseq_eval_main vm.c:2851
#25 0x102a82588 in rb_ec_exec_node eval.c:281
#26 0x102a81fe0 in ruby_run_node eval.c:319
#27 0x1027f3db4 in rb_main main.c:43
#28 0x1027f3bd4 in main main.c:68
#29 0x183900270 (<unknown module>)
previously allocated by thread T0 here:
#0 0x104174c04 in malloc+0x94 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x54c04)
#1 0x102ada0ec in rb_gc_impl_malloc default.c:8198
#2 0x102acee44 in ruby_xmalloc gc.c:4438
#3 0x102f3c85c in rb_st_init_table_with_size st.c:571
#4 0x102f3c900 in rb_st_init_table st.c:600
#5 0x102f3c920 in rb_st_init_numtable st.c:608
#6 0x103140698 in vm_track_constant_cache vm_insnhelper.c:6337
#7 0x1030b91d8 in vm_ic_track_const_chain vm_insnhelper.c:6356
#8 0x1030b8cf8 in rb_vm_opt_getconstant_path vm_insnhelper.c:6424
#9 0x1030bc1e0 in vm_exec_core insns.def:263
#10 0x1030b55fc in rb_vm_exec vm.c:2585
#11 0x1030fe0ac in rb_iseq_eval_main vm.c:2851
#12 0x102a82588 in rb_ec_exec_node eval.c:281
#13 0x102a81fe0 in ruby_run_node eval.c:319
#14 0x1027f3db4 in rb_main main.c:43
#15 0x1027f3bd4 in main main.c:68
#16 0x183900270 (<unknown module>)
This commit fixes this bug by adding a inserting_constant_cache_id field
to the VM, which stores the ID that is currently being inserted and, in
remove_from_constant_cache, we don't free the ST table for ID equal to
this one.
Co-Authored-By: Alan Wu <[email protected]>
|
|
|
|
6b4f8945d600168bf530d21395da8293fbd5e8ba: [Backport #20909]
Check negative integer underflow
Many of Oniguruma functions need valid encoding strings
|
|
Ensure fiber scheduler re-acquires mutex when interrupted from sleep. (#12158)
[Bug #20907]
|
|
Fix a bug in rb_include_module that stops nested inclusion into module subclasses
This bug was present since the code was originally added by me
in 3556a834a2847e52162d1d3302d4c64390df1694.
Fixes [Bug #20871]
|
|
wasm: align fiber stack pointer to 16 bytes
In WebAssembly C ABI, the linear stack pointer must be always aligned
to 16 bytes like other archs.
The misaligned stack pointer causes some weird memory corruption since
compiler assumes the aligned stack pointer.
|
|
|
|
There have been some sproradically flaky tests related to GC compaction,
which fail with:
1) Failure:
TestGCCompact#test_moving_hashes_down_size_pools [/test/ruby/test_gc_compact.rb:442]:
Expected 499 to be >= 500.
What's happening here, is that, _sometimes_, depending on very unlucky
combinations of machine things, one of the expected-to-be-moved hashes
might be found on the machine stack during GC, and thus pinned.
One factor which seems to make this _more_ likely is that GCC 11 on
Ubuntu 22.04 seems to want to allocate 440 bytes of stack space for
`gc_start`, which is much more than it actually uses on the common code
path. The result is that there are some 50-odd VALUE-sized cells "live"
on the stack which may well contain valid heap pointers from previous
function calls, and will need to be pinned.
This is, of course, totally normal and expected; Ruby's GC is
conservative and if there is the possibility that a VALUE might be live
on the machine stack, it can't be moved. However, it does make these
tests flaky.
This commit "fixes" the tests by performing the work in a fiber; the
fiber goes out of scope and should be collected by the call to
verify_compaction_references, so there should be no references to the
to-be-moved objects floating around on the machine stack.
Fixes [#20021]
|
|
It's not guaranteed that the first element will always be embedded.
|
|
|
|
|
|
Previously if any of the tests that move objects between size pools
failed to move anything, then the call to stats.dig would return `nil`
which would then cause assert_operator to error.
This should be a test Failure, rather than an Error so this commit uses
a default value of 0 if stats.dig fails to find a key.
Also refactor object movement tests to use stats.dig, rather than :[]
|
|
Https://learn.microsoft.com/en-us/cpp/build/reference/zc-inline-remove-unreferenced-comdat?view=msvc-140
> If `/Zc:inline` is specified, the compiler enforces the C++11
> requirement that all functions declared inline must have a definition
> available in the same translation unit if they're used.
|
|
Windows 11 SDK Version 10.0.26100.0 introduced a new internal inline
function in ucrt/corecrt_math.h. Even it appears in object files and
will be included in the DEF file, it will be removed from the DLL and
result in a linker error.
|
|
Warned if both of `main` and `wmain` are exposed:
```
LINK : warning LNK4067: ambiguous entry point; selected 'mainCRTStartup'
```
|
|
It is not expected that `target_os` will change going forward.
|
|
|
|
|
|
Mingw crt-git 12.0.0.r369.g0d4221712-1 now prohibits "command line
contains characters that are not supported in the active code page".
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/0d42217123d3aec0341b79f6d959c76e09648a1e/
Already Ruby builds `argv` in `rb_w32_sysinit`, instead of mswin- or
mingw-made `argv`. Just bypass the conversion in mingw crt.
|
|
https://github.com/ruby/net-http/commit/5544243c41
|
|
RFC 2986, section 4.1 only defines version 1 for CSRs. This version
is encoded as a 0. Starting with OpenSSL 3.3, setting the CSR version
to anything but 1 fails.
Do not attempt to generate a CSR with invalid version (which now fails)
and invalidate the CSR in test_sign_and_verify_rsa_sha1 by changing its
subject rather than using an invalid version.
This commit fixes the following error.
```
2) Error: test_version(OpenSSL::TestX509Request): OpenSSL::X509::RequestError:
X509_REQ_set_version: passed invalid argument
/home/runner/work/openssl/openssl/test/openssl/test_x509req.rb:18:in `version='
/home/runner/work/openssl/openssl/test/openssl/test_x509req.rb:18:in `issue_csr'
/home/runner/work/openssl/openssl/test/openssl/test_x509req.rb:43:in
`test_version'
40: req = OpenSSL::X509::Request.new(req.to_der)
41: assert_equal(0, req.version)
42:
=> 43: req = issue_csr(1, @dn, @rsa1024, OpenSSL::Digest.new('SHA256'))
44: assert_equal(1, req.version)
45: req = OpenSSL::X509::Request.new(req.to_der)
46: assert_equal(1, req.version)
```
https://github.com/ruby/openssl/commit/c06fdeb091
|
|
5.16.3 is flaky with `make test-bundled-gems`
https://github.com/ruby/actions/actions/runs/11898853810/job/33156475298
|
|
[Bug #20873] Consider `-FIXNUM_MIN` overflow
`-FIXNUM_MIN` is usually greater than `FIXNUM_MAX` on platforms using
two's complement representation.
|
|
Although a binary (aka ASCII-8BIT) string will never have a broken
coderange, it still has to differentiate between "valid" and "7bit".
On Ruby 3.4/trunk this problem is masked because we now clear the
coderange more agressively in rb_str_resize, and we happened to always
be strinking this string, but we should not assume that.
On Ruby 3.3 this created strings where `ascii_only?` was true in cases
it shouldn't be as well as other problems.
Fixes [Bug #20883]
Co-authored-by: Daniel Colson <[email protected]>
Co-authored-by: Matthew Draper <[email protected]>
|
|
[Bug #20868] Fix Method#hash to not change after compaction
The hash value of a Method must remain constant after a compaction, otherwise
it may not work as the key in a hash table.
For example:
def a; end
# Need this method here because otherwise the iseq may be on the C stack
# which would get pinned and not move during compaction
def get_hash
method(:a).hash
end
puts get_hash # => 2993401401091578131
GC.verify_compaction_references(expand_heap: true, toward: :empty)
puts get_hash # => -2162775864511574135
|
|
[Bug #20853] Fix Proc#hash to not change after compaction
The hash value of a Proc must remain constant after a compaction, otherwise
it may not work as the key in a hash table.
|
|
rb_any_hash() non-static.
|
|
|
|
We should fix this later
|
|
|
|
|
|
|
|
|
|
```
clang: error: unknown argument '-emit-pch'; did you mean '-Xclang -emit-pch'?
MJIT warning: Making precompiled header failed on compilation. Stopping MJIT worker...
Successful MJIT finish
```
|
|
|
|
Update bundled gems list
|
|
Define `incflags` also on mswin
|
|
[Bug #19778] Pass additional include options to INCFLAGS in common.mk
|
|
[Bug #20500] Search non-default directories for jemalloc
Co-Authored-by: lish82 (Hiroki Katagiri)
|
|
dc64448202299633a235f310b8bf2192263f274f: [Backport #20716]
Fix method caching bug when including/prepend module A that prepends module B
Fix by always adding the generated iclass to the subclasses list,
otherwise the method cache for the iclass is not cleared when
the method in the module is overwritten.
Fixes [Bug #20716]
Remove an unused variable
|
|
[Bug #20755] Frozen string should not be writable via IO::Buffer
|
|
|
|
Remove `.travis.yml` as a temporary workaround.
|
|
https://github.com/ruby/actions/actions/runs/11095032727/job/30823174026#step:3:349
|
