May 2026 - ruby-core - ml.ruby-lang.org

[ruby-core:125534] [Ruby Bug#22073] Ruby 3.4.9 segfaults when loading native default gems compiled on Ubuntu 26.04 (GCC 15.2); Ruby 4.0.3 unaffected on same system
by taq (Eustaquio Rangel) 19 May '26

19 May '26

Issue #22073 has been reported by taq (Eustaquio Rangel). ---------------------------------------- Bug #22073: Ruby 3.4.9 segfaults when loading native default gems compiled on Ubuntu 26.04 (GCC 15.2); Ruby 4.0.3 unaffected on same system https://bugs.ruby-lang.org/issues/22073 * Author: taq (Eustaquio Rangel) * Status: Open * ruby -v: 3.4.9 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hello, I'm reporting a reproducible issue on Ruby 3.4.9 on a freshly upgraded Ubuntu 26.04 LTS. Please let me know if you'd prefer this as a comment on #21655 instead. On Ubuntu 26.04 LTS, Ruby 3.4.9 produces unusable binaries when compiling current versions of native default gems (prism, cgi, date, io-console, rbs, and likely others). The versions of these gems that ship with the Ruby tarball work fine, but as soon as bundle install (or any gem install) compiles a newer version of them in the local environment, loading those gems segfaults or bus-errors immediately. Ruby 4.0.3 on the same machine, same toolchain, same Ubuntu installation does not exhibit this problem. My environment: OS: Ubuntu 26.04 LTS (Resolute Raccoon), upgraded today Kernel: 7.0.0-15-generic glibc: ldd (Ubuntu GLIBC 2.43-2ubuntu2) 2.43 System GCC: gcc (Ubuntu 15.2.0-16ubuntu1) 15.2.0 (default is GCC 15.2 on this release; GCC 14 also tested via apt install gcc-14) Ruby: ruby 3.4.9 (2026-03-11 revision 76cca827ab) +YJIT +PRISM [x86_64-linux] Reproduced with both RVM and rbenv (independent installations) 1. Install Ruby 3.4.9 on Ubuntu 26.04. irb works. 2. gem install bundler && bundle install in any project with a non-trivial Gemfile (e.g. Rails 8). Among other things, this installs newer versions of default gems: prism 1.9.0, cgi 0.5.1, date 3.5.1, io-console 0.8.2, etc. 3. Run irb (or any Ruby that loads one of those gems). Segfault or bus error on loading the native .so. The crashing extension varies depending on load order, but I've reproduced it in prism.so, cgi/escape.so, date_core.so, io/console.so, and rbs_extension.so. Removing the newer gem from the gemset (e.g. rm -rf ~/.rvm/gems/ruby-3.4.9/gems/prism-1.9.0) causes Ruby to fall back to the older version that ships with the Ruby tarball (prism 1.5.2), which works — until the next crash on another default gem. Ruby 4.0.3 installed via the same RVM, on the same Ubuntu 26.04 system, runs a non-trivial Rails 8 application with bundle install and bundle exec working without any crashes. This suggests the fix (or whatever change avoids the issue) is on master/4.0 and was not backported to the 3.4 branch. Workarounds attempted (none successful): 1. rvm get stable to install all current Ruby build dependencies (including libncurses5-dev which was initially missing). Ruby itself rebuilt; gems still crash. 2. Rebuilding Ruby with CFLAGS="-fno-ipa-modref" per #21655. RbConfig::CONFIG["CFLAGS"] confirms the flag is in the build. Gems still crash. (Note: I have not verified whether the flag is propagated to the gem build via mkmf.) 3. Rebuilding Ruby with CC=gcc-14 CXX=g++-14 (GCC 14 is available in default 26.04 repositories). Gems still crash. 4. Reinstalling Ruby 3.4.9 via rbenv (independent of RVM) and reproducing from scratch. Same crash. Happy to provide additional information — debug build, full gdb backtrace, build logs, etc. Just let me know what would be most useful. Thank you. -- https://bugs.ruby-lang.org/

3 7

[ruby-core:125441] [Ruby Feature#22060] Improve Pathname by migrating internal methods to pathname.c
by nobu (Nobuyoshi Nakada) 17 May '26

17 May '26

Issue #22060 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #22060: Improve Pathname by migrating internal methods to pathname.c https://bugs.ruby-lang.org/issues/22060 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- Currently, Pathname implementation is mainly in pathname_builtin.rb and only a few methods in pathname.c. The code in pathname_builtin.rb is using `File` methods probably for platform portabilities. This is kind of smart but is a roundabout way and is hard to understand. I think it can be easier to maintain and more efficient by migrating some internal methods to pathname.c. Comparison with master 9fefb48643: | |master w/o JIT|PR w/o JIT|master w/ JIT|PR w/ JIT| |:-------------------|-------------:|---------:|------------:|--------:| |p1+p2 | 332.541k| 696.202k| 347.315k| 952.254k| | | -| 2.09x| 1.04x| 2.86x| |abs.root? | 3.282M| 97.180M| 3.504M| 82.821M| | | -| 29.61x| 1.07x| 25.23x| |rel.root? | 3.298M| 101.917M| 3.535M| 96.676M| | | -| 30.91x| 1.07x| 29.32x| |abs.absolute? | 22.184M| 110.749M| 31.099M| 129.464M| | | -| 4.99x| 1.40x| 5.84x| |rel.absolute? | 30.862M| 111.914M| 47.010M| 118.712M| | | -| 3.63x| 1.52x| 3.85x| |p1.cleanpath | 395.604k| 904.909k| 418.752k| 1.342M| | | -| 2.29x| 1.06x| 3.39x| |p2.cleanpath | 445.949k| 982.354k| 468.972k| 1.451M| | | -| 2.20x| 1.05x| 3.25x| |relative_path_from | 137.595k| 271.209k| 144.976k| 393.710k| | | -| 1.97x| 1.05x| 2.86x| Although YJIT is not effective on `Pathname#root?`, probably it is too simple for JIT. [GH-16907](https://github.com/ruby/ruby/pull/16907) -- https://bugs.ruby-lang.org/

2 2

[ruby-core:125531] [Ruby Feature#18959] Handle gracefully nil kwargs eg. **nil
by Earlopain (Earlopain _) 16 May '26

16 May '26

Issue #18959 has been updated by Earlopain (Earlopain _). Status changed from Open to Closed I believe this can be closed now that https://bugs.ruby-lang.org/issues/20064 was implemented ---------------------------------------- Feature #18959: Handle gracefully nil kwargs eg. **nil https://bugs.ruby-lang.org/issues/18959#change-117354 * Author: LevLukomskyi (Lev Lukomskyi) * Status: Closed ---------------------------------------- The issue: ```ruby def qwe(a: 1) end qwe(**nil) #=> fails with `no implicit conversion of nil into Hash (TypeError)` error { a:1, **nil } #=> fails with `no implicit conversion of nil into Hash (TypeError)` error ``` Reasoning: I found myself that I often want to insert a key/value to hash if a certain condition is met, and it's very convenient to do this inside hash syntax, eg.: ```ruby { some: 'value', **({ id: id } if id.present?), } ``` Such syntax is much more readable than: ```ruby h = { some: 'value' } h[:id] = id if id.present? h ``` Yes, it's possible to write like this: ```ruby { some: 'value', **(id.present? ? { id: id } : {}), } ``` but it adds unnecessary boilerplate noise. I enjoy writing something like this in ruby on rails: ```ruby content_tag :div, class: [*('is-hero' if hero), *('is-search-page' if search_page)].presence ``` If no conditions are met then the array is empty, then converted to nil by `presence`, and `class` attribute is not rendered if it's nil. It's short and so convenient! There should be a similar way for hashes! I found this issue here: https://bugs.ruby-lang.org/issues/8507 where "consistency" thing is discussed. While consistency is the right thing to do, I think the main point here is to have fun with programming, and being able to write stuff in a concise and readable way. Please, add this small feature to the language, that'd be so wonderful! 🙏 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125511] [Ruby Bug#22071] super in method in module that is refined results in NoMethodError
by jeremyevans0 (Jeremy Evans) 16 May '26

16 May '26

Issue #22071 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #22071: super in method in module that is refined results in NoMethodError https://bugs.ruby-lang.org/issues/22071 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * ruby -v: ruby 4.1.0dev (2026-05-03T23:57:21Z master d8d2ed5dc9) +PRISM [x86_64-openbsd7.9] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- We currently support refinements of modules, even though doc/syntax/refinements.rdoc and https://github.com/ruby/ruby/wiki/Refinements-Spec imply that we would not respect refinements of included or prepended modules and would only respect refinements of classes and superclasses. If you refine a module, and have the refined method definition call `super` and the method in the refined module call `super`, and that refined method is found first during method lookup, the `super` call in the method in the refined module results in a `NoMethodError`. Example: ```ruby module F def a; "F" + super end end class A def a; "A" end end class B < A include F end p B.new.a module R refine F do def a; "R" + super end end end using R p B.new.a ``` Output: ``` "FA" t.rb:2:in 'F#a': super: no superclass method 'a' for an instance of B (NoMethodError) from t.rb:17:in 'a' from t.rb:22:in '<main>' ``` Two things to note: * Before the refinement is activated, things work as expected, returning "FA". * After the refinement is activated, the `NoMethodError` is raised not in the refinement method `super` (line 17), but in the `super` in the method in the module that is refined (line 2). What should be the expected behavior here? I can think of two possibilities: * Per the documentation, we should not consider refinements of included/prepended modules. So in this example, we should print "FA" and ignore the refinement instead of raising the `NoMethodError`. In this case, it would be best to raise during the `refine F` call, and prohibit the refining of modules completely. This would break backwards compatibility, though I'm not sure how much real world code uses refinements of modules. * Fix `super` when the refinement is activated to use the correct method lookup and return "RFA" instead of raising the `NoMethodError`. Also fix the documentation to describe how refinements of included/prepended modules work during method lookup. -- https://bugs.ruby-lang.org/

2 4

[ruby-core:124286] [Ruby Bug#21789] `IO#flush` doesn't invoke fiber scheduler io_write hook
by noteflakes (Sharon Rosner) 15 May '26

15 May '26

Issue #21789 has been reported by noteflakes (Sharon Rosner). ---------------------------------------- Bug #21789: `IO#flush` doesn't invoke fiber scheduler io_write hook https://bugs.ruby-lang.org/issues/21789 * Author: noteflakes (Sharon Rosner) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When calling `IO#flush` or closing an IO with unflushed writes, the flushing is done by calling `rb_io_blocking_region_wait` and eventually doing a `write` system call. When done in a non-blocking fiber with an active fiber scheduler, this will invoke the `#blocking_operation_wait` fiber scheduler hook, which will run the system call in a worker thread, and therefore the flushing bypasses the async I/O capabilities of the fiber scheduler. The proposed fix is to test for the presence of a fiber scheduler in `io_flush_buffer_async` and invoke the `#io_write` fiber scheduler hook with the unflushed part of the IO's write buffer. Associated PR here: https://github.com/ruby/ruby/pull/15609 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125497] [Ruby Bug#22070] `Thread.each_caller_location(1, 1)` segfaults when called from a cfunc
by AMomchilov (Alexander Momchilov) 15 May '26

15 May '26

Issue #22070 has been reported by AMomchilov (Alexander Momchilov). ---------------------------------------- Bug #22070: `Thread.each_caller_location(1, 1)` segfaults when called from a cfunc https://bugs.ruby-lang.org/issues/22070 * Author: AMomchilov (Alexander Momchilov) * Status: Open * ruby -v: ruby 4.0.2 (2026-03-17 revision d3da9fec82) +PRISM [arm64-darwin24] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Reading the `label` of a `Thread::Backtrace::Location` (directly or indirectly via e.g. `to_s`) segfauls if called from within `Thread.each_caller_location(1, 1) { it.label }`. Reading the `lineno` or `path` seems to not cause any problems, perhaps by coincidence. ## Minimal repro ```sh ruby -e 'tap { Thread.each_caller_location(1, 1) { it.label } }' # 🧨 Boom ``` ## More cases <details><summary><code>repro.rb</code></summary> ```ruby # All four conditions must hold; varying any one makes the crash go away: # # 1. The yielded location is inspected via a `cme`-reading method # (`label`, `base_label`, `to_s`, `inspect`). # * The `iseq`-based methods (`path`, `absolute_path`, `lineno`) seem to survive by accident. # 2. `start` is exactly 1. # 3. `length` is exactly 1. # * Ranges that compute to length=1 (`1..1`, `1...2`) crash # * e.g. `1..3` (length=3) does not. # 4. The caller is inside a C-method frame (`tap`, `Array#each`, `instance_exec`, `eval`, ...). # * Top-level and plain Ruby methods are safe. $ruby = begin require "rbconfig" RbConfig.ruby rescue LoadError ENV["_"] || "ruby" end def check(label, code) out = IO.popen([$ruby, "-e", code, err: [:child, :out]], &:read) crashed = !$?.success? || out.include?("[BUG]") printf " %-7s %s\n", (crashed ? "CRASH" : "OK"), label end puts "== Which Location method is accessed (start=1, length=1, from tap{}) ==" check("it.path", "tap { Thread.each_caller_location(1, 1) { it.path } }") check("it.absolute_path", "tap { Thread.each_caller_location(1, 1) { it.absolute_path } }") check("it.lineno", "tap { Thread.each_caller_location(1, 1) { it.lineno } }") check("it.label", "tap { Thread.each_caller_location(1, 1) { it.label } }") check("it.base_label", "tap { Thread.each_caller_location(1, 1) { it.base_label } }") check("it.to_s", "tap { Thread.each_caller_location(1, 1) { it.to_s } }") check("it.inspect", "tap { Thread.each_caller_location(1, 1) { it.inspect } }") puts "== Vary `start` (length=1, .label, from tap{}) ==" check("start=0", "tap { Thread.each_caller_location(0, 1) { it.label } }") check("start=1", "tap { Thread.each_caller_location(1, 1) { it.label } }") check("start=2", "tap { Thread.each_caller_location(2, 1) { it.label } }") check("start=3", "tap { Thread.each_caller_location(3, 1) { it.label } }") puts "== Vary `length` (start=1, .label, from tap{}) ==" check("length=1", "tap { Thread.each_caller_location(1, 1) { it.label } }") check("length=2", "tap { Thread.each_caller_location(1, 2) { it.label } }") check("length=3", "tap { Thread.each_caller_location(1, 3) { it.label } }") check("length=4", "tap { Thread.each_caller_location(1, 4) { it.label } }") puts "== Range forms equivalent to (start=1, length=1) ==" check("(1, 1)", "tap { Thread.each_caller_location(1, 1) { it.label } }") check("(1..1)", "tap { Thread.each_caller_location(1..1) { it.label } }") check("(1...2)", "tap { Thread.each_caller_location(1...2) { it.label } }") check("(1..2)", "tap { Thread.each_caller_location(1..2) { it.label } }") puts "== Caller context (start=1, length=1, .label) ==" check("top-level", 'Thread.each_caller_location(1, 1) { it.label }') check("tap { ... }", 'tap { Thread.each_caller_location(1, 1) { it.label } }') check("[1].each { ... }", '[1].each { Thread.each_caller_location(1, 1) { it.label } }') check("instance_exec", 'instance_exec { Thread.each_caller_location(1, 1) { it.label } }') check("eval '...'", %{eval 'Thread.each_caller_location(1, 1) { it.label }'}) check("def m; ...; end; m", 'def m; Thread.each_caller_location(1, 1) { it.label }; end; m') check("tap { m }", 'def m; Thread.each_caller_location(1, 1) { it.label }; end; tap { m }') puts puts "Ruby: #{RUBY_DESCRIPTION}" ``` </details> -- https://bugs.ruby-lang.org/

5 6

[ruby-core:125492] [Ruby Bug#22069] Backport openssl 3.2.4/3.3.3/4.0.2
by rhenium (Kazuki Yamaguchi) 15 May '26

15 May '26

Issue #22069 has been reported by rhenium (Kazuki Yamaguchi). ---------------------------------------- Bug #22069: Backport openssl 3.2.4/3.3.3/4.0.2 https://bugs.ruby-lang.org/issues/22069 * Author: rhenium (Kazuki Yamaguchi) * Status: Closed * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- The main change is OpenSSL 4.0 support. OpenSSL 4.0 was released on 2026-04-14 with several incompatible changes, and the default gems currently included in Ruby 3.3.11/3.4.9/4.0.4 do not compile against it. Although this can be considered more of a feature rather than a bug fix, I believe this would still be useful to backport. Branch maintainers, what do you think? I've created GitHub PRs for each stable branch: - ruby_3_3 (v3.2.2 -> v3.2.4) https://github.com/ruby/ruby/pull/16945 - ruby_3_4 (v3.3.1 -> v3.3.3) https://github.com/ruby/ruby/pull/16946 - ruby_4_0 (v4.0.0 -> v4.0.2) https://github.com/ruby/ruby/pull/16947 -- https://bugs.ruby-lang.org/

5 4

[ruby-core:125491] [Ruby Feature#22068] Adding post-quantum cryptography (PQC) support across Ruby standard libraries
by jaruga (Jun Aruga) 15 May '26

15 May '26

Issue #22068 has been reported by jaruga (Jun Aruga). ---------------------------------------- Feature #22068: Adding post-quantum cryptography (PQC) support across Ruby standard libraries https://bugs.ruby-lang.org/issues/22068 * Author: jaruga (Jun Aruga) * Status: Open ---------------------------------------- ## Summary and motivation Post-quantum cryptography (PQC) means cryptography algorithm which people can safely use after (post) quantum computing is practically used in the future. By using the quantum computing which is much more powerful than the current computing, it can be possible to crack the current non-PQC algorithms. The goal of this ticket is to make Ruby (including libraries: default gems + bundle gems) work in the environment where only post-quantum cryptography (PQC)-supported algorithms are enabled, and other cryptography algorithms such as RSA are disabled. PQC-supported algorithms are only ML-DSA, ML-KEM and SLH-DSA for now. ML-DSA is used for signature (certification), and ML-KEM is used for connection. As I heard from my colleagues working for OpenSSL, that SLH-DSA is not ready to be used, we can ignore SLH-DSA for now. Ruby OpenSSL (ruby/openssl) already supports PQC by the ticket [ruby/openssl#894][ruby-openssl-pqc-issue]. And there are some works are needed for other standard libraries using Ruby OpenSSL in Ruby to support PQC. I cite the following text from the [NIST][nist-wikipedia]'s [PQC document][nist-pqc]. NIST is an organization deciding cryptography specifications in my understanding. > Some engineers even predict that within the next twenty or so years sufficiently large quantum computers will be built to break essentially all public key schemes currently in use. Historically, it has taken almost two decades to deploy our modern public key cryptography infrastructure. Therefore, regardless of whether we can estimate the exact time of the arrival of the quantum computing era, we must begin now to prepare our information security systems to be able to resist quantum computing. I also cite the following text from DigiCert, a security company's blog. ([link][digicert-blog-google-mtc]) > Gartner predicts that by 2029, conventional asymmetric cryptography like RSA and ECC will be unsafe for protecting sensitive data due to “harvest-now, decrypt-later" threats—even before a quantum break occurs. So, it's better to prepare PQC support now. As an example of the actual movement European Commission is trying to migrate from non-PQC to PQC.([link][ec-pqc]) ## Proof of concept I manage my proof-of-concept scripts on my [junaruga/ruby-pqc-test] repository. For now, there are only some scripts to test RubyGems and Bundler in PQC use cases. ## Tasks I checked ruby/ruby including default gems and bundled gems at the master branch commit `93f1010f70a3ac924c3b37e4ae82cf1a669fcbf0` which was the latest at that time. While ruby/ruby original code doesn't have PQC logic, the following libraries that have the own upstream project need to be modified to support PQC use cases in my investigation. And I am motivated to work on these tasks, adding the PQC features and/or tests. I will open the issue ticket for each upstream project ruby/* one by one. * [ruby/rubygems](https://github.com/ruby/rubygems) - Add PQC features * [ruby/rubygems bundler](https://github.com/ruby/rubygems/tree/master/bundler) - Add PQC features * [ruby/net-http](https://github.com/ruby/net-http) - default gem - Update code comments and add PQC tests * [ruby/open-uri](https://github.com/ruby/open-uri) - default gem - Add PQC tests * [ruby/spec](https://github.com/ruby/spec) - spec/ - Add PQC tests * [ruby/drb](https://github.com/ruby/drb): bundled gem - Add PQC features * [ruby/rbs](https://github.com/ruby/rbs): bundled gem - Not sure. There is `stdlib/openssl/0/openssl.rbs`. Note I used the following [ripgrep]'s `rg` command (an enhanced `grep` command) to check the affected files by PQC. ``` $ rg "require +['\"]openssl['\"]|OpenSSL" --type ruby ``` Please let me know what you think. [openssl-35-release]: https://openssl-library.org/post/2025-04-08-openssl-35-final-release/ [ruby-openssl-pqc-issue]: https://github.com/ruby/openssl/issues/894 [nist-wikipedia]: https://en.wikipedia.org/wiki/National_Institute_of_Standards_and_Technology [nist-pqc]: https://csrc.nist.gov/projects/post-quantum-cryptography [ec-pqc]: https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation… [digicert-blog-google-mtc]: https://www.digicert.com/blog/google-merkle-tree-certificates [junaruga/ruby-pqc-test]: https://github.com/junaruga/ruby-pqc-test [ripgrep]: https://github.com/BurntSushi/ripgrep -- https://bugs.ruby-lang.org/

2 3

[ruby-core:125430] [Ruby Bug#22059] make -j problem in dtrace build
by wiz (Thomas Klausner) 15 May '26

15 May '26

Issue #22059 has been reported by wiz (Thomas Klausner). ---------------------------------------- Bug #22059: make -j problem in dtrace build https://bugs.ruby-lang.org/issues/22059 * Author: wiz (Thomas Klausner) * Status: Open * ruby -v: 4.0.3 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- When building ruby 4.0.3 on NetBSD (from pkgsrc) in a parallel build (make -j16), I sometimes see build problems like this: ``` processing probes in object files dtrace: target object (probes.o) already exists. Please remove the target dtrace: object and rebuild all the source objects if you wish to run the DTrace dtrace: linking process again linking miniruby ld: probes.o: warning: relocation against `$dtrace1391839.rb_str_resurrect' in read-only section `.SUNW_dof' ld: array.o: in function `empty_ary_alloc': /tmp/lang/ruby40/work/ruby-4.0.3/array.c:716:(.text+0x14e0): undefined reference to `__dtraceenabled_ruby___array__create' ld: /tmp/lang/ruby40/work/ruby-4.0.3/array.c:716:(.text+0x1541): undefined reference to `__dtrace_ruby___array__create' ... ``` (longer log attached) I think the problem is (something like) this: In template/Makefile.in, probes.stamp is: ``` probes.stamp: $(DTRACE_REBUILD_OBJS) $(Q) if test -f $@ -o -f probes.$(OBJEXT); then \ $(RM) $(DTRACE_REBUILD_OBJS) $@; \ $(ECHO0) "rebuilding objects which were modified by \"dtrace -G\""; \ $(MAKE) $(DTRACE_REBUILD_OBJS); \ fi $(Q) touch $@ ``` where DTRACE_REBUILD_OBJS includes probes.o. So if probes.stamp (for example, because probes.o should be built when dtrace is enabled) is triggered, it _deletes_ probes.o and then runs make to generate it. At the same time, e.g. miniruby might be built in another make job. miniruby, in common.mk, depends on ``` miniruby$(EXEEXT): config.status $(NORMALMAINOBJ) $(MINIOBJS) $(COMMONOBJS) $(ARCHFILE) ``` COMMONOBJS, in the same file, includes $(DTRACE_OBJ), which is set to probes.o by configure: ``` build/Makefile:DTRACE_OBJ = probes.$(OBJEXT) ``` so this might also trigger a (re)build of probes.o, and in some cases this breaks the build. libruby also has a dependency chain that includes probes.o (it links OBJS which includes EXPORTOBJS which includes COMMONOBJS). ---Files-------------------------------- install.log (19.1 KB) -- https://bugs.ruby-lang.org/

1 1

[ruby-core:111146] [Ruby master Bug#19172] `ruby_thread_has_gvl_p` is innacurate sometimes -- document or change?
by ivoanjo (Ivo Anjo) 15 May '26

15 May '26

Issue #19172 has been reported by ivoanjo (Ivo Anjo). ---------------------------------------- Bug #19172: `ruby_thread_has_gvl_p` is innacurate sometimes -- document or change? https://bugs.ruby-lang.org/issues/19172 * Author: ivoanjo (Ivo Anjo) * Status: Open * Priority: Normal * ruby -v: (All Ruby versions) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Howdy 👋! I work for Datadog [on the ddtrace gem](https://github.com/DataDog/dd-trace-rb) and I found a... sharp edge on the internal `ruby_thread_has_gvl_p` API. I am aware that `ruby_thread_has_gvl_p` is documented an experimental API that is exported as a symbol but not present on the VM include files. ### Background In the ddtrace profiling component, we setup a signal handler and then periodically send SIGPROF signals to try to interrupt the running Ruby thread (e.g. the thread that is holding the global VM lock or equivalent). In the signal handler, we need to perform some API calls which are not safe to do without the GVL. So we need to check if the signal handler got called in the thread that has the GVL. ### The issue ```ruby int ruby_thread_has_gvl_p(void) { rb_thread_t *th = ruby_thread_from_native(); if (th && th->blocking_region_buffer == 0) { return 1; } else { return 0; } } ``` In its current implementation, `ruby_thread_has_gvl_p` only checks if the thread has a `blocking_region_buffer` or not. Unfortunately, this means that when called from a thread that lost the GVL but not due to blocking (e.g. via `rb_thread_schedule()`), it can still claim that a thread is holding the GVL when that is not the case. I ran into this issue in https://github.com/DataDog/dd-trace-rb/pull/2415, and needed to find a workaround. ### Next steps Since this is an internal VM API, I'm not sure you'd want to change the current behavior, so I was thinking of perhaps two options: * Is it worth changing `ruby_thread_has_gvl_p` to be accurate in the case I've listed? * If not, would you accept a PR to document its current limitations, so that others don't run into the same issue I did? -- https://bugs.ruby-lang.org/

3 3