If we don't have uint128, then rb_int128_to_numeric emits a strict
aliasing warning:
numeric.c:3641:39: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
3641 | return rb_uint128_to_numeric(*(rb_uint128_t*)&n);
| ^~~~~~~~~~~~~~~~~
We're seeing an occasional crash on CI because this ends up inlined all
the way into ractor_wait_receive. On llvm (possibly other compilers) the
thread local address of ec ends up cached (not the value of ec, the
address ec is read from). So if we are migrated to another native
thread, that may be invalid.
Using rb_current_ec_noinline avoids this problems. It would be good to
adjust this code so that ec (or current ractor) is calculated once and
then passed through to both lock and unlock.
Add fallback to `require` when `require_relative` fails to load native
extensions. This addresses an issue on RHEL-based Linux distributions
where Ruby scripts and built native extension shared libraries are
installed in separate directories.
https://github.com/ruby/rubygems/commit/68599bd107
Move these macros from include/ruby/backward.h to
include/ruby/internal/attr/deprecated.h, alongside the other similar
macros.
include/ruby/internal/intern/vm.h cannot currently use them because
include/ruby/backward.h is included too late.
The #ifdef is currently not taken because include/ruby/backward.h is
not included at this point. The attribute is unnecessary in an internal
header, so remove it.
The id2ref table needs to be under a VM lock to ensure there are no race
conditions. The following script crashes:
o = Object.new
ObjectSpace._id2ref(o.object_id)
10.times.map do
Ractor.new do
10_000.times do
a = Object.new
a.object_id
end
end
end.map(&:value)
With:
[BUG] Object ID seen, but not in _id2ref table: object_id=2800 object=T_OBJECT
ruby 4.0.0dev (2025-12-06T15:15:43Z ractor-id2ref-fix e7f9abdc91) +PRISM [x86_64-linux]
-- Control frame information -----------------------------------------------
c:0001 p:---- s:0003 e:000002 l:y b:---- DUMMY [FINISH]
-- Threading information ---------------------------------------------------
Total ractor count: 5
Ruby thread count for this ractor: 1
-- C level backtrace information -------------------------------------------
miniruby(rb_print_backtrace+0x14) [0x6047d09b2dff] vm_dump.c:1105
miniruby(rb_vm_bugreport) vm_dump.c:1450
miniruby(rb_bug_without_die_internal+0x5f) [0x6047d066bf57] error.c:1098
miniruby(rb_bug) error.c:1116
miniruby(rb_gc_get_ractor_newobj_cache+0x0) [0x6047d066c8dd] gc.c:2052
miniruby(gc_sweep_plane+0xad) [0x6047d079276d] gc/default/default.c:3513
miniruby(gc_sweep_page) gc/default/default.c:3605
miniruby(gc_sweep_step) gc/default/default.c:3886
miniruby(gc_sweep+0x1ba) [0x6047d0794cfa] gc/default/default.c:4154
miniruby(gc_start+0xbf2) [0x6047d0796742] gc/default/default.c:6519
miniruby(heap_prepare+0xcc) [0x6047d079748c] gc/default/default.c:2090
miniruby(heap_next_free_page) gc/default/default.c:2305
miniruby(newobj_cache_miss) gc/default/default.c:2412
miniruby(newobj_alloc+0xd) [0x6047d0798ff5] gc/default/default.c:2436
miniruby(rb_gc_impl_new_obj) gc/default/default.c:2515
miniruby(newobj_of) gc.c:996
miniruby(rb_wb_protected_newobj_of) gc.c:1046
miniruby(str_alloc_embed+0x28) [0x6047d08fda18] string.c:1019
miniruby(str_enc_new) string.c:1069
miniruby(prep_io+0x5) [0x6047d07cda14] io.c:9305
miniruby(prep_stdio) io.c:9347
miniruby(rb_io_prep_stdin) io.c:9365
miniruby(thread_start_func_2+0x77c) [0x6047d093a55c] thread.c:679
miniruby(thread_sched_lock_+0x0) [0x6047d093aacd] thread_pthread.c:2241
miniruby(co_start) thread_pthread_mn.c:469
It's possible that both half_days_in_day and day_in_nanoseconds are Ruby
objects, which means that creating day_in_nanoseconds may trigger GC.
Since half_days_in_day is not registered as a mark object until after
day_in_nanoseconds is allocated, the GC may reclaim half_days_in_day.
We can see this crash:
ruby(rb_print_backtrace+0xb) [0x63a373c0] vm_dump.c:1105
ruby(rb_vm_bugreport) vm_dump.c:1450
ruby(rb_assert_failure_detail+0xdb) [0x6371d3a2] error.c:1216
ruby(RB_FL_TEST_RAW+0x0) [0x6371d3d5] error.c:1192
ruby(rb_assert_failure) (null):0
ruby(rb_gc_impl_writebarrier+0xb4) [0x636f01e4] gc/default/default.c:6103
ruby(pin_array_list_append+0x72) [0x638f9787] include/ruby/internal/gc.h:788
ruby(rb_vm_register_global_object) vm.c:4713
ruby(rb_gc_register_mark_object+0x3a) [0x6374144a] gc.c:3449
.ext/i686-linux-gnu/date_core.so(Init_date_core+0x204) [0xdbec86c4] ext/date/date_core.c:9511
.ext/i686-linux-gnu/date_core.so(Init_date_core) (null):0
ruby(dln_load_and_init+0x71) [0x6392c541] dln.c:521
ruby(dln_load_feature+0xd2) [0x6392c7d2] dln.c:566
ruby(load_ext+0xc3) [0x637931b3] load.c:1210
ruby(rb_vm_pop_frame+0x0) [0x638f80cd] vm.c:3120
ruby(rb_vm_call_cfunc_in_box) vm.c:3122
ruby(rb_long2num_inline+0x0) [0x637956f8] load.c:1353
ruby(require_internal) load.c:1354
ruby(rb_require_string_internal+0x60) [0x63795fa1] load.c:1457
ruby(rb_require_string) load.c:1443
https://github.com/ruby/date/commit/cbec5948e0
OpenSSL plans to make asn1_string_st opaque, the struct underlying most
ASN.1 types such as ASN1_*STRING, ASN1_ENUMERATED, ASN1_INTEGER, etc.
Most of ruby/openssl's C code can be straigtforwardly converted to use
accessors available since OpenSS
https://github.com/ruby/openssl/commit/374262435a
The following warnings are emitted. We can use type punning to prevent
strict aliasing violations.
io_buffer.c:1935:23: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
1935 | rb_uint128_t u = *(rb_uint128_t*)&x;
| ^~~~~~~~~~~~~~~~~
io_buffer.c:1937:13: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
1937 | return *(rb_int128_t*)&swapped;
|
