September 2023 - ruby-core - ml.ruby-lang.org

[ruby-core:113107] [Ruby master Bug#19576] Backport request: Gemfile.lock resolving is broken with bundler shipped with Ruby 3.1.4
by jprokop (Jarek Prokop) 10 Nov '23

10 Nov '23

Issue #19576 has been reported by jprokop (Jarek Prokop). ---------------------------------------- Bug #19576: Backport request: Gemfile.lock resolving is broken with bundler shipped with Ruby 3.1.4 https://bugs.ruby-lang.org/issues/19576 * Author: jprokop (Jarek Prokop) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This is a backport request for bundler, that regressed in 2.3.36 in a specific situation. Newer and older bundler versions that ship with Ruby are not problematic, only the version that ships with Ruby version >= 3.1.3. A few weeks ago, we discovered a bug in resolving in bundler shipped with Ruby 3.1.3 and 3.1.4: Bundler version: ``` $ bundler --version Bundler version 2.3.26 ``` Affected rubies `ruby -v`: First: ``` $ ruby -v ruby 3.1.4p223 (2023-03-30 revision 957bb7cb81) [x86_64-linux] ``` Second: ``` $ruby -v ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux] ``` Initial bug report with reproducer and more in-depth description can be found here: https://github.com/sclorg/s2i-ruby-container/issues/469 Using the following Gemfile for a rails app: https://github.com/sclorg/rails-ex/blob/67b7a61eae9efa1088ff3f634ae316e1022… bundler locks up in trying to resolve Nokogiri for Ruby 3.1, but keeps failing because it keeps using incompatible built binary gem instead of falling back to installing and building the binary extension of Nokogiri locally. We craft this Gemfile to be usable from Ruby 2.5 up to Ruby 3.1, as the app is used mainly for testing. I have created a patch to fix the situation, see the attached files. There are 2 of them, one contains the fix and the other one contains the test from the rubygems repo PR#6225. full commit available here: https://src.fedoraproject.org/fork/jackorp/rpms/ruby/c/5ef600a8f40b76de5636… The patches are created from the following upstream changes in bundler: https://github.com/rubygems/rubygems/pull/6225 and adapted: https://github.com/rubygems/rubygems/commit/7b64c64262a7a980c0eb23b96ea56cf… for the PR#6225. With the fix applied I no longer have issues doing `bundle install` with our Gemfile.lock. ---Files-------------------------------- rubygem-bundler-2.3.26-Tests-from-bundler-PR-6225.patch (1.82 KB) rubygem-bundler-2.3.26-Provide-fix-for-bundler-Gemfile-resolving-regression.patch (5.21 KB) -- https://bugs.ruby-lang.org/

5 7

[ruby-core:114422] [Ruby master Feature#19842] Intorduce M:N threads
by ko1 (Koichi Sasada) 10 Nov '23

10 Nov '23

Issue #19842 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Feature #19842: Intorduce M:N threads https://bugs.ruby-lang.org/issues/19842 * Author: ko1 (Koichi Sasada) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) ---------------------------------------- This ticket proposes to introduce M:N threads to improve Threads/Ractors performance. ## Background Ruby threads (RT in short) are implemented from old Ruby versions and they have the following features: * Can be created with simple notation `Thread.new{}` * Can be switched to another ready Ruby thread by: * Time-slice. * I/O blocking. * Synchronization such as Mutex features. * And other blocking reasons. * Can be interruptible by: * OS-deliver signals (only for the main thread). * `Thread#kill`. * Can be terminated by: * the end of each Ruby thread. * the end of the main thread (and other Ruby threads are killed). Ruby 1.8 and erlier versions uses M:1 threads (green threads, user level threads, .... the word 1:N threads is more popular but to make this explanation consistent I use "M:1" term here) which manages multiple Ruby threads on 1 native thread. (Native threads are provided by C interfaces such as Pthreads. In many cases, native threads are OS threads, but there are also user-level implementations, such as user-level pthread libraries in theory. Therefore, they are referred to as native threads in this article and NT in short) If a Ruby thread T1 blocked because of a I/O operation, Ruby interpreter switches to the next ready Ruby thread T2. The I/O operation will be monitors by a `select()` (or similar) functionality and if the I/O is ready, T1 is marked as a ready thread and T1 will be resumed soon. However, when a Ruby thread issues some other blocking operations such as `gethostbyname()`, Ruby interpreter can not swtich to any other Ruby thread while `gethostbyname()` is not finished. We named two types blocking operations: * Managed blocking operations * I/O (most of read/write) * manage by I/O multiplexing API (select, poll, epoll, kqueue, IOCP, io_uring, ...) * Sleeping * Synchronization (Mutex, Queue, ...) * Unmanaged operations * All other blocking operations not listed above, written in C * Huge number calculation like `Bignum#*` * DNS lookup * I/O (can not detect block-able or not by multiplexing API) * open on FIFO, close on NFS, ... * flock and other locking mechanism * library call which uses blocking operations * `libfoo` has `foo_func()` and `foo_func()` waits DNS lookup. A Ruby extension `foo-ruby` can call `foo_func()`. With these terms we can say that M:1 threads can suport managed blocking operations but can not support unmanaged operations (can not make progress other Ruby threads) without further tricks. Note that if the `select()`-like system calls say a `fd` is ready, but the I/O opeartion for `fd` can be blocked because of some contention (read by another thread or process, for example). M:1 threads has another disadvantage that it can not run in parallel because only a native thread is used. From Ruby 1.9 we had implemented 1:1 thread which means a Ruby thread has a corresponding native thread. To make implementation easy we also introduced a GVL. Only a Ruby thread acquires GVL can run. With 1:1 model, we can support managed blocking oprations and unmanaged blocking operations by releasing GVL. When a Ruby thread want to issue a blocking operation, the Ruby thread releases GVL and another ready Ruby threads continue to run. We don't care the blocking operation is managed or unmanaged. (We can not make some of unmanaged blocking operations interruptible (stop by Ctrl-C for example)). Advantages of 1:1 threads to the M:1 threads is: * Easy to handle blocking operations by releasing GVL. * We can utilize parallelism with multiple native threads by releasing GVL. Disadvantages of 1:1 threads to the M:1 threads is: * Overhead to make many native threads for many Ruby threads * We can not make huge number of Ruby threads and Ractors on 1:1 threads. * Thread switching overhead by GVL because inter-core communication is needed. From Ruby 3.0 we introduced fiber scheduler mechanism to maintain multiple fibers Differences between Ruby 1.8 M:1 threads are: * No timeslice (only switch fibers by managed blocking operations) * Ruby users can make own schedulers for apps with favorite underlying mechanism Disadvantages are similar to M:1 threads. Another disadvantages is we need to consider about Fiber's behavior. From Ruby 3.0 we also introduced Ractors. Ractors can run in parallel because of separating most of objects. 1 Ractor creates 1 Ruby thread, so Ractors has same disadvantages of 1:1 threads. For example, we can not make huge number of Ractors. ## Goal Our goal is making lightweight Ractors on lightweight Ruby threads. To enable this goal we propose to implement M:N threads on MRI. M:N threads manages M Ruby threads on N native threads, with limited N (~= CPU core numbers for example). Advantages of M:N threads are: 1. We can run N ractors on N native threads simultaneously if the machine has N cores. 2. We can make huge number of Ruby threads or Ractors because we don't need huge number of native threads 3. We can support unmanaged blocking operations by locking a native thread to a Ruby thread which issues an unmanaged blocking operation. 4. We can make our own Ruby threads or Ractors scheduler instead of the native thread (OS) scheduler. Disadvantages of M:N threads are: 1. It is complex implmentation and it can be hard. 2. It can introduce incompatibility especaially on TLS (Thread local storage). 3. We need to maitain our own scheduler. Without using multiple Ractors, it is similar to Ruby 1.8 M:1 threads. The difference with M:1 threads are locking NT mechanism to support unmanaged blocking operations. Another advantage is that it is easy to fallback to 1:1 threads by locking all of corresponding native threads to Ruby threads. ## Proposed design ### User facing changes If a program only has a main Ractor (i.e., most Ruby programs), the user will not face any changes by default. On main Ractor, all threads are 1:1 threads by default and there is no compatibility issue. `RUBY_MN_THREADS=1` envrionment variable is given, main Ractor enables M:N threads. Note that the main thread locks NT by default because the initial NT is special in some case. I'm not sure we can relax this limitation. On the multiple Ractors, N (+ alpha) native threads run M ractors. Now there is no way to disable M:N threads on multiple Ractors because there are only a few multi-Ractor programs and no compatibility issues. Maximum number of N can be specified by `RUBY_MAX_PROC=N`. 8 by default but this value should be specified with the number of CPU processors (cores). ### TLS issue On M:N threads a Ruby thread (RT1) migrates from a native thread (NT1) to NT2, ... so that TLS on native code can be a problem. For example, RT1 calls a library function `foo()` and it set TLS1 on NT1. After migrating RT1 to NT2, RT1 calls `foo()` again but there is no TLS1 record because TLS1 is recorded only on NT1. On this case, RT1 should be run on NT1 while using native library foo. To avoid such prbolem, we need the following features: * 1:1 threads on main Ractor by default * functionality to lock the NT for RT, maybe `Thread#lock_native_thread` and `Thread#unlock_native_thread` API is needed. For example, Go language has `runtime.LockOSThread()` and `runtime.UnlockOSThread()` for this purpose. * Or C-API only for this purpose? (not fixed yet) Thankfully, the same problem can occur with Fiber scheduler (and of course Ruby 1.8 M:1 threads), but I have not heard of it being much of a problem, so I expect that TLS will not be much of an issue. ### Unmanaged blocking operations From Ruby 1.9 (1:1 threads), the `nogvl(func)` API is used for most blocking operations to keep the threading system healthy. In other words, `nogvl(func)` represents that the given function is blocking operation. To support unmanaged blocking operations, we lock a native thread for the Ruby thread which issues blocking operation. If the blocking operations doesn't finish soon, other Ruby threads can not run because a RT locks NT. In this case, another system monitoring thread named "Timer thread" (historical name and TT in short) creates another NT to run ready other Ruby threads. This TT's behavior is the same as the behavior of "sysmon" in the Go language. We named locked NT as dedicated native threads (DNT) and other NT as shared native threads (SNT). The upper bound by `RUBY_MAX_PROC` affects the number of SNT. In other words, the number of DNT is not limited (it is same that the number of NT on 1:1 threads are not limited). ### Managed blocking operations Managed blocking operations are multiplexing by `select()`-like functions on the Timer thread.. Now only `epoll()` is supported. I/O operation flow (read on fd1) on Ruby thread RT1: 1. check the ready-ness of fd1 by `poll(timeout = 0)`, goto step 4. 2. register fd1 to Timer thread (TT) epoll and resume another ready Ruby thread. 3. If TT detects that the fd1 is ready, make RT1 as ready thread. 4. When RT1 is resumed, then do `read()` by locking corresponding NT1. `sleep(n)` operation flow on Ruby thread RT1: 1. register timeout of RT1 to TT epoll. 2. If TT detects the timeout of RT1 (n seconds), TT makes RT1 as a ready Ruby thread. ### Internal design * 2 level scheduling * Ruby threads of a Ractor is managed by 1:N threads * Ruby threads of different Ractors are managed by M:N threads * Timer thread has several duties 1. Monitoring I/O (or other event) ready-ness 2. Monitoring timeout 3. Produce timeslice signals 4. Help OS signal delivering (On pthread environment) recent Ruby doesn't make timer thread but MaNy implementation makes TT anytime. it can be improved. ## Implementation The code name is MaNy project, it is from MN threads. https://github.com/ko1/ruby/tree/many2 The implementation is not matured (debugging now). ## Measurements See RubyKaigi 2023 slides: https://atdot.net/~ko1/activities/2023_rubykaigi2023.pdf ## Discussion * Enable/disable * default behavior * how to switch the behavior * Should we lock the NT for main thread anytime? * Ruby/C API to lock the native threads ## Misc This description will be improved more later. -- https://bugs.ruby-lang.org/

7 29

[ruby-core:114072] [Ruby master Bug#19754] `IO::Buffer#get_string` raises unsuitable exception for too large offset
by nobu (Nobuyoshi Nakada) 06 Nov '23

06 Nov '23

Issue #19754 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #19754: `IO::Buffer#get_string` raises unsuitable exception for too large offset https://bugs.ruby-lang.org/issues/19754 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The message seems suitable when both of `offset` and `length` are given. ```ruby IO::Buffer.for("test").get_string(5, 0) #=> Specified offset+length exceeds buffer size! (ArgumentError) ``` But without `length`, it doesn't seem to check `offset` properly. ```ruby IO::Buffer.for("test").get_string(5) #=> negative string size (or size too big) (ArgumentError) ``` -- https://bugs.ruby-lang.org/

4 6

[ruby-core:111953] [Ruby master Bug#19362] #dup on Proc doesn't call initialize_dup
by zverok (Victor Shepelev) 26 Oct '23

26 Oct '23

Issue #19362 has been reported by zverok (Victor Shepelev). ---------------------------------------- Bug #19362: #dup on Proc doesn't call initialize_dup https://bugs.ruby-lang.org/issues/19362 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- In #17545, `#dup` had changed to create an instance of the subclass. It, though, doesn't invoke `initialize_dup` of the subclass, unlike other standard classes. ```ruby class MyAry < Array def initialize_dup(...) p(self.class, ...) super end end class MyString < String def initialize_dup(...) p(self.class, ...) super end end class MyProc < Proc def initialize_dup(...) p(self.class, ...) super end end MyString.new('test').dup # prints MyString, "test" MyAry.new(['test']).dup # prints MyAry, ["test"] MyProc.new { 'test' }.dup # doesn't print anything ``` This makes the change in #17545 useless: while inheriting from core classes is indeed marginal, one of author's intention might be carrying additional information with the Proc instance, and bypassing `#initialize_dup` makes it impossible to maintain this information. It seems that actually `#initialize_dup` is also invoked on the core classes themselves, but ignored on `Proc`. ```ruby class Array def initialize_dup(...) p(self.class, ...) super end end class String def initialize_dup(...) p(self.class, ...) super end end class Proc def initialize_dup(...) p(self.class, ...) super end end 'test'.dup # prints String, "test" ['test'].dup # prints Array, ["test"] Proc.new { 'test' }.dup # doesn't print anything ``` Which is an even more marginal problem but still an inconsistency. -- https://bugs.ruby-lang.org/

3 7

[ruby-core:114338] [Ruby master Bug#19828] Segfault when `OpenSSL::X509::Certificate#public_key=` is given a `OpenSS::PKey::DH` object
by postmodern (Hal Brodigan) 26 Oct '23

26 Oct '23

Issue #19828 has been reported by postmodern (Hal Brodigan). ---------------------------------------- Bug #19828: Segfault when `OpenSSL::X509::Certificate#public_key=` is given a `OpenSS::PKey::DH` object https://bugs.ruby-lang.org/issues/19828 * Author: postmodern (Hal Brodigan) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The OpenSSL bindings cause a SegFault when creating a new OpenSSL::X509::Certificate object and setting it's `public_key` to the `public_key` of a new `OpenSSL::PKey::DH` key-pair. ### Steps To Reproduce ```ruby #!/usr/bin/env ruby require 'openssl' cert = OpenSSL::X509::Certificate.new key = OpenSSL::PKey::DH.generate(1024) cert.public_key = key.public_key ``` ### Expected Results Sets the public key. ### Actual Results ``` test.rb:8: [BUG] Segmentation fault at 0x0000000000000010 ruby 3.3.0dev (2023-08-02T18:35:08Z master 32e828bb4a) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0003 p:---- s:0014 e:000013 CFUNC :public_key= c:0002 p:0031 s:0009 E:001850 EVAL test.rb:8 [FINISH] c:0001 p:0000 s:0003 E:002540 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- test.rb:8:in `<main>' test.rb:8:in `public_key=' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ RIP: 0x00007fb3144e4c24 RBP: 0x00007ffd6dbb6bb0 RSP: 0x00007ffd6dbb6b88 RAX: 0x00005599fe68ed00 RBX: 0x00005599fe68ec40 RCX: 0x00005599fe68ed00 RDX: 0x0000000000000018 RDI: 0x0000000000000000 RSI: 0x0000000000000000 R8: 0x00005599fe68ed10 R9: 0x00007fb324a59ce0 R10: 0x0000000000000040 R11: 0x0000000000000000 R12: 0x0000000000000000 R13: 0x00005599fe68ed00 R14: 0x0000000000000000 R15: 0x0000000000000001 EFL: 0x0000000000010206 -- C level backtrace information ------------------------------------------- /home/postmodern/.rubies/ruby-trunk/bin/ruby(rb_vm_bugreport+0x5c7) [0x5599fce806a7] /home/postmodern/src/ruby/vm_dump.c:772 /home/postmodern/.rubies/ruby-trunk/bin/ruby(rb_bug_for_fatal_signal+0xe8) [0x5599fcf2a4b8] /home/postmodern/src/ruby/error.c:820 /home/postmodern/.rubies/ruby-trunk/bin/ruby(sigsegv+0x4b) [0x5599fcdcdccb] /home/postmodern/src/ruby/signal.c:920 /lib64/libc.so.6(__restore_rt+0x0) [0x7fb3248c2b70] /lib64/libcrypto.so.3(BN_is_negative+0x4) [0x7fb3144e4c24] /lib64/libcrypto.so.3(0x7fb3144b8d08) [0x7fb3144b8d08] /lib64/libcrypto.so.3(0x7fb31452514a) [0x7fb31452514a] /lib64/libcrypto.so.3(X509_PUBKEY_set+0x6f) [0x7fb31464134f] /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/openssl.so(ossl_x509_set_public_key+0x39) [0x7fb314ac1a29] /home/postmodern/src/ruby/ext/openssl/ossl_x509cert.c:525 /home/postmodern/.rubies/ruby-trunk/bin/ruby(vm_call_cfunc_other+0x169) [0x5599fce558b9] /home/postmodern/src/ruby/vm_insnhelper.c:3462 /home/postmodern/.rubies/ruby-trunk/bin/ruby(vm_exec_core+0x117) [0x5599fce72a37] /home/postmodern/src/ruby/vm_insnhelper.c:5534 /home/postmodern/.rubies/ruby-trunk/bin/ruby(rb_vm_exec+0x344) [0x5599fce636c4] /home/postmodern/src/ruby/vm.c:2390 /home/postmodern/.rubies/ruby-trunk/bin/ruby(rb_ec_exec_node+0xa5) [0x5599fcc77785] /home/postmodern/src/ruby/eval.c:287 /home/postmodern/.rubies/ruby-trunk/bin/ruby(ruby_run_node+0x8b) [0x5599fcc7ca5b] /home/postmodern/src/ruby/eval.c:328 /home/postmodern/.rubies/ruby-trunk/bin/ruby(main+0x62) [0x5599fcc77242] ./main.c:39 -- Other runtime information ----------------------------------------------- * Loaded script: test.rb * Loaded features: 0 enumerator.so 1 thread.rb 2 fiber.so 3 rational.so 4 complex.so 5 ruby2_keywords.rb 6 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/enc/encdb.so 7 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/enc/trans/transdb.so 8 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/rbconfig.rb 9 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/rubygems/compatibility.rb 10 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/rubygems/defaults.rb 11 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/rubygems/deprecate.rb 12 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/rubygems/errors.rb 13 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/rubygems/unknown_command_spell_checker.rb 14 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/rubygems/exceptions.rb 15 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/rubygems/basic_specification.rb 16 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/rubygems/stub_specification.rb 17 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/rubygems/platform.rb 18 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/rubygems/util/list.rb 19 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/rubygems/version.rb 20 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/rubygems/requirement.rb 21 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/rubygems/specification.rb 22 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/rubygems/util.rb 23 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/rubygems/dependency.rb 24 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/rubygems/core_ext/kernel_gem.rb 25 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/monitor.so 26 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/monitor.rb 27 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/rubygems.rb 28 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/bundled_gems.rb 29 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/rubygems/path_support.rb 30 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/error_highlight/version.rb 31 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/error_highlight/base.rb 32 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/error_highlight/formatter.rb 33 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/error_highlight/core_ext.rb 34 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/error_highlight.rb 35 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/did_you_mean/version.rb 36 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/did_you_mean/core_ext/name_error.rb 37 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/did_you_mean/levenshtein.rb 38 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/did_you_mean/jaro_winkler.rb 39 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/did_you_mean/spell_checker.rb 40 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/did_you_mean/spell_checkers/name_error_checkers/class_name_checker.rb 41 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/did_you_mean/spell_checkers/name_error_checkers/variable_name_checker.rb 42 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/did_you_mean/spell_checkers/name_error_checkers.rb 43 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/did_you_mean/spell_checkers/method_name_checker.rb 44 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/did_you_mean/spell_checkers/key_error_checker.rb 45 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/did_you_mean/spell_checkers/null_checker.rb 46 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/did_you_mean/tree_spell_checker.rb 47 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/did_you_mean/spell_checkers/require_path_checker.rb 48 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/did_you_mean/spell_checkers/pattern_key_name_checker.rb 49 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/did_you_mean/formatter.rb 50 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/did_you_mean.rb 51 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/syntax_suggest/core_ext.rb 52 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/digest/version.rb 53 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/digest.so 54 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/digest/loader.rb 55 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/digest.rb 56 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/openssl.so 57 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/openssl/bn.rb 58 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/openssl/marshal.rb 59 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/openssl/pkey.rb 60 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/openssl/cipher.rb 61 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/openssl/digest.rb 62 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/openssl/hmac.rb 63 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/openssl/x509.rb 64 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/openssl/buffering.rb 65 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/io/nonblock.so 66 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/socket.so 67 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/socket.rb 68 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/ipaddr.rb 69 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/openssl/ssl.rb 70 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/openssl/pkcs5.rb 71 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/openssl/version.rb 72 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/openssl.rb * Process memory map: 5599fcc41000-5599fcc72000 r--p 00000000 00:23 554309 /home/postmodern/.rubies/ruby-trunk/bin/ruby 5599fcc72000-5599fcf6f000 r-xp 00031000 00:23 554309 /home/postmodern/.rubies/ruby-trunk/bin/ruby 5599fcf6f000-5599fd0b4000 r--p 0032e000 00:23 554309 /home/postmodern/.rubies/ruby-trunk/bin/ruby 5599fd0b4000-5599fd0bf000 r--p 00473000 00:23 554309 /home/postmodern/.rubies/ruby-trunk/bin/ruby 5599fd0bf000-5599fd0c5000 rw-p 0047e000 00:23 554309 /home/postmodern/.rubies/ruby-trunk/bin/ruby 5599fd0c5000-5599fd0d9000 rw-p 00000000 00:00 0 5599fe223000-5599fe6bd000 rw-p 00000000 00:00 0 [heap] 7fb30da00000-7fb30de3d000 r--s 00000000 00:23 1740382 /usr/lib64/libcrypto.so.3.0.9 7fb30e000000-7fb30e222000 r--s 00000000 00:23 157485 /usr/lib64/libc.so.6 7fb30e400000-7fb30ffdf000 r--s 00000000 00:23 554309 /home/postmodern/.rubies/ruby-trunk/bin/ruby 7fb310000000-7fb310021000 rw-p 00000000 00:00 0 7fb310021000-7fb314000000 ---p 00000000 00:00 0 7fb3141ff000-7fb314200000 ---p 00000000 00:00 0 7fb314200000-7fb314400000 rw-p 00000000 00:00 0 7fb314400000-7fb3144ad000 r--p 00000000 00:23 1740382 /usr/lib64/libcrypto.so.3.0.9 7fb3144ad000-7fb314711000 r-xp 000ad000 00:23 1740382 /usr/lib64/libcrypto.so.3.0.9 7fb314711000-7fb3147ca000 r--p 00311000 00:23 1740382 /usr/lib64/libcrypto.so.3.0.9 7fb3147ca000-7fb314821000 r--p 003ca000 00:23 1740382 /usr/lib64/libcrypto.so.3.0.9 7fb314821000-7fb314824000 rw-p 00421000 00:23 1740382 /usr/lib64/libcrypto.so.3.0.9 7fb314824000-7fb314827000 rw-p 00000000 00:00 0 7fb314958000-7fb31495b000 r--p 00000000 00:23 1753127 /usr/lib64/libgcc_s-13-20230728.so.1 7fb31495b000-7fb314976000 r-xp 00003000 00:23 1753127 /usr/lib64/libgcc_s-13-20230728.so.1 7fb314976000-7fb31497a000 r--p 0001e000 00:23 1753127 /usr/lib64/libgcc_s-13-20230728.so.1 7fb31497a000-7fb31497b000 r--p 00021000 00:23 1753127 /usr/lib64/libgcc_s-13-20230728.so.1 7fb31497b000-7fb31497c000 rw-p 00000000 00:00 0 7fb314990000-7fb3149a0000 rw-p 00000000 00:00 0 7fb3149a1000-7fb3149a7000 r--p 00000000 00:23 554354 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/socket.so 7fb3149a7000-7fb3149c6000 r-xp 00006000 00:23 554354 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/socket.so 7fb3149c6000-7fb3149ce000 r--p 00025000 00:23 554354 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/socket.so 7fb3149ce000-7fb3149cf000 r--p 0002c000 00:23 554354 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/socket.so 7fb3149cf000-7fb3149d0000 rw-p 0002d000 00:23 554354 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/socket.so 7fb3149d0000-7fb3149e0000 rw-p 00000000 00:00 0 7fb3149e0000-7fb3149fe000 r--p 00000000 00:23 1740384 /usr/lib64/libssl.so.3.0.9 7fb3149fe000-7fb314a5b000 r-xp 0001e000 00:23 1740384 /usr/lib64/libssl.so.3.0.9 7fb314a5b000-7fb314a75000 r--p 0007b000 00:23 1740384 /usr/lib64/libssl.so.3.0.9 7fb314a75000-7fb314a7f000 r--p 00094000 00:23 1740384 /usr/lib64/libssl.so.3.0.9 7fb314a7f000-7fb314a83000 rw-p 0009e000 00:23 1740384 /usr/lib64/libssl.so.3.0.9 7fb314a83000-7fb314a98000 r--p 00000000 00:23 554347 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/openssl.so 7fb314a98000-7fb314ac9000 r-xp 00015000 00:23 554347 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/openssl.so 7fb314ac9000-7fb314adb000 r--p 00046000 00:23 554347 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/openssl.so 7fb314adb000-7fb314add000 r--p 00058000 00:23 554347 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/openssl.so 7fb314add000-7fb314adf000 rw-p 0005a000 00:23 554347 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/openssl.so 7fb314adf000-7fb314b80000 rw-p 00000000 00:00 0 7fb314b90000-7fb314c60000 rw-p 00000000 00:00 0 7fb314c60000-7fb314c61000 ---p 00000000 00:00 0 7fb314c61000-7fb314d02000 rw-p 00000000 00:00 0 7fb314d02000-7fb314d03000 ---p 00000000 00:00 0 7fb314d03000-7fb314da4000 rw-p 00000000 00:00 0 7fb314da4000-7fb314da5000 ---p 00000000 00:00 0 7fb314da5000-7fb314e46000 rw-p 00000000 00:00 0 7fb314e46000-7fb314e47000 ---p 00000000 00:00 0 7fb314e47000-7fb314ee8000 rw-p 00000000 00:00 0 7fb314ee8000-7fb314ee9000 ---p 00000000 00:00 0 7fb314ee9000-7fb314f8a000 rw-p 00000000 00:00 0 7fb314f8a000-7fb314f8b000 ---p 00000000 00:00 0 7fb314f8b000-7fb31502c000 rw-p 00000000 00:00 0 7fb31502c000-7fb31502d000 ---p 00000000 00:00 0 7fb31502d000-7fb3150ce000 rw-p 00000000 00:00 0 7fb3150ce000-7fb3150cf000 ---p 00000000 00:00 0 7fb3150cf000-7fb315170000 rw-p 00000000 00:00 0 7fb315170000-7fb315171000 ---p 00000000 00:00 0 7fb315171000-7fb315212000 rw-p 00000000 00:00 0 7fb315212000-7fb315213000 ---p 00000000 00:00 0 7fb315213000-7fb3152b4000 rw-p 00000000 00:00 0 7fb3152b4000-7fb3152b5000 ---p 00000000 00:00 0 7fb3152b5000-7fb315356000 rw-p 00000000 00:00 0 7fb315356000-7fb315357000 ---p 00000000 00:00 0 7fb315357000-7fb3153f8000 rw-p 00000000 00:00 0 7fb3153f8000-7fb3153f9000 ---p 00000000 00:00 0 7fb3153f9000-7fb31549a000 rw-p 00000000 00:00 0 7fb31549a000-7fb31549b000 ---p 00000000 00:00 0 7fb31549b000-7fb31553c000 rw-p 00000000 00:00 0 7fb31553c000-7fb31553d000 ---p 00000000 00:00 0 7fb31553d000-7fb3155de000 rw-p 00000000 00:00 0 7fb3155de000-7fb3155df000 ---p 00000000 00:00 0 7fb3155df000-7fb315680000 rw-p 00000000 00:00 0 7fb315680000-7fb315681000 ---p 00000000 00:00 0 7fb315681000-7fb315722000 rw-p 00000000 00:00 0 7fb315722000-7fb315723000 ---p 00000000 00:00 0 7fb315723000-7fb3157c4000 rw-p 00000000 00:00 0 7fb3157c4000-7fb3157c5000 ---p 00000000 00:00 0 7fb3157c5000-7fb315866000 rw-p 00000000 00:00 0 7fb315866000-7fb315867000 ---p 00000000 00:00 0 7fb315867000-7fb315908000 rw-p 00000000 00:00 0 7fb315908000-7fb315909000 ---p 00000000 00:00 0 7fb315909000-7fb3159aa000 rw-p 00000000 00:00 0 7fb3159aa000-7fb3159ab000 ---p 00000000 00:00 0 7fb3159ab000-7fb315a4c000 rw-p 00000000 00:00 0 7fb315a4c000-7fb315a4d000 ---p 00000000 00:00 0 7fb315a4d000-7fb315aee000 rw-p 00000000 00:00 0 7fb315aee000-7fb315aef000 ---p 00000000 00:00 0 7fb315aef000-7fb315b90000 rw-p 00000000 00:00 0 7fb315b90000-7fb315b91000 ---p 00000000 00:00 0 7fb315b91000-7fb315c32000 rw-p 00000000 00:00 0 7fb315c32000-7fb315c33000 ---p 00000000 00:00 0 7fb315c33000-7fb315cd4000 rw-p 00000000 00:00 0 7fb315cd4000-7fb315cd5000 ---p 00000000 00:00 0 7fb315cd5000-7fb315d76000 rw-p 00000000 00:00 0 7fb315d76000-7fb315d77000 ---p 00000000 00:00 0 7fb315d77000-7fb315e18000 rw-p 00000000 00:00 0 7fb315e18000-7fb315e19000 ---p 00000000 00:00 0 7fb315e19000-7fb315eba000 rw-p 00000000 00:00 0 7fb315eba000-7fb315ebb000 ---p 00000000 00:00 0 7fb315ebb000-7fb315f5c000 rw-p 00000000 00:00 0 7fb315f5c000-7fb315f5d000 ---p 00000000 00:00 0 7fb315f5d000-7fb315ffe000 rw-p 00000000 00:00 0 7fb315ffe000-7fb315fff000 ---p 00000000 00:00 0 7fb315fff000-7fb3160f0000 rw-p 00000000 00:00 0 7fb3160ff000-7fb317200000 rw-p 00000000 00:00 0 7fb317200000-7fb3247f9000 r--p 00000000 00:23 156716 /usr/lib/locale/locale-archive 7fb324808000-7fb32480a000 r--p 00000000 00:23 554324 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/digest.so 7fb32480a000-7fb32480c000 r-xp 00002000 00:23 554324 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/digest.so 7fb32480c000-7fb32480d000 r--p 00004000 00:23 554324 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/digest.so 7fb32480d000-7fb32480e000 r--p 00004000 00:23 554324 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/digest.so 7fb32480e000-7fb32480f000 rw-p 00005000 00:23 554324 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/digest.so 7fb32480f000-7fb324880000 rw-p 00000000 00:00 0 7fb324881000-7fb324885000 rw-p 00000000 00:00 0 7fb324885000-7fb3248ab000 r--p 00000000 00:23 157485 /usr/lib64/libc.so.6 7fb3248ab000-7fb324a08000 r-xp 00026000 00:23 157485 /usr/lib64/libc.so.6 7fb324a08000-7fb324a55000 r--p 00183000 00:23 157485 /usr/lib64/libc.so.6 7fb324a55000-7fb324a59000 r--p 001d0000 00:23 157485 /usr/lib64/libc.so.6 7fb324a59000-7fb324a5b000 rw-p 001d4000 00:23 157485 /usr/lib64/libc.so.6 7fb324a5b000-7fb324a63000 rw-p 00000000 00:00 0 7fb324a63000-7fb324a73000 r--p 00000000 00:23 157488 /usr/lib64/libm.so.6 7fb324a73000-7fb324ae8000 r-xp 00010000 00:23 157488 /usr/lib64/libm.so.6 7fb324ae8000-7fb324b42000 r--p 00085000 00:23 157488 /usr/lib64/libm.so.6 7fb324b42000-7fb324b43000 r--p 000de000 00:23 157488 /usr/lib64/libm.so.6 7fb324b43000-7fb324b44000 rw-p 000df000 00:23 157488 /usr/lib64/libm.so.6 7fb324b44000-7fb324b46000 r--p 00000000 00:23 1208073 /usr/lib64/libcrypt.so.2.0.0 7fb324b46000-7fb324b5a000 r-xp 00002000 00:23 1208073 /usr/lib64/libcrypt.so.2.0.0 7fb324b5a000-7fb324b73000 r--p 00016000 00:23 1208073 /usr/lib64/libcrypt.so.2.0.0 7fb324b73000-7fb324b74000 r--p 0002e000 00:23 1208073 /usr/lib64/libcrypt.so.2.0.0 7fb324b74000-7fb324b7d000 rw-p 00000000 00:00 0 7fb324b7d000-7fb324b8e000 r--p 00000000 00:23 32293 /usr/lib64/libgmp.so.10.4.1 7fb324b8e000-7fb324c0a000 r-xp 00011000 00:23 32293 /usr/lib64/libgmp.so.10.4.1 7fb324c0a000-7fb324c1f000 r--p 0008d000 00:23 32293 /usr/lib64/libgmp.so.10.4.1 7fb324c1f000-7fb324c21000 r--p 000a1000 00:23 32293 /usr/lib64/libgmp.so.10.4.1 7fb324c21000-7fb324c22000 rw-p 000a3000 00:23 32293 /usr/lib64/libgmp.so.10.4.1 7fb324c22000-7fb324c25000 r--p 00000000 00:23 33100 /usr/lib64/libz.so.1.2.13 7fb324c25000-7fb324c34000 r-xp 00003000 00:23 33100 /usr/lib64/libz.so.1.2.13 7fb324c34000-7fb324c3a000 r--p 00012000 00:23 33100 /usr/lib64/libz.so.1.2.13 7fb324c3a000-7fb324c3b000 r--p 00018000 00:23 33100 /usr/lib64/libz.so.1.2.13 7fb324c3b000-7fb324c3c000 rw-p 00000000 00:00 0 7fb324c3c000-7fb324c3d000 r--p 00000000 00:23 554338 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/io/nonblock.so 7fb324c3d000-7fb324c3e000 r-xp 00001000 00:23 554338 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/io/nonblock.so 7fb324c3e000-7fb324c3f000 r--p 00002000 00:23 554338 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/io/nonblock.so 7fb324c3f000-7fb324c40000 r--p 00002000 00:23 554338 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/io/nonblock.so 7fb324c40000-7fb324c41000 rw-p 00003000 00:23 554338 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/io/nonblock.so 7fb324c41000-7fb324c42000 r--p 00000000 00:23 554344 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/monitor.so 7fb324c42000-7fb324c43000 r-xp 00001000 00:23 554344 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/monitor.so 7fb324c43000-7fb324c44000 r--p 00002000 00:23 554344 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/monitor.so 7fb324c44000-7fb324c45000 r--p 00002000 00:23 554344 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/monitor.so 7fb324c45000-7fb324c46000 rw-p 00003000 00:23 554344 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/monitor.so 7fb324c46000-7fb324c47000 r--p 00000000 00:23 554361 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/enc/trans/transdb.so 7fb324c47000-7fb324c48000 r-xp 00001000 00:23 554361 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/enc/trans/transdb.so 7fb324c48000-7fb324c49000 r--p 00002000 00:23 554361 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/enc/trans/transdb.so 7fb324c49000-7fb324c4a000 r--p 00002000 00:23 554361 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/enc/trans/transdb.so 7fb324c4a000-7fb324c4b000 rw-p 00003000 00:23 554361 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/enc/trans/transdb.so 7fb324c4b000-7fb324c4c000 r--p 00000000 00:23 554382 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/enc/encdb.so 7fb324c4c000-7fb324c4d000 r-xp 00001000 00:23 554382 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/enc/encdb.so 7fb324c4d000-7fb324c4e000 r--p 00002000 00:23 554382 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/enc/encdb.so 7fb324c4e000-7fb324c4f000 r--p 00002000 00:23 554382 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/enc/encdb.so 7fb324c4f000-7fb324c50000 rw-p 00003000 00:23 554382 /home/postmodern/.rubies/ruby-trunk/lib/ruby/3.3.0+0/x86_64-linux/enc/encdb.so 7fb324c50000-7fb324c52000 rw-p 00000000 00:00 0 7fb324c52000-7fb324c53000 r--p 00000000 00:23 157482 /usr/lib64/ld-linux-x86-64.so.2 7fb324c53000-7fb324c79000 r-xp 00001000 00:23 157482 /usr/lib64/ld-linux-x86-64.so.2 7fb324c79000-7fb324c83000 r--p 00027000 00:23 157482 /usr/lib64/ld-linux-x86-64.so.2 7fb324c83000-7fb324c85000 r--p 00030000 00:23 157482 /usr/lib64/ld-linux-x86-64.so.2 7fb324c85000-7fb324c87000 rw-p 00032000 00:23 157482 /usr/lib64/ld-linux-x86-64.so.2 7ffd6d3bb000-7ffd6dbba000 rw-p 00000000 00:00 0 [stack] 7ffd6dbdf000-7ffd6dbe3000 r--p 00000000 00:00 0 [vvar] 7ffd6dbe3000-7ffd6dbe5000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] Aborted (core dumped) ``` ### Versions * ruby 3.3.0dev (2023-08-02T18:35:08Z master 32e828bb4a) [x86_64-linux] * ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux] * ruby 3.1.4p223 (2023-03-30 revision 957bb7cb81) [x86_64-linux] * OpenSSL 3.0.9 30 May 2023 (Library: OpenSSL 3.0.9 30 May 2023) ### GDB Backtrace ``` (gdb) bt -full #0 BN_is_negative (a=0x0) at crypto/bn/bn_lib.c:945 No locals. #1 0x00007fffe78b8d08 in bn_to_asn1_string (bn=0x0, ai=0x0, atype=<optimized out>) at crypto/asn1/a_int.c:479 ret = 0x555555e57570 len = <optimized out> __func__ = "bn_to_asn1_string" #2 0x00007fffe792514a in dh_pub_encode (pk=0x555555e580e0, pkey=0x555555e224b0) at crypto/dh/dh_ameth.c:134 dh = 0x555555e572e0 ptype = 16 penc = 0x0 penclen = <optimized out> str = 0x555555e574b0 pub_key = 0x0 __func__ = "dh_pub_encode" #3 0x00007fffe7a4134f in X509_PUBKEY_set (x=0x555555e2d440, pkey=0x555555e224b0) at crypto/x509/x_pubkey.c:332 pk = 0x555555e580e0 __func__ = "X509_PUBKEY_set" #4 0x00007fffe7e31a29 in ossl_x509_set_public_key (self=<optimized out>, key=140737082617600) at ossl_x509cert.c:525 x509 = 0x555555e2d3f0 pkey = 0x555555e224b0 #5 0x00005555557688b9 in vm_call_cfunc_with_frame_ (stack_bottom=<optimized out>, argv=<optimized out>, argc=<optimized out>, calling=<optimized out>, reg_cfp=<optimized out>, ec=<optimized out>) at /home/postmodern/src/ruby/vm_insnhelper.c:3462 ci = <optimized out> cc = <optimized out> val = <optimized out> me = <optimized out> cfunc = <optimized out> recv = <optimized out> frame_type = <optimized out> len = <optimized out> block_handler = <optimized out> ci = <optimized out> cc = <optimized out> val = <optimized out> me = <optimized out> cfunc = <optimized out> recv = <optimized out> block_handler = <optimized out> frame_type = <optimized out> len = <optimized out> args = <optimized out> flag_arg_ = <optimized out> hooks_arg_ = <optimized out> flag_arg_ = <optimized out> hooks_arg_ = <optimized out> args = <optimized out> #6 vm_call_cfunc_with_frame (calling=<optimized out>, reg_cfp=<optimized out>, ec=<optimized out>) at /home/postmodern/src/ruby/vm_insnhelper.c:3490 argc = <optimized out> stack_bottom = <optimized out> argv = <optimized out> argc = <optimized out> stack_bottom = <optimized out> argv = <optimized out> #7 vm_call_cfunc_other (ec=0x5555559f1080, reg_cfp=0x7ffff7bf1fa0, calling=<optimized out>) at /home/postmodern/src/ruby/vm_insnhelper.c:3516 ci = <optimized out> argv_ary = <optimized out> #8 0x0000555555785a37 in vm_sendish (method_explorer=<optimized out>, block_handler=<optimized out>, cd=<optimized out>, reg_cfp=<optimized out>, ec=<optimized out>) at /home/postmodern/src/ruby/vm_callinfo.h:403 val = 93824999513184 ci = 0x18 cc = <optimized out> recv = 0 argc = <optimized out> calling = {cd = 0x555555c45c60, cc = 0x7fffe7d0eed8, block_handler = 0, recv = 140737082618600, argc = 1, kw_splat = false, heap_argv = 0} val = <optimized out> ci = <optimized out> cc = <optimized out> argc = <optimized out> recv = <optimized out> calling = <optimized out> #9 vm_exec_core (ec=0x0, ec@entry=0x5555559f1080) at /home/postmodern/src/ruby/insns.def:835 bh = <optimized out> cd = 0x555555c45c60 leaf = <optimized out> val = 93824999513184 reg_pc = 0x555555b3aef8 reg_cfp = 0x7ffff7bf1fa0 insns_address_table = {0x555555788b24 <vm_exec_core+12804>, 0x55555578789f <vm_exec_core+8063>, 0x55555578783b <vm_exec_core+7963>, 0x5555557877c9 <vm_exec_core+7849>, 0x55555578775c <vm_exec_core+7740>, 0x5555557876f0 <vm_exec_core+7632>, 0x555555787624 <vm_exec_core+7428>, 0x555555787a0c <vm_exec_core+8428>, 0x555555787901 <vm_exec_core+8161>, 0x555555787958 <vm_exec_core+8248>, 0x555555787509 <vm_exec_core+7145>, 0x555555787395 <vm_exec_core+6773>, 0x555555787244 <vm_exec_core+6436>, 0x5555557871f2 <vm_exec_core+6354>, 0x5555557871a4 <vm_exec_core+6276>, 0x555555787170 <vm_exec_core+6224>, 0x555555787141 <vm_exec_core+6177>, 0x555555787115 <vm_exec_core+6133>, 0x5555557870e9 <vm_exec_core+6089>, 0x5555557870bd <vm_exec_core+6045>, 0x55555578702a <vm_exec_core+5898>, 0x555555786ff5 <vm_exec_core+5845>, 0x555555786fa6 <vm_exec_core+5766>, 0x555555786f69 <vm_exec_core+5705>, 0x555555786ef3 <vm_exec_core+5587>, 0x555555786ec5 <vm_exec_core+5541>, 0x555555786e70 <vm_exec_core+5456>, 0x555555786e02 <vm_exec_core+5346>, 0x555555786dd1 <vm_exec_core+5297>, 0x555555786da0 <vm_exec_core+5248>, 0x555555786c02 <vm_exec_core+4834>, 0x555555786ae4 <vm_exec_core+4548>, 0x555555786a93 <vm_exec_core+4467>, 0x555555786a46 <vm_exec_core+4390>, 0x555555786a05 <vm_exec_core+4325>, 0x555555786b98 <vm_exec_core+4728>, 0x555555786b66 <vm_exec_core+4678>, 0x555555786bb6 <vm_exec_core+4758>, 0x5555557869da <vm_exec_core+4282>, 0x555555786938 <vm_exec_core+4120>, 0x5555557868fa <vm_exec_core+4058>, 0x5555557868bb <vm_exec_core+3995>, 0x555555786892 <vm_exec_core+3954>, 0x55555578682d <vm_exec_core+3853>, 0x5555557867d5 <vm_exec_core+3765>, 0x55555578673a <vm_exec_core+3610>, 0x5555557866d4 <vm_exec_core+3508>, 0x555555786660 <vm_exec_core+3392>, 0x5555557865c5 <vm_exec_core+3237>, 0x555555786593 <vm_exec_core+3187>, 0x555555786556 <vm_exec_core+3126>, 0x5555557864f7 <vm_exec_core+3031>, 0x555555785980 <vm_exec_core+96>, 0x55555578645c <vm_exec_core+2876>, 0x555555786419 <vm_exec_core+2809>, 0x555555788971 <vm_exec_core+12369>, 0x5555557862ef <vm_exec_core+2511>, 0x55555578625e <vm_exec_core+2366>, 0x555555786332 <vm_exec_core+2578>, 0x555555786147 <vm_exec_core+2087>, 0x555555786091 <vm_exec_core+1905>, 0x555555787be1 <vm_exec_core+8897>, 0x55555578605a <vm_exec_core+1850>, 0x555555786004 <vm_exec_core+1764>, 0x555555787a97 <vm_exec_core+8567>, 0x555555787a64 <vm_exec_core+8516>, 0x555555787aed <vm_exec_core+8653>, 0x555555785f28 <vm_exec_core+1544>, 0x55555578890e <vm_exec_core+12270>, 0x555555788a31 <vm_exec_core+12561>, 0x555555788879 <vm_exec_core+12121>, 0x555555788a93 <vm_exec_core+12659>, 0x5555557885b4 <vm_exec_core+11412>, 0x55555578865d <vm_exec_core+11581>, 0x5555557886b3 <vm_exec_core+11667>, 0x555555788721 <vm_exec_core+11777>, 0x555555788777 <vm_exec_core+11863>, 0x5555557887cd <vm_exec_core+11949>, 0x555555788823 <vm_exec_core+12035>, 0x5555557889b8 <vm_exec_core+12440>, 0x5555557883ac <vm_exec_core+10892>, 0x5555557883f3 <vm_exec_core+10963>, 0x555555788445 <vm_exec_core+11045>, 0x5555557884a6 <vm_exec_core+11142>, 0x555555785e90 <vm_exec_core+1392>, 0x555555785e4f <vm_exec_core+1327>, 0x555555788526 <vm_exec_core+11270>, 0x55555578856d <vm_exec_core+11341>, 0x555555788277 <vm_exec_core+10583>, 0x5555557882a0 <vm_exec_core+10624>, 0x5555557882fe <vm_exec_core+10718>, 0x55555578835e <vm_exec_core+10814>, 0x555555785de8 <vm_exec_core+1224>, 0x555555785d72 <vm_exec_core+1106>, 0x555555785cc6 <vm_exec_core+934>, 0x555555785c88 <vm_exec_core+872>, 0x555555785c42 <vm_exec_core+802>, 0x555555785bfc <vm_exec_core+732>, 0x555555785bae <vm_exec_core+654>, 0x555555785b82 <vm_exec_core+610>, 0x555555785b56 <vm_exec_core+566>, 0x555555788393 <vm_exec_core+10867>, 0x555555787893 <vm_exec_core+8051>, 0x55555578782f <vm_exec_core+7951>, 0x5555557877bd <vm_exec_core+7837>, 0x555555787750 <vm_exec_core+7728>, 0x5555557876e4 <vm_exec_core+7620>, 0x555555787618 <vm_exec_core+7416>, 0x555555787a00 <vm_exec_core+8416>, 0x5555557878f5 <vm_exec_core+8149>, 0x55555578794c <vm_exec_core+8236>, 0x5555557874fd <vm_exec_core+7133>, 0x555555787389 <vm_exec_core+6761>, 0x555555787238 <vm_exec_core+6424>, 0x5555557871e6 <vm_exec_core+6342>, 0x555555787198 <vm_exec_core+6264>, 0x555555787164 <vm_exec_core+6212>, 0x555555787135 <vm_exec_core+6165>, 0x555555787109 <vm_exec_core+6121>, 0x5555557870dd <vm_exec_core+6077>, 0x5555557870b1 <vm_exec_core+6033>, 0x55555578701e <vm_exec_core+5886>, 0x555555786fe9 <vm_exec_core+5833>, 0x555555786f9a <vm_exec_core+5754>, 0x555555786f5d <vm_exec_core+5693>, 0x555555786ee7 <vm_exec_core+5575>, 0x555555786eb9 <vm_exec_core+5529>, 0x555555786e64 <vm_exec_core+5444>, 0x555555786df6 <vm_exec_core+5334>, 0x555555786dc5 <vm_exec_core+5285>, 0x555555786d94 <vm_exec_core+5236>, 0x555555786bf6 <vm_exec_core+4822>, 0x555555786ad8 <vm_exec_core+4536>, 0x555555786a87 <vm_exec_core+4455>, 0x555555786a3a <vm_exec_core+4378>, 0x5555557869f9 <vm_exec_core+4313>, 0x555555786b8c <vm_exec_core+4716>, 0x555555786b5a <vm_exec_core+4666>, 0x555555786baa <vm_exec_core+4746>, 0x5555557869ce <vm_exec_core+4270>, 0x55555578692c <vm_exec_core+4108>, 0x5555557868ee <vm_exec_core+4046>, 0x5555557868af <vm_exec_core+3983>, 0x555555786886 <vm_exec_core+3942>, 0x555555786821 <vm_exec_core+3841>, 0x5555557867c9 <vm_exec_core+3753>, 0x55555578672e <vm_exec_core+3598>, 0x5555557866c8 <vm_exec_core+3496>, 0x555555786654 <vm_exec_core+3380>, 0x5555557865b9 <vm_exec_core+3225>, 0x555555786587 <vm_exec_core+3175>, 0x55555578654a <vm_exec_core+3114>, 0x5555557864eb <vm_exec_core+3019>, 0x5555557880fa <vm_exec_core+10202>, 0x555555786450 <vm_exec_core+2864>, 0x55555578640d <vm_exec_core+2797>, 0x55555578810b <vm_exec_core+10219>, 0x5555557862e3 <vm_exec_core+2499>, 0x555555786252 <vm_exec_core+2354>, 0x555555786326 <vm_exec_core+2566>, 0x55555578613b <vm_exec_core+2075>, 0x555555786085 <vm_exec_core+1893>, 0x555555787bd5 <vm_exec_core+8885>, 0x55555578604e <vm_exec_core+1838>, 0x555555785ff8 <vm_exec_core+1752>, 0x555555787a8b <vm_exec_core+8555>, 0x555555787a58 <vm_exec_core+8504>, 0x555555787ae1 <vm_exec_core+8641>, 0x555555785f1c <vm_exec_core+1532>, 0x55555578811c <vm_exec_core+10236>, 0x55555578812d <vm_exec_core+10253>, 0x55555578813e <vm_exec_core+10270>, 0x55555578814f <vm_exec_core+10287>, 0x555555788160 <vm_exec_core+10304>, 0x555555788171 <vm_exec_core+10321>, 0x555555788182 <vm_exec_core+10338>, 0x55555578819a <vm_exec_core+10362>, 0x5555557881ab <vm_exec_core+10379>, 0x5555557881bc <vm_exec_core+10396>, 0x5555557881cd <vm_exec_core+10413>, 0x5555557881de <vm_exec_core+10430>, 0x5555557881ef <vm_exec_core+10447>, 0x555555788200 <vm_exec_core+10464>, 0x555555788211 <vm_exec_core+10481>, 0x555555788222 <vm_exec_core+10498>, 0x555555785e84 <vm_exec_core+1380>, 0x555555785e43 <vm_exec_core+1315>, 0x555555788233 <vm_exec_core+10515>, 0x555555788244 <vm_exec_core+10532>, 0x555555788255 <vm_exec_core+10549>, 0x555555788266 <vm_exec_core+10566>, 0x55555578596e <vm_exec_core+78>, 0x55555578596e <vm_exec_core+78>, 0x555555785ddc <vm_exec_core+1212>, 0x555555785d66 <vm_exec_core+1094>, 0x555555785cba <vm_exec_core+922>, 0x555555785c7c <vm_exec_core+860>, 0x555555785c36 <vm_exec_core+790>, 0x555555785bf0 <vm_exec_core+720>, 0x555555785ba2 <vm_exec_core+642>...} #10 0x00005555557766c4 in rb_vm_exec (ec=0x5555559f1080) at vm.c:2390 _ec = 0x5555559f1080 _tag = {tag = 36, retval = 4, buf = {0x7fffffffda20, 0x5555557764d0 <rb_vm_exec+336>, 0x7fffffffd8e0, 0x14da16a575657c00, 0x7ffff7a2a6f8}, prev = 0x7fffffffda60, state = RUBY_TAG_NONE, lock_rec = 0} state = <optimized out> result = <optimized out> #11 0x000055555578cc98 in rb_iseq_eval_main (iseq=<optimized out>) at vm.c:2640 ec = <optimized out> val = <optimized out> #12 0x000055555558a785 in rb_ec_exec_node (ec=ec@entry=0x5555559f1080, n=n@entry=0x7fffe7ea0aa8) at eval.c:287 th = <optimized out> _ec = <optimized out> _tag = {tag = 36, retval = 93824994127712, buf = {0x5555559f1080, 0x55555558a7da <rb_ec_exec_node+250>, 0x7fffffffda30, 0x7fffe7ea0aa8, 0x24}, prev = 0x0, state = RUBY_TAG_NONE, lock_rec = 0} state = 0 iseq = 0x7fffe7ea0aa8 #13 0x000055555558fa5b in ruby_run_node (n=0x7fffe7ea0aa8) at eval.c:328 ec = 0x5555559f1080 status = 32767 #14 0x000055555558a242 in rb_main (argv=0x7fffffffdc78, argc=2) at ./main.c:39 variable_in_this_stack_frame = 0 #15 main (argc=<optimized out>, argv=<optimized out>) at ./main.c:58 ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:112944] [Ruby master Feature#19541] Proposal: Generate frame unwinding info for YJIT code
by kjtsanaktsidis (KJ Tsanaktsidis) 19 Oct '23

19 Oct '23

Issue #19541 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Feature #19541: Proposal: Generate frame unwinding info for YJIT code https://bugs.ruby-lang.org/issues/19541 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Priority: Normal ---------------------------------------- ## What is being propsed? Currently, Ruby crashes with yjit generated code on the stack, `rb_print_backtrace()` is unable to actually show any frames underneath the yjit code. For example, if you send SIGSEGV to a Ruby process running yjit, this is what you see: ``` /ruby/miniruby(rb_print_backtrace+0xc) [0xaaaad0276884] /ruby/vm_dump.c:785 /ruby/miniruby(rb_vm_bugreport) /ruby/vm_dump.c:1093 /ruby/miniruby(rb_bug_for_fatal_signal+0xd0) [0xaaaad0075580] /ruby/error.c:813 /ruby/miniruby(sigsegv+0x5c) [0xaaaad01bedac] /ruby/signal.c:919 linux-vdso.so.1(__kernel_rt_sigreturn+0x0) [0xffff91a3e8bc] /ruby/miniruby(map<(usize, yjit::backend::ir::Insn), (usize, yjit::backend::ir::Insn), yjit::backend::ir::{impl#17}::next_mapped::{closure_env#0}>+0x8c) [0xaaaad03b8b00] /rustc/897e37553bba8b42751c67658967889d11ecd120/library/core/src/option.rs:929 /ruby/miniruby(next_mapped+0x3c) [0xaaaad0291dc0] src/backend/ir.rs:1225 /ruby/miniruby(arm64_split+0x114) [0xaaaad0287744] src/backend/arm64/mod.rs:359 /ruby/miniruby(compile_with_regs+0x80) [0xaaaad028bf84] src/backend/arm64/mod.rs:1106 /ruby/miniruby(compile+0xc4) [0xaaaad0291ae0] src/backend/ir.rs:1158 /ruby/miniruby(gen_single_block+0xe44) [0xaaaad02b1f88] src/codegen.rs:854 /ruby/miniruby(gen_block_series_body+0x9c) [0xaaaad03b0250] src/core.rs:1698 /ruby/miniruby(gen_block_series+0x50) [0xaaaad03b0100] src/core.rs:1676 /ruby/miniruby(branch_stub_hit_body+0x80c) [0xaaaad03b1f68] src/core.rs:2021 /ruby/miniruby({closure#0}+0x28) [0xaaaad02eb86c] src/core.rs:1924 /ruby/miniruby(do_call<yjit::core::branch_stub_hit::{closure_env#0}, *const u8>+0x98) [0xaaaad035ba3c] /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/panicking.rs:492 [0xaaaad035c9b4] ``` (n.b. - I compiled Ruby with `-fasynchronous-unwind-tables –rdynamic –g` in cflags to make sure gcc generates appropriate unwind info & keeps the symbol tables). Likewise, if you attach gdb to a Ruby process with yjit enabled, gdb can't show thread backtraces through yjit-generated code either. My proposal is that YJIT generate sufficient unwinding and debug information on all platforms to allow both `rb_print_backtrace()` and the platform's debugger (gdb/lldb/WinDbg) to show: * Full stack traces all the way back to `main`. That is, it should be possible to see frames _underneath_ `[0xaaaad035c9b4]` from the backtrace above. * Names for the dynamically generated yjit blocks (e.g. instead of `[0xaaaad035c9b4]`, we should see something like `yjit$$name_of_ruby_method`, where `name_of_ruby_method` is the `label` for the iseq this is JIT'd code for). ## Motivation I have a few motivations for wanting this. Firstly, I feel this functionality is independently useful. When Ruby crashes, the more information we can get, the more likely we are to find the root cause. Likewise, the same principle applies to debugging with gdb - you can get a fuller understanding of what the process is doing if you see the whole stack. I have often found attaching gdb to the Ruby interpreter helps in understanding problems in Ruby code or C extensions and is something I do relatively frequently; yjit breaking that will definitely be inconvenient for me! ## Implementation I have a draft implementation here on how I'd implement this: . It's currently missing tests & platform support (it only works on Linux aarch64). Also, it implements unwind info generation, so unwinding can work _through_ yjit code, but it does not currently emit symbols to give _names_ to those yjit frames. My PR contains a document which explains how the Linux interfaces for registering unwind info for JIT'd code work, so I won't duplicate that information here. The biggest implementation question I had is around the use of Rust crates. Currently, I prototyped my implementation using the gimli & object crates, for generating DWARF info and ELF binaries. However, the yjit build does purposefully does not use cargo & external crates for release builds. There are a few different ways we could go here: * Don't use the gimli & object crates; instead, re-implement all debug info & object file generation code in yjit. * Don't use the crates; instead, link againt C libraries to provide this functionality & call them from Rust (perhaps some combination of libelf, libdw, libbfd, or llvm might do what we need) * Use cargo after all for the release build & download the crates at build-time * Use cargo for the release build, but vendor everything, so the build doesn't need to download anything * Only make unwind info generation available in dev mode where cargo is used, and so mark the gimli/object dependencies as optional in Cargo.toml. We'd need to decide on one of these approaches for this proposal to work. I don't really have a strong sense of the pros/cons of each. (Side note - my PR actually depends on a _fork_ of gimli - I've been discussing adding the needed interfaces upstream here: https://github.com/gimli-rs/gimli/issues/648) ## Benchmarks I ran the yit-bench suite on my branch and compared it to Ruby master: * My branch: https://gist.github.com/KJTsanaktsidis/5741a9f64e5cd75cdf5fedd846091a4f * Ruby master: https://gist.github.com/KJTsanaktsidis/592d3ebcf98f6745dfa3efbd30a25acf This is a (very simple) comparison: ``` -------------- ------------ ------------ --------------- bench yjit (ms) branch (ms) branch/yjit (%) activerecord 97.5 98.5 101.03% hexapdf 2415.3 2458.2 101.78% liquid-c 61.9 63.1 101.94% liquid-render 135.3 135.0 99.78% mail 104.6 105.5 100.86% psych-load 1887.1 1922.0 101.85% railsbench 1544.4 1556.0 100.75% ruby-lsp 88.4 89.5 101.24% sequel 147.5 151.1 102.44% binarytrees 303 305.6 100.86% chunky_png 1075.8 1079.4 100.33% erubi 392.9 392.3 99.85% erubi_rails 14.7 14.7 100.00% etanni 792.3 791.4 99.89% fannkuchredux 3815.9 3813.6 99.94% lee 1030.2 1039.2 100.87% nbody 49.2 49.3 100.20% optcarrot 4142 4143.3 100.03% ruby-json 2860.7 2874.0 100.46% rubykon 7906.6 7904.2 99.97% 30k_ifelse 348.7 345.4 99.05% 30k_methods 828.6 831.8 100.39% cfunc_itself 28.8 28.9 100.35% fib 34.4 34.5 100.29% getivar 115.5 109.7 94.98% keyword_args 37.7 38.0 100.80% respond_to 26 26.1 100.38% setivar 33.8 33.5 99.11% setivar_object 208.7 194.3 93.10% str_concat 52.6 52.2 99.24% throw 23.8 24.1 101.26% -------------- ------------ ------------ --------------- ``` It seems like the performance impact of generating and registering the debug info is marginal. -- https://bugs.ruby-lang.org/

7 12

[ruby-core:112326] [Ruby master Feature#19430] Contribution wanted: DNS lookup by c-ares library
by mame (Yusuke Endoh) 19 Oct '23

19 Oct '23

Issue #19430 has been reported by mame (Yusuke Endoh). ---------------------------------------- Feature #19430: Contribution wanted: DNS lookup by c-ares library https://bugs.ruby-lang.org/issues/19430 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal ---------------------------------------- ## Problem At the present time, Ruby uses `getaddrinfo(3)` to resolve names. Because this function is synchronous, we cannot interrupt the thread performing name resolution until the DNS server returns a response. We can see this behavior by setting blackhole.webpagetest.org (72.66.115.13) as a DNS server, which swallows all packets, and resolving any name: ``` # cat /etc/resolv.conf nameserver 72.66.115.13 # ./local/bin/ruby -rsocket -e 'Addrinfo.getaddrinfo("www.ruby-lang.org", 80)' ^C^C^C^C ``` As we see, Ctrl+C does not stop ruby. The current workaround that users can take is to do name resolution in a Ruby thread. ```ruby Thread.new { Addrinfo.getaddrinfo("www.ruby-lang.org", 80) }.value ``` The thread that calls this code is interruptible. (Note that the newly created thread itself will be stuck until the DNS lookup exceeds the time out.) ## Proposal We can solve this problem by using c-ares, which is an asynchronous name resolver, as a backend of `Addrinfo.getaddrinfo`, etc. (@sorah told me about this library, thanks!) https://c-ares.org/ I have created a PoC patch. https://github.com/mame/ruby/commit/547806146993bbc25984011d423dcc0f913b211c By applying this patch, we can interrupt `Addrinfo.getaddrinfo` by Ctrl+C. ``` # cat /etc/resolv.conf nameserver 72.66.115.13 # ./local/bin/ruby -rsocket -e 'Addrinfo.getaddrinfo("www.ruby-lang.org", 80)' ^C-e:1:in `getaddrinfo': Interrupt from -e:1:in `<main>' ``` ## Discussion ### About c-ares According to the site of c-ares, some major tools including libcurl, Wireshark, and Apache Arrow are already using c-ares. In the language interpreter, node.js seems to be using c-ares. I am honestly not sure about the compatibility of c-ares with `getaddrinfo(3)`. I guess there is no major incompatibility because I have not experienced any name resolution problem of curl. @akr (who is the author and maintainer of Ruby's socket library) suggested to check if OS-specific name resolution, e.g., WINS on Windows, NIS on Solaris, etc., is supported. He also said that it may be acceptable even if they are not supported. Whether to bundle c-ares source code with ruby would require further discussion. If this proposal is accepted, then c-ares will become a de facto essential dependency for practical use, like gmp, in my opinion. Incidentally, node.js bundles c-ares: https://github.com/nodejs/node/tree/main/deps/cares ### Alternative approaches Recent glibc provides `getaddrinfo_a(3)` which performs asynchronous name resolution. However, this function has a fatal problem of being incompatible with `fork(2)`, which is heavily used in the Ruby ecosystem. In fact, the attempt to use `getaddrinfo_a(3)` (#17134) has been revert because it fails rails tests. (#17220) Another alternative is to have a worker pthread inside Ruby that calls getaddrinfo(3). Instead of calling getaddrinfo(3) directly, `Addrinfo.getaddrinfo` would ask the worker to resolve a name and wait for a response. This method should be able to implement cancellation. (Simply put, this means reimplementation of getaddrinfo_a(3) on our own, taking into account of `fork(2).) This has the advantages: not adding dependencies on external libraries and not having compatibility issues with `getaddrinfo(3)`. However, it is considerably more difficult to implement and maintain. An internal pthread may have a non-trivial impact on the execution efficiency and memory usage. Also, we may need to implement a mechanism to dynamically change the number of workers depending on the load. It would be ideal if we could try and evaluate both approaches. But my current impression is that using c-ares is the quickest and best compromise. ## Contribution wanted I have made it up to the PoC, but don't have much time to complete this. @naruse suggested me to create a ticket asking for contributions. Is anyone interested in this? * This patch changes `rsock_getaddrinfo` to accept a timeout argument. There are several places where Qnil is passed as a timeout (where I add `// TODO` in the PoC). We need to consider what timeout we should pass. * This cares only `getaddrinfo`, but we also need to care `getnameinfo` (and something else if any). There may be some issues I'm not aware of. * I have not yet tested this PoC seriously. It would be great if we could evaluate it with some real apps. Also, it would be great to hear from someone who knows more about c-ares. -- https://bugs.ruby-lang.org/

6 15

[ruby-core:114250] [Ruby master Bug#19778] mkmf.rb pkg_config() interaction with RbConfig::CONFIG["cflags"]
by rhenium (Kazuki Yamaguchi) 17 Oct '23

17 Oct '23

Issue #19778 has been reported by rhenium (Kazuki Yamaguchi). ---------------------------------------- Bug #19778: mkmf.rb pkg_config() interaction with RbConfig::CONFIG["cflags"] https://bugs.ruby-lang.org/issues/19778 * Author: rhenium (Kazuki Yamaguchi) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-07-21T09:38:29Z master 22f9735587) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- (This was first reported at https://github.com/ruby/openssl/issues/650: The extension's build breaks in a strange way if `RbConfig::CONFIG["*flags"]` contains the path of an OpenSSL installation but `pkg-config` returns the path of a different OpenSSL installation) Commit commit:097c3e9cbbf23718371f08c24b2d2297b039f63f ("mkmf.rb: -I flags to $INCFLAGS", Ruby 2.2) changed how mkmf's `pkg_config()` handles the result of the `pkg-config` command. It now stores the `-I` flags in $INCFLAGS and others in $CFLAGS. mkmf generates a Makefile that compiles source files with: $(CC) $(INCFLAGS) $(CPPFLAGS) $(CFLAGS) and link the final library with: $(LDSHARED) -o $@ $(OBJS) $(LIBPATH) $(DLDFLAGS) $(LOCAL_LIBS) $(LIBS) This "new" behavior of `pkg_config()` is problematic when `RbConfig::CONFIG["{C,CPP}FLAGS"]` also provide `-I` flags and `RbConfig::CONFIG["LDFLAGS"]` provides the matching `-L` flags -- for example, if Ruby is compiled with `./configure --with-opt-dir=<dir>`. This would end up with compiling sources with [...] -I<from pkg-config> -I<from RbConfig> [...] and then linking with [...] -L<from RbConfig> -L<from pkg-config> [...] This doesn't seem right. I don't know which should come earlier, but the order should be consistent. The commit in question clearly describes the change in the commit message, but it doesn't have a linked issue. What is it intended for? Also, what is $INCFLAGS? On the other hand, `dir_config()` would prepend `-I` flags to $CPPFLAGS and `-L` flags to $LIBPATH, so it doesn't have issues with flags from `RbConfig`, albeit in a differently way. -- https://bugs.ruby-lang.org/

5 4

[ruby-core:114826] [Ruby master Bug#19894] Memory leak in complemented method entries
by peterzhu2118 (Peter Zhu) 17 Oct '23

17 Oct '23

Issue #19894 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #19894: Memory leak in complemented method entries https://bugs.ruby-lang.org/issues/19894 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: REQUIRED ---------------------------------------- GitHub pull request: https://github.com/ruby/ruby/pull/8481 When a copy of a complemented method entry is created, there are two issues: 1. IMEMO_FL_USER3 is not copied, so the complemented status is not copied over. 2. In rb_method_entry_clone we increment both alias_count and complemented_count. However, when we free the method entry in rb_method_definition_release, we only decrement one of the two counters, resulting in the rb_method_definition_t being leaked. The following script reproduces this issue: ```ruby 10.times do 20_000.times do $c = Class.new do def foo; end end $m = Module.new do refine $c do def foo; end end end Class.new do using $m def initialize o = $c.new o.method(:foo).unbind end end.new end puts `ps -o rss= -p #{$$}` end ``` Before this fix: ``` 17328 19248 21408 23296 25600 27408 29424 31520 33728 35664 ``` After this fix: ``` 16240 17680 18800 19744 20640 21840 22896 24336 25280 26096 ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:114782] [Ruby master Bug#19885] Invalid Warning for Default Gems That Will Move to Bundled Gems
by jeremyevans0 (Jeremy Evans) 13 Oct '23

13 Oct '23

Issue #19885 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #19885: Invalid Warning for Default Gems That Will Move to Bundled Gems https://bugs.ruby-lang.org/issues/19885 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * ruby -v: ruby 3.3.0preview2 (2023-09-14 master e50fcca9a7) [x86_64-openbsd] * Backport: 3.0: DONTNEED, 3.1: DONTNEED, 3.2: DONTNEED ---------------------------------------- Starting in ruby 3.3.0-preview2, attempting to require bigdecimal, mutex_m, base64, or other libraries that will move to bundled gems in Ruby 3.4.0 results in a warning, even when bundler is not in use: ``` $ ruby33 -v -r bigdecimal -e '' ruby 3.3.0preview2 (2023-09-14 master e50fcca9a7) [x86_64-openbsd] warning: bigdecimal which will be not part of the default gems since Ruby 3.4.0 ``` I think such warnings are bugs if bundler is not in use. When a library is moved from a default gem to a bundled gem, such code will work fine if not using bundler. It is only when using bundler where such code would have problems, and therefore, if Ruby warns at all, it should only warn when bundler is in use. The only time such a warning would make sense if bundler is not in use is if the library was not going to be a bundled gem. In that case, first the library should be moved from a default gem to a bundled gem, then the bundled gem that ships with Ruby should provide the warning, which you can avoid by installing an updated gem version. Note that you also get the warning when loading a gem that has bigdecimal as a runtime dependency (this example uses Sequel 5.72.0, which has a runtime dependency on bigdecimal as you can see at https://rubygems.org/gems/sequel/versions/5.72.0) ``` $ ruby33 -v -r sequel -e '' ruby 3.3.0preview2 (2023-09-14 master e50fcca9a7) [x86_64-openbsd] /usr/local/lib/ruby/gems/3.3/gems/sequel-5.72.0/lib/sequel/core.rb:3: warning: bigdecimal which will be not part of the default gems since Ruby 3.4.0 ``` This warning makes even less sense, because even if bigdecimal was removed as both a default gem and a bundled gem, installing Sequel 5.72.0 would install bigdecimal as a dependency. -- https://bugs.ruby-lang.org/

4 5