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

[ruby-core:112606] [Ruby master Bug#18572] Performance regression when invoking refined methods
by Eregon (Benoit Daloze) 25 Feb '23

25 Feb '23

Issue #18572 has been updated by Eregon (Benoit Daloze). palkan (Vladimir Dementyev) wrote in #note-4: > As far as I understand, this line is responsible for "the 13 seconds" boot time overhead: https://github.com/ruby/ruby/blob/master/eval.c#L1342 (I was able to achieve similar results by adding tons of `using` to the source code). The line was added in the same commit as mentioned above, so the root cause is the same for sure. Oh yeah, good find, clearing all method lookup caches on every call to `using` with `ObjectSpace.each_object` is terrible for performance. It likely throws away all JITed code too. A bit like `extend` used to blow up every method lookup inline cache a long time ago. I guess we need to wait for @ko1 to fix that. This is probably fixable but might require some changes to the overall method lookup design, which is then quite involved (from looking at similar things in TruffleRuby). My concern above is mainly the whole complexity of refinements in Ruby implementations and some parts of the semantics are/were unsound (e.g. `super` in refinements can cause infinite loops, this is being addressed by preventing `include`/`prepend` in a refinement and replacing by `import_methods`, a welcome simplification). ---------------------------------------- Bug #18572: Performance regression when invoking refined methods https://bugs.ruby-lang.org/issues/18572#change-102053 * Author: palkan (Vladimir Dementyev) * Status: Assigned * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Since Ruby 3.0, defining a refinement for a method slows down its execution even if we do not activate the refinement: ```ruby require "benchmark_driver" source = <<~RUBY class Hash def symbolize_keys transform_keys { |key| key.to_sym rescue key } end def refined_symbolize_keys transform_keys { |key| key.to_sym rescue key } end end module HashRefinements refine Hash do def refined_symbolize_keys raise "never called" end end end HASH = {foo: 1, bar: 2, baz: 3} class Foo def original end def refined end end module FooRefinements refine Foo do def refined raise "never called" end end end FOO = Foo.new RUBY Benchmark.driver do |x| x.prelude %Q{ #{source} } x.report "#symbolize_keys original", %{ HASH.symbolize_keys } x.report "#symbolize_keys refined", %{ HASH.refined_symbolize_keys } end Benchmark.driver do |x| x.prelude %Q{ #{source} } x.report "no-op original", %{ FOO.original } x.report "no-op refined", %{ FOO.refined } end ``` The results for Ruby 3.1: ```sh ... Comparison: #symbolize_keys original: 2372420.1 i/s #symbolize_keys refined: 1941019.0 i/s - 1.22x slower ... Comparison: no-op original: 51790974.2 i/s no-op refined: 14456518.9 i/s - 3.58x slower ``` For Ruby 2.6 and 2.7: ```sh Comparison: #symbolize_keys original: 2278339.7 i/s #symbolize_keys refined: 2264153.1 i/s - 1.01x slower ... Comparison: no-op refined: 64178338.5 i/s no-op original: 63357980.1 i/s - 1.01x slower ``` You can find the full code and more results in this [gist](https://gist.github.com/palkan/637dc83edd86d70b5dbf72f2a4d702e5). P.S. The problem was originally noticed by @byroot, see https://github.com/ruby-i18n/i18n/pull/573 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112585] [Ruby master Feature#19466] Class.new takes a block, why doesn't Module.new take a block?
by ioquatix (Samuel Williams) 25 Feb '23

25 Feb '23

Issue #19466 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #19466: Class.new takes a block, why doesn't Module.new take a block? https://bugs.ruby-lang.org/issues/19466 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- ```ruby Class.new do #... equivalent to class_eval end ``` So, why don't we introduce: ```ruby Module.new do #... equivalent to class_eval end ``` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:112517] [Ruby master Feature#19453] Move `Fiber.current` into core.
by ioquatix (Samuel Williams) 24 Feb '23

24 Feb '23

Issue #19453 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #19453: Move `Fiber.current` into core. https://bugs.ruby-lang.org/issues/19453 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) ---------------------------------------- i.e. don't `require 'fiber'` to use `Fiber.current`. Are there other methods we should consider too? -- https://bugs.ruby-lang.org/

2 2

[ruby-core:112579] [Ruby master Bug#18572] Performance regression when invoking refined methods
by palkan (Vladimir Dementyev) 24 Feb '23

24 Feb '23

Issue #18572 has been updated by palkan (Vladimir Dementyev). Eregon (Benoit Daloze) wrote in #note-3: > Interesting, maybe this is partly the cause for the `13 seconds` mentioned in https://shopify.engineering/the-case-against-monkey-patching. As far as I understand, this line is responsible for "the 13 seconds" boot time overhead: https://github.com/ruby/ruby/blob/master/eval.c#L1342 (I was able to achieve similar results by adding tons of `using` to the source code). The line was added in the same commit as mentioned above, so the root cause is the same for sure. > Maybe we should deprecate refinements: my main concern about them is it's a ton of complexity in Ruby implementations (in method lookup and even worse in super method lookup) and it's not really used much or gains much, so it does not seem worth it. It does make every uncached/cache-filling method lookup slower. > It shouldn't make cached method lookup slower though when no refinements are active in that scope, at least it does not currently in TruffleRuby. But that wasn't the case in Ruby <3; refined methods were fast (b/c cached), and had no effect on the original method calls, like today. I believe, something just got lost along the introduction of disposable call-caches. The problem with "it's not really used much or gains much" is that it took many years for refinements to reach some sort of stability (2.6 and 2.7 releases were pretty good) and finally developers were convinced not to be afraid of the "experimentality" of the feature, and with Ruby 3 we made a huge step back. Especially now, when Shopify engineers claim that "refinements are really slow!" (which is only partially true), we, for sure, should expect the community to turn backs on refinements, again. It's a two-edged sword 🤷‍♂️ ---------------------------------------- Bug #18572: Performance regression when invoking refined methods https://bugs.ruby-lang.org/issues/18572#change-102028 * Author: palkan (Vladimir Dementyev) * Status: Assigned * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Since Ruby 3.0, defining a refinement for a method slows down its execution even if we do not activate the refinement: ```ruby require "benchmark_driver" source = <<~RUBY class Hash def symbolize_keys transform_keys { |key| key.to_sym rescue key } end def refined_symbolize_keys transform_keys { |key| key.to_sym rescue key } end end module HashRefinements refine Hash do def refined_symbolize_keys raise "never called" end end end HASH = {foo: 1, bar: 2, baz: 3} class Foo def original end def refined end end module FooRefinements refine Foo do def refined raise "never called" end end end FOO = Foo.new RUBY Benchmark.driver do |x| x.prelude %Q{ #{source} } x.report "#symbolize_keys original", %{ HASH.symbolize_keys } x.report "#symbolize_keys refined", %{ HASH.refined_symbolize_keys } end Benchmark.driver do |x| x.prelude %Q{ #{source} } x.report "no-op original", %{ FOO.original } x.report "no-op refined", %{ FOO.refined } end ``` The results for Ruby 3.1: ```sh ... Comparison: #symbolize_keys original: 2372420.1 i/s #symbolize_keys refined: 1941019.0 i/s - 1.22x slower ... Comparison: no-op original: 51790974.2 i/s no-op refined: 14456518.9 i/s - 3.58x slower ``` For Ruby 2.6 and 2.7: ```sh Comparison: #symbolize_keys original: 2278339.7 i/s #symbolize_keys refined: 2264153.1 i/s - 1.01x slower ... Comparison: no-op refined: 64178338.5 i/s no-op original: 63357980.1 i/s - 1.01x slower ``` You can find the full code and more results in this [gist](https://gist.github.com/palkan/637dc83edd86d70b5dbf72f2a4d702e5). P.S. The problem was originally noticed by @byroot, see https://github.com/ruby-i18n/i18n/pull/573 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112577] [Ruby master Bug#18572] Performance regression when invoking refined methods
by Eregon (Benoit Daloze) 24 Feb '23

24 Feb '23

Issue #18572 has been updated by Eregon (Benoit Daloze). Interesting, maybe this is partly the cause for the `13 seconds` mentioned in https://shopify.engineering/the-case-against-monkey-patching. Maybe we should deprecate refinements: my main concern about them is it's a ton of complexity in Ruby implementations (in method lookup and even worse in super method lookup) and it's not really used much or gains much, so it does not seem worth it. It does make every uncached/cache-filling method lookup slower. It shouldn't make cached method lookup slower though when no refinements are active in that scope, at least it does not currently in TruffleRuby. For context-independent JITed code there is no clear solution when using refinements, i.e., it might just be uncached lookups (i.e., several hashmap lookups) for calls affected by refinements (calls after `using`), which is terrible performance-wise. Maybe there is a complex solution to fix it but I'm not sure it's worth the complexity and it of course increases further the maintenance cost of refinements. ---------------------------------------- Bug #18572: Performance regression when invoking refined methods https://bugs.ruby-lang.org/issues/18572#change-102026 * Author: palkan (Vladimir Dementyev) * Status: Assigned * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Since Ruby 3.0, defining a refinement for a method slows down its execution even if we do not activate the refinement: ```ruby require "benchmark_driver" source = <<~RUBY class Hash def symbolize_keys transform_keys { |key| key.to_sym rescue key } end def refined_symbolize_keys transform_keys { |key| key.to_sym rescue key } end end module HashRefinements refine Hash do def refined_symbolize_keys raise "never called" end end end HASH = {foo: 1, bar: 2, baz: 3} class Foo def original end def refined end end module FooRefinements refine Foo do def refined raise "never called" end end end FOO = Foo.new RUBY Benchmark.driver do |x| x.prelude %Q{ #{source} } x.report "#symbolize_keys original", %{ HASH.symbolize_keys } x.report "#symbolize_keys refined", %{ HASH.refined_symbolize_keys } end Benchmark.driver do |x| x.prelude %Q{ #{source} } x.report "no-op original", %{ FOO.original } x.report "no-op refined", %{ FOO.refined } end ``` The results for Ruby 3.1: ```sh ... Comparison: #symbolize_keys original: 2372420.1 i/s #symbolize_keys refined: 1941019.0 i/s - 1.22x slower ... Comparison: no-op original: 51790974.2 i/s no-op refined: 14456518.9 i/s - 3.58x slower ``` For Ruby 2.6 and 2.7: ```sh Comparison: #symbolize_keys original: 2278339.7 i/s #symbolize_keys refined: 2264153.1 i/s - 1.01x slower ... Comparison: no-op refined: 64178338.5 i/s no-op original: 63357980.1 i/s - 1.01x slower ``` You can find the full code and more results in this [gist](https://gist.github.com/palkan/637dc83edd86d70b5dbf72f2a4d702e5). P.S. The problem was originally noticed by @byroot, see https://github.com/ruby-i18n/i18n/pull/573 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112574] [Ruby master Bug#18572] Performance regression when invoking refined methods
by palkan (Vladimir Dementyev) 24 Feb '23

24 Feb '23

Issue #18572 has been updated by palkan (Vladimir Dementyev). Checked Ruby 3.2—better than Ruby 3.1 but still noticeable: ```sh Comparison: #symbolize_keys original: 4362026.0 i/s #symbolize_keys refined: 3999755.6 i/s - 1.09x slower Comparison: no-op original: 80631273.5 i/s no-op refined: 29181553.6 i/s - 2.76x slower ``` ---------------------------------------- Bug #18572: Performance regression when invoking refined methods https://bugs.ruby-lang.org/issues/18572#change-102023 * Author: palkan (Vladimir Dementyev) * Status: Assigned * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Since Ruby 3.0, defining a refinement for a method slows down its execution even if we do not activate the refinement: ```ruby require "benchmark_driver" source = <<~RUBY class Hash def symbolize_keys transform_keys { |key| key.to_sym rescue key } end def refined_symbolize_keys transform_keys { |key| key.to_sym rescue key } end end module HashRefinements refine Hash do def refined_symbolize_keys raise "never called" end end end HASH = {foo: 1, bar: 2, baz: 3} class Foo def original end def refined end end module FooRefinements refine Foo do def refined raise "never called" end end end FOO = Foo.new RUBY Benchmark.driver do |x| x.prelude %Q{ #{source} } x.report "#symbolize_keys original", %{ HASH.symbolize_keys } x.report "#symbolize_keys refined", %{ HASH.refined_symbolize_keys } end Benchmark.driver do |x| x.prelude %Q{ #{source} } x.report "no-op original", %{ FOO.original } x.report "no-op refined", %{ FOO.refined } end ``` The results for Ruby 3.1: ```sh ... Comparison: #symbolize_keys original: 2372420.1 i/s #symbolize_keys refined: 1941019.0 i/s - 1.22x slower ... Comparison: no-op original: 51790974.2 i/s no-op refined: 14456518.9 i/s - 3.58x slower ``` For Ruby 2.6 and 2.7: ```sh Comparison: #symbolize_keys original: 2278339.7 i/s #symbolize_keys refined: 2264153.1 i/s - 1.01x slower ... Comparison: no-op refined: 64178338.5 i/s no-op original: 63357980.1 i/s - 1.01x slower ``` You can find the full code and more results in this [gist](https://gist.github.com/palkan/637dc83edd86d70b5dbf72f2a4d702e5). P.S. The problem was originally noticed by @byroot, see https://github.com/ruby-i18n/i18n/pull/573 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112573] [Ruby master Bug#18286] Universal arm64/x86_84 binary built on an x86_64 machine segfaults/is killed on arm64
by benhamilton (Ben Hamilton) 24 Feb '23

24 Feb '23

Issue #18286 has been updated by benhamilton (Ben Hamilton). I also reproduced the `SIGSEGV` from the original bug using a build with debug symbols: ``` * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8) * frame #0: 0x00000001002444b4 ruby`ruby_vm_special_exception_copy [inlined] RBASIC_CLASS(obj=0) at rbasic.h:155:25 frame #1: 0x00000001002444b4 ruby`ruby_vm_special_exception_copy(exc=0) at vm_insnhelper.c:52:42 frame #2: 0x0000000100244584 ruby`ec_stack_overflow(ec=0x0000000100704920, setup=1) at vm_insnhelper.c:65:16 frame #3: 0x0000000100244504 ruby`rb_ec_stack_overflow(ec=0x0000000100704920, crit=0) at vm_insnhelper.c:97:5 frame #4: 0x000000010026b544 ruby`rb_call0(ec=0x0000000100704920, recv=4300956680, mid=3121, argc=1, argv=0x000000016fdff3e0, call_scope=<unavailable>, self=4) at rgengc.h:0:9 frame #5: 0x000000010013ca30 ruby`rb_class_new_instance [inlined] rb_class_new_instance_kw(argc=1, argv=0x000000016fdff3e0, klass=<unavailable>, kw_splat=0) at object.c:2025:5 frame #6: 0x000000010013c9f0 ruby`rb_class_new_instance(argc=1, argv=0x000000016fdff3e0, klass=<unavailable>) at object.c:2033:12 frame #7: 0x00000001000953c0 ruby`rb_exc_new_str(etype=<unavailable>, str=4300956720) at error.c:1145:12 frame #8: 0x000000010025d668 ruby`rb_vm_register_special_exception_str(sp=ruby_error_reenter, cls=<unavailable>, mesg=<unavailable>) at vm.c:2872:17 frame #9: 0x00000001000a1d50 ruby`Init_eval at eval.c:2091:5 frame #10: 0x00000001000d51fc ruby`rb_call_inits at inits.c:41:5 frame #11: 0x000000010009fa14 ruby`ruby_setup at eval.c:89:9 frame #12: 0x000000010009fa90 ruby`ruby_init at eval.c:101:17 frame #13: 0x0000000100004610 ruby`main [inlined] rb_main(argc=1, argv=0x000000016fdff938) at main.c:37:5 frame #14: 0x0000000100004604 ruby`main(argc=1, argv=0x000000016fdff938) at main.c:57:12 frame #15: 0x000000018599be50 dyld`start + 2544 (snip) (lldb) print *ec (rb_execution_context_t) $7 = { vm_stack = 0x0000000108028000 vm_stack_size = 131072 cfp = 0x0000000108127fc0 tag = 0x000000016fdff4b0 interrupt_flag = 0 interrupt_mask = 0 fiber_ptr = 0x00000001007048d0 thread_ptr = 0x0000000100704260 local_storage = NULL local_storage_recursive_hash = 4 local_storage_recursive_hash_for_trace = 4 storage = 4 root_lep = 0x0000000000000000 root_svar = 0 ensure_list = NULL trace_arg = NULL errinfo = 4 passed_block_handler = 0 raised_flag = '\0' method_missing_reason = MISSING_NOENTRY private_const_reference = 0 machine = { stack_start = 0x000000016fdff4ac stack_end = 0x000000016fdff2c0 stack_maxsize = 0 (snip) (lldb) print ec->machine.stack_start (VALUE *) $4 = 0x000000016fdff4ac (lldb) print ec->machine.stack_end (VALUE *) $5 = 0x000000016fdff2c0 (lldb) print ec->machine.stack_end - ec->machine.stack_start (long) $6 = -61 (snip) (lldb) print ruby_stack_length(NULL) (size_t) $8 = 18446744073709551529 ``` Looks like it's got the stack direction backwards. I checked `config.log`, and it's incorrectly detecting the stack length as `+1` (growing towards larger addresses) for `arm64`: ``` | #if defined __x86_64__ | #define STACK_GROW_DIRECTION -1 | #endif /* defined __x86_64__ */ | #if defined __arm64__ | #define STACK_GROW_DIRECTION +1 (snip) rb_cv_stack_grow_dir_arm64=+1 rb_cv_stack_grow_dir_x86_64=-1 ``` Sent PR https://github.com/ruby/ruby/pull/7373 with this fix as well. ---------------------------------------- Bug #18286: Universal arm64/x86_84 binary built on an x86_64 machine segfaults/is killed on arm64 https://bugs.ruby-lang.org/issues/18286#change-102022 * Author: ccaviness (Clay Caviness) * Status: Open * Priority: Normal * ruby -v: 3.0.2 * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- A universal arm64/x86_84 ruby binary for macOS built on a x86_64 machine segfaults/is killed when executed on an arm64 machine. To reproduce: * On an Intel Mac: `git clone https://github.com/ruby/ruby && cd ruby && git checkout v3_0_2 && ./autogen.sh && ./configure --with-arch=arm64,x86_64 && make -j$(sysctl -n hw.ncpu)` * Copy the built `./ruby` binary to an Apple Silicon machine * Attempt to execute it Expected: The universal `ruby` binary works correctly on both devices Actual: The universal `ruby` binary crashes with either `Segmentation fault: 11` or `Killed: 9` (this seems to occur if `arm64e` is used instead of `arm64`). Details: I'm attempting to build a universal Ruby for macOS that will run on both Intel (x86_64) and Apple Silicon (arm64) machines. It seemed initially that this was as easy as adding `--with-arch=arm64,x86_64` to `./configure` would do it, as it produced a `ruby` binary that reports as `Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]` This `ruby` works correctly on the Intel machine I built in on, but does not work when copied to an Apple Silicon device. The reverse, however, seems to work. That is, if I build the universal ruby on an Apple Silicon machine, the `ruby` binary that's built seems to work correctly on both Intel and Apple Silicon machines. Intel: ``` $ ./ruby -v ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [universal.x86_64-darwin21] ``` Apple Silicon: ``` $ ./ruby -v Segmentation fault: 11 $ lldb ./ruby (lldb) target create "./ruby" Current executable set to '/Users/crc/ruby' (arm64). (lldb) run Process 77071 launched: '/Users/crc/ruby' (arm64) Process 77071 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8) frame #0: 0x00000001002176b8 ruby`ruby_vm_special_exception_copy + 16 ruby`ruby_vm_special_exception_copy: -> 0x1002176b8 <+16>: ldr x0, [x0, #0x8] 0x1002176bc <+20>: bl 0x10011fed8 ; rb_class_real 0x1002176c0 <+24>: bl 0x10012070c ; rb_obj_alloc 0x1002176c4 <+28>: mov x20, x0 Target 0: (ruby) stopped. (lldb) ^D ``` I also attempted the same thing with ruby 2.7.4 source, with the same result. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112563] [Ruby master Bug#18286] Universal arm64/x86_84 binary built on an x86_64 machine segfaults/is killed on arm64
by benhamilton (Ben Hamilton) 23 Feb '23

23 Feb '23

Issue #18286 has been updated by benhamilton (Ben Hamilton). Sent PR https://github.com/ruby/ruby/pull/7367 with a fix. ---------------------------------------- Bug #18286: Universal arm64/x86_84 binary built on an x86_64 machine segfaults/is killed on arm64 https://bugs.ruby-lang.org/issues/18286#change-102012 * Author: ccaviness (Clay Caviness) * Status: Open * Priority: Normal * ruby -v: 3.0.2 * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- A universal arm64/x86_84 ruby binary for macOS built on a x86_64 machine segfaults/is killed when executed on an arm64 machine. To reproduce: * On an Intel Mac: `git clone https://github.com/ruby/ruby && cd ruby && git checkout v3_0_2 && ./autogen.sh && ./configure --with-arch=arm64,x86_64 && make -j$(sysctl -n hw.ncpu)` * Copy the built `./ruby` binary to an Apple Silicon machine * Attempt to execute it Expected: The universal `ruby` binary works correctly on both devices Actual: The universal `ruby` binary crashes with either `Segmentation fault: 11` or `Killed: 9` (this seems to occur if `arm64e` is used instead of `arm64`). Details: I'm attempting to build a universal Ruby for macOS that will run on both Intel (x86_64) and Apple Silicon (arm64) machines. It seemed initially that this was as easy as adding `--with-arch=arm64,x86_64` to `./configure` would do it, as it produced a `ruby` binary that reports as `Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]` This `ruby` works correctly on the Intel machine I built in on, but does not work when copied to an Apple Silicon device. The reverse, however, seems to work. That is, if I build the universal ruby on an Apple Silicon machine, the `ruby` binary that's built seems to work correctly on both Intel and Apple Silicon machines. Intel: ``` $ ./ruby -v ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [universal.x86_64-darwin21] ``` Apple Silicon: ``` $ ./ruby -v Segmentation fault: 11 $ lldb ./ruby (lldb) target create "./ruby" Current executable set to '/Users/crc/ruby' (arm64). (lldb) run Process 77071 launched: '/Users/crc/ruby' (arm64) Process 77071 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8) frame #0: 0x00000001002176b8 ruby`ruby_vm_special_exception_copy + 16 ruby`ruby_vm_special_exception_copy: -> 0x1002176b8 <+16>: ldr x0, [x0, #0x8] 0x1002176bc <+20>: bl 0x10011fed8 ; rb_class_real 0x1002176c0 <+24>: bl 0x10012070c ; rb_obj_alloc 0x1002176c4 <+28>: mov x20, x0 Target 0: (ruby) stopped. (lldb) ^D ``` I also attempted the same thing with ruby 2.7.4 source, with the same result. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112562] [Ruby master Bug#13831] error when try to install
by joshc (Josh C) 23 Feb '23

23 Feb '23

Issue #13831 has been updated by joshc (Josh C). We've been carrying a patch for this issue for many years now and I submitted a PR: https://github.com/ruby/ruby/pull/7366 It affects ruby 3.2.1 through 1.9.3. ---------------------------------------- Bug #13831: error when try to install https://bugs.ruby-lang.org/issues/13831#change-102011 * Author: khaledal (khaled alajmi) * Status: Third Party's Issue * Priority: Normal * ruby -v: ruby 2.4.1p111 (2017-03-22 revision 58053) [x64-mingw32] * Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN ---------------------------------------- ruby 2.4.1p111 (2017-03-22 revision 58053) [x64-mingw32] C:\Users\K>gem install sass C:/Ruby24-x64/lib/ruby/2.4.0/win32/registry.rb:72:in `find': unknown encoding name - CP720 (ArgumentError) from C:/Ruby24-x64/lib/ruby/2.4.0/win32/registry.rb:72:in `<module:Win32>' from C:/Ruby24-x64/lib/ruby/2.4.0/win32/registry.rb:4:in `<top (required)>' from C:/Ruby24-x64/lib/ruby/site_ruby/2.4.0/ruby_installer/runtime/msys2_installation.rb:46:in `require' from C:/Ruby24-x64/lib/ruby/site_ruby/2.4.0/ruby_installer/runtime/msys2_installation.rb:46:in `iterate_msys_paths' from C:/Ruby24-x64/lib/ruby/site_ruby/2.4.0/ruby_installer/runtime/msys2_installation.rb:69:in `msys_path' from C:/Ruby24-x64/lib/ruby/site_ruby/2.4.0/ruby_installer/runtime/msys2_installation.rb:82:in `mingw_bin_path' from C:/Ruby24-x64/lib/ruby/site_ruby/2.4.0/ruby_installer/runtime/msys2_installation.rb:92:in `enable_dll_search_paths' from C:/Ruby24-x64/lib/ruby/site_ruby/2.4.0/ruby_installer/runtime/singleton.rb:27:in `enable_dll_search_paths' from C:/Ruby24-x64/lib/ruby/2.4.0/rubygems/defaults/operating_system.rb:3:in `<top (required)>' from C:/Ruby24-x64/lib/ruby/2.4.0/rubygems.rb:1345:in `require' from C:/Ruby24-x64/lib/ruby/2.4.0/rubygems.rb:1345:in `<top (required)>' from <internal:gem_prelude>:4:in `require' from <internal:gem_prelude>:4:in `<internal:gem_prelude>' C:\Users\K> -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112561] [Ruby master Bug#18286] Universal arm64/x86_84 binary built on an x86_64 machine segfaults/is killed on arm64
by benhamilton (Ben Hamilton) 23 Feb '23

23 Feb '23

Issue #18286 has been updated by benhamilton (Ben Hamilton). I think I know what the problem is. During the build, Ruby has special logic to serialize its own `builtin` module to disk using the binary `iseq` format during the build (I assume for speed so it doesn't have to parse `builtin` every time it starts up). However, since `iseq` format is architecture-specific, when building on x86_64 for universal x86_64 + arm64, the serialized `builtin` module is written with the `x86_64` architecture of the build machine, which fails this check whenever `ruby` imports the `builtin` module on arm64: https://github.com/ruby/ruby/blob/1fdaa0666086529b3aae2d509a2e71c4247c3a12/… Thankfully, there's logic to disable this feature for cross-compiled builds: https://github.com/ruby/ruby/blob/1fdaa0666086529b3aae2d509a2e71c4247c3a12/… We just need to enable this for universal builds as well. ---------------------------------------- Bug #18286: Universal arm64/x86_84 binary built on an x86_64 machine segfaults/is killed on arm64 https://bugs.ruby-lang.org/issues/18286#change-102010 * Author: ccaviness (Clay Caviness) * Status: Open * Priority: Normal * ruby -v: 3.0.2 * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- A universal arm64/x86_84 ruby binary for macOS built on a x86_64 machine segfaults/is killed when executed on an arm64 machine. To reproduce: * On an Intel Mac: `git clone https://github.com/ruby/ruby && cd ruby && git checkout v3_0_2 && ./autogen.sh && ./configure --with-arch=arm64,x86_64 && make -j$(sysctl -n hw.ncpu)` * Copy the built `./ruby` binary to an Apple Silicon machine * Attempt to execute it Expected: The universal `ruby` binary works correctly on both devices Actual: The universal `ruby` binary crashes with either `Segmentation fault: 11` or `Killed: 9` (this seems to occur if `arm64e` is used instead of `arm64`). Details: I'm attempting to build a universal Ruby for macOS that will run on both Intel (x86_64) and Apple Silicon (arm64) machines. It seemed initially that this was as easy as adding `--with-arch=arm64,x86_64` to `./configure` would do it, as it produced a `ruby` binary that reports as `Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]` This `ruby` works correctly on the Intel machine I built in on, but does not work when copied to an Apple Silicon device. The reverse, however, seems to work. That is, if I build the universal ruby on an Apple Silicon machine, the `ruby` binary that's built seems to work correctly on both Intel and Apple Silicon machines. Intel: ``` $ ./ruby -v ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [universal.x86_64-darwin21] ``` Apple Silicon: ``` $ ./ruby -v Segmentation fault: 11 $ lldb ./ruby (lldb) target create "./ruby" Current executable set to '/Users/crc/ruby' (arm64). (lldb) run Process 77071 launched: '/Users/crc/ruby' (arm64) Process 77071 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8) frame #0: 0x00000001002176b8 ruby`ruby_vm_special_exception_copy + 16 ruby`ruby_vm_special_exception_copy: -> 0x1002176b8 <+16>: ldr x0, [x0, #0x8] 0x1002176bc <+20>: bl 0x10011fed8 ; rb_class_real 0x1002176c0 <+24>: bl 0x10012070c ; rb_obj_alloc 0x1002176c4 <+28>: mov x20, x0 Target 0: (ruby) stopped. (lldb) ^D ``` I also attempted the same thing with ruby 2.7.4 source, with the same result. -- https://bugs.ruby-lang.org/

1 0