January 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:120047] [Ruby master Bug#20920] When loading a file, __FILE__ gets relative paths expanded only when they start with "./"
by deivid 13 Feb '25

13 Feb '25

Issue #20920 has been reported by deivid (David Rodríguez). ---------------------------------------- Bug #20920: When loading a file, __FILE__ gets relative paths expanded only when they start with "./" https://bugs.ruby-lang.org/issues/20920 * Author: deivid (David Rodríguez) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- $ cat foo.rb puts __FILE__ $ ruby foo.rb foo.rb $ ruby ./foo.rb ./foo.rb $ ruby -e 'load "foo.rb"' foo.rb $ ruby -e 'load "./foo.rb"' /full/path/to/foo.rb ``` More than an issue, this is mainly a question. In principle, it seems more consistent to me to either expand or not expand, but this is not causing real issues for me. I just want to figure out what to do with one pending spec in Bundler (https://github.com/rubygems/rubygems/blob/cd65092deb3168759820c613ecbc54cd9…) -- https://bugs.ruby-lang.org/

5 5

[ruby-core:120850] [Ruby master Bug#21102] Unexpected encoding when concatenating ASCII string with ASCII compatible string with non ASCII encoding
by toy (Ivan Kuchin) 13 Feb '25

13 Feb '25

Issue #21102 has been reported by toy (Ivan Kuchin). ---------------------------------------- Bug #21102: Unexpected encoding when concatenating ASCII string with ASCII compatible string with non ASCII encoding https://bugs.ruby-lang.org/issues/21102 * Author: toy (Ivan Kuchin) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The problem was noticed in code that is boiled down to: ```ruby # encoding: UTF-8 str = "something" p str.encoding # => #<Encoding:UTF-8> p [nil, str].join.encoding # => #<Encoding:US-ASCII> ``` As `nil.to_s` is an empty string with encoding `ASCII` and `"something"` is `ASCII` compatible string, the result is a string with `ASCII` encoding. Event simpler example is `p (nil.to_s + "something").encoding`. Confusing is that resulting encoding depends on order and on compatibility of string encodings: ```ruby # encoding: UTF-8 str1 = "something" # ASCII compatible str2 = "söméthíng" # not ASCII compatible p (nil.to_s + str1).encoding # => #<Encoding:US-ASCII> p (nil.to_s + str2).encoding # => #<Encoding:UTF-8> p (str1 + nil.to_s).encoding # => #<Encoding:UTF-8> p (str2 + nil.to_s).encoding # => #<Encoding:UTF-8> ``` I would expect it to behave akin to summing integers and floats or rationals: ```ruby p 1 + 1.0 # => 2.0 p 1.0 + 1 # => 2.0 p 1 + 1r # => (2/1) p 1r + 1 # => (2/1) ``` So it is at least surprising to me. #18579 is probably the most related, but also #14975 and #20594 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:113033] [Ruby master Feature#19555] Allow passing default options to `Data.define`
by p8 (Petrik de Heus) 13 Feb '25

13 Feb '25

Issue #19555 has been reported by p8 (Petrik de Heus). ---------------------------------------- Feature #19555: Allow passing default options to `Data.define` https://bugs.ruby-lang.org/issues/19555 * Author: p8 (Petrik de Heus) * Status: Open * Priority: Normal ---------------------------------------- Defining a subclass of `Data` with default attributes can currently be implemented by overriding `intialize`: ```ruby class Point < Data.define(:x, :y, :z) def initialize(x:, y:, z: 0) = super end p Point.new(1, 2) #=> #<data Point x=1, y=2, z=0> ``` It would be nice if we could do it in `define` as well: ```ruby Point = Data.define(:x, :y, z: 0) ``` -- https://bugs.ruby-lang.org/

5 6

[ruby-core:120747] [Ruby master Feature#21082] Alias it to its
by northeastprince (Matt Almeida) 13 Feb '25

13 Feb '25

Issue #21082 has been reported by northeastprince (Matt Almeida). ---------------------------------------- Feature #21082: Alias it to its https://bugs.ruby-lang.org/issues/21082 * Author: northeastprince (Matt Almeida) * Status: Open ---------------------------------------- One of Ruby's core tenants is beautiful code - and a key part of that is sweating names. Adding `it` as a pointer to the first block parameter was a huge step forward in that regard, but we're not done yet. If `[1, 2, 3].each { puts it }` works, `posts.each { puts its.title }` should work too. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:120573] [Ruby master Misc#21019] DevMeeting-2025-02-13
by mame (Yusuke Endoh) 08 Feb '25

08 Feb '25

Issue #21019 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #21019: DevMeeting-2025-02-13 https://bugs.ruby-lang.org/issues/21019 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2025/02/13 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2025/02/10. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

5 4

[ruby-core:120749] [Ruby master Feature#21084] Declare objects have weak references
by peterzhu2118 (Peter Zhu) 06 Feb '25

06 Feb '25

Issue #21084 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Feature #21084: Declare objects have weak references https://bugs.ruby-lang.org/issues/21084 * Author: peterzhu2118 (Peter Zhu) * Status: Open ---------------------------------------- # Summary The current way of marking weak references uses `rb_gc_mark_weak(VALUE *ptr)`. This presents challenges because Ruby's GC is incremental, meaning that if the `ptr` changes (e.g. realloc'd or free'd), then we could have an invalid memory access. This also overwrites `*ptr = Qundef` if `*ptr` is dead, which prevents any cleanup to be run (e.g. freeing memory or deleting entries from hash tables). This ticket proposes `rb_gc_declare_weak_references` which declares that an object has weak references and calls a cleanup function after marking, allowing the object to clean up any memory for dead objects. # Introduction In [[Feature #19783]](https://bugs.ruby-lang.org/issues/19783), I introduced an API allowing objects to mark weak references, the function signature looks like this: ```c void rb_gc_mark_weak(VALUE *ptr); ``` `rb_gc_mark_weak` is called during the marking phase of the GC to specify that the memory at `ptr` holds a pointer to a Ruby object that is weakly referenced. `rb_gc_mark_weak` appends this pointer to a list that is processed after the marking phase of the GC. If the object at `*ptr` is no longer alive, then it overwrites the object reference with a special value (`*ptr = Qundef`). However, this API resulted in two challenges: 1. Ruby's default GC is incremental, which means that the GC is not ran in one phase, but rather split into chunks of work that interleaves with Ruby execution. The `ptr` passed into `rb_gc_mark_weak` could be on the malloc heap, and that memory could be realloc'd or even free'd. We had to use workarounds such as `rb_gc_remove_weak` to ensure that there were no illegal memory accesses. This made `rb_gc_mark_weak` difficult to use, impacted runtime performance, and increased memory usage. 2. When an object dies, `rb_gc_mark_weak` only overwites the reference with `Qundef`. This means that if we want to do any cleanup (e.g. free a piece of memory or delete a hash table entry), we could not do that and had to defer this process elsewhere (e.g. during marking or runtime). # Declarative weak references In this ticket, I'm proposing a new API for weak references. Instead of an object marking its weak references during the marking phase, the object declares that it has weak references using the `rb_gc_declare_weak_references` function. This declaration occurs during runtime (e.g. after the object has been created) rather than during GC. After an object declares that it has weak references, it will have its callback function called after marking as long as that object is alive. This callback function can then call a special function `rb_gc_handle_weak_references_alive_p` to determine whether its references are alive. This will allow the callback function to do whatever it wants on the object, allowing it to perform any cleanup work it needs. This significantly simplifies the code for `ObjectSpace::WeakMap` and `ObjectSpace::WeakKeyMap` because it no longer needs to have the workarounds for the limitations of `rb_gc_mark_weak`. # Performance The performance results below demonstrate that `ObjectSpace::WeakMap#[]=` is now about 60% faster because the implementation has been simplified and the number of allocations has been reduced. We can see that there is not a significant impact on the performance of `ObjectSpace::WeakMap#[]`. Base: ``` ObjectSpace::WeakMap#[]= 4.620M (± 6.4%) i/s (216.44 ns/i) - 23.342M in 5.072149s ObjectSpace::WeakMap#[] 30.967M (± 1.9%) i/s (32.29 ns/i) - 154.998M in 5.007157s ``` Branch: ``` ObjectSpace::WeakMap#[]= 7.336M (± 2.8%) i/s (136.31 ns/i) - 36.755M in 5.013983s ObjectSpace::WeakMap#[] 30.902M (± 5.4%) i/s (32.36 ns/i) - 155.901M in 5.064060s ``` Code: ``` require "bundler/inline" gemfile do source "https://rubygems.org" gem "benchmark-ips" end wmap = ObjectSpace::WeakMap.new key = Object.new val = Object.new wmap[key] = val Benchmark.ips do |x| x.report("ObjectSpace::WeakMap#[]=") do |times| i = 0 while i < times wmap[Object.new] = Object.new i += 1 end end x.report("ObjectSpace::WeakMap#[]") do |times| i = 0 while i < times wmap[key] wmap[val] # does not exist i += 1 end end end ``` # Alternative designs Currently, `rb_gc_declare_weak_references` is designed to be an internal-only API. This allows us to assume the object types that call `rb_gc_declare_weak_references`. In the future, if we want to open up this API to third parties, we may want to change this function to something like: ```c void rb_gc_add_cleaner(VALUE obj, void (*callback)(VALUE obj)); ``` This will allow the third party to implement a custom `callback` that gets called after the marking phase of GC to clean up any dead references. I chose not to implement this design because it is less efficient as we would need to store a mapping from `obj` to `callback`, which requires extra memory. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:116983] [Ruby master Feature#20309] Bundled gems for Ruby 3.5
by hsbt (Hiroshi SHIBATA) 06 Feb '25

06 Feb '25

Issue #20309 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Feature #20309: Bundled gems for Ruby 3.5 https://bugs.ruby-lang.org/issues/20309 * Author: hsbt (Hiroshi SHIBATA) * Status: Assigned * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- I propose migrate the following default gems to bundled gems at Ruby 3.5. So, It means users will get warnings if users try to load them. * ostruct * irb * reline * readline (wrapper file for readline-ext and reline) * io-console * logger * fiddle * pstore * open-uri * yaml (wrapper file for psych) * win32ole I have a plan to migrate the following default gems too. But I need to more feedback from other committers about them. * rdoc * We need to change build task like download rdoc gem before document generation. * or We make document generation is optional from Ruby 3.5 * We explicitly separate `make install` and `make install-doc` * un * `ruby -run` is one of cool feature of Ruby. Should we avoid uninstalling `un` gem? * singleton * This is famous design pattern. Should we enforce users add them to their Gemfile? * forwadable * `reline` needs to add forwardable their `runtime_dependency` after migration. * weakref * I'm not sure how impact after migrating bundled gems. * fcntl * Should we integrate these constants into ruby core? I would like to migrate `ipaddr` and `uri` too. But these are used by webrick that is mock server for our test suite. We need to rewrite `webrick` with `TCPSocker` or extract `ipaddr` and `uri` dependency from `webrick` Other default gems depend on our build process or other libraries deeply. I will update this proposal if I could extract them from default gems. -- https://bugs.ruby-lang.org/

9 27

[ruby-core:120643] [Ruby master Feature#21033] Allow lambdas that don't access `self` to be Ractor shareable
by tenderlovemaking (Aaron Patterson) 04 Feb '25

04 Feb '25

Issue #21033 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Feature #21033: Allow lambdas that don't access `self` to be Ractor shareable https://bugs.ruby-lang.org/issues/21033 * Author: tenderlovemaking (Aaron Patterson) * Status: Open ---------------------------------------- Hi, I would like to allow lambdas that don't access `self` to be eligible for Ractor shareability regardless of the shareability status of `self`. Consider the following code: ```ruby class Foo def make_lambda x = 123 lambda { x } end end Ractor.make_shareable(Foo.new.make_lambda) ``` With Ruby 3.4.X, this will raise an exception. The reason is because `self`, which is an unfrozen instance of `Foo`, is not shareable. However, we can see from the code that the lambda doesn't access `self`. I would like to make lambdas such as the ones above eligible for shareability, and I've submitted a patch [here](https://github.com/ruby/ruby/pull/12567). I think we can detect access to `self` by scanning the instructions in the lambda. Any references to `putself`, `getinstancevariable`, or `setinstancevariable` will result in using the default behavior (checking the frozen status of `self`). ## Considerations ### What about `eval`? I think that `eval` is not a problem because calling eval has an implicit reference to `self`: ``` $ ./miniruby --dump=insns -e 'lambda { eval("123") }' == disasm: #<ISeq:<main>@-e:1 (1,0)-(1,22)> 0000 putself ( 1)[Li] 0001 send <calldata!mid:lambda, argc:0, FCALL>, block in <main> 0004 leave == disasm: #<ISeq:block in <main>@-e:1 (1,7)-(1,22)> 0000 putself ( 1)[LiBc] 0001 putchilledstring "123" 0003 opt_send_without_block <calldata!mid:eval, argc:1, FCALL|ARGS_SIMPLE> 0005 leave [Br] ``` If we try to call `eval` inside the lambda, there will be an implicit `putself` instruction added which means we will fall back to the old behavior. ### What about `binding`? If you call `binding` from inside the `lambda` there will be a `putself` instruction so we fall back to the old behavior. This is the same as the `eval` case. ### What about `binding` via a local? If you assign `binding` to a local, shareability will fail because the `lambda` references an unshareable local: ```ruby class Foo def make_lambda x = binding lambda { x } end end b = Foo.new.make_lambda # exception because local `x` is not shareable Ractor.make_shareable(b) ``` ### What about accessing `binding` via the proc itself? The lambda can references itself via a local and access binding, but again this will fail isolation when locals are scanned: ```ruby class Foo def make_lambda x = lambda { x.binding.eval("self") } end end b = Foo.new.make_lambda # exception because local `x` is not shareable Ractor.make_shareable(b) ``` I _think_ I've covered all cases where `self` can possibly escape. I would appreciate any feedback. Again, [here is the patch](https://github.com/ruby/ruby/pull/12567). Thanks. -- https://bugs.ruby-lang.org/

4 17

[ruby-core:120795] [Ruby master Bug#21090] SEGV from require in Thread in Ractor
by wanabe (_ wanabe) 02 Feb '25

02 Feb '25

Issue #21090 has been reported by wanabe (_ wanabe). ---------------------------------------- Bug #21090: SEGV from require in Thread in Ractor https://bugs.ruby-lang.org/issues/21090 * Author: wanabe (_ wanabe) * Status: Open * ruby -v: ruby 3.5.0dev (2025-01-18T00:19:17Z origin/master 65a7c69188) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When ruby calls 'require' in Thread in non-main Ractor, it can cause SEGV sometimes. ``` $ ruby -e '1000.times { Ractor.new { th = Thread.new { require "rbconfig" }; Thread.pass }.take }' > segv.log 2>&1 Segmentation fault (core dumped) ``` `segv.log` is too large to paste in this description, so I attached as a file. ---Files-------------------------------- segv.log (36.9 KB) -- https://bugs.ruby-lang.org/

2 2

[ruby-core:120774] [Ruby master Bug#21087] "try to mark T_NONE object" error in ActiveRecord with 3.4.1 upgrade
by p8 (Petrik de Heus) 02 Feb '25

02 Feb '25

Issue #21087 has been reported by p8 (Petrik de Heus). ---------------------------------------- Bug #21087: "try to mark T_NONE object" error in ActiveRecord with 3.4.1 upgrade https://bugs.ruby-lang.org/issues/21087 * Author: p8 (Petrik de Heus) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The TechEmpower benchmarks for `rage` fail when setting the `isolation_level` to `:fiber`. The bug can be replicated by checking out [the branch](https://github.com/p8/FrameworkBenchmarks/tree/rage/fiber) and running the following: ```bash ./tfb --test rage --type fortune ``` The error: ``` rage: rb_obj_info_dump: �s�� rage: /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/explain_registry.rb:34: [BUG] try to mark T_NONE object rage: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +YJIT +PRISM [aarch64-linux] rage: -- Control frame information ----------------------------------------------- rage: c:0040 p:0007 s:0276 e:000275 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/explain_registry.rb:34 rage: c:0039 p:0003 s:0272 e:000271 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/explain_registry.rb:25 [FINISH] rage: c:0038 p:---- s:0268 e:000267 CFUNC :new rage: c:0037 p:0016 s:0264 e:000260 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/explain_registry.rb:17 rage: c:0036 p:0003 s:0257 e:000256 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/explain_registry.rb:13 rage: c:0035 p:0004 s:0250 e:000249 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/explain_subscriber.rb:13 rage: c:0034 p:0010 s:0243 e:000242 BLOCK /usr/local/bundle/gems/activesupport-7.2.2.1/lib/active_support/notifications/fanout.rb:162 rage: c:0033 p:0005 s:0239 e:000238 BLOCK /usr/local/bundle/gems/activesupport-7.2.2.1/lib/active_support/notifications/fanout.rb:25 rage: c:0032 p:0027 s:0234 e:000233 METHOD <internal:array>:228 rage: c:0031 p:0008 s:0228 e:000227 METHOD /usr/local/bundle/gems/activesupport-7.2.2.1/lib/active_support/notifications/fanout.rb:24 rage: c:0030 p:0010 s:0222 e:000221 METHOD /usr/local/bundle/gems/activesupport-7.2.2.1/lib/active_support/notifications/fanout.rb:122 rage: c:0029 p:0004 s:0217 e:000216 METHOD /usr/local/bundle/gems/activesupport-7.2.2.1/lib/active_support/notifications/fanout.rb:161 rage: c:0028 p:0010 s:0210 e:000209 BLOCK /usr/local/bundle/gems/activesupport-7.2.2.1/lib/active_support/notifications/fanout.rb:259 rage: c:0027 p:0005 s:0206 e:000205 BLOCK /usr/local/bundle/gems/activesupport-7.2.2.1/lib/active_support/notifications/fanout.rb:25 rage: c:0026 p:0027 s:0201 e:000200 METHOD <internal:array>:228 rage: c:0025 p:0008 s:0195 e:000194 METHOD /usr/local/bundle/gems/activesupport-7.2.2.1/lib/active_support/notifications/fanout.rb:24 rage: c:0024 p:0018 s:0189 e:000188 METHOD /usr/local/bundle/gems/activesupport-7.2.2.1/lib/active_support/notifications/fanout.rb:258 rage: c:0023 p:0012 s:0182 e:000181 METHOD /usr/local/bundle/gems/activesupport-7.2.2.1/lib/active_support/notifications/fanout.rb:251 rage: c:0022 p:0035 s:0178 e:000176 METHOD /usr/local/bundle/gems/activesupport-7.2.2.1/lib/active_support/notifications/instrumenter.rb:64 [FINISH] rage: c:0021 p:0047 s:0169 e:000168 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract_adapter.rb:1119 [FINISH] rage: c:0020 p:0031 s:0156 e:000155 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/postgresql_adapter.rb:892 rage: c:0019 p:0041 s:0144 e:000143 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/postgresql_adapter.rb:872 rage: c:0018 p:0026 s:0130 e:000129 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/postgresql/database_statements.rb:66 rage: c:0017 p:0093 s:0118 e:000117 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/database_statements.rb:647 rage: c:0016 p:0064 s:0105 e:000104 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/database_statements.rb:73 [FINISH] rage: c:0015 p:0143 s:0093 e:000092 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/query_cache.rb:251 [FINISH] rage: c:0014 p:0025 s:0080 e:000079 BLOCK /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/relation/calculations.rb:318 rage: c:0013 p:0030 s:0076 e:000075 METHOD /usr/local/bundle/gems/rage-rb-1.11.0/lib/rage/ext/active_record/connection_pool.rb:205 [FINISH] rage: c:0012 p:0011 s:0069 e:000068 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/connection_handling.rb:296 rage: c:0011 p:0022 s:0062 e:000061 BLOCK /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/relation/calculations.rb:317 rage: c:0010 p:0015 s:0059 e:000058 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/relation.rb:1452 rage: c:0009 p:0120 s:0054 e:000053 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/relation/calculations.rb:313 [FINISH] rage: c:0008 p:0012 s:0046 e:000045 METHOD /usr/local/bundle/gems/activerecord-7.2.2.1/lib/active_record/querying.rb:24 rage: c:0007 p:0008 s:0037 e:000036 METHOD /rage/app/controllers/benchmarks_controller.rb:32 rage: c:0006 p:0038 s:0032 e:000031 METHOD /usr/local/bundle/gems/rage-rb-1.11.0/lib/rage/controller/api.rb:98 rage: c:0005 p:0010 s:0028 e:000027 BLOCK (eval at /usr/local/bundle/gems/rage-rb-1.11.0/lib/rage/router/backend.rb:79):1 [FINISH] rage: c:0004 p:0043 s:0023 e:000019 METHOD /usr/local/bundle/gems/rage-rb-1.11.0/lib/rage/application.rb:16 rage: c:0003 p:0008 s:0011 e:000010 BLOCK /usr/local/bundle/gems/rage-rb-1.11.0/lib/rage/middleware/fiber_wrapper.rb:19 [FINISH] rage: c:0002 p:0016 s:0008 e:000005 BLOCK /usr/local/bundle/gems/rage-rb-1.11.0/lib/rage/fiber_scheduler.rb:122 [FINISH] rage: c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] rage: -- Ruby level backtrace information --------------------------------------- ``` -- https://bugs.ruby-lang.org/

3 5