March 2024 - ruby-core - ml.ruby-lang.org

[ruby-core:117378] Re: [Ruby master Bug#20330] [BUG] Segmentation fault at 0xffffffffffffffff
by Jon 29 Mar '24

29 Mar '24

Also seeing this on fly.io, but only when running `fly console` which boots up a machine, and then runs bin/rails console. Here's my trace: ➜ metricswatch git:(fly-again) ✗ fly console Created an ephemeral machine 28744e6a361e58 to run the console. Connecting to fdaa:9:884:a7b:db:e1ba:d550:2... complete /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/ruby/site_ruby/3.3.0/rubygems.rb:165: [BUG] Segmentation fault at 0xffffffffffffffff ruby 3.3.0 (2023-12-25 revision 5124f9ac75) +jemalloc +YJIT [x86_64-linux] -- Control frame information ----------------------------------------------- c:0005 p:0074 s:0023 e:000021 CLASS /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/ruby/site_ruby/3.3.0/rubygems.rb:165 c:0004 p:0045 s:0019 e:000018 TOP /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/ruby/site_ruby/3.3.0/rubygems.rb:115 [FINISH] c:0003 p:---- s:0012 e:000011 CFUNC :require c:0002 p:0012 s:0007 e:000006 TOP <internal:gem_prelude>:2 [FINISH] c:0001 p:0000 s:0003 E:001840 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- <internal:gem_prelude>:2:in `<internal:gem_prelude>' <internal:gem_prelude>:2:in `require' /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/ruby/site_ruby/3.3.0/rubygems.rb:115:in `<top (required)>' /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/ruby/site_ruby/3.3.0/rubygems.rb:165:in `<module:Gem>' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ RIP: 0x00007fe952c151b4 RBP: 0x00007fe950800050 RSP: 0x00007ffd8a0fab78 RAX: 0xffffffffffffffff RBX: 0x00007fe9508003e8 RCX: 0x00007fe9508003e9 RDX: 0xffffffffffffffff RDI: 0x00007fe951c170d0 RSI: 0x000000000000c2d3 R8: 0x0000000000000000 R9: 0x00007fe951e36340 R10: 0x0000000000000001 R11: 0x00007fe952586a40 R12: 0x00007fe952f9b860 R13: 0x0000000000000001 R14: 0x00007fe950800550 R15: 0x00007fe952586a40 EFL: 0x0000000000010202 -- C level backtrace information ------------------------------------------- /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3(rb_vm_bugreport+0x96b) [0x7fe952ccadab] /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3(rb_bug_for_fatal_signal+0x100) [0x7fe952ac6720] /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3(sigsegv+0x4b) [0x7fe952c174db] /lib/x86_64-linux-gnu/libc.so.6(0x7fe952687050) [0x7fe952687050] /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3(redblack_insert_aux+0x364) [0x7fe952c151b4] /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3(redblack_cache_ancestors+0x8f) [0x7fe952c1552f] /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3(redblack_cache_ancestors+0x6d) [0x7fe952c1550d] /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3(redblack_cache_ancestors+0x6d) [0x7fe952c1550d] /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3(redblack_cache_ancestors+0x6d) [0x7fe952c1550d] /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3(redblack_cache_ancestors+0x6d) [0x7fe952c1550d] /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3(redblack_cache_ancestors+0x6d) [0x7fe952c1550d] /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3(rb_shape_get_next+0x2a8) [0x7fe952c16458] /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3(rb_class_ivar_set+0xb0) [0x7fe952c92560] /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3(rb_ivar_set+0x83) [0x7fe952c92743] /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3(vm_exec_core+0x8ca) [0x7fe952caea1a] /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3(rb_vm_exec+0x179) [0x7fe952cb40f9] /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3(require_internal+0xd2f) [0x7fe952b384bf] /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3(rb_require_string+0x66) [0x7fe952b39156] /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3(vm_call_cfunc_other+0x169) [0x7fe952c9cf29] /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3(vm_exec_core+0x129) [0x7fe952cae279] /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3(rb_vm_exec+0x179) [0x7fe952cb40f9] /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3(ruby_opt_init.part.0+0xbf) [0x7fe952c1185f] /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3(load_file_internal+0x47e) [0x7fe952c11e7e] /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3(rb_ensure+0x110) [0x7fe952ad0190] /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3(process_options+0x15fb) [0x7fe952c138ab] /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3(ruby_process_options+0x145) [0x7fe952c13ff5] /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3(ruby_options+0xc9) [0x7fe952ad1249] ruby(0x55a95a82210a) [0x55a95a82210a] /lib/x86_64-linux-gnu/libc.so.6(0x7fe95267224a) [0x7fe95267224a] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x7fe952672305] ruby(_start+0x21) [0x55a95a822151] -- Other runtime information ----------------------------------------------- * Loaded script: ruby * Loaded features: 0 enumerator.so 1 thread.rb 2 fiber.so 3 rational.so 4 complex.so 5 ruby2_keywords.rb 6 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/ruby/3.3.0/x86_64-linux/enc/encdb.so 7 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/ruby/3.3.0/x86_64-linux/enc/trans/transdb.so 8 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/ruby/3.3.0/x86_64-linux/rbconfig.rb 9 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/ruby/site_ruby/3.3.0/rubygems/compatibility.rb 10 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/ruby/site_ruby/3.3.0/rubygems/defaults.rb 11 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/ruby/site_ruby/3.3.0/rubygems/deprecate.rb 12 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/ruby/site_ruby/3.3.0/rubygems/errors.rb * Process memory map: 55a95a821000-55a95a822000 r--p 00000000 fe:00 3579 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/bin/ruby 55a95a822000-55a95a823000 r-xp 00001000 fe:00 3579 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/bin/ruby 55a95a823000-55a95a824000 r--p 00002000 fe:00 3579 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/bin/ruby 55a95a824000-55a95a825000 r--p 00002000 fe:00 3579 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/bin/ruby 55a95a825000-55a95a826000 rw-p 00003000 fe:00 3579 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/bin/ruby 7fe94dd4f000-7fe94e400000 r--s 00000000 fe:00 3798 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3.0 7fe94e400000-7fe94e800000 rw-p 00000000 00:00 0 7fe94e9e9000-7fe94ebbf000 r--s 00000000 fe:00 718 /usr/lib/x86_64-linux-gnu/libc.so.6 7fe94ebbf000-7fe94ebc0000 ---p 00000000 00:00 0 7fe94ebc0000-7fe94ec61000 rw-p 00000000 00:00 0 7fe94ec61000-7fe94ec62000 ---p 00000000 00:00 0 7fe94ec62000-7fe94ed03000 rw-p 00000000 00:00 0 7fe94ed03000-7fe94ed04000 ---p 00000000 00:00 0 7fe94ed04000-7fe94eda5000 rw-p 00000000 00:00 0 7fe94eda5000-7fe94eda6000 ---p 00000000 00:00 0 7fe94eda6000-7fe94ee47000 rw-p 00000000 00:00 0 7fe94ee47000-7fe94ee48000 ---p 00000000 00:00 0 7fe94ee48000-7fe94eee9000 rw-p 00000000 00:00 0 7fe94eee9000-7fe94eeea000 ---p 00000000 00:00 0 7fe94eeea000-7fe94ef8b000 rw-p 00000000 00:00 0 7fe94ef8b000-7fe94ef8c000 ---p 00000000 00:00 0 7fe94ef8c000-7fe94f02d000 rw-p 00000000 00:00 0 7fe94f02d000-7fe94f02e000 ---p 00000000 00:00 0 7fe94f02e000-7fe94f0cf000 rw-p 00000000 00:00 0 7fe94f0cf000-7fe94f0d0000 ---p 00000000 00:00 0 7fe94f0d0000-7fe94f171000 rw-p 00000000 00:00 0 7fe94f171000-7fe94f172000 ---p 00000000 00:00 0 7fe94f172000-7fe94f213000 rw-p 00000000 00:00 0 7fe94f213000-7fe94f214000 ---p 00000000 00:00 0 7fe94f214000-7fe94f2b5000 rw-p 00000000 00:00 0 7fe94f2b5000-7fe94f2b6000 ---p 00000000 00:00 0 7fe94f2b6000-7fe94f357000 rw-p 00000000 00:00 0 7fe94f357000-7fe94f358000 ---p 00000000 00:00 0 7fe94f358000-7fe94f3f9000 rw-p 00000000 00:00 0 7fe94f3f9000-7fe94f3fa000 ---p 00000000 00:00 0 7fe94f3fa000-7fe94f49b000 rw-p 00000000 00:00 0 7fe94f49b000-7fe94f49c000 ---p 00000000 00:00 0 7fe94f49c000-7fe94f53d000 rw-p 00000000 00:00 0 7fe94f53d000-7fe94f53e000 ---p 00000000 00:00 0 7fe94f53e000-7fe94f5df000 rw-p 00000000 00:00 0 7fe94f5df000-7fe94f5e0000 ---p 00000000 00:00 0 7fe94f5e0000-7fe94f681000 rw-p 00000000 00:00 0 7fe94f681000-7fe94f682000 ---p 00000000 00:00 0 7fe94f682000-7fe94f723000 rw-p 00000000 00:00 0 7fe94f723000-7fe94f724000 ---p 00000000 00:00 0 7fe94f724000-7fe94f7c5000 rw-p 00000000 00:00 0 7fe94f7c5000-7fe94f7c6000 ---p 00000000 00:00 0 7fe94f7c6000-7fe94f867000 rw-p 00000000 00:00 0 7fe94f867000-7fe94f868000 ---p 00000000 00:00 0 7fe94f868000-7fe94f909000 rw-p 00000000 00:00 0 7fe94f909000-7fe94f90a000 ---p 00000000 00:00 0 7fe94f90a000-7fe94f9ab000 rw-p 00000000 00:00 0 7fe94f9ab000-7fe94f9ac000 ---p 00000000 00:00 0 7fe94f9ac000-7fe94fa4d000 rw-p 00000000 00:00 0 7fe94fa4d000-7fe94fa4e000 ---p 00000000 00:00 0 7fe94fa4e000-7fe94faef000 rw-p 00000000 00:00 0 7fe94faef000-7fe94faf0000 ---p 00000000 00:00 0 7fe94faf0000-7fe94fb91000 rw-p 00000000 00:00 0 7fe94fb91000-7fe94fb92000 ---p 00000000 00:00 0 7fe94fb92000-7fe94fc33000 rw-p 00000000 00:00 0 7fe94fc33000-7fe94fc34000 ---p 00000000 00:00 0 7fe94fc34000-7fe94fcd5000 rw-p 00000000 00:00 0 7fe94fcd5000-7fe94fcd6000 ---p 00000000 00:00 0 7fe94fcd6000-7fe94fd77000 rw-p 00000000 00:00 0 7fe94fd77000-7fe94fd78000 ---p 00000000 00:00 0 7fe94fd78000-7fe94fe19000 rw-p 00000000 00:00 0 7fe94fe19000-7fe94fe1a000 ---p 00000000 00:00 0 7fe94fe1a000-7fe94febb000 rw-p 00000000 00:00 0 7fe94febb000-7fe94febc000 ---p 00000000 00:00 0 7fe94febc000-7fe94ff5d000 rw-p 00000000 00:00 0 7fe94ff5d000-7fe94ff5e000 ---p 00000000 00:00 0 7fe94ff5e000-7fe94ffff000 rw-p 00000000 00:00 0 7fe94ffff000-7fe950000000 ---p 00000000 00:00 0 7fe950000000-7fe952400000 rw-p 00000000 00:00 0 7fe9524d0000-7fe952560000 rw-p 00000000 00:00 0 7fe952562000-7fe952566000 r--s 00000000 fe:00 3579 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/bin/ruby 7fe952566000-7fe952567000 r--p 00000000 fe:00 5157 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/ruby/3.3.0/x86_64-linux/enc/trans/transdb.so 7fe952567000-7fe952568000 r-xp 00001000 fe:00 5157 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/ruby/3.3.0/x86_64-linux/enc/trans/transdb.so 7fe952568000-7fe952569000 r--p 00002000 fe:00 5157 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/ruby/3.3.0/x86_64-linux/enc/trans/transdb.so 7fe952569000-7fe95256a000 r--p 00002000 fe:00 5157 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/ruby/3.3.0/x86_64-linux/enc/trans/transdb.so 7fe95256a000-7fe95256b000 rw-p 00003000 fe:00 5157 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/ruby/3.3.0/x86_64-linux/enc/trans/transdb.so 7fe95256b000-7fe95256c000 r--p 00000000 fe:00 5113 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/ruby/3.3.0/x86_64-linux/enc/encdb.so 7fe95256c000-7fe95256d000 r-xp 00001000 fe:00 5113 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/ruby/3.3.0/x86_64-linux/enc/encdb.so 7fe95256d000-7fe95256e000 r--p 00002000 fe:00 5113 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/ruby/3.3.0/x86_64-linux/enc/encdb.so 7fe95256e000-7fe95256f000 r--p 00002000 fe:00 5113 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/ruby/3.3.0/x86_64-linux/enc/encdb.so 7fe95256f000-7fe952570000 rw-p 00003000 fe:00 5113 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/ruby/3.3.0/x86_64-linux/enc/encdb.so 7fe952570000-7fe9525d0000 rw-p 00000000 00:00 0 7fe9525d2000-7fe952629000 r--p 00000000 fe:00 335 /usr/lib/locale/C.utf8/LC_CTYPE 7fe952629000-7fe95262b000 rw-p 00000000 00:00 0 7fe95262b000-7fe95262e000 r--p 00000000 fe:00 740 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 7fe95262e000-7fe952645000 r-xp 00003000 fe:00 740 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 7fe952645000-7fe952649000 r--p 0001a000 fe:00 740 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 7fe952649000-7fe95264a000 r--p 0001d000 fe:00 740 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 7fe95264a000-7fe95264b000 rw-p 0001e000 fe:00 740 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 7fe95264b000-7fe952671000 r--p 00000000 fe:00 718 /usr/lib/x86_64-linux-gnu/libc.so.6 7fe952671000-7fe9527c6000 r-xp 00026000 fe:00 718 /usr/lib/x86_64-linux-gnu/libc.so.6 7fe9527c6000-7fe952819000 r--p 0017b000 fe:00 718 /usr/lib/x86_64-linux-gnu/libc.so.6 7fe952819000-7fe95281d000 r--p 001ce000 fe:00 718 /usr/lib/x86_64-linux-gnu/libc.so.6 7fe95281d000-7fe95281f000 rw-p 001d2000 fe:00 718 /usr/lib/x86_64-linux-gnu/libc.so.6 7fe95281f000-7fe95282e000 rw-p 00000000 00:00 0 7fe95282e000-7fe95283e000 r--p 00000000 fe:00 757 /usr/lib/x86_64-linux-gnu/libm.so.6 7fe95283e000-7fe9528b1000 r-xp 00010000 fe:00 757 /usr/lib/x86_64-linux-gnu/libm.so.6 7fe9528b1000-7fe95290b000 r--p 00083000 fe:00 757 /usr/lib/x86_64-linux-gnu/libm.so.6 7fe95290b000-7fe95290c000 r--p 000dc000 fe:00 757 /usr/lib/x86_64-linux-gnu/libm.so.6 7fe95290c000-7fe95290d000 rw-p 000dd000 fe:00 757 /usr/lib/x86_64-linux-gnu/libm.so.6 7fe95290d000-7fe95290f000 r--p 00000000 fe:00 727 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 7fe95290f000-7fe952925000 r-xp 00002000 fe:00 727 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 7fe952925000-7fe95293f000 r--p 00018000 fe:00 727 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 7fe95293f000-7fe952940000 r--p 00031000 fe:00 727 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 7fe952940000-7fe952941000 rw-p 00032000 fe:00 727 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 7fe952941000-7fe952949000 rw-p 00000000 00:00 0 7fe952949000-7fe95294c000 r--p 00000000 fe:00 3795 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libjemalloc.so.1 7fe95294c000-7fe952983000 r-xp 00003000 fe:00 3795 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libjemalloc.so.1 7fe952983000-7fe95298b000 r--p 0003a000 fe:00 3795 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libjemalloc.so.1 7fe95298b000-7fe95298d000 r--p 00042000 fe:00 3795 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libjemalloc.so.1 7fe95298d000-7fe95298e000 rw-p 00044000 fe:00 3795 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libjemalloc.so.1 7fe95298e000-7fe95298f000 rw-p 00000000 00:00 0 7fe95298f000-7fe952992000 r--p 00000000 fe:00 817 /usr/lib/x86_64-linux-gnu/libz.so.1.2.13 7fe952992000-7fe9529a5000 r-xp 00003000 fe:00 817 /usr/lib/x86_64-linux-gnu/libz.so.1.2.13 7fe9529a5000-7fe9529ac000 r--p 00016000 fe:00 817 /usr/lib/x86_64-linux-gnu/libz.so.1.2.13 7fe9529ac000-7fe9529ad000 r--p 0001c000 fe:00 817 /usr/lib/x86_64-linux-gnu/libz.so.1.2.13 7fe9529ad000-7fe9529ae000 rw-p 0001d000 fe:00 817 /usr/lib/x86_64-linux-gnu/libz.so.1.2.13 7fe9529ae000-7fe9529b5000 r--s 00000000 fe:00 691 /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache 7fe9529b5000-7fe952a00000 r--p 00000000 fe:00 3798 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3.0 7fe952a00000-7fe952dea000 r-xp 0004b000 fe:00 3798 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3.0 7fe952dea000-7fe952f71000 r--p 00435000 fe:00 3798 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3.0 7fe952f71000-7fe952f88000 r--p 005bb000 fe:00 3798 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3.0 7fe952f88000-7fe952f8c000 rw-p 005d2000 fe:00 3798 /usr/lib/fullstaq-ruby/versions/3.3.0-jemalloc/lib/libruby.so.3.3.0 7fe952f8c000-7fe952fa3000 rw-p 00000000 00:00 0 7fe952fa3000-7fe952fa4000 r--p 00000000 fe:00 700 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 7fe952fa4000-7fe952fc9000 r-xp 00001000 fe:00 700 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 7fe952fc9000-7fe952fd3000 r--p 00026000 fe:00 700 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 7fe952fd3000-7fe952fd5000 r--p 00030000 fe:00 700 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 7fe952fd5000-7fe952fd7000 rw-p 00032000 fe:00 700 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 7ffd89900000-7ffd8a0ff000 rw-p 00000000 00:00 0 [stack] 7ffd8a1aa000-7ffd8a1ae000 r--p 00000000 00:00 0 [vvar] 7ffd8a1ae000-7ffd8a1b0000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Waiting for ephemeral machine 28744e6a361e58 to be destroyed ... done. Error: ssh shell: Process exited with status 4294967295

1 0

[ruby-core:117365] [Ruby master Bug#20399] Ripper doesn't respect implicit -x
by kddnewton (Kevin Newton) 29 Mar '24

29 Mar '24

Issue #20399 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20399: Ripper doesn't respect implicit -x https://bugs.ruby-lang.org/issues/20399 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- For the given script: ```ruby #!/bin/sh # -*- ruby -*- exec "${RUBY-ruby}" "-x" "$0" "$@" && [ ] if false #!ruby # This needs ruby 2.0, Subversion and Git. # As a Ruby committer, run this in an SVN repository # to commit a change. require 'tempfile' require 'net/http' ``` I would expect all of the various Ripper APIs (`lex`, `sexp`, `sexp_raw`, `new.parse`, etc.) to start parsing on line 4, because that's what the parser does. Instead, it starts parsing on line 1. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:117268] [Ruby master Feature#20384] RubyVM::InstructionSequence.{new,compile} use --parser option
by kddnewton (Kevin Newton) 29 Mar '24

29 Mar '24

Issue #20384 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Feature #20384: RubyVM::InstructionSequence.{new,compile} use --parser option https://bugs.ruby-lang.org/issues/20384 * Author: kddnewton (Kevin Newton) * Status: Open ---------------------------------------- Right now we have `RubyVM::InstructionSequence.compile` and `RubyVM::InstructionSequence.compile_prism`. We introduced this API in order to properly test the integration, even when running with `--parser=parse.y`. I'm running into issues, however, when tests are comparing between `eval` and `RubyVM::InstructionSequence.new`. The latter always uses `parse.y`, even if `--parser=prism` is passed on the command line. I would like to change that so that `RubyVM::InstructionSequence.{new,compile}` respects the `--parser` option so that it's consistent. Would this change be okay? It would only impact processes with `--parser=prism`, so I don't imagine there's any kind of risk here. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:117366] [Ruby master Bug#20400] Nested BEGIN{} execution order
by kddnewton (Kevin Newton) 29 Mar '24

29 Mar '24

Issue #20400 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20400: Nested BEGIN{} execution order https://bugs.ruby-lang.org/issues/20400 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Right now there are specs for the order in which `BEGIN{}` should be executed, which is the order they appear in the file. For example: ```ruby BEGIN { print "1" } print "4" BEGIN { print "2" } print "5" BEGIN { print "3" } ``` should output "12345". However, I couldn't find any tests/specs on what happens when `BEGIN{}` is nested. The order appears to be somewhat confusing, so I wanted to clarify if it was intentional or a bug. For example: ```ruby BEGIN { print "1" BEGIN { print "2" } } ``` prints "21", and: ```ruby BEGIN { print "1" BEGIN { print "2" } BEGIN { print "3" } } ``` prints "231", and finally: ```ruby BEGIN { print "1" BEGIN { print "2" BEGIN { print "3" } } BEGIN { print "4" } } ``` prints "3241". Is this intentional? -- https://bugs.ruby-lang.org/

2 2

[ruby-core:117354] [Ruby master Bug#20398] heap-buffer-overflow in numeric literal parsing
by kjtsanaktsidis (KJ Tsanaktsidis) 29 Mar '24

29 Mar '24

Issue #20398 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Bug #20398: heap-buffer-overflow in numeric literal parsing https://bugs.ruby-lang.org/issues/20398 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Assignee: kjtsanaktsidis (KJ Tsanaktsidis) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I found the following ASAN error in `TestRubyLiteral#test_integer`. It appears that this code is calling strlen on a non-null terminated string. ``` [1/1] TestRubyLiteral#test_integer================================================================= ==484771==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x5060001ab1fc at pc 0x5597fe21d8e1 bp 0x7ffdc6fb0a50 sp 0x7ffdc6fb0210 READ of size 61 at 0x5060001ab1fc thread T0 #0 0x5597fe21d8e0 in strlen.part.0 /home/kj/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:391:5 #1 0x5597fe6b2feb in ruby_strdup /home/kj/ruby/build/../util.c:538:18 #2 0x5597fe4cb1c5 in set_number_literal /home/kj/ruby/build/parse.y:9694:9 #3 0x5597fe4cab3d in no_digits /home/kj/ruby/build/parse.y:10409:12 #4 0x5597fe4b9de9 in parse_numeric /home/kj/ruby/build/parse.y #5 0x5597fe4a8adf in parser_yylex /home/kj/ruby/build/parse.y #6 0x5597fe45c5cd in yylex /home/kj/ruby/build/parse.y:11916:9 #7 0x5597fe45c5cd in ruby_yyparse /home/kj/ruby/build/parse.c:11200:16 #8 0x5597fe49dc00 in yycompile0 /home/kj/ruby/build/parse.y:8121:9 #9 0x5597fe76db1b in rb_suppress_tracing /home/kj/ruby/build/../vm_trace.c:487:18 #10 0x5597fe494416 in yycompile /home/kj/ruby/build/parse.y:8177:5 #11 0x5597fe494416 in parser_compile_string /home/kj/ruby/build/parse.y:8240:12 #12 0x5597fe494416 in rb_ruby_parser_compile_string_path /home/kj/ruby/build/parse.y:8247:12 #13 0x5597fe498858 in rb_parser_compile_string_path /home/kj/ruby/build/parse.y:16663:12 #14 0x5597fe75688c in eval_make_iseq /home/kj/ruby/build/../vm_eval.c:1799:11 #15 0x5597fe70c8fa in eval_string_with_cref /home/kj/ruby/build/../vm_eval.c:1837:12 #16 0x5597fe70c396 in rb_f_eval /home/kj/ruby/build/../vm_eval.c:1912:16 #17 0x5597fe73f5e2 in vm_call_cfunc_with_frame_ /home/kj/ruby/build/../vm_insnhelper.c:3492:11 #18 0x5597fe6dca64 in vm_sendish /home/kj/ruby/build/../vm_callinfo.h #19 0x5597fe6e64fa in vm_exec_core /home/kj/ruby/build/../insns.def:867:11 #20 0x5597fe6dde00 in vm_exec_loop /home/kj/ruby/build/../vm.c:2578:22 #21 0x5597fe6dde00 in rb_vm_exec /home/kj/ruby/build/../vm.c:2557:18 #22 0x5597fe758bc4 in invoke_block /home/kj/ruby/build/../vm.c:1515:12 #23 0x5597fe758bc4 in invoke_iseq_block_from_c /home/kj/ruby/build/../vm.c:1585:16 #24 0x5597fe758bc4 in invoke_block_from_c_bh /home/kj/ruby/build/../vm.c:1603:20 #25 0x5597fe70e4b7 in vm_yield_with_cref /home/kj/ruby/build/../vm.c:1640:12 #26 0x5597fe709861 in vm_yield /home/kj/ruby/build/../vm.c:1648:12 #27 0x5597fe709861 in rb_yield_0 /home/kj/ruby/build/../vm_eval.c:1366:12 #28 0x5597fe709861 in rb_yield /home/kj/ruby/build/../vm_eval.c #29 0x5597fec0eff9 in rb_ary_collect /home/kj/ruby/build/../array.c:3601:30 #30 0x5597fe73f5e2 in vm_call_cfunc_with_frame_ /home/kj/ruby/build/../vm_insnhelper.c:3492:11 #31 0x5597fe6dca64 in vm_sendish /home/kj/ruby/build/../vm_callinfo.h #32 0x5597fe6e2d8f in vm_exec_core /home/kj/ruby/build/../insns.def:847:11 #33 0x5597fe6dde00 in vm_exec_loop /home/kj/ruby/build/../vm.c:2578:22 #34 0x5597fe6dde00 in rb_vm_exec /home/kj/ruby/build/../vm.c:2557:18 #35 0x5597fe3ffe9e in load_iseq_eval /home/kj/ruby/build/../load.c:778:5 #36 0x5597fe3fb498 in require_internal /home/kj/ruby/build/../load.c:1284:21 #37 0x5597fe3f9bf3 in rb_require_string_internal /home/kj/ruby/build/../load.c:1383:18 #38 0x5597fe73f5e2 in vm_call_cfunc_with_frame_ /home/kj/ruby/build/../vm_insnhelper.c:3492:11 #39 0x5597fe6dca64 in vm_sendish /home/kj/ruby/build/../vm_callinfo.h #40 0x5597fe6e64fa in vm_exec_core /home/kj/ruby/build/../insns.def:867:11 #41 0x5597fe6dda82 in rb_vm_exec /home/kj/ruby/build/../vm.c:2551:22 #42 0x5597fe30a753 in rb_ec_exec_node /home/kj/ruby/build/../eval.c:283:9 #43 0x5597fe30a43d in ruby_run_node /home/kj/ruby/build/../eval.c:323:30 #44 0x5597fe3059b0 in rb_main /home/kj/ruby/build/../main.c:40:12 #45 0x5597fe3059b0 in main /home/kj/ruby/build/../main.c:59:12 #46 0x7f1a93141149 in __libc_start_call_main /usr/src/debug/glibc-2.38-16.fc39.x86_64/csu/../sysdeps/nptl/libc_start_call_main.h:58:16 #47 0x7f1a9314120a in __libc_start_main(a)GLIBC_2.2.5 /usr/src/debug/glibc-2.38-16.fc39.x86_64/csu/../csu/libc-start.c:360:3 #48 0x5597fe1d3e34 in _start (/home/kj/ruby/build/ruby+0x38ae34) 0x5060001ab1fc is located 0 bytes after 60-byte region [0x5060001ab1c0,0x5060001ab1fc) allocated by thread T0 here: #0 0x5597fe2bde4f in malloc /home/kj/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:68:3 #1 0x5597fe3491a9 in objspace_xmalloc0 /home/kj/ruby/build/../gc.c:12605:5 #2 0x5597fe4a8adf in parser_yylex /home/kj/ruby/build/parse.y #3 0x5597fe45c5cd in yylex /home/kj/ruby/build/parse.y:11916:9 #4 0x5597fe45c5cd in ruby_yyparse /home/kj/ruby/build/parse.c:11200:16 #5 0x5597fe49dc00 in yycompile0 /home/kj/ruby/build/parse.y:8121:9 SUMMARY: AddressSanitizer: heap-buffer-overflow /home/kj/ruby/build/../util.c:538:18 in ruby_strdup Shadow bytes around the buggy address: 0x5060001aaf00: fa fa fa fa fd fd fd fd fd fd fd fd fa fa fa fa 0x5060001aaf80: 00 00 00 00 00 00 00 04 fa fa fa fa 00 00 00 00 0x5060001ab000: 00 00 00 fa fa fa fa fa 00 00 00 00 00 00 00 fa 0x5060001ab080: fa fa fa fa 00 00 00 00 00 00 00 00 fa fa fa fa 0x5060001ab100: 00 00 00 00 00 00 00 00 fa fa fa fa 00 00 00 00 =>0x5060001ab180: 00 00 00 00 fa fa fa fa 00 00 00 00 00 00 00[04] 0x5060001ab200: fa fa fa fa fd fd fd fd fd fd fd fd fa fa fa fa 0x5060001ab280: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x5060001ab300: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x5060001ab380: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x5060001ab400: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==484771==ABORTING ``` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:117370] [Ruby master Bug#17996] Cygwin: thread + pipe behavior since Ruby 2.6
by hsbt (Hiroshi SHIBATA) 29 Mar '24

29 Mar '24

Issue #17996 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Open to Closed https://github.com/ruby/ruby/pull/9357 may be fixed this. ---------------------------------------- Bug #17996: Cygwin: thread + pipe behavior since Ruby 2.6 https://bugs.ruby-lang.org/issues/17996#change-107528 * Author: xtkoba (Tee KOBAYASHI) * Status: Closed * Assignee: cygwin * ruby -v: ruby 3.1.0dev (2021-06-10T23:31:51Z master 9210f8df7f) [x86_64-cygwin] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- The following one-liner is the repro named `thread-pipe-read-close.rb` the aim of which is essentially the same as that of "IO#close raises an IOError with a clear message" test in `spec/ruby/core/io/close_spec.rb`. ```ruby r, w = IO.pipe; Thread.new{ r.read }; sleep 0.5; r.close ``` Run on Cygwin with Ruby 2.6 or later, this hangs up indefinitely consuming a full core. On the other hand, with Ruby 2.5.9p229 it works as expected. ``` $ miniruby25 -v ruby 2.5.9p229 (2021-04-05 revision 67939) [x86_64-cygwin] $ miniruby25 thread-pipe-read-close.rb #<Thread:0x000000080006c9f0@thread-pipe-read-close.rb:2 run> terminated with exception (report_on_exception is true): Traceback (most recent call last): 1: from thread-pipe-read-close.rb:2:in `block in <main>' thread-pipe-read-close.rb:2:in `read': IOError $ miniruby -v ruby 3.1.0dev (2021-06-10T23:31:51Z master 9210f8df7f) [x86_64-cygwin] $ miniruby thread-pipe-read-close.rb ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117324] [Ruby master Feature#20394] Add an offset parameter to `String#to_i`
by byroot (Jean Boussier) 28 Mar '24

28 Mar '24

Issue #20394 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #20394: Add an offset parameter to `String#to_i` https://bugs.ruby-lang.org/issues/20394 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- ### Context I maintain the `redis-client` gem, and it comes with an optional swapable implementation in C that binds the `hiredis` C client, [which used to performs up to 5 times faster in some cases](https://github.com/redis-rb/redis-client/commit/9fabd57c6786a03fe0c6…. I recently paired with @tenderlovemaking to try to close this gap, or even try to make the pure Ruby version faster, and we came up with several optimizations that now almost make both version on par (assuming YJIT is enabled). An important source of performance loss, is that the Redis protocol is line based and to parse it in Ruby requires to slice a lot of small strings from the buffer. To give an example, here's how an Array with two String (`["foo", "plop"]`) is serialized in RESP3 (Redis protocol): ``` *2\r\n $3\r\n foo\r\n $4\r\n plop\r\n ``` From this you can understand that a big hotspot in the parser is essentially `Integer(gets)`. With @tenderlovemaking we managed to get [a fairly significant perf boost](https://github.com/redis-rb/redis-client/commit/41b3abe94243d2598211… by avoiding these string allocation using `String#getbyte` and [basically implementing a rudimentary `String#to_i(offset: )` in Ruby](https://github.com/redis-rb/redis-client/commit/41b3abe94243d2598211d…. But while the gains are huge with YJIT enabled, they are much more tame with the interpreter. And it feels a bit wrong to have to implement this sorts of things for performance reasons. ### `String#to_i(offset: )` Similar to `String#unpack(offset:)` ([Feature #18254]), I believe `String#to_i(offset: )` would be useful. ### Alternative new `String#unpack` format Another possibility would be to add a new format to `String#pack` `String#unpack` for decimal numbers. It sounds a bit weird at first, but given it supports things like Base64 and hexadecimal, perhaps it's not that much of a stretch? -- https://bugs.ruby-lang.org/

7 15

[ruby-core:117300] [Ruby master Feature#19057] Hide implementation of `rb_io_t`.
by ioquatix (Samuel Williams) 28 Mar '24

28 Mar '24

Issue #19057 has been updated by ioquatix (Samuel Williams). > Why don't you reconsider the "nested public interface" approach? My assessment of this approach is that it would require a rewrite of all internal code that accesses `rb_io_t` internals. Rewriting code isn't a problem, but it takes a lot of time and effort that I don't have in abundance right now. Additionally, it's still only a partial solution. One of the issues is accessing the file descriptor directly and the handling of `IO#close` from a different thread/fiber. Using the file descriptor directly can be problematic. > Ruby lost numerous users due to a never-ending stream of incompatibilities introduced every year. Compatibility and progress are always something to balance out. I think on the whole, Ruby does a pretty decent job at it. Lack of forward progress also causes users to look elsewhere as the language stagnates. So this isn't just. a matter of "preserve compatibility at all costs", as those costs will be the same. The hard part is finding the middle ground of compatibility and progress. Both compatibility at any cost, and progress at any cost, are naive statements. ---------------------------------------- Feature #19057: Hide implementation of `rb_io_t`. https://bugs.ruby-lang.org/issues/19057#change-107442 * Author: ioquatix (Samuel Williams) * Status: Assigned * Assignee: ioquatix (Samuel Williams) * Target version: 3.4 ---------------------------------------- In order to make improvements to the IO implementation like <https://bugs.ruby-lang.org/issues/18455>, we need to add new fields to `struct rb_io_t`. By the way, ending types in `_t` is not recommended by POSIX, so I'm also trying to rename the internal implementation to drop `_t` where possible during this conversion. Anyway, we should try to hide the implementation of `struct rb_io`. Ideally, we don't expose any of it, but the problem is backwards compatibility. So, in order to remain backwards compatibility, we should expose some fields of `struct rb_io`, the most commonly used one is `fd` and `mode`, but several others are commonly used. There are many fields which should not be exposed because they are implementation details. ## Current proposal The current proposed change <https://github.com/ruby/ruby/pull/6511> creates two structs: ```c // include/ruby/io.h #ifndef RB_IO_T struct rb_io { int fd; // ... public fields ... }; #else struct rb_io; #endif // internal/io.h #define RB_IO_T struct rb_io { int fd; // ... public fields ... // ... private fields ... }; ``` However, we are not 100% confident this is safe according to the C specification. My experience is not sufficiently wide to say this is safe in practice, but it does look okay to both myself, and @Eregon + @tenderlovemaking have both given some kind of approval. That being said, maybe it's not safe. There are two alternatives: ## Hide all details We can make public `struct rb_io` completely invisible. ```c // include/ruby/io.h #define RB_IO_HIDDEN struct rb_io; int rb_ioptr_descriptor(struct rb_io *ioptr); // accessor for previously visible state. // internal/io.h struct rb_io { // ... all fields ... }; ``` This would only be forwards compatible, and code would need to feature detect like this: ```c #ifdef RB_IO_HIDDEN #define RB_IOPTR_DESCRIPTOR rb_ioptr_descriptor #else #define RB_IOPTR_DESCRIPTOR(ioptr) rb_ioptr_descriptor(ioptr) #endif ``` ## Nested public interface Alternatively, we can nest the public fields into the private struct: ```c // include/ruby/io.h struct rb_io_public { int fd; // ... public fields ... }; // internal/io.h #define RB_IO_T struct rb_io { struct rb_io_public public; // ... private fields ... }; ``` ## Considerations I personally think the "Hide all details" implementation is the best, but it's also the lest compatible. This is also what we are ultimately aiming for, whether we decide to take an intermediate "compatibility step" is up to us. I think "Nested public interface" is messy and introduces more complexity, but it might be slightly better defined than the "Current proposal" which might create undefined behaviour. That being said, all the tests are passing. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:117351] embedd ruby 3.3.0 - unknown Time.now class method
by fiesta06 27 Mar '24

27 Mar '24

Hi, I want to embedd the ruby 3.3.0 interpreter into my application by using the following code: int error, n; static char* args[] = {}; n = 0; ruby_sysinit(&n, (char ***)&args); RUBY_INIT_STACK; ruby_init(); ruby_init_loadpath(); rb_eval_string_protect("p Time.now", &error); if(error) { rb_eval_string("p :ERROR"); } In principle it does work. However, the Time class is missing the now method, thus a :ERROR is printed. What it missing in the above code ?

1 0

[ruby-core:117326] [Ruby master Bug#20395] Invalid license note in vsnprintf.c
by vo.x (Vit Ondruch) 27 Mar '24

27 Mar '24

Issue #20395 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #20395: Invalid license note in vsnprintf.c https://bugs.ruby-lang.org/issues/20395 * Author: vo.x (Vit Ondruch) * Status: Open * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I am looking into Ruby licenses and I stumble upon vsnprintf.c, namely about these lines: ~~~ /* * IMPORTANT NOTE: * -------------- * From ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change * paragraph 3 above is now null and void. */ ~~~ I doubt the note is valid since commit:git|626f1ee196fe06514d66771ff0e3f82d7686af25, which actually removes the 3rd clause, while the (broken) URL refers to "4bsd". Can somebody please review? The note from the URL can be likely viewed e.g. [here](https://www.freebsd.org/copyright/license/) -- https://bugs.ruby-lang.org/

2 4