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

[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:115325] [Ruby master Feature#19995] Proposal: Signal._trap as analogue to Process._fork
by kjtsanaktsidis (KJ Tsanaktsidis) 09 Nov '23

09 Nov '23

Issue #19995 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Feature #19995: Proposal: Signal._trap as analogue to Process._fork https://bugs.ruby-lang.org/issues/19995 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Priority: Normal ---------------------------------------- This is a proposal to define a method `Signal#_trap`, which would function as a single place to be wrapped by monitoring libraries for detecting when signal handlers are entered and exited. ## Motivation #1 - stack-based context leaks into signal handlers When writing monitoring & instrumentation libraries, we often want to add context to emitted logs/metrics/etc based on the current call stack. For example, `ActiveSupport::TaggedLogging` allows you to write code like this: ``` $logger = ActiveSupport::TaggedLogging.new(Logger.new($stderr)) def method_one $logger.tagged("method_one") do method_two end end def method_two $logger.tagged("method_two") do $logger.info "hello there" end end method_one # logs "[method_one] [method_two] hello there" ``` Signal handlers can complicate this picture though because they can run at arbitrary points in the program. Using a threadlocal variable to store context, as is commonly done, means that the invoked signal handler shares the context of whatever thread it interrupted. For example, this program will log the "method_one" tag from inside the signal handler: ``` # n.b. - need to use the mono_logger gem instead of stdlib ::Logger because ::Logger contains a mutex, # which cannot be used from a trap handler. $logger = ActiveSupport::TaggedLogging.new(MonoLogger.new($stderr)) Signal.trap(:TERM) do $logger.tagged("term_handler") do $logger.info "goodbye there" exit end end def method_one $logger.tagged("method_one") do Process.kill :TERM, Process.pid sleep end end method_one # logs "[method_one] [term_handler] goodbye there" ``` This is, in my opinion, undesirable. The fact that the signal handler happened to interrupt at this point and not some other point does not mean that the handler has anything at all to do with `method_one`. I would like a way to, in the logger implementation, detect that we have entered a signal handler and switch to a different context stack, so that the above example printed "[term_handler] goodbye there" instead. ## Motivation #2 - avoiding mutex use in signal handlers This motivation is hinted at by the use of the `mono_logger` gem in the preceding example. It’s not legal to use a mutex in a trap handler, which means `::Logger` can’t be used. However, the mutex is there for a good reason - it synchronises writes to the log device amongst multiple threads so that messages are written atomically, even if they’re longer than `PIPE_BUF` (the max size write the OS guarantees is atomic in a single write syscall). Ideally, we would like to use the mutex-based implementation in normal code, but avoid the mutex in trap handlers (possibly writing to a different stream e.g. `$stderr` instead of `$stdout`). For an instrumentation implementation to do this, it needs a way to detect if it’s currently running inside a trap handler. ## Proposed solution I would like to add a "hook" method `Signal._trap`, which works in a similar way to `Process._fork`. Essentially, when Ruby invokes a signal handler, instead of directly invoking the registered proc, it would invoke `Signal._trap`, and _that_ would invoke the proc. This means that by prepending to `Signal.singleton_class`, you could write code which wraps around all signal handlers. My first example could then be re-written like so: ``` $logger = ActiveSupport::TaggedLogging.new(MonoLogger.new($stderr)) Signal.singleton_class.prepend(Module.new do def _trap(signo) old_tags = $logger.pop_tags 1_000_000_000 # ActiveSupport hack; there's no "pop_all" method. super $logger.push_tags old_tags end end) Signal.trap(:TERM) do $logger.tagged("term_handler") do $logger.info "goodbye there" exit end end def method_one $logger.tagged("method_one") do Process.kill :TERM, Process.pid sleep end end method_one # logs "[term_handler] goodbye there" ``` ## Polyfill for older Rubies I believe `Signal._trap` can be fully implemented in a gem for older versions of Ruby; something like the following will work: https://gist.github.com/KJTsanaktsidis/0b263c76523a16a049fa5a035e868a68. This is, again, analogous to how monitoring libraries would handle fork hooking before `_fork` was added - possible, but very tricky and ugly. ## Alternative solution Another option which might help solve the two problems I outlined is to expose the `ec->interrupt_mask |= TRAP_INTERRUPT_MASK flag` as a method on `Signal` or a special `$MAGIC_GLOBAL` variable. This would essentially let code detect whether or not it’s in a trap handler, but not execute specific code around trap handlers. ---- Thanks for your time friends, looking forward to any feedback or discussion! -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115323] [Ruby master Feature#14548] Allow some_array&.[1] to be a valid syntax
by zverok (Victor Shepelev) 09 Nov '23

09 Nov '23

Issue #14548 has been updated by zverok (Victor Shepelev). > What about using `dig` Actually, many codebases are already using `dig` in those cases (and it is _clearer_ without redefinition on `nil`, telling the reader "we are aware there might be `nil` here"): ```ruby array_or_nil&.dig(index) ``` ...but using the proposed solution is shorter and cleaner. > There is also nothing wrong with `array_or_nil && array_or_nil[index]`. ...until it is part of the message chain: ```ruby # bad calculate_some_value(with, some, arguments) && calculate_some_value(with, some, arguments)[index] # wordy, requires inventing new names: intermediate = calculate_some_value(with, some, arguments) intermediate && intermediate[index] ``` Though, even if there is already a variable, `foo && foo[bar]` is already non-DRY and impends reading. > IMO these `?.[` look too cryptic. I honestly don't see how it is more cryptic than `&.foo(`. For the codebases that use `&.` where appropriate, an attempt to write `foo&.[bar]` is what less experienced programmers always try to do, and "why it doesn't work" is more cryptic than if it would. Those are somewhat more confusing, too: ```ruby # I tried to use foo&.[bar], it failed, I know [] is a method and I write this: foo&.[](bar) # I find the above ugly, and I switch to dig: foo&.dig(bar) ``` ...but it is kind of non-standar to use `dig` with one argument, and needs to be remembered as a separate idiom. ---------------------------------------- Feature #14548: Allow some_array&.[1] to be a valid syntax https://bugs.ruby-lang.org/issues/14548#change-105243 * Author: rosenfeld (Rodrigo Rosenfeld Rosas) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Currently, Ruby allows accessing an array's index while testing whether the array is not nil with this syntax: `my_array&.[](1)`. I've always found this awkward but didn't mind about suggesting anything to improve this. I was just reading about how JavaScript is probably going to support myArray?.[1] and found that it read good enough for me. So I'd like to propose about the same syntax, replacing ?. with the Ruby equivalent &. instead. How does that look like to you? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115322] [Ruby master Feature#14548] Allow some_array&.[1] to be a valid syntax
by Eregon (Benoit Daloze) 09 Nov '23

09 Nov '23

Issue #14548 has been updated by Eregon (Benoit Daloze). What about using `dig` for this like `array_or_nil.dig(index)` and adding `class NilClass; def dig(*) = nil; end`? There is also nothing wrong with `array_or_nil && array_or_nil[index]`. IMO these `?.[` look too cryptic. ---------------------------------------- Feature #14548: Allow some_array&.[1] to be a valid syntax https://bugs.ruby-lang.org/issues/14548#change-105242 * Author: rosenfeld (Rodrigo Rosenfeld Rosas) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Currently, Ruby allows accessing an array's index while testing whether the array is not nil with this syntax: `my_array&.[](1)`. I've always found this awkward but didn't mind about suggesting anything to improve this. I was just reading about how JavaScript is probably going to support myArray?.[1] and found that it read good enough for me. So I'd like to propose about the same syntax, replacing ?. with the Ruby equivalent &. instead. How does that look like to you? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114985] [Ruby master Bug#19916] URI#to_s can serialize to a value that doesn't deserialize to the original
by yawboakye (yaw boakye) 09 Nov '23

09 Nov '23

Issue #19916 has been reported by yawboakye (yaw boakye). ---------------------------------------- Bug #19916: URI#to_s can serialize to a value that doesn't deserialize to the original https://bugs.ruby-lang.org/issues/19916 * Author: yawboakye (yaw boakye) * Status: Open * Priority: Normal * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- It appears that when we're serializing a URI to string, we don't check/confirm that it is represented in a form that can be deserialized back into the original. I think it's fair to expect that serialize+deserialize produces an object that is the same as the original, only differing perhaps in terms of the unique object identifier. This isn't the case with URI when they are custom built, which might happen a lot, for example in a Rails app that accepts URL inputs from users. Let me attempt a reproduction, using the generic URI `example.com`. ```ruby example_url = "example.com" example_uri = URI(example_url) ``` Given that no scheme is explicitly set in the URI, it is correctly parsed as generic, with the given `example.com` interpreted as the path. The object returned to is mutable. Since we didn't automatically detect a scheme, let's fix that as well as the hostname. ``` ruby example_uri.scheme = "https" example_uri.hostname = example_uri.path # I've intentionally left path value unchanged, since it helps demonstrate the potential bug. ``` Given that we have a scheme, an authority, and a path, and given that we format URI according to [RFC 3986], one may expect that serializing the URI to string will follow the guidelines of section 3 of the RFC: [Syntax Components], which requires a slash separator between the authority (in our case hostname) and the path. It appears that `URI#to_s` may not do that if path didn't already have a slash prefix. Which would be fine if we were keeping an invariant that ensured that we never produced bad serialized URI. To return to our `example_uri`, serialization produces: ```ruby serialized_uri = example_uri.to_s puts serialized_uri # https://example.comexample.com ``` This is obviously bad. One would have expected `https://example.com/example.com` instead. That is, the slash will be automatically and correctly inserted, just as the double slashes were automatically inserted between the scheme and and the authority. `serialized_uri` cannot be deserialized into `example_uri`, in fact. Below is an attempt at deserialization and a comparison of the new value to the original: ```ruby deserialized_example_uri = URI(serialized_uri) example_uri.scheme == deserialized_example_uri.scheme # true example_uri.hostname == deserialized_example_uri.hostname # false (for, example.com =/= example.comexample.com) example_uri.path == deserialized_example_uri.path # false (for, example.com =/= "") ``` I believe that the ability to serialize and deserialize an object without losing fidelity is a great thing. I believe even more strongly that we should preserve/maintain an invariant that allows us to always serialize a URI to a format that meets the RFC's specification. Therefore I consider this a bug, and I'd be willing to work on a fix, as my first contribution to Ruby, if enough people consider it a bug too. Regards! [RFC 3986]: https://www.rfc-editor.org/rfc/rfc3986 [Syntax Components]: https://www.rfc-editor.org/rfc/rfc3986#section-3 ---Files-------------------------------- Screenshot 2023-09-29 at 12.19.26.png (180 KB) -- https://bugs.ruby-lang.org/

4 3

[ruby-core:115227] [Ruby master Feature#19985] Support `Pathname` for `require`
by vo.x (Vit Ondruch) 09 Nov '23

09 Nov '23

Issue #19985 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Feature #19985: Support `Pathname` for `require` https://bugs.ruby-lang.org/issues/19985 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal ---------------------------------------- It seems that RubyGems / Bundler `require` method overrides of accept `Pathname` as and argument ~~~ $ ruby -rpathname -e ' pa = Pathname.new("test") require pa ' <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require': cannot load such file -- test (LoadError) from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:85:in `require' from -e:3:in `<main>' ~~~ while plain Ruby require does not: ~~~ $ ruby --disable-gems -rpathname -e ' pa = Pathname.new("test") require pa ' -e:3:in `require': no implicit conversion of Pathname into String (TypeError) from -e:3:in `<main>' ~~~ This inconsistency is surprising. It seems that RubyGems / Bundler developers think [1] that Ruby `require` should also accept `Pathname`. ~~~ $ ruby -v ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux] ~~~ [1]: https://github.com/rubygems/rubygems/pull/7128 -- https://bugs.ruby-lang.org/

7 13

[ruby-core:115316] [Ruby master Feature#14548] Allow some_array&.[1] to be a valid syntax
by knu (Akinori MUSHA) 09 Nov '23

09 Nov '23

Issue #14548 has been updated by knu (Akinori MUSHA). Status changed from Rejected to Open Assignee set to matz (Yukihiro Matsumoto) Can we reconsider this? JavaScript already introduced this syntax a while ago and we are already getting pretty much used to it. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators… ```javascript obj.val?.prop obj.val?.[expr] obj.func?.(args) ``` I know `ary&.[]` is ambiguous, but it's extremely rare to call `[]` with no arguments, so let's just keep the compatibility and allow it to swallow the following arguments if any. ---------------------------------------- Feature #14548: Allow some_array&.[1] to be a valid syntax https://bugs.ruby-lang.org/issues/14548#change-105233 * Author: rosenfeld (Rodrigo Rosenfeld Rosas) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Currently, Ruby allows accessing an array's index while testing whether the array is not nil with this syntax: `my_array&.[](1)`. I've always found this awkward but didn't mind about suggesting anything to improve this. I was just reading about how JavaScript is probably going to support myArray?.[1] and found that it read good enough for me. So I'd like to propose about the same syntax, replacing ?. with the Ruby equivalent &. instead. How does that look like to you? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115293] [Ruby master Bug#19992] Seemingly GC causes double free for regparse
by mtasaka (Mamoru Tasaka) 08 Nov '23

08 Nov '23

Issue #19992 has been reported by mtasaka (Mamoru Tasaka). ---------------------------------------- Bug #19992: Seemingly GC causes double free for regparse https://bugs.ruby-lang.org/issues/19992 * Author: mtasaka (Mamoru Tasaka) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-11-07 master ced84beb25) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Using ruby3.3.0dev (now I've tried commit:ced84beb2518d173988bb92c6d96aa854a35abe6 ), trying to execute rubygem-addressable 2.8.5 ( https://github.com/sporkmonger/addressable/releases/tag/addressable-2.8.5 ) testsuite causes ruby segfault: ``` $ LC_ALL=C.UTF-8 rspec -I. spec/ Could not load native IDN implementation. ........................................................................................................................................................................................................................................................................................................................................................................./usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/example_group.rb:530: [BUG] Segmentation fault at 0x00005618a54262ba ruby 3.3.0dev (2023-11-07 master ced84beb25) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0022 p:0009 s:0108 e:000107 METHOD /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/example_group.rb:530 c:0021 p:0004 s:0104 e:000102 BLOCK /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/example_group.rb:536 c:0020 p:0015 s:0099 e:000098 BLOCK /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/example_group.rb:702 [FINISH] c:0019 p:---- s:0095 e:000094 CFUNC :each c:0018 p:0007 s:0091 e:000090 METHOD /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/example_group.rb:701 c:0017 p:0006 s:0086 e:000085 METHOD /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/example_group.rb:535 c:0016 p:0026 s:0081 e:000079 METHOD /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/example_group.rb:556 c:0015 p:0046 s:0075 e:000074 METHOD /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/example_group.rb:606 c:0014 p:0007 s:0066 e:000065 BLOCK /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/runner.rb:121 [FINISH] c:0013 p:---- s:0062 e:000061 CFUNC :map c:0012 p:0030 s:0058 e:000057 BLOCK /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/runner.rb:121 c:0011 p:0026 s:0055 e:000054 METHOD /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/configuration.rb:2070 c:0010 p:0007 s:0051 e:000050 BLOCK /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/runner.rb:116 c:0009 p:0009 s:0047 e:000046 METHOD /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/reporter.rb:74 c:0008 p:0019 s:0042 e:000041 METHOD /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/runner.rb:115 c:0007 p:0035 s:0035 e:000034 METHOD /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/runner.rb:89 c:0006 p:0058 s:0029 e:000028 METHOD /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/runner.rb:71 c:0005 p:0013 s:0021 e:000020 METHOD /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/runner.rb:45 c:0004 p:0010 s:0016 e:000015 TOP /usr/share/gems/gems/rspec-core-3.12.2/exe/rspec:4 [FINISH] c:0003 p:---- s:0013 e:000012 CFUNC :load c:0002 p:0078 s:0008 E:001e80 EVAL /usr/bin/rspec:25 [FINISH] c:0001 p:0000 s:0003 E:000730 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- /usr/bin/rspec:25:in `<main>' /usr/bin/rspec:25:in `load' /usr/share/gems/gems/rspec-core-3.12.2/exe/rspec:4:in `<top (required)>' /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/runner.rb:45:in `invoke' /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/runner.rb:71:in `run' /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/runner.rb:89:in `run' /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/runner.rb:115:in `run_specs' /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/reporter.rb:74:in `report' /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/runner.rb:116:in `block in run_specs' /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/configuration.rb:2070:in `with_suite_hooks' /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/runner.rb:121:in `block (2 levels) in run_specs' /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/runner.rb:121:in `map' /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/runner.rb:121:in `block (3 levels) in run_specs' /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/example_group.rb:606:in `run' /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/example_group.rb:556:in `run_before_context_hooks' /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/example_group.rb:535:in `store_before_context_ivars' /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/example_group.rb:701:in `each_instance_variable_for_example' /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/example_group.rb:701:in `each' /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/example_group.rb:702:in `block in each_instance_variable_for_example' /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/example_group.rb:536:in `block in store_before_context_ivars' /usr/share/gems/gems/rspec-core-3.12.2/lib/rspec/core/example_group.rb:530:in `before_context_ivars' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 2 -- Machine register context ------------------------------------------------ RIP: 0x00007fe976ebc8e5 RBP: 0x00007ffd7d6c5e80 RSP: 0x00007ffd7d6c5e50 RAX: 0x00007fe9771d5720 RBX: 0xffffffffffffff18 RCX: 0x0000000000000000 RDX: 0x0000000000000000 RDI: 0x00005618a54262c2 RSI: 0x0000561dc49e21a0 R8: 0x0000000561dc49e2 R9: 0x0000000000000007 R10: 0x0000561dc49e2b60 R11: 0x0000000000000000 R12: 0x0000561dc49e21d0 R13: 0x00005618a54262b2 R14: 0x0000000000000001 R15: 0x0000561dc49e2090 EFL: 0x0000000000010206 -- C level backtrace information ------------------------------------------- /lib64/libruby.so.3.3(rb_print_backtrace+0x21) [0x7fe9772750a1] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/vm_dump.c:812 /lib64/libruby.so.3.3(rb_vm_bugreport+0x9aa) [0x7fe977277f2a] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/vm_dump.c:1143 /lib64/libruby.so.3.3(rb_bug_for_fatal_signal+0x110) [0x7fe9770d4420] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/error.c:1065 /lib64/libruby.so.3.3(sigsegv+0x56) [0x7fe9771ec576] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/signal.c:920 /lib64/libc.so.6(__restore_rt+0x0) [0x7fe976e5b990] /lib64/libc.so.6(free+0x25) [0x7fe976ebc8e5] /lib64/libruby.so.3.3(i_free_name_entry+0x19) [0x7fe9771d5739] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/regparse.c:521 /lib64/libruby.so.3.3(rb_st_foreach+0x85) [0x7fe9771eddd5] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/hash.c:870 /lib64/libruby.so.3.3(onig_names_free+0x27) [0x7fe9771da0c7] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/regparse.c:534 /lib64/libruby.so.3.3(onig_free+0x1a) [0x7fe9771cb86a] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/regcomp.c:5682 /lib64/libruby.so.3.3(obj_free.lto_priv.0+0x3d2) [0x7fe9770ec122] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/gc.c:3611 /lib64/libruby.so.3.3(gc_sweep_page.constprop.0+0x168) [0x7fe9772e9058] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/gc.c:5538 /lib64/libruby.so.3.3(gc_sweep_step.lto_priv.0+0xf3) [0x7fe9770ea023] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/gc.c:5905 /lib64/libruby.so.3.3(gc_continue+0x34b) [0x7fe9770f249b] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/gc.c:5977 /lib64/libruby.so.3.3(newobj_alloc+0x2de) [0x7fe9770f28be] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/gc.c:2500 /lib64/libruby.so.3.3(rb_wb_protected_newobj_of+0x74) [0x7fe9770f31a4] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/gc.c:2919 /lib64/libruby.so.3.3(rb_hash_new+0x3c) [0x7fe9770ff19c] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/hash.c:1432 /lib64/libruby.so.3.3(vm_exec_core.lto_priv.0+0x30da) [0x7fe97725dffa] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/redhat-linux-build/insns.def:545 /lib64/libruby.so.3.3(rb_vm_exec+0x17d) [0x7fe97727348d] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/vm.c:2472 /lib64/libruby.so.3.3(rb_yield+0x77) [0x7fe977260707] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/vm.c:1622 /lib64/libruby.so.3.3(rb_ary_each+0x44) [0x7fe977062474] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/array.c:2532 /lib64/libruby.so.3.3(vm_call_cfunc_with_frame_+0x117) [0x7fe977253b27] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/vm_insnhelper.c:3503 /lib64/libruby.so.3.3(vm_sendish+0xb1) [0x7fe9772560a1] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/vm_insnhelper.c:5585 /lib64/libruby.so.3.3(vm_exec_core.lto_priv.0+0x1f7f) [0x7fe97725ce9f] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/redhat-linux-build/insns.def:802 /lib64/libruby.so.3.3(rb_vm_exec+0x17d) [0x7fe97727348d] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/vm.c:2472 /lib64/libruby.so.3.3(rb_yield+0x77) [0x7fe977260707] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/vm.c:1622 /lib64/libruby.so.3.3(rb_ary_collect.lto_priv.0+0x5c) [0x7fe9770626cc] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/array.c:3624 /lib64/libruby.so.3.3(vm_call_cfunc_with_frame_+0x117) [0x7fe977253b27] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/vm_insnhelper.c:3503 /lib64/libruby.so.3.3(vm_sendish+0xb1) [0x7fe9772560a1] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/vm_insnhelper.c:5585 /lib64/libruby.so.3.3(vm_exec_core.lto_priv.0+0x1f7f) [0x7fe97725ce9f] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/redhat-linux-build/insns.def:802 /lib64/libruby.so.3.3(rb_vm_exec+0x17d) [0x7fe97727348d] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/vm.c:2472 /lib64/libruby.so.3.3(rb_load_internal+0x73) [0x7fe977134a63] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/load.c:800 /lib64/libruby.so.3.3(rb_f_load+0xad) [0x7fe977134d4d] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/load.c:875 /lib64/libruby.so.3.3(vm_call_cfunc_with_frame_+0x117) [0x7fe977253b27] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/vm_insnhelper.c:3503 /lib64/libruby.so.3.3(vm_exec_core.lto_priv.0+0x16c) [0x7fe97725b08c] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/vm_insnhelper.c:5581 /lib64/libruby.so.3.3(rb_vm_exec+0x17d) [0x7fe97727348d] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/vm.c:2472 /lib64/libruby.so.3.3(rb_ec_exec_node+0xaa) [0x7fe9770dba9a] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/eval.c:287 /lib64/libruby.so.3.3(ruby_run_node+0x93) [0x7fe9770dda53] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/eval.c:328 /usr/bin/ruby-mri(0x561dc3276197) [0x561dc3276197] /lib64/libc.so.6(__libc_start_call_main+0x7a) [0x7fe976e4514a] /lib64/libc.so.6(__libc_start_main+0x8b) [0x7fe976e4520b] /usr/bin/ruby-mri(_start+0x25) [0x561dc32761e5] /usr/src/debug/ruby-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64/main.c:59 -- Other runtime information ----------------------------------------------- * Process memory map: 561dc3275000-561dc3276000 r--p 00000000 08:08 6714104 /usr/bin/ruby-mri 561dc3276000-561dc3277000 r-xp 00001000 08:08 6714104 /usr/bin/ruby-mri 561dc3277000-561dc3278000 r--p 00002000 08:08 6714104 /usr/bin/ruby-mri 561dc3278000-561dc3279000 r--p 00002000 08:08 6714104 /usr/bin/ruby-mri 561dc3279000-561dc327a000 rw-p 00003000 08:08 6714104 /usr/bin/ruby-mri 561dc34c1000-561dc58f8000 rw-p 00000000 00:00 0 [heap] 7fe94a000000-7fe94bf6a000 r--s 00000000 08:08 6789556 /usr/lib/debug/usr/lib64/libruby.so.3.3.0-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64.debug 7fe94c000000-7fe94c021000 rw-p 00000000 00:00 0 7fe94c021000-7fe950000000 ---p 00000000 00:00 0 7fe952000000-7fe953f6a000 r--s 00000000 08:08 6789556 /usr/lib/debug/usr/lib64/libruby.so.3.3.0-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64.debug 7fe954000000-7fe954021000 rw-p 00000000 00:00 0 7fe954021000-7fe958000000 ---p 00000000 00:00 0 7fe959600000-7fe959851000 r--s 00000000 08:08 6707607 /usr/lib64/libc.so.6 7fe959a00000-7fe959f64000 r--s 00000000 08:08 6788707 /usr/lib64/libruby.so.3.3.0 7fe959f8f000-7fe959f90000 ---p 00000000 00:00 0 7fe959f90000-7fe95a7f0000 rw-p 00000000 00:00 0 7fe95aaa0000-7fe95ac40000 rw-p 00000000 00:00 0 7fe95ac49000-7fe95ac4d000 r--p 00000000 08:08 6708025 /usr/lib64/libnss_resolve.so.2 7fe95ac4d000-7fe95ac69000 r-xp 00004000 08:08 6708025 /usr/lib64/libnss_resolve.so.2 7fe95ac69000-7fe95ac71000 r--p 00020000 08:08 6708025 /usr/lib64/libnss_resolve.so.2 7fe95ac71000-7fe95ac72000 r--p 00027000 08:08 6708025 /usr/lib64/libnss_resolve.so.2 7fe95ac72000-7fe95ac73000 rw-p 00028000 08:08 6708025 /usr/lib64/libnss_resolve.so.2 7fe95ac73000-7fe95ac78000 r--p 00000000 08:08 6708024 /usr/lib64/libnss_myhostname.so.2 7fe95ac78000-7fe95ac8d000 r-xp 00005000 08:08 6708024 /usr/lib64/libnss_myhostname.so.2 7fe95ac8d000-7fe95ac99000 r--p 0001a000 08:08 6708024 /usr/lib64/libnss_myhostname.so.2 7fe95ac99000-7fe95ac9e000 r--p 00025000 08:08 6708024 /usr/lib64/libnss_myhostname.so.2 7fe95ac9e000-7fe95ac9f000 rw-p 0002a000 08:08 6708024 /usr/lib64/libnss_myhostname.so.2 7fe95ac9f000-7fe95aca0000 ---p 00000000 00:00 0 7fe95aca0000-7fe95b040000 rw-p 00000000 00:00 0 7fe95b050000-7fe95b410000 rw-p 00000000 00:00 0 7fe95b41f000-7fe95b421000 r--p 00000000 08:08 6714089 /usr/lib64/libyaml-0.so.2.0.9 7fe95b421000-7fe95b43a000 r-xp 00002000 08:08 6714089 /usr/lib64/libyaml-0.so.2.0.9 7fe95b43a000-7fe95b43e000 r--p 0001b000 08:08 6714089 /usr/lib64/libyaml-0.so.2.0.9 7fe95b43e000-7fe95b43f000 r--p 0001e000 08:08 6714089 /usr/lib64/libyaml-0.so.2.0.9 7fe95b43f000-7fe95b570000 rw-p 00000000 00:00 0 7fe95b571000-7fe95b574000 r--p 00000000 08:08 6789373 /usr/lib64/gems/ruby/bigdecimal-3.1.5/bigdecimal.so 7fe95b574000-7fe95b588000 r-xp 00003000 08:08 6789373 /usr/lib64/gems/ruby/bigdecimal-3.1.5/bigdecimal.so 7fe95b588000-7fe95b58b000 r--p 00017000 08:08 6789373 /usr/lib64/gems/ruby/bigdecimal-3.1.5/bigdecimal.so 7fe95b58b000-7fe95b58c000 r--p 0001a000 08:08 6789373 /usr/lib64/gems/ruby/bigdecimal-3.1.5/bigdecimal.so 7fe95b58c000-7fe95b58d000 rw-p 0001b000 08:08 6789373 /usr/lib64/gems/ruby/bigdecimal-3.1.5/bigdecimal.so 7fe95b58d000-7fe95b591000 r--p 00000000 08:08 6788798 /usr/lib64/ruby/zlib.so 7fe95b591000-7fe95b59b000 r-xp 00004000 08:08 6788798 /usr/lib64/ruby/zlib.so 7fe95b59b000-7fe95b59e000 r--p 0000e000 08:08 6788798 /usr/lib64/ruby/zlib.so 7fe95b59e000-7fe95b59f000 r--p 00010000 08:08 6788798 /usr/lib64/ruby/zlib.so 7fe95b59f000-7fe95b5c0000 rw-p 00000000 00:00 0 7fe95b5ce000-7fe95b5d5000 r--p 00000000 08:08 6788794 /usr/lib64/ruby/socket.so 7fe95b5d5000-7fe95b5f7000 r-xp 00007000 08:08 6788794 /usr/lib64/ruby/socket.so 7fe95b5f7000-7fe95b5fe000 r--p 00029000 08:08 6788794 /usr/lib64/ruby/socket.so 7fe95b5fe000-7fe95b5ff000 r--p 00030000 08:08 6788794 /usr/lib64/ruby/socket.so 7fe95b5ff000-7fe95b600000 rw-p 00031000 08:08 6788794 /usr/lib64/ruby/socket.so 7fe95b600000-7fe95b780000 rw-p 00000000 00:00 0 7fe95b790000-7fe95b8a0000 rw-p 00000000 00:00 0 7fe95b8a6000-7fe95b8a8000 r--p 00000000 08:08 6707981 /usr/lib64/libcap.so.2.48 7fe95b8a8000-7fe95b8ac000 r-xp 00002000 08:08 6707981 /usr/lib64/libcap.so.2.48 7fe95b8ac000-7fe95b8ae000 r--p 00006000 08:08 6707981 /usr/lib64/libcap.so.2.48 7fe95b8ae000-7fe95b8af000 r--p 00007000 08:08 6707981 /usr/lib64/libcap.so.2.48 7fe95b8af000-7fe95b8b0000 rw-p 00008000 08:08 6707981 /usr/lib64/libcap.so.2.48 7fe95b8b0000-7fe95b940000 rw-p 00000000 00:00 0 7fe95b940000-7fe95b945000 r--s 00000000 08:08 6789371 /usr/lib/debug/usr/bin/ruby-mri-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64.debug 7fe95b945000-7fe95b947000 r--p 00000000 08:08 6788795 /usr/lib64/ruby/stringio.so 7fe95b947000-7fe95b94c000 r-xp 00002000 08:08 6788795 /usr/lib64/ruby/stringio.so 7fe95b94c000-7fe95b94e000 r--p 00007000 08:08 6788795 /usr/lib64/ruby/stringio.so 7fe95b94e000-7fe95b94f000 r--p 00008000 08:08 6788795 /usr/lib64/ruby/stringio.so 7fe95b94f000-7fe95ba10000 rw-p 00000000 00:00 0 7fe95ba10000-7fe95ba15000 r--s 00000000 08:08 6789371 /usr/lib/debug/usr/bin/ruby-mri-3.3.0~20231107.1312gitced84beb25-183.fc40.283.x86_64.debug 7fe95ba15000-7fe95ba16000 r--p 00000000 08:08 6788784 /usr/lib64/ruby/io/wait.so 7fe95ba16000-7fe95ba17000 r-xp 00001000 08:08 6788784 /usr/lib64/ruby/io/wait.so 7fe95ba17000-7fe95ba18000 r--p 00002000 08:08 6788784 /usr/lib64/ruby/io/wait.so 7fe95ba18000-7fe95ba19000 r--p 00002000 08:08 6788784 /usr/lib64/ruby/io/wait.so 7fe95ba19000-7fe95ba1a000 rw-p 00000000 00:00 0 7fe95ba1a000-7fe95ba1b000 r--p 00000000 08:08 6788779 /usr/lib64/ruby/erb/escape.so 7fe95ba1b000-7fe95ba1c000 r-xp 00001000 08:08 6788779 /usr/lib64/ruby/erb/escape.so 7fe95ba1c000-7fe95ba1d000 r--p 00002000 08:08 6788779 /usr/lib64/ruby/erb/escape.so 7fe95ba1d000-7fe95ba1e000 r--p 00002000 08:08 6788779 /usr/lib64/ruby/erb/escape.so 7fe95ba1e000-7fe95ba1f000 rw-p 00000000 00:00 0 7fe95ba1f000-7fe95ba20000 ---p 00000000 00:00 0 7fe95ba20000-7fe95bac1000 rw-p 00000000 00:00 0 7fe95bac1000-7fe95bac2000 ---p 00000000 00:00 0 7fe95bac2000-7fe95bb63000 rw-p 00000000 00:00 0 7fe95bb63000-7fe95bb64000 ---p 00000000 00:00 0 7fe95bb64000-7fe95bc05000 rw-p 00000000 00:00 0 7fe95bc05000-7fe95bc06000 ---p 00000000 00:00 0 7fe95bc06000-7fe95bca7000 rw-p 00000000 00:00 0 7fe95bca7000-7fe95bca8000 ---p 00000000 00:00 0 7fe95bca8000-7fe95bd49000 rw-p 00000000 00:00 0 7fe95bd49000-7fe95bd4a000 ---p 00000000 00:00 0 7fe95bd4a000-7fe95bdeb000 rw-p 00000000 00:00 0 7fe95bdeb000-7fe95bdec000 ---p 00000000 00:00 0 7fe95bdec000-7fe95be8d000 rw-p 00000000 00:00 0 7fe95be8d000-7fe95be8e000 ---p 00000000 00:00 0 7fe95be8e000-7fe95bf2f000 rw-p 00000000 00:00 0 7fe95bf2f000-7fe95bf30000 ---p 00000000 00:00 0 7fe95bf30000-7fe95bfd1000 rw-p 00000000 00:00 0 7fe95bfd1000-7fe95bfd2000 ---p 00000000 00:00 0 7fe95bfd2000-7fe95c073000 rw-p 00000000 00:00 0 7fe95c073000-7fe95c074000 ---p 00000000 00:00 0 7fe95c074000-7fe95c115000 rw-p 00000000 00:00 0 7fe95c115000-7fe95c116000 ---p 00000000 00:00 0 7fe95c116000-7fe95c1b7000 rw-p 00000000 00:00 0 7fe95c1b7000-7fe95c1b8000 ---p 00000000 00:00 0 7fe95c1b8000-7fe95c259000 rw-p 00000000 00:00 0 7fe95c259000-7fe95c25a000 ---p 00000000 00:00 0 7fe95c25a000-7fe95c2fb000 rw-p 00000000 00:00 0 7fe95c2fb000-7fe95c2fc000 ---p 00000000 00:00 0 7fe95c2fc000-7fe95c39d000 rw-p 00000000 00:00 0 7fe95c39d000-7fe95c39e000 ---p 00000000 00:00 0 7fe95c39e000-7fe95c43f000 rw-p 00000000 00:00 0 7fe95c43f000-7fe95c440000 ---p 00000000 00:00 0 7fe95c440000-7fe95c4e1000 rw-p 00000000 00:00 0 7fe95c4e1000-7fe95c4e2000 ---p 00000000 00:00 0 7fe95c4e2000-7fe95c583000 rw-p 00000000 00:00 0 7fe95c583000-7fe95c584000 ---p 00000000 00:00 0 7fe95c584000-7fe95c625000 rw-p 00000000 00:00 0 7fe95c625000-7fe95c626000 ---p 00000000 00:00 0 7fe95c626000-7fe95c6c7000 rw-p 00000000 00:00 0 7fe95c6c7000-7fe95c6c8000 ---p 00000000 00:00 0 7fe95c6c8000-7fe95c769000 rw-p 00000000 00:00 0 7fe95c769000-7fe95c76a000 ---p 00000000 00:00 0 7fe95c76a000-7fe95c80b000 rw-p 00000000 00:00 0 7fe95c80b000-7fe95c80c000 ---p 00000000 00:00 0 7fe95c80c000-7fe95c8ad000 rw-p 00000000 00:00 0 7fe95c8ad000-7fe95c8ae000 ---p 00000000 00:00 0 7fe95c8ae000-7fe95c94f000 rw-p 00000000 00:00 0 7fe95c94f000-7fe95c950000 ---p 00000000 00:00 0 7fe95c950000-7fe95c9f1000 rw-p 00000000 00:00 0 7fe95c9f1000-7fe95c9f2000 ---p 00000000 00:00 0 7fe95c9f2000-7fe95ca93000 rw-p 00000000 00:00 0 7fe95ca93000-7fe95ca94000 ---p 00000000 00:00 0 7fe95ca94000-7fe95cb35000 rw-p 00000000 00:00 0 7fe95cb35000-7fe95cb36000 ---p 00000000 00:00 0 7fe95cb36000-7fe95cbd7000 rw-p 00000000 00:00 0 7fe95cbd7000-7fe95cbd8000 ---p 00000000 00:00 0 7fe95cbd8000-7fe95cc79000 rw-p 00000000 00:00 0 7fe95cc79000-7fe95cc7a000 ---p 00000000 00:00 0 7fe95cc7a000-7fe95cd1b000 rw-p 00000000 00:00 0 7fe95cd1b000-7fe95cd1c000 ---p 00000000 00:00 0 7fe95cd1c000-7fe95cdbd000 rw-p 00000000 00:00 0 7fe95cdbd000-7fe95cdbe000 ---p 00000000 00:00 0 7fe95cdbe000-7fe95ce5f000 rw-p 00000000 00:00 0 7fe95ce5f000-7fe95ce60000 ---p 00000000 00:00 0 7fe95ce60000-7fe95d6b0000 rw-p 00000000 00:00 0 7fe95d6b0000-7fe95d6b2000 r--p 00000000 08:08 6788796 /usr/lib64/ruby/strscan.so 7fe95d6b2000-7fe95d6b5000 r-xp 00002000 08:08 6788796 /usr/lib64/ruby/strscan.so 7fe95d6b5000-7fe95d6b6000 r--p 00005000 08:08 6788796 /usr/lib64/ruby/strscan.so 7fe95d6b6000-7fe95d6b7000 r--p 00006000 08:08 6788796 /usr/lib64/ruby/strscan.so 7fe95d6b7000-7fe95d6b8000 rw-p 00000000 00:00 0 7fe95d6b8000-7fe95d6ba000 r--p 00000000 08:08 6788708 /usr/lib64/ruby/cgi/escape.so 7fe95d6ba000-7fe95d6bc000 r-xp 00002000 08:08 6788708 /usr/lib64/ruby/cgi/escape.so 7fe95d6bc000-7fe95d6bd000 r--p 00004000 08:08 6788708 /usr/lib64/ruby/cgi/escape.so 7fe95d6bd000-7fe95d6be000 r--p 00004000 08:08 6788708 /usr/lib64/ruby/cgi/escape.so 7fe95d6be000-7fe976abf000 rw-p 00000000 00:00 0 7fe976ac2000-7fe976ac6000 r--s 00000000 08:08 6714104 /usr/bin/ruby-mri 7fe976ac6000-7fe976ac9000 r--p 00000000 08:08 6714117 /usr/lib64/gems/ruby/psych-5.1.1.1/psych.so 7fe976ac9000-7fe976acd000 r-xp 00003000 08:08 6714117 /usr/lib64/gems/ruby/psych-5.1.1.1/psych.so 7fe976acd000-7fe976ace000 r--p 00007000 08:08 6714117 /usr/lib64/gems/ruby/psych-5.1.1.1/psych.so 7fe976ace000-7fe976acf000 r--p 00008000 08:08 6714117 /usr/lib64/gems/ruby/psych-5.1.1.1/psych.so 7fe976acf000-7fe976b30000 rw-p 00000000 00:00 0 7fe976b32000-7fe976b33000 r--p 00000000 08:08 6788785 /usr/lib64/ruby/monitor.so 7fe976b33000-7fe976b34000 r-xp 00001000 08:08 6788785 /usr/lib64/ruby/monitor.so 7fe976b34000-7fe976b35000 r--p 00002000 08:08 6788785 /usr/lib64/ruby/monitor.so 7fe976b35000-7fe976b36000 r--p 00002000 08:08 6788785 /usr/lib64/ruby/monitor.so 7fe976b36000-7fe976b37000 rw-p 00000000 00:00 0 7fe976b37000-7fe976b38000 r--p 00000000 08:08 6788765 /usr/lib64/ruby/enc/trans/transdb.so 7fe976b38000-7fe976b39000 r-xp 00001000 08:08 6788765 /usr/lib64/ruby/enc/trans/transdb.so 7fe976b39000-7fe976b3a000 r--p 00002000 08:08 6788765 /usr/lib64/ruby/enc/trans/transdb.so 7fe976b3a000-7fe976b3b000 r--p 00002000 08:08 6788765 /usr/lib64/ruby/enc/trans/transdb.so 7fe976b3b000-7fe976c3d000 rw-p 00000000 00:00 0 7fe976c3d000-7fe976c96000 r--p 00000000 08:08 6707590 /usr/lib/locale/C.utf8/LC_CTYPE 7fe976c96000-7fe976ca6000 r--p 00000000 08:08 6707610 /usr/lib64/libm.so.6 7fe976ca6000-7fe976d1c000 r-xp 00010000 08:08 6707610 /usr/lib64/libm.so.6 7fe976d1c000-7fe976d76000 r--p 00086000 08:08 6707610 /usr/lib64/libm.so.6 7fe976d76000-7fe976d77000 r--p 000df000 08:08 6707610 /usr/lib64/libm.so.6 7fe976d77000-7fe976d78000 rw-p 000e0000 08:08 6707610 /usr/lib64/libm.so.6 7fe976d78000-7fe976d89000 r--p 00000000 08:08 6707959 /usr/lib64/libgmp.so.10.4.1 7fe976d89000-7fe976e05000 r-xp 00011000 08:08 6707959 /usr/lib64/libgmp.so.10.4.1 7fe976e05000-7fe976e1a000 r--p 0008d000 08:08 6707959 /usr/lib64/libgmp.so.10.4.1 7fe976e1a000-7fe976e1c000 r--p 000a1000 08:08 6707959 /usr/lib64/libgmp.so.10.4.1 7fe976e1c000-7fe976e1d000 rw-p 000a3000 08:08 6707959 /usr/lib64/libgmp.so.10.4.1 7fe976e1d000-7fe976e43000 r--p 00000000 08:08 6707607 /usr/lib64/libc.so.6 7fe976e43000-7fe976fa4000 r-xp 00026000 08:08 6707607 /usr/lib64/libc.so.6 7fe976fa4000-7fe976ff2000 r--p 00187000 08:08 6707607 /usr/lib64/libc.so.6 7fe976ff2000-7fe976ff6000 r--p 001d4000 08:08 6707607 /usr/lib64/libc.so.6 7fe976ff6000-7fe976ff8000 rw-p 001d8000 08:08 6707607 /usr/lib64/libc.so.6 7fe976ff8000-7fe977000000 rw-p 00000000 00:00 0 7fe977000000-7fe977049000 r--p 00000000 08:08 6788707 /usr/lib64/libruby.so.3.3.0 7fe977049000-7fe9773bf000 r-xp 00049000 08:08 6788707 /usr/lib64/libruby.so.3.3.0 7fe9773bf000-7fe977527000 r--p 003bf000 08:08 6788707 /usr/lib64/libruby.so.3.3.0 7fe977527000-7fe977540000 r--p 00526000 08:08 6788707 /usr/lib64/libruby.so.3.3.0 7fe977540000-7fe977541000 rw-p 0053f000 08:08 6788707 /usr/lib64/libruby.so.3.3.0 7fe977541000-7fe977556000 rw-p 00000000 00:00 0 7fe977559000-7fe97755a000 r--p 00000000 08:08 6788722 /usr/lib64/ruby/enc/encdb.so 7fe97755a000-7fe97755b000 r-xp 00001000 08:08 6788722 /usr/lib64/ruby/enc/encdb.so 7fe97755b000-7fe97755c000 r--p 00002000 08:08 6788722 /usr/lib64/ruby/enc/encdb.so 7fe97755c000-7fe97755d000 r--p 00002000 08:08 6788722 /usr/lib64/ruby/enc/encdb.so 7fe97755d000-7fe97755e000 rw-p 00000000 00:00 0 7fe97755e000-7fe977565000 r--s 00000000 08:08 6707673 /usr/lib64/gconv/gconv-modules.cache 7fe977565000-7fe977568000 rw-p 00000000 00:00 0 7fe977568000-7fe97756b000 r--p 00000000 08:08 6706024 /usr/lib64/libgcc_s-13-20231011.so.1 7fe97756b000-7fe977586000 r-xp 00003000 08:08 6706024 /usr/lib64/libgcc_s-13-20231011.so.1 7fe977586000-7fe97758a000 r--p 0001e000 08:08 6706024 /usr/lib64/libgcc_s-13-20231011.so.1 7fe97758a000-7fe97758b000 r--p 00021000 08:08 6706024 /usr/lib64/libgcc_s-13-20231011.so.1 7fe97758b000-7fe97758e000 rw-p 00000000 00:00 0 7fe97758e000-7fe977590000 r--p 00000000 08:08 6707999 /usr/lib64/libcrypt.so.2.0.0 7fe977590000-7fe9775a4000 r-xp 00002000 08:08 6707999 /usr/lib64/libcrypt.so.2.0.0 7fe9775a4000-7fe9775bd000 r--p 00016000 08:08 6707999 /usr/lib64/libcrypt.so.2.0.0 7fe9775bd000-7fe9775be000 r--p 0002e000 08:08 6707999 /usr/lib64/libcrypt.so.2.0.0 7fe9775be000-7fe9775c7000 rw-p 00000000 00:00 0 7fe9775c7000-7fe9775ca000 r--p 00000000 08:08 6707836 /usr/lib64/libz.so.1.2.13 7fe9775ca000-7fe9775d9000 r-xp 00003000 08:08 6707836 /usr/lib64/libz.so.1.2.13 7fe9775d9000-7fe9775df000 r--p 00012000 08:08 6707836 /usr/lib64/libz.so.1.2.13 7fe9775df000-7fe9775e0000 r--p 00018000 08:08 6707836 /usr/lib64/libz.so.1.2.13 7fe9775e0000-7fe9775e3000 rw-p 00000000 00:00 0 7fe9775e6000-7fe9775e7000 r--p 00000000 08:08 6707604 /usr/lib64/ld-linux-x86-64.so.2 7fe9775e7000-7fe97760e000 r-xp 00001000 08:08 6707604 /usr/lib64/ld-linux-x86-64.so.2 7fe97760e000-7fe977618000 r--p 00028000 08:08 6707604 /usr/lib64/ld-linux-x86-64.so.2 7fe977618000-7fe97761a000 r--p 00031000 08:08 6707604 /usr/lib64/ld-linux-x86-64.so.2 7fe97761a000-7fe97761c000 rw-p 00033000 08:08 6707604 /usr/lib64/ld-linux-x86-64.so.2 7ffd7cec9000-7ffd7d6c8000 rw-p 00000000 00:00 0 [stack] 7ffd7d7c9000-7ffd7d7cd000 r--p 00000000 00:00 0 [vvar] 7ffd7d7cd000-7ffd7d7cf000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] Aborted (core dumped) ``` Looks like running testsuite brings about GC for ruby regex and it seems to cause segfault. valgrind says: ``` ==93== Invalid free() / delete / delete[] / realloc() ==93== at 0x4845B2C: free (vg_replace_malloc.c:985) ==93== by 0x4A2E738: i_free_name_entry (regparse.c:521) ==93== by 0x4A46DD4: UnknownInlinedFun (hash.c:870) ==93== by 0x4A46DD4: UnknownInlinedFun (st.c:1516) ==93== by 0x4A46DD4: rb_st_foreach (st.c:1613) ==93== by 0x4A330C6: UnknownInlinedFun (regparse.c:534) ==93== by 0x4A330C6: onig_names_free (regparse.c:545) ==93== by 0x4A24869: UnknownInlinedFun (regcomp.c:5682) ==93== by 0x4A24869: onig_free (regcomp.c:5679) ==93== by 0x4945121: obj_free.lto_priv.0 (gc.c:3611) ==93== by 0x4B42057: UnknownInlinedFun (gc.c:5538) ==93== by 0x4B42057: gc_sweep_page.constprop.0 (gc.c:5623) ==93== by 0x4943022: gc_sweep_step.lto_priv.0 (gc.c:5905) ==93== by 0x494B49A: UnknownInlinedFun (gc.c:5977) ==93== by 0x494B49A: gc_continue (gc.c:2488) ==93== by 0x494B8BD: UnknownInlinedFun (gc.c:2500) ==93== by 0x494B8BD: UnknownInlinedFun (gc.c:2715) ==93== by 0x494B8BD: newobj_alloc (gc.c:2816) ==93== by 0x494C1A3: UnknownInlinedFun (gc.c:2919) ==93== by 0x494C1A3: UnknownInlinedFun (gc.c:2936) ==93== by 0x494C1A3: rb_wb_protected_newobj_of (gc.c:2951) ==93== by 0x495819B: UnknownInlinedFun (hash.c:1432) ==93== by 0x495819B: UnknownInlinedFun (hash.c:1443) ==93== by 0x495819B: rb_hash_new (hash.c:1457) ==93== Address 0x223e3ec0 is 0 bytes inside a block of size 6 free'd ==93== at 0x4845B2C: free (vg_replace_malloc.c:985) ==93== by 0x4A2E738: i_free_name_entry (regparse.c:521) ==93== by 0x4A46DD4: UnknownInlinedFun (hash.c:870) ==93== by 0x4A46DD4: UnknownInlinedFun (st.c:1516) ==93== by 0x4A46DD4: rb_st_foreach (st.c:1613) ==93== by 0x4A330C6: UnknownInlinedFun (regparse.c:534) ==93== by 0x4A330C6: onig_names_free (regparse.c:545) ==93== by 0x4A24869: UnknownInlinedFun (regcomp.c:5682) ==93== by 0x4A24869: onig_free (regcomp.c:5679) ==93== by 0x4945121: obj_free.lto_priv.0 (gc.c:3611) ==93== by 0x4B42057: UnknownInlinedFun (gc.c:5538) ==93== by 0x4B42057: gc_sweep_page.constprop.0 (gc.c:5623) ==93== by 0x4943022: gc_sweep_step.lto_priv.0 (gc.c:5905) ==93== by 0x494B49A: UnknownInlinedFun (gc.c:5977) ==93== by 0x494B49A: gc_continue (gc.c:2488) ==93== by 0x494B8BD: UnknownInlinedFun (gc.c:2500) ==93== by 0x494B8BD: UnknownInlinedFun (gc.c:2715) ==93== by 0x494B8BD: newobj_alloc (gc.c:2816) ==93== by 0x494C1A3: UnknownInlinedFun (gc.c:2919) ==93== by 0x494C1A3: UnknownInlinedFun (gc.c:2936) ==93== by 0x494C1A3: rb_wb_protected_newobj_of (gc.c:2951) ==93== by 0x495819B: UnknownInlinedFun (hash.c:1432) ==93== by 0x495819B: UnknownInlinedFun (hash.c:1443) ==93== by 0x495819B: rb_hash_new (hash.c:1457) ==93== Block was alloc'd at ==93== at 0x484280F: malloc (vg_replace_malloc.c:442) ==93== by 0x4A3AFA9: UnknownInlinedFun (regparse.c:287) ==93== by 0x4A3AFA9: UnknownInlinedFun (regparse.c:887) ==93== by 0x4A3AFA9: UnknownInlinedFun (regparse.c:5150) ==93== by 0x4A3AFA9: parse_exp (regparse.c:6227) ==93== by 0x4A3B1E6: parse_branch (regparse.c:6585) ==93== by 0x4A3B477: parse_subexp (regparse.c:6646) ==93== by 0x4A39C1A: UnknownInlinedFun (regparse.c:5074) ==93== by 0x4A39C1A: parse_exp (regparse.c:6227) ==93== by 0x4A3B2D4: parse_branch (regparse.c:6598) ==93== by 0x4A3B396: parse_subexp (regparse.c:6631) ==93== by 0x4A3B5DD: UnknownInlinedFun (regparse.c:6680) ==93== by 0x4A3B5DD: onig_parse_make_tree (regparse.c:6725) ==93== by 0x4A24B5E: onig_compile_ruby (regcomp.c:5866) ==93== by 0x4A18AA7: UnknownInlinedFun (re.c:876) ==93== by 0x4A18AA7: UnknownInlinedFun (re.c:900) ==93== by 0x4A18AA7: rb_reg_initialize (re.c:3265) ==93== by 0x4A18D0C: rb_reg_initialize_str (re.c:3299) ==93== by 0x4A18E0E: rb_reg_init_str (re.c:3334) ``` so looks like this is double-free. Currently I am unable to create minimum reproducer. -- https://bugs.ruby-lang.org/

4 5

[ruby-core:115310] [Ruby master Feature#14602] Version of dig that raises error if a key is not present
by mame (Yusuke Endoh) 08 Nov '23

08 Nov '23

Issue #14602 has been updated by mame (Yusuke Endoh). As far as I understand, Matz expects that, for a tree structure: * `dig_*` touches only nodes on a specific path, * `deep_*` touches all nodes. ---------------------------------------- Feature #14602: Version of dig that raises error if a key is not present https://bugs.ruby-lang.org/issues/14602#change-105226 * Author: amcaplan (Ariel Caplan) * Status: Open * Priority: Normal ---------------------------------------- Currently, if I have a hash like this: ~~~ ruby { :name => { :first => "Ariel", :last => "Caplan" } } ~~~ and I want to navigate confidently and raise a KeyError if something is missing, I can do: ~~~ ruby hash.fetch(:name).fetch(:first) ~~~ Unfortunately, the length of the name, combined with the need to repeat the method name every time, means most programmers are more likely to do this: ~~~ ruby hash[:name][:first] ~~~ which leads to many unexpected errors. The Hash#dig method made it easy to access methods safely from a nested hash; I'd like to have something similar for access without error protection, and I'd think the most natural name would be Hash#dig!. It would work like this: ~~~ ruby hash = { :name => { :first => "Ariel", :last => "Caplan" } } hash.dig!(:name, :first) # => Ariel hash.dig!(:name, :middle) # raises KeyError (key not found: :middle) hash.dig!(:name, :first, :foo) # raises TypeError (String does not have #dig! method) ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115309] [Ruby master Feature#14602] Version of dig that raises error if a key is not present
by Eregon (Benoit Daloze) 08 Nov '23

08 Nov '23

Issue #14602 has been updated by Eregon (Benoit Daloze). mame (Yusuke Endoh) wrote in #note-30: > * `deep` sounds to be an operation on the entire data structure, due to the influence of deep_copy. It actually is a deep operation, on the entire data structure/multiple objects, exactly like deep_copy would. So it seems a perfect match, no? ---------------------------------------- Feature #14602: Version of dig that raises error if a key is not present https://bugs.ruby-lang.org/issues/14602#change-105225 * Author: amcaplan (Ariel Caplan) * Status: Open * Priority: Normal ---------------------------------------- Currently, if I have a hash like this: ~~~ ruby { :name => { :first => "Ariel", :last => "Caplan" } } ~~~ and I want to navigate confidently and raise a KeyError if something is missing, I can do: ~~~ ruby hash.fetch(:name).fetch(:first) ~~~ Unfortunately, the length of the name, combined with the need to repeat the method name every time, means most programmers are more likely to do this: ~~~ ruby hash[:name][:first] ~~~ which leads to many unexpected errors. The Hash#dig method made it easy to access methods safely from a nested hash; I'd like to have something similar for access without error protection, and I'd think the most natural name would be Hash#dig!. It would work like this: ~~~ ruby hash = { :name => { :first => "Ariel", :last => "Caplan" } } hash.dig!(:name, :first) # => Ariel hash.dig!(:name, :middle) # raises KeyError (key not found: :middle) hash.dig!(:name, :first, :foo) # raises TypeError (String does not have #dig! method) ~~~ -- https://bugs.ruby-lang.org/

1 0