- ruby-core - ml.ruby-lang.org

[ruby-core:116028] [Ruby master Feature#20152] mkmf / extconf: Add a proper way to not compile the extension
by byroot (Jean Boussier) 06 Feb '26

06 Feb '26

Issue #20152 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #20152: mkmf / extconf: Add a proper way to not compile the extension https://bugs.ruby-lang.org/issues/20152 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- ### Context There are various gems that ship with a native extension as a way to speedup part of the gem, but also ship with a pure Ruby version of these methods as a fallback. So they only want to compile the extension if the platform supports it, and if not, just fallback to the slightly slower Ruby version. Right now users rely on one of two hacks to do this. Either they create an empty Makefile, but then still depend on `make` being available, or publish platform specific packages without any extension in them. Examples: - [`bootsnap` skip compilation if not on MRI or TruffleRuby](https://github.com/Shopify/bootsnap/blob/070151f1305f23102365d… - [`erb` has an extension for MRI but then need to publish a `java` version of the gem that doesn't actually contain Java code, just to skip compilation on JRuby](https://github.com/ruby/erb/issues/52) - [`hiredis-client` skips the compilation for Windows and non-MRI rubies](https://github.com/redis-rb/redis-client/blob/1ab081c1d0e47df5d55e0… ### Feature It would be very useful to have some proper first class API to skip compiling the extension. Something like: ```ruby require "mkmf" if RUBY_ENGINE != "ruby" || RUBY_PLATFORM.match?(/mswin/) skip_compilation else # ... end ``` cc @k0kubun @headius -- https://bugs.ruby-lang.org/

10 21

[ruby-core:124694] [Ruby Feature#12906] do/end blocks work with ensure/rescue/else
by zverok (Victor Shepelev) 06 Feb '26

06 Feb '26

Issue #12906 has been updated by zverok (Victor Shepelev). > I tried finding out why this is called `ensure`/`rescue`/`else` when it only handles `ensure` and `rescue`? ```ruby begin File.read(filename) rescue ArgumentError puts "wrong arguments" rescue Errno::ENOENT puts "file does not exist" else puts "read successfully" end ``` `else` is part of `rescue` clause that invoked if no exception was raised; it is useful to do some post-body actions that doesn't affect the main flow (though affects the exception-handling return value). It is _documented_ [here](https://docs.ruby-lang.org/en/master/language/exceptions_md.html#else…. > I thought this might be something like the empty iterator pattern that is used in some frontend frameworks. I don't think this is possible to implement in Ruby without very serious effort and a significant toll to the mental model of the language. In your code example, `else` clause is part of the block's body; a block is mostly a "black box" for a method that receives it, and only can be interacted with via `block.call(args)`; invoking _some_ of the block statements conditionally is a questionable road. Though not unimaginable. ---------------------------------------- Feature #12906: do/end blocks work with ensure/rescue/else https://bugs.ruby-lang.org/issues/12906#change-116288 * Author: josh.cheek (Josh Cheek) * Status: Closed * Assignee: nobu (Nobuyoshi Nakada) * Target version: 2.5 ---------------------------------------- When you want to rescue in a block, you must do this: ~~~ruby lambda do begin raise 'err' rescue $! # => #<RuntimeError: err> end end.call ~~~ I've wished on numerous occasions that I could omit the begin/end and not need the extra wrapper: ~~~ruby lambda do raise 'err' rescue $! # => #<RuntimeError: err> end.call ~~~ This would be consistent with how classes and methods work: ~~~ruby class C raise 'err' rescue $! # => #<RuntimeError: err> end send def m raise 'err' rescue $! # => #<RuntimeError: err> end ~~~ It's not really clear to me how to submit this since it may require some discussion, but this is the diff: ~~~diff diff --git a/parse.y b/parse.y index 54ccc52..223e5d3 100644 --- a/parse.y +++ b/parse.y @@ -3757,7 +3757,7 @@ brace_body : {$<vars>$ = dyna_push();} do_body : {$<vars>$ = dyna_push();} {$<val>$ = cmdarg_stack >> 1; CMDARG_SET(0);} - opt_block_param compstmt + opt_block_param bodystmt { $$ = new_do_body($3, $4); dyna_pop($<vars>1); ~~~ I added tests for ensure to rubyspec, but there wasn't an obvious place to talk about rescue/else in this context (the spec for rescue only uses it in a begin/end block) It's probably fine as the spec for ensure does hit rescue, too, and they ultimately delegate to the same pieces. Not totally clear, though. I can do more with that if you need. ~~~diff diff --git a/language/ensure_spec.rb b/language/ensure_spec.rb index 13575fc..b14b0b5 100644 --- a/language/ensure_spec.rb +++ b/language/ensure_spec.rb @@ -124,3 +124,74 @@ describe "An ensure block inside a method" do @obj.explicit_return_in_method_with_ensure.should == :ensure end end + +describe "An ensure block inside a do block" do + before :each do + ScratchPad.record [] + end + + it "is executed when an exception is raised in it's corresponding do block" do + begin + lambda do + ScratchPad << :begin + raise "An exception occured!" + ensure + ScratchPad << :ensure + end.should raise_error(RuntimeError) + + ScratchPad.recorded.should == [:begin, :ensure] + end + end + + it "is executed when an exception is raised and rescued in it's corresponding do block" do + begin + lambda do + ScratchPad << :begin + raise "An exception occured!" + rescue + ScratchPad << :rescue + ensure + ScratchPad << :ensure + end.call + + ScratchPad.recorded.should == [:begin, :rescue, :ensure] + end + end + + it "is executed even when a symbol is thrown in it's corresponding do block" do + begin + catch(:symbol) do + lambda do + ScratchPad << :begin + throw(:symbol) + rescue + ScratchPad << :rescue + ensure + ScratchPad << :ensure + end.call + end + + ScratchPad.recorded.should == [:begin, :ensure] + end + end + + it "is executed when nothing is raised or thrown in it's corresponding do block" do + lambda do + ScratchPad << :begin + rescue + ScratchPad << :rescue + ensure + ScratchPad << :ensure + end.call + + ScratchPad.recorded.should == [:begin, :ensure] + end + + it "has no return value" do + lambda do + :begin + ensure + :ensure + end.call.should == :begin + end +end ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124687] [Ruby Bug#21864] Inconsistencies in type coercion error messages for integers
by herwin (Herwin W) 05 Feb '26

05 Feb '26

Issue #21864 has been reported by herwin (Herwin W). ---------------------------------------- Bug #21864: Inconsistencies in type coercion error messages for integers https://bugs.ruby-lang.org/issues/21864 * Author: herwin (Herwin W) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [x86_64-linux], but consisten since at least Ruby 3.2, haven't checked older releases * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Some context in https://github.com/ruby/spec/pull/1345, all code snippets are run using Ruby 4.0.1 on a 64bit Linux (Debian) system, unless stated otherwise. Ruby has some generic type coercion error message. For example: ```ruby File.truncate(var, 1) ``` Depending on the type of `var`, it can generate error messages like: ``` no implicit conversion of Integer into String (TypeError) no implicit conversion of false into String (TypeError) ``` In general `true`, `false` and `nil` print the string representation of the object, anything else prints the class of the object. One could argue that this is inconsistent, but it's probably better than printing `NilClass` in the error (something I've recently seen happen in Natalie and TruffleRuby, I would guess JRuby occasionally has this issue as well, but I haven't looked for it. The exact error messages are often missing in the Ruby specs). The conversion to integer is weird. ```ruby File.truncate("/dev/zero", var) ``` Anything other than `nil` gets pretty much the same output as before: ``` no implicit conversion of Symbol into Integer (TypeError) no implicit conversion of false into Integer (TypeError ``` But this is where nil has a special path: ``` no implicit conversion from nil to integer (TypeError) ``` Now it's usng "from .. to" instead of "of .. into", and `integer` is written in lower case. But, this message is not consistent either, based on the size of `off_t`, where the coercion uses either `rb_num2long` or `rb_num2ll`, which have different checks for `nil`: ```c // Taken from commit 86dba8cfaeabb3b86df921da24b3243b9ce4ab2a long rb_num2long(VALUE val) { again: if (NIL_P(val)) { rb_raise(rb_eTypeError, "no implicit conversion from nil to integer"); } LONG_LONG rb_num2ll(VALUE val) { if (NIL_P(val)) { rb_raise(rb_eTypeError, "no implicit conversion from nil"); } ``` That last one has some internal checks for other types, with more inconsistent error messages: ```c rb_raise(rb_eTypeError, "no implicit conversion from string"); rb_raise(rb_eTypeError, "no implicit conversion from boolean"); ``` That last one looks like the only error message to mention the term `boolean`. IMHO the first message type is the clearest, so I would propose to write every coercion failure in this way: ```ruby type = value.nil? || value == true || value == "false" ? value.inspect : value.class klass = "String" # Or Integer, or ... "no implicit conversion of #{type} into #{klass}" ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:124689] [Ruby Feature#12906] do/end blocks work with ensure/rescue/else
by phoet 05 Feb '26

05 Feb '26

Issue #12906 has been updated by phoet (Peter Schröder). I tried finding out why this is called `ensure/rescue/else` when it only handles `ensure` and `rescue`? Stumbled open this in the Ruby version history https://rubyreferences.github.io/rubychanges/2.5.html#rescueelseensure-are-… I thought this might be something like the empty iterator pattern that is used in some frontend frameworks. ``` def print_elements elements.each do |e| puts e else puts "No Elements" end end ``` ---------------------------------------- Feature #12906: do/end blocks work with ensure/rescue/else https://bugs.ruby-lang.org/issues/12906#change-116282 * Author: josh.cheek (Josh Cheek) * Status: Closed * Assignee: nobu (Nobuyoshi Nakada) * Target version: 2.5 ---------------------------------------- When you want to rescue in a block, you must do this: ~~~ruby lambda do begin raise 'err' rescue $! # => #<RuntimeError: err> end end.call ~~~ I've wished on numerous occasions that I could omit the begin/end and not need the extra wrapper: ~~~ruby lambda do raise 'err' rescue $! # => #<RuntimeError: err> end.call ~~~ This would be consistent with how classes and methods work: ~~~ruby class C raise 'err' rescue $! # => #<RuntimeError: err> end send def m raise 'err' rescue $! # => #<RuntimeError: err> end ~~~ It's not really clear to me how to submit this since it may require some discussion, but this is the diff: ~~~diff diff --git a/parse.y b/parse.y index 54ccc52..223e5d3 100644 --- a/parse.y +++ b/parse.y @@ -3757,7 +3757,7 @@ brace_body : {$<vars>$ = dyna_push();} do_body : {$<vars>$ = dyna_push();} {$<val>$ = cmdarg_stack >> 1; CMDARG_SET(0);} - opt_block_param compstmt + opt_block_param bodystmt { $$ = new_do_body($3, $4); dyna_pop($<vars>1); ~~~ I added tests for ensure to rubyspec, but there wasn't an obvious place to talk about rescue/else in this context (the spec for rescue only uses it in a begin/end block) It's probably fine as the spec for ensure does hit rescue, too, and they ultimately delegate to the same pieces. Not totally clear, though. I can do more with that if you need. ~~~diff diff --git a/language/ensure_spec.rb b/language/ensure_spec.rb index 13575fc..b14b0b5 100644 --- a/language/ensure_spec.rb +++ b/language/ensure_spec.rb @@ -124,3 +124,74 @@ describe "An ensure block inside a method" do @obj.explicit_return_in_method_with_ensure.should == :ensure end end + +describe "An ensure block inside a do block" do + before :each do + ScratchPad.record [] + end + + it "is executed when an exception is raised in it's corresponding do block" do + begin + lambda do + ScratchPad << :begin + raise "An exception occured!" + ensure + ScratchPad << :ensure + end.should raise_error(RuntimeError) + + ScratchPad.recorded.should == [:begin, :ensure] + end + end + + it "is executed when an exception is raised and rescued in it's corresponding do block" do + begin + lambda do + ScratchPad << :begin + raise "An exception occured!" + rescue + ScratchPad << :rescue + ensure + ScratchPad << :ensure + end.call + + ScratchPad.recorded.should == [:begin, :rescue, :ensure] + end + end + + it "is executed even when a symbol is thrown in it's corresponding do block" do + begin + catch(:symbol) do + lambda do + ScratchPad << :begin + throw(:symbol) + rescue + ScratchPad << :rescue + ensure + ScratchPad << :ensure + end.call + end + + ScratchPad.recorded.should == [:begin, :ensure] + end + end + + it "is executed when nothing is raised or thrown in it's corresponding do block" do + lambda do + ScratchPad << :begin + rescue + ScratchPad << :rescue + ensure + ScratchPad << :ensure + end.call + + ScratchPad.recorded.should == [:begin, :ensure] + end + + it "has no return value" do + lambda do + :begin + ensure + :ensure + end.call.should == :begin + end +end ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124664] [Ruby Bug#21859] Inconsistent behaviors in Regexp lookbehind/lookahead with capture groups
by trinistr (Alexander Bulancov) 05 Feb '26

05 Feb '26

Issue #21859 has been reported by trinistr (Alexander Bulancov). ---------------------------------------- Bug #21859: Inconsistent behaviors in Regexp lookbehind/lookahead with capture groups https://bugs.ruby-lang.org/issues/21859 * Author: trinistr (Alexander Bulancov) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- First issue: `Regexp.linear_time?` is `false` for a positive lookahead with a capture, but `true` for a positive lookbehind: ```ruby irb(main):002> Regexp.linear_time?(/(?=(a))/) => false irb(main):003> Regexp.linear_time?(/(?<=(a))/) => true ``` This should be `false` in both cases. Second issue: Capture group is allowed in a negative lookahead, but causes a `SyntaxError` in a negative lookbehind: ```ruby irb(main):001> /(?!(a))b/ => /(?!(a))b/ irb(main):002> /(?<!(a))b/ /home/alex/.local/share/mise/installs/ruby/4.0.1/lib/ruby/gems/4.0.0/gems/irb-1.16.0/exe/irb:9:in '<top (required)>': (irb):2: invalid pattern in look-behind: /(?<!(a))b/ (SyntaxError) ``` I believe such a capture group can never capture anything, so it probably should be an error in both cases. -- https://bugs.ruby-lang.org/

3 7

[ruby-core:124680] [Ruby Bug#21862] dtrace is passed unmodified CPPFLAGS, but not all compiler flags are supported by dtrace
by wiz (Thomas Klausner) 05 Feb '26

05 Feb '26

Issue #21862 has been reported by wiz (Thomas Klausner). ---------------------------------------- Bug #21862: dtrace is passed unmodified CPPFLAGS, but not all compiler flags are supported by dtrace https://bugs.ruby-lang.org/issues/21862 * Author: wiz (Thomas Klausner) * Status: Open * ruby -v: 4.0.1 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I use "CPPFLAGS=-g" to enable symbols in my builds. This works for most software, except for ruby. The problem is that, in template/Makefile.in, CPPFLAGS are passed unmodified to dtrace: ``` .d.h: @$(ECHO) translating probes $< $(Q) $(DTRACE) -o $@.tmp -h -C $(INCFLAGS) $(CPPFLAGS) -s $< ``` which on NetBSD leads to a dtrace usage warning, because -g is not supported: ``` BASERUBY = ./tool/missing-baseruby.bat CC = gcc LD = ld LDSHARED = gcc -shared CFLAGS = -O2 -g -fstack-clash-protection -pthread -I/usr/pkg/include -I/usr/include -fPIC -pipe XCFLAGS = -fno-strict-overflow -fvisibility=hidden -fexcess-precision=standard -DRUBY_EXPORT -I. -I.ext/include/x86_64-netbsd -I.ext/include -I./include -I. -I./prism -I./enc/unicode/17.0.0 -Dmodular_gc_dir= CPPFLAGS = -g -I/usr/pkg/include -I/usr/include DLDFLAGS = -Wl,-zrelro -Wl,-znow -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -L/usr/lib -Wl,-R/usr/lib -pthread -Wl,--compress-debug-sections=zlib -Wl,-soname,libruby40.so.40 SOLIBS = -lexecinfo -lz -lrt -lrt -lcrypt -lm -lpthread LANG = C LC_ALL = C LC_CTYPE = C MFLAGS = RUSTC = rustc YJIT_RUSTC_ARGS = --crate-name=yjit --crate-type=staticlib --cfg feature="stats_allocator" --edition=2021 -g -C lto=thin -C opt-level=3 -C overflow-checks=on '--out-dir=/tmp/lang/ruby40/work/ruby-4.0.1/tar get/release/' './yjit/src/lib.rs' ZJIT_RUSTC_ARGS = --crate-name=zjit --crate-type=staticlib --cfg feature="stats_allocator" --edition=2024 -g -C lto=thin -C opt-level=3 -C overflow-checks=on '--out-dir=/tmp/lang/ruby40/work/ruby-4.0.1/tar get/release/' './zjit/src/lib.rs' gcc (nb2 20260118) 14.3.0 Copyright (C) 2024 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. compiling ./main.c compiling dmydln.c compiling miniinit.c translating probes probes.d dtrace: unknown option -- g Usage: dtrace [-32|-64] [-aACeFGhHlqSvVwZ] [-b bufsz] [-c cmd] [-D name[=def]] [-I path] [-L path] [-o output] [-p pid] [-s script] [-U name] [-x opt[=val]] [-X a|c|s|t] [-P provider [[ predicate ] action ]] [-m [ provider: ] module [[ predicate ] action ]] [-f [[ provider: ] module: ] func [[ predicate ] action ]] [-n [[[ provider: ] module: ] func: ] name [[ predicate ] action ]] [-i probe-id [[ predicate ] action ]] [ args ... ] ... ``` which breaks the build. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:124359] [Ruby Misc#21804] Getting setup-ruby Earlier
by koic (Koichi ITO) 03 Feb '26

03 Feb '26

Issue #21804 has been reported by koic (Koichi ITO). ---------------------------------------- Misc #21804: Getting setup-ruby Earlier https://bugs.ruby-lang.org/issues/21804 * Author: koic (Koichi ITO) * Status: Open ---------------------------------------- ruby/setup-ruby is commonly used for development in OSS projects and real-world Rails applications. https://github.com/ruby/setup-ruby This is not specific to Ruby 4.0.0. There is often a delay between a Ruby release and the availability of the corresponding version in setup-ruby. setup-ruby is maintained by the ruby organization and may take a few days to become available after a Ruby release. In contrast, ruby-build is maintained by the rbenv organization and tends to become available shortly after a Ruby release. This makes it easier to start using new Ruby versions immediately. If setup-ruby maintained by the ruby organization were released shortly after a Ruby release, users could start using new Ruby versions sooner. It is difficult to determine whether this issue should be registered on bugs.ruby-lang.org. Since setup-ruby is maintained by the ruby organization, this issue is being opened to raise awareness of the situation. If this is not appropriate, please feel free to close it. Thank you for your continued maintenance and for releasing Ruby. -- https://bugs.ruby-lang.org/

9 17

[ruby-core:123681] [Ruby Bug#21669] Thoroughly implement void value expression check
by mame (Yusuke Endoh) 03 Feb '26

03 Feb '26

Issue #21669 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #21669: Thoroughly implement void value expression check https://bugs.ruby-lang.org/issues/21669 * Author: mame (Yusuke Endoh) * Status: Open * Assignee: prism * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- A void-value-expression check is a syntax check that raises a `SyntaxError` if an expression that cannot grammatically return a value (a "void value expression," such as a `return` expression) appears in a context where a value is expected (e.g., the right-hand side of an assignment, the argument of a method call, etc.). A typical example rejected by this check is `x = return`. However, it has become clear that this check is incomplete. This ticket summarizes the results of a discussion with @matz at the hackathon before RubyWorld Conference today. ## 1\. Expressions containing branches @matz said that an expression containing branches should be considered a void value expression only if it can be grammatically determined that all possible branches do not return a value. Based on this, both parse.y and prism currently reject the following code with a "void value expression" `SyntaxError`, but it should be accepted: ```ruby x = begin raise return rescue "OK" else return end # Expected: Code parses and executes successfully. # Actual: Rejected with "unexpected void value expression" SyntaxError. ``` Reason: The `rescue` clause can return a value ("OK"), so the entire `begin` expression is not void. Conversely, the following code is currently accepted by both parse.y and prism, but it should be rejected: ```ruby x = begin foo rescue return else return end # Expected: Rejected with SyntaxError. # Actual: Code parses and executes. ``` Reason: This expression always does `return`, so it is void whether `foo` raises an exception or not. Furthermore, `case` expressions must also be rejected similarly when all branches are void: ```ruby x = case when 1; return when 2; return else return end # Expected: Rejected with SyntaxError. # Actual: Code parses and executes. ``` Note that `if` expressions appear to be implemented correctly as intended: ```ruby x = if rand < 0.5 return else return end # Expected: Rejected with SyntaxError. # Actual: Rejected. (OK!) ``` ## 2\. Statement lists containing a void value expression @matz also said that if a statements node contains a void value expression, the entire statement list should be treated as a void value expression, even if the void expression is not the last one. Therefore, the following code is currently accepted but should be rejected: ```ruby x = begin return "NG" end # Expected: Rejected with SyntaxError. # Actual: Code parses and executes. ``` The same applies to branches within other expressions: ```ruby x = if rand < 0.5 return "NG" else return end # Expected: Rejected with SyntaxError. # Actual: Code parses and executes. ``` Note that if a return statement is inside a branch, that statement cannot be considered a void value expression, so the entire expression also cannot be a void value expression. ```ruby x = begin return if true "NG" end # Expected: Code parses and executes. # Actual: Code parses and executes as expected. (OK!) ``` --- This is considered a bug, but if it causes practical compatibility issues, it may be necessary to plan a migration path or revisit the specifications. (Both prism and parse.y need to be fixed, but I'll assign it to the prism team for now.) -- https://bugs.ruby-lang.org/

6 15

[ruby-core:124638] [Ruby Bug#21854] ruby-prof breaks on 4.0.1
by cfis (Charlie Savage) 31 Jan '26

31 Jan '26

Issue #21854 has been reported by cfis (Charlie Savage). ---------------------------------------- Bug #21854: ruby-prof breaks on 4.0.1 https://bugs.ruby-lang.org/issues/21854 * Author: cfis (Charlie Savage) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [x64-mswin64_140] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ruby-prof breaks on 4.0.1 with segmentation faults when measuring memory. See: https://github.com/ruby-prof/ruby-prof/actions/runs/21465420365/job/6182646… (note failures for ruby 3.x are some test that fail, not segementation faults). Tracking this down, one test that fails measure memory (see traceback below). That way that works: * Get a tracearg event (https://github.com/ruby-prof/ruby-prof/blob/master/ext/ruby_prof/rp_profile…) * Get a measurement - time, memory, etc. - https://github.com/ruby-prof/ruby-prof/blob/master/ext/ruby_prof/rp_measure… * Get the tracearg object - https://github.com/ruby-prof/ruby-prof/blob/master/ext/ruby_prof/rp_measure… * Call rb_obj_memsize_of - https://github.com/ruby-prof/ruby-prof/blob/master/ext/ruby_prof/rp_measure… * For a T_DATA object in gc.c > case T_DATA: > size += rb_objspace_data_type_memsize(obj); > break; > Then segmentation fault. Running in debugger: ``` RTYPEDDATA_TYPE(obj) 0x332d747365676964 {wrap_struct_name=??? function={dmark=??? dfree=??? dsize=??? ...} parent=??? ...} wrap_struct_name: <Unable to read memory> function: {dmark=??? dfree=??? dsize=??? ...} parent: <Unable to read memory> data: <Unable to read memory> flags: <Unable to read memory> ``` It sure seems like the object that was provide by tracearg has been garbage collected and is no longer valid. Here is the traceback. This is from a MSVC build, but you can see in the gitlab pipelines the same happens on Ubuntu. ```bash -- C level backtrace information ------------------------------------------- C:\WINDOWS\SYSTEM32\ntdll.dll(NtWaitForSingleObject+0x14) [0x00007FF817DA1C44] C:\WINDOWS\System32\KERNELBASE.dll(WaitForSingleObjectEx+0xaf) [0x00007FF814F2BC5F] C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_print_backtrace+0x3e) [0x00007FFEEBB01F92] C:\Source\ruby-4.0.1-mswin\vm_dump.c:1129 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_vm_bugreport+0x223) [0x00007FFEEBB021BB] C:\Source\ruby-4.0.1-mswin\vm_dump.c:1453 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_bug_for_fatal_signal+0x75) [0x00007FFEEB9BE779] C:\Source\ruby-4.0.1-mswin\error.c:1131 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(sigsegv+0x3d) [0x00007FFEEBAFAF91] C:\Source\ruby-4.0.1-mswin\signal.c:948 C:\WINDOWS\System32\ucrtbase.dll(seh_filter_exe+0x84) [0x00007FF81591E8A4] C:\msys64\usr\local\ruby-4.0.1-mswin\bin\ruby.exe(`__scrt_common_main_seh'::`1'::filt$0+0x16) [0x00007FF7B95D1B4C] D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:304 C:\WINDOWS\SYSTEM32\VCRUNTIME140.dll(_C_specific_handler+0x9d) [0x00007FFFF400F55D] C:\WINDOWS\SYSTEM32\ntdll.dll(_chkstk+0x9f) [0x00007FF817DA62FF] C:\WINDOWS\SYSTEM32\ntdll.dll(RtlLocateExtendedFeature+0x597) [0x00007FF817C52327] C:\WINDOWS\SYSTEM32\ntdll.dll(KiUserExceptionDispatcher+0x2e) [0x00007FF817DA5C3E] C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_obj_memsize_of+0x1dc) [0x00007FFEEB9A2C8C] C:\Source\ruby-4.0.1-mswin\gc.c:2351 C:\Source\ruby-prof\ext\ruby_prof\ruby_prof.so(measure_memory+0x51) [0x00007FFFA8427161] C:\Source\ruby-prof\ext\ruby_prof\rp_measure_memory.c:23 C:\Source\ruby-prof\ext\ruby_prof\ruby_prof.so(prof_measure+0x1a) [0x00007FFFA8425D8A] C:\Source\ruby-prof\ext\ruby_prof\rp_measurement.c:38 C:\Source\ruby-prof\ext\ruby_prof\ruby_prof.so(prof_event_hook+0x43) [0x00007FFFA842AC23] C:\Source\ruby-prof\ext\ruby_prof\rp_profile.c:200 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(tp_call_trace+0x26) [0x00007FFEEBA41E12] C:\Source\ruby-4.0.1-mswin\vm_trace.c:1300 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(exec_hooks_body+0x74) [0x00007FFEEBA3FCA4] C:\Source\ruby-4.0.1-mswin\vm_trace.c:457 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_exec_event_hooks+0x4a) [0x00007FFEEBA40326] C:\Source\ruby-4.0.1-mswin\vm_trace.c:543 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_gc_event_hook+0xc1) [0x00007FFEEB99DE35] C:\Source\ruby-4.0.1-mswin\gc.c:241 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(newobj_of+0x17c) [0x00007FFEEB99C348] C:\Source\ruby-4.0.1-mswin\gc.c:1014 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(typed_data_alloc+0xb6) [0x00007FFEEB9A565A] C:\Source\ruby-4.0.1-mswin\gc.c:1102 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_data_typed_object_zalloc+0x3b) [0x00007FFEEB99D877] C:\Source\ruby-4.0.1-mswin\gc.c:1125 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_managed_id_table_create+0x21) [0x00007FFEEBA2AF2D] C:\Source\ruby-4.0.1-mswin\id_table.c:375 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(callable_method_entry_or_negative+0x299) [0x00007FFEEB9C434D] C:\Source\ruby-4.0.1-mswin\vm_method.c:1918 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(callable_method_entry+0x9) [0x00007FFEEB9C4081] C:\Source\ruby-4.0.1-mswin\vm_method.c:1937 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_populate_cc+0x2a) [0x00007FFEEB9E1CF2] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:2155 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_vm_search_method_slowpath+0x7d) [0x00007FFEEB9D0D21] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:2299 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_search_method_slowpath0+0x20) [0x00007FFEEB9E261C] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:2321 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_sendish+0x14e) [0x00007FFEEB9E2B2E] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:6123 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_exec_core+0x1f41) [0x00007FFEEB9DCA85] C:\Source\ruby-4.0.1-mswin\vm_exec.c:101 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_vm_exec+0x101) [0x00007FFEEB9CF7C9] C:\Source\ruby-4.0.1-mswin\vm.c:2801 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(invoke_block_from_c_bh+0x2eb) [0x00007FFEEB9C688B] C:\Source\ruby-4.0.1-mswin\vm.c:1834 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_yield_with_cref+0x93) [0x00007FFEEB9E41BF] C:\Source\ruby-4.0.1-mswin\vm.c:1874 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_yield+0x55) [0x00007FFEEB9D1125] C:\Source\ruby-4.0.1-mswin\vm_eval.c:1380 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_protect+0x14a) [0x00007FFEEB9B8DFA] C:\Source\ruby-4.0.1-mswin\eval.c:1127 C:\Source\ruby-prof\ext\ruby_prof\ruby_prof.so(prof_profile_instance+0x58) [0x00007FFFA842C128] C:\Source\ruby-prof\ext\ruby_prof\rp_profile.c:820 C:\Source\ruby-prof\ext\ruby_prof\ruby_prof.so(prof_profile_class+0x2f) [0x00007FFFA842C19F] C:\Source\ruby-prof\ext\ruby_prof\rp_profile.c:845 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc_with_frame_+0x14a) [0x00007FFEEB9D52DA] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:3904 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc_with_frame+0x29) [0x00007FFEEB9D5189] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:3949 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc_other+0xbc) [0x00007FFEEB9D5154] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:3976 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc+0x103) [0x00007FFEEB9D4E67] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:4057 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_method_each_type+0x67b) [0x00007FFEEB9D7503] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:4888 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_method+0x14c) [0x00007FFEEB9D6E68] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:5052 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_sendish+0x163) [0x00007FFEEB9E2B43] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:6134 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_exec_core+0x1f41) [0x00007FFEEB9DCA85] C:\Source\ruby-4.0.1-mswin\vm_exec.c:101 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_vm_exec+0x101) [0x00007FFEEB9CF7C9] C:\Source\ruby-4.0.1-mswin\vm.c:2801 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(invoke_block_from_c_bh+0x2eb) [0x00007FFEEB9C688B] C:\Source\ruby-4.0.1-mswin\vm.c:1834 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_yield_with_cref+0x93) [0x00007FFEEB9E41BF] C:\Source\ruby-4.0.1-mswin\vm.c:1874 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_yield+0x55) [0x00007FFEEB9D1125] C:\Source\ruby-4.0.1-mswin\vm_eval.c:1380 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_ary_each+0x7f) [0x00007FFEEBA1A083] C:\Source\ruby-4.0.1-mswin\array.c:2754 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc_with_frame_+0x14a) [0x00007FFEEB9D52DA] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:3904 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc_with_frame+0x29) [0x00007FFEEB9D5189] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:3949 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_sendish+0x163) [0x00007FFEEB9E2B43] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:6134 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_exec_core+0x1f41) [0x00007FFEEB9DCA85] C:\Source\ruby-4.0.1-mswin\vm_exec.c:101 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_vm_exec+0x101) [0x00007FFEEB9CF7C9] C:\Source\ruby-4.0.1-mswin\vm.c:2801 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(invoke_block_from_c_bh+0x2eb) [0x00007FFEEB9C688B] C:\Source\ruby-4.0.1-mswin\vm.c:1834 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_yield_with_cref+0x93) [0x00007FFEEB9E41BF] C:\Source\ruby-4.0.1-mswin\vm.c:1874 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_yield+0x55) [0x00007FFEEB9D1125] C:\Source\ruby-4.0.1-mswin\vm_eval.c:1380 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_ary_collect+0xa4) [0x00007FFEEBA18F38] C:\Source\ruby-4.0.1-mswin\array.c:3767 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc_with_frame_+0x14a) [0x00007FFEEB9D52DA] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:3904 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc_with_frame+0x29) [0x00007FFEEB9D5189] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:3949 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_sendish+0x163) [0x00007FFEEB9E2B43] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:6134 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_exec_core+0x1f41) [0x00007FFEEB9DCA85] C:\Source\ruby-4.0.1-mswin\vm_exec.c:101 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_vm_exec+0x101) [0x00007FFEEB9CF7C9] C:\Source\ruby-4.0.1-mswin\vm.c:2801 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_invoke_proc+0x304) [0x00007FFEEB9DF6D8] C:\Source\ruby-4.0.1-mswin\vm.c:1944 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_vm_invoke_proc+0x95) [0x00007FFEEB9CFCE9] C:\Source\ruby-4.0.1-mswin\vm.c:1967 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_proc_call_kw+0x70) [0x00007FFEEBAADD6C] C:\Source\ruby-4.0.1-mswin\proc.c:1134 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(exec_end_procs_chain+0x3d) [0x00007FFEEB9B5B4D] C:\Source\ruby-4.0.1-mswin\eval_jump.c:106 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_ec_exec_end_proc+0x13b) [0x00007FFEEB9B73AF] C:\Source\ruby-4.0.1-mswin\eval_jump.c:122 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_ec_teardown+0x11e) [0x00007FFEEB9B789A] C:\Source\ruby-4.0.1-mswin\eval.c:158 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_ec_cleanup+0x260) [0x00007FFEEB9B6C68] C:\Source\ruby-4.0.1-mswin\eval.c:211 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(ruby_run_node+0x4d) [0x00007FFEEB9B998D] C:\Source\ruby-4.0.1-mswin\eval.c:321 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\ruby.exe(wmain+0x52) [0x00007FF7B95D1052] C:\Source\ruby-4.0.1-mswin\main.c:48 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\ruby.exe(__scrt_common_main_seh+0x10c) [0x00007FF7B95D126C] D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288 C:\WINDOWS\System32\KERNEL32.DLL(BaseThreadInitThunk+0x17) [0x00007FF816AEE8D7] ``` -- https://bugs.ruby-lang.org/

2 5

[ruby-core:124563] [Ruby Bug#21840] Locking a mutex can lead to starvation
by luke-gru (Luke Gruber) 29 Jan '26

29 Jan '26

Issue #21840 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #21840: Locking a mutex can lead to starvation https://bugs.ruby-lang.org/issues/21840 * Author: luke-gru (Luke Gruber) * Status: Open * Assignee: luke-gru (Luke Gruber) * Target version: 4.0 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Continually locking a mutex `m` can lead to starvation if all other threads are on the waitq of `m`. Let `T` be the thread that keeps on acquiring mutex `m` in a loop. Iteration 1: 1) `T` locks mutex `m` 2) All other threads attempt to acquire `m` and end up on its waitq 3) `T` releases the GVL, doesn't wake any other threads because they're all waiting on `m` 4) `T` returns from the blocking function, resets its `running_time` to 0, acquires the GVL and continues running 5) `T` unlocks `m`. It adds the head of the waitq (`T2`) to the thread readyq. `T` continues running Iteration 2: 1) `T` locks mutex `m` 2) `T` calls a blocking function. This time, it dequeues the readyq (ex: `T2`) and sends it the wakeup signal. `T` runs its blocking function 3) `T2` wakes up, acquires the GVL and attempts to lock mutex `m`. It fails and goes back asleep, putting itself back on the waitq of `m`. 4) `T` returns from the blocking function, sets its `running_time` back to 0, acquires the GVL and keeps running 5) `T` unlocks `m`. It adds the head of the waitq (ex: `T3`) to the end of the thread readyq. `T` continues running. Repeat Iteration 2 except the head of readyq is now `T3` The problem is that `T` can never be pre-empted. Example script: ```ruby m = Mutex.new def fib(n) return n if n <= 1 fib(n - 1) + fib(n - 2) end t1_running = false t1 = Thread.new do t1_running = true loop do fib(20) m.synchronize do $stderr.puts "t1 iter" end end end loop until t1_running 5.times.map do Thread.new do m.synchronize do end end end.each(&:join) ``` -- https://bugs.ruby-lang.org/

2 2