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

[ruby-core:115739] Ruby 3.2.2 Solaris-Sparc Compilation Error in iseq.c
by Jay Mav 14 Dec '23

14 Dec '23

Hello, Building Ruby 3.2.2 on Solaris-Sparc 32-bit with Developer Studio 12.6. Issues: 1) compilation of iseq.c fails due to variable definition in macro OPTION: #define SET_COMPILE_OPTION(o, h, mem) \ { VALUE flag = rb_hash_aref((h), ID2SYM(rb_intern(#mem))); \ if (flag == Qtrue) { (o)->mem = 1; } \ else if (flag == Qfalse) { (o)->mem = 0; } \ } SET_COMPILE_OPTION(option, opt, inline_const_cache); SET_COMPILE_OPTION(option, opt, peephole_optimization); SET_COMPILE_OPTION(option, opt, tailcall_optimization); SET_COMPILE_OPTION(option, opt, specialized_instruction); SET_COMPILE_OPTION(option, opt, operands_unification); SET_COMPILE_OPTION(option, opt, instructions_unification); SET_COMPILE_OPTION(option, opt, stack_caching); SET_COMPILE_OPTION(option, opt, frozen_string_literal); SET_COMPILE_OPTION(option, opt, debug_frozen_string_literal); SET_COMPILE_OPTION(option, opt, coverage_enabled); "iseq.c", line 812: identifier redefined: flag current : unsigned long ... If the definition of flag is moved outside of the macro: VALUE flag; #define SET_COMPILE_OPTION(o, h, mem) \ { flag = rb_hash_aref((h), ID2SYM(rb_intern(#mem))); \ if (flag == Qtrue) { (o)->mem = 1; } \ else if (flag == Qfalse) { (o)->mem = 0; } \ } then iseq.c gets compiled. What's the correct fix for this macro? 2) After fixing the above error, the build progresses but fails in linking miniruby linking miniruby Undefined first referenced symbol in file .L13046 iseq.o It is not clear what .L13046 represents. Can any one please share how this issue can be resolved? Thanks.

2 1

[ruby-core:115710] [Ruby master Bug#20060] bundled_gems.rb is not working with Bootsnap
by hsbt (Hiroshi SHIBATA) 13 Dec '23

13 Dec '23

Issue #20060 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #20060: bundled_gems.rb is not working with Bootsnap https://bugs.ruby-lang.org/issues/20060 * Author: hsbt (Hiroshi SHIBATA) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Addressed from https://github.com/ruby/ruby/pull/9163#issuecomment-1850924893 `bundled_gems.rb` of 3.3.0-rc1 couldn't handle full paths by Bootsnap. ``` $ rails new example (snip) rails importmap:install bin/rails aborted! ArgumentError: comparison of String with nil failed (ArgumentError) msg = " #{RUBY_VERSION < SINCE[gem] ? "will no longer be" : "is not"} part of the default gems since Ruby #{SINCE[gem]}." (snip) ``` It's working with DISABLE_BOOTSNAP=1. But we should resolve it with under the bootsnap. -- https://bugs.ruby-lang.org/

1 3

[ruby-core:115733] [Ruby master Feature#13383] [PATCH] Module#source_location
by matheusrich (Matheus Richard) 13 Dec '23

13 Dec '23

Issue #13383 has been updated by matheusrich (Matheus Richard). I want to bring this up again. This feature feels very natural to me, and it was surprising that `Module#source_locations` isn't implemented yet. What can we do to move this forward? ---------------------------------------- Feature #13383: [PATCH] Module#source_location https://bugs.ruby-lang.org/issues/13383#change-105666 * Author: koba789 (Hidekazu Kobayashi) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) ---------------------------------------- # Abstract It can inspect where the module or class is defined. # Background In debugging or development an application, I usually want to find out where the class definition of using library. There is Method#source_location but I could not find **Class** easily. # Implementation In Github: https://github.com/ruby/ruby/pull/1562 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115197] [Ruby master Misc#19980] Is the Ruby 3.3 ABI frozen?
by mdalessio (Mike Dalessio) 13 Dec '23

13 Dec '23

Issue #19980 has been reported by mdalessio (Mike Dalessio). ---------------------------------------- Misc #19980: Is the Ruby 3.3 ABI frozen? https://bugs.ruby-lang.org/issues/19980 * Author: mdalessio (Mike Dalessio) * Status: Open * Priority: Normal ---------------------------------------- I'm a co-maintainer of [rake-compiler-dock](https://github.com/rake-compiler/rake-compiler-dock) which is used to build precompiled native packages for some gems, including nokogiri, sqlite3, grpc, re2, and ruby-magic. In the past, precompiled native gems generally released support for a new version of Ruby days or weeks after Ruby's release (for example, [Nokogiri v1.14.0 released on 2023-01-12](https://nokogiri.org/CHANGELOG.html)) In some cases, the lack of native gem support has slowed user adoption of the new version of Ruby. This year, I'd like to see native gems release Ruby 3.3 support before the final version is released. This will encourage testing of Ruby 3.3 previews and allow users to immediately upgrade to Ruby 3.3 final when it is released. To do that, I would like to cut a release of the rake-compiler-dock gem (and its [build containers](https://github.com/rake-compiler/rake-compiler-dock/pkgs/contai…) that supports Ruby 3.3 as soon as possible (I already have a feature branch mostly working based on 3.3.0_preview1 at https://github.com/rake-compiler/rake-compiler-dock/pull/105) Is the Ruby 3.3 ABI frozen now? If I build a native gem against Ruby 3.3.0_preview2, is there any reason to believe that it wouldn't work with Ruby 3.3 final when it is released? Thank you for any guidance you can provide. -- https://bugs.ruby-lang.org/

3 6

[ruby-core:115727] [Ruby master Bug#19114] Calling TracePoint#enable multiple times causes TracePoint to be activated multiple times
by ivoanjo (Ivo Anjo) 13 Dec '23

13 Dec '23

Issue #19114 has been updated by ivoanjo (Ivo Anjo). Nice, thanks for fixing this one! 🙇 ---------------------------------------- Bug #19114: Calling TracePoint#enable multiple times causes TracePoint to be activated multiple times https://bugs.ruby-lang.org/issues/19114#change-105660 * Author: ivoanjo (Ivo Anjo) * Status: Closed * Priority: Normal * ruby -v: ruby 3.2.0preview2 (2022-09-09 master 35cfc9a3bb) [x86_64-darwin20] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Howdy 👋! I work for Datadog [on the `ddtrace` gem](https://github.com/DataDog/dd-trace-rb) and I found an issue with TracePoint. ### Background For tracking time spent in Garbage Collection on our Ruby profiler, we use a tracepoint. While doing some experiments around our code, I realized that enabling the same `TracePoint` more than once made it trigger multiple times. ### How to reproduce (Ruby version & script) This can be reproduced with any tracepoint: ```ruby puts RUBY_DESCRIPTION puts "Enabling tracepoint" tracepoint = TracePoint.new(:line) { |tp| p [tp.path, tp.lineno, tp.event] }.tap(&:enable) 5.times { tracepoint.enable } puts "Finished!" ``` ### Expectation and result This is the output of the above script: ``` ruby 3.2.0preview2 (2022-09-09 master 35cfc9a3bb) [x86_64-darwin20] Enabling tracepoint ["<internal:kernel>", 91, :line] ["triggertracepoint.rb", 4, :line] ["triggertracepoint.rb", 4, :line] ["<internal:trace_point>", 213, :line] ["triggertracepoint.rb", 4, :line] ["triggertracepoint.rb", 4, :line] ["<internal:trace_point>", 213, :line] ["<internal:trace_point>", 213, :line] ["triggertracepoint.rb", 4, :line] ["triggertracepoint.rb", 4, :line] ["triggertracepoint.rb", 4, :line] ["<internal:trace_point>", 213, :line] ["<internal:trace_point>", 213, :line] ["<internal:trace_point>", 213, :line] ["triggertracepoint.rb", 4, :line] ["triggertracepoint.rb", 4, :line] ["triggertracepoint.rb", 4, :line] ["triggertracepoint.rb", 4, :line] ["<internal:trace_point>", 213, :line] ["<internal:trace_point>", 213, :line] ["<internal:trace_point>", 213, :line] ["<internal:trace_point>", 213, :line] ["triggertracepoint.rb", 4, :line] ["triggertracepoint.rb", 4, :line] ["triggertracepoint.rb", 4, :line] ["triggertracepoint.rb", 4, :line] ["triggertracepoint.rb", 4, :line] ["<internal:trace_point>", 213, :line] ["<internal:trace_point>", 213, :line] ["<internal:trace_point>", 213, :line] ["<internal:trace_point>", 213, :line] ["<internal:trace_point>", 213, :line] ["triggertracepoint.rb", 5, :line] ["triggertracepoint.rb", 5, :line] ["triggertracepoint.rb", 5, :line] ["triggertracepoint.rb", 5, :line] ["triggertracepoint.rb", 5, :line] ["triggertracepoint.rb", 5, :line] Finished! ``` My expectation is that once enabled, a `TracePoint` fires only once for each event, regardless of how many times `TracePoint#enable` was called. Instead, I see it being called as many times as `#enable` was called. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115713] [Ruby master Bug#20061] test_free_on_exit_env_var failed with some cppflags
by znz (Kazuhiro NISHIYAMA) 12 Dec '23

12 Dec '23

Issue #20061 has been reported by znz (Kazuhiro NISHIYAMA). ---------------------------------------- Bug #20061: test_free_on_exit_env_var failed with some cppflags https://bugs.ruby-lang.org/issues/20061 * Author: znz (Kazuhiro NISHIYAMA) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-12-12T01:31:37Z master 73b43fffa1) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I use following `cppflags`, and `TestRubyOptions#test_free_on_exit_env_var` failed. ``` ../configure 'cppflags=-DUSE_RVARGC -DRUBY_DEBUG -DVM_CHECK_MODE=1 -DTRANSIENT_HEAP_CHECK_MODE -DRGENGC_CHECK_MODE -DENC_DEBUG -DUSE_RUBY_DEBUG_LOG=1' --prefix=$(rbenv root)/versions/master --with-baseruby=/usr/bin/ruby --disable-install-doc ``` It can reproduce using `miniruby`. ``` $ env RUBY_FREE_ON_EXIT=1 ./miniruby -e 0 ./miniruby: warning: Free on exit is experimental and may be unstable -e: [BUG] obj_free: RVALUE_MARKED(0x00007efe26a69010 [3LM ] T_CLASS (anon)) != FALSE ruby 3.3.0dev (2023-12-12T01:31:37Z master 73b43fffa1) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0001 p:0000 s:0003 E:0006b0 DUMMY [FINISH] -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- /home/ubuntu/ruby/build/miniruby(rb_print_backtrace+0x14) [0x5563381d66a7] ../vm_dump.c:820 /home/ubuntu/ruby/build/miniruby(rb_vm_bugreport) ../vm_dump.c:1151 /home/ubuntu/ruby/build/miniruby(bug_report_end+0x0) [0x556337fc41ad] ../error.c:1042 /home/ubuntu/ruby/build/miniruby(rb_bug_without_die) ../error.c:1042 /home/ubuntu/ruby/build/miniruby(die+0x0) [0x556337eef35b] ../error.c:1050 /home/ubuntu/ruby/build/miniruby(rb_bug) ../error.c:1052 /home/ubuntu/ruby/build/miniruby(obj_free+0x6db) [0x556337fed3fb] ../gc.c:3551 /home/ubuntu/ruby/build/miniruby(rb_objspace_call_finalizer+0x3bb) [0x556337fed8db] ../gc.c:4692 /home/ubuntu/ruby/build/miniruby(rb_ec_finalize+0x2a) [0x556337fccf80] ../eval.c:168 /home/ubuntu/ruby/build/miniruby(rb_ec_cleanup) ../eval.c:260 /home/ubuntu/ruby/build/miniruby(ruby_run_node+0x6e) [0x556337fcf58e] ../eval.c:328 /home/ubuntu/ruby/build/miniruby(rb_main+0x21) [0x556337f0ff0b] ../main.c:39 /home/ubuntu/ruby/build/miniruby(main) ../main.c:58 /lib/x86_64-linux-gnu/libc.so.6(0x7efe2a5bad90) [0x7efe2a5bad90] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x7efe2a5bae40] [0x556337f0ff55] -- Other runtime information ----------------------------------------------- * Process memory map: 556337ea6000-556337ee9000 r--p 00000000 00:39 4234136 /home/ubuntu/ruby/build/miniruby 556337ee9000-5563382fc000 r-xp 00043000 00:39 4234136 /home/ubuntu/ruby/build/miniruby 5563382fc000-5563384aa000 r--p 00456000 00:39 4234136 /home/ubuntu/ruby/build/miniruby 5563384aa000-5563384c1000 r--p 00603000 00:39 4234136 /home/ubuntu/ruby/build/miniruby 5563384c1000-5563384c2000 rw-p 0061a000 00:39 4234136 /home/ubuntu/ruby/build/miniruby 5563384c2000-5563384d8000 rw-p 00000000 00:00 0 55633a3d2000-55633a6dd000 rw-p 00000000 00:00 0 [heap] 7efe23be1000-7efe26710000 r--s 00000000 00:39 4234136 /home/ubuntu/ruby/build/miniruby 7efe26710000-7efe26720000 rw-p 00000000 00:00 0 7efe26812000-7efe26a30000 r--s 00000000 00:39 4191832 /usr/lib/x86_64-linux-gnu/libc.so.6 7efe26a30000-7efe26ad0000 rw-p 00000000 00:00 0 7efe26ad0000-7efe26ad1000 ---p 00000000 00:00 0 7efe26ad1000-7efe26b72000 rw-p 00000000 00:00 0 7efe26b72000-7efe26b73000 ---p 00000000 00:00 0 7efe26b73000-7efe26c14000 rw-p 00000000 00:00 0 7efe26c14000-7efe26c15000 ---p 00000000 00:00 0 7efe26c15000-7efe26cb6000 rw-p 00000000 00:00 0 7efe26cb6000-7efe26cb7000 ---p 00000000 00:00 0 7efe26cb7000-7efe26d58000 rw-p 00000000 00:00 0 7efe26d58000-7efe26d59000 ---p 00000000 00:00 0 7efe26d59000-7efe26dfa000 rw-p 00000000 00:00 0 7efe26dfa000-7efe26dfb000 ---p 00000000 00:00 0 7efe26dfb000-7efe26e9c000 rw-p 00000000 00:00 0 7efe26e9c000-7efe26e9d000 ---p 00000000 00:00 0 7efe26e9d000-7efe26f3e000 rw-p 00000000 00:00 0 7efe26f3e000-7efe26f3f000 ---p 00000000 00:00 0 7efe26f3f000-7efe26fe0000 rw-p 00000000 00:00 0 7efe26fe0000-7efe26fe1000 ---p 00000000 00:00 0 7efe26fe1000-7efe27082000 rw-p 00000000 00:00 0 7efe27082000-7efe27083000 ---p 00000000 00:00 0 7efe27083000-7efe27124000 rw-p 00000000 00:00 0 7efe27124000-7efe27125000 ---p 00000000 00:00 0 7efe27125000-7efe271c6000 rw-p 00000000 00:00 0 7efe271c6000-7efe271c7000 ---p 00000000 00:00 0 7efe271c7000-7efe27268000 rw-p 00000000 00:00 0 7efe27268000-7efe27269000 ---p 00000000 00:00 0 7efe27269000-7efe2730a000 rw-p 00000000 00:00 0 7efe2730a000-7efe2730b000 ---p 00000000 00:00 0 7efe2730b000-7efe273ac000 rw-p 00000000 00:00 0 7efe273ac000-7efe273ad000 ---p 00000000 00:00 0 7efe273ad000-7efe2744e000 rw-p 00000000 00:00 0 7efe2744e000-7efe2744f000 ---p 00000000 00:00 0 7efe2744f000-7efe274f0000 rw-p 00000000 00:00 0 7efe274f0000-7efe274f1000 ---p 00000000 00:00 0 7efe274f1000-7efe27592000 rw-p 00000000 00:00 0 7efe27592000-7efe27593000 ---p 00000000 00:00 0 7efe27593000-7efe27634000 rw-p 00000000 00:00 0 7efe27634000-7efe27635000 ---p 00000000 00:00 0 7efe27635000-7efe276d6000 rw-p 00000000 00:00 0 7efe276d6000-7efe276d7000 ---p 00000000 00:00 0 7efe276d7000-7efe27778000 rw-p 00000000 00:00 0 7efe27778000-7efe27779000 ---p 00000000 00:00 0 7efe27779000-7efe2781a000 rw-p 00000000 00:00 0 7efe2781a000-7efe2781b000 ---p 00000000 00:00 0 7efe2781b000-7efe278bc000 rw-p 00000000 00:00 0 7efe278bc000-7efe278bd000 ---p 00000000 00:00 0 7efe278bd000-7efe2795e000 rw-p 00000000 00:00 0 7efe2795e000-7efe2795f000 ---p 00000000 00:00 0 7efe2795f000-7efe27a00000 rw-p 00000000 00:00 0 7efe27a00000-7efe27a01000 ---p 00000000 00:00 0 7efe27a01000-7efe27aa2000 rw-p 00000000 00:00 0 7efe27aa2000-7efe27aa3000 ---p 00000000 00:00 0 7efe27aa3000-7efe27b44000 rw-p 00000000 00:00 0 7efe27b44000-7efe27b45000 ---p 00000000 00:00 0 7efe27b45000-7efe27be6000 rw-p 00000000 00:00 0 7efe27be6000-7efe27be7000 ---p 00000000 00:00 0 7efe27be7000-7efe27c88000 rw-p 00000000 00:00 0 7efe27c88000-7efe27c89000 ---p 00000000 00:00 0 7efe27c89000-7efe27d2a000 rw-p 00000000 00:00 0 7efe27d2a000-7efe27d2b000 ---p 00000000 00:00 0 7efe27d2b000-7efe27dcc000 rw-p 00000000 00:00 0 7efe27dcc000-7efe27dcd000 ---p 00000000 00:00 0 7efe27dcd000-7efe27e6e000 rw-p 00000000 00:00 0 7efe27e6e000-7efe27e6f000 ---p 00000000 00:00 0 7efe27e6f000-7efe27f20000 rw-p 00000000 00:00 0 7efe27f2f000-7efe27f30000 ---p 00000000 00:00 0 7efe27f30000-7efe28780000 rw-p 00000000 00:00 0 7efe2878f000-7efe2a140000 rw-p 00000000 00:00 0 7efe2a144000-7efe2a245000 rw-p 00000000 00:00 0 7efe2a245000-7efe2a24c000 r--s 00000000 00:39 4192098 /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache 7efe2a24c000-7efe2a2a3000 r--p 00000000 00:39 4193355 /usr/lib/locale/C.utf8/LC_CTYPE 7efe2a2a3000-7efe2a58c000 r--p 00000000 00:39 4192959 /usr/lib/locale/locale-archive 7efe2a58c000-7efe2a591000 rw-p 00000000 00:00 0 7efe2a591000-7efe2a5b9000 r--p 00000000 00:39 4191832 /usr/lib/x86_64-linux-gnu/libc.so.6 7efe2a5b9000-7efe2a74e000 r-xp 00028000 00:39 4191832 /usr/lib/x86_64-linux-gnu/libc.so.6 7efe2a74e000-7efe2a7a6000 r--p 001bd000 00:39 4191832 /usr/lib/x86_64-linux-gnu/libc.so.6 7efe2a7a6000-7efe2a7aa000 r--p 00214000 00:39 4191832 /usr/lib/x86_64-linux-gnu/libc.so.6 7efe2a7aa000-7efe2a7ac000 rw-p 00218000 00:39 4191832 /usr/lib/x86_64-linux-gnu/libc.so.6 7efe2a7ac000-7efe2a7b9000 rw-p 00000000 00:00 0 7efe2a7b9000-7efe2a7bc000 r--p 00000000 00:39 3583519 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 7efe2a7bc000-7efe2a7d3000 r-xp 00003000 00:39 3583519 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 7efe2a7d3000-7efe2a7d7000 r--p 0001a000 00:39 3583519 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 7efe2a7d7000-7efe2a7d8000 r--p 0001d000 00:39 3583519 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 7efe2a7d8000-7efe2a7d9000 rw-p 0001e000 00:39 3583519 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 7efe2a7d9000-7efe2a7e7000 r--p 00000000 00:39 4191835 /usr/lib/x86_64-linux-gnu/libm.so.6 7efe2a7e7000-7efe2a863000 r-xp 0000e000 00:39 4191835 /usr/lib/x86_64-linux-gnu/libm.so.6 7efe2a863000-7efe2a8be000 r--p 0008a000 00:39 4191835 /usr/lib/x86_64-linux-gnu/libm.so.6 7efe2a8be000-7efe2a8bf000 r--p 000e4000 00:39 4191835 /usr/lib/x86_64-linux-gnu/libm.so.6 7efe2a8bf000-7efe2a8c0000 rw-p 000e5000 00:39 4191835 /usr/lib/x86_64-linux-gnu/libm.so.6 7efe2a8c0000-7efe2a8c2000 r--p 00000000 00:39 12895 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 7efe2a8c2000-7efe2a8d6000 r-xp 00002000 00:39 12895 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 7efe2a8d6000-7efe2a8ef000 r--p 00016000 00:39 12895 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 7efe2a8ef000-7efe2a8f0000 ---p 0002f000 00:39 12895 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 7efe2a8f0000-7efe2a8f1000 r--p 0002f000 00:39 12895 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 7efe2a8f1000-7efe2a8f2000 rw-p 00030000 00:39 12895 /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 7efe2a8f2000-7efe2a8fa000 rw-p 00000000 00:00 0 7efe2a8fa000-7efe2a904000 r--p 00000000 00:39 13002 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 7efe2a904000-7efe2a963000 r-xp 0000a000 00:39 13002 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 7efe2a963000-7efe2a97a000 r--p 00069000 00:39 13002 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 7efe2a97a000-7efe2a97b000 r--p 0007f000 00:39 13002 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 7efe2a97b000-7efe2a97c000 rw-p 00080000 00:39 13002 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 7efe2a97c000-7efe2a97e000 r--p 00000000 00:39 13365 /usr/lib/x86_64-linux-gnu/libz.so.1.2.11 7efe2a97e000-7efe2a98f000 r-xp 00002000 00:39 13365 /usr/lib/x86_64-linux-gnu/libz.so.1.2.11 7efe2a98f000-7efe2a995000 r--p 00013000 00:39 13365 /usr/lib/x86_64-linux-gnu/libz.so.1.2.11 7efe2a995000-7efe2a996000 ---p 00019000 00:39 13365 /usr/lib/x86_64-linux-gnu/libz.so.1.2.11 7efe2a996000-7efe2a997000 r--p 00019000 00:39 13365 /usr/lib/x86_64-linux-gnu/libz.so.1.2.11 7efe2a997000-7efe2a998000 rw-p 0001a000 00:39 13365 /usr/lib/x86_64-linux-gnu/libz.so.1.2.11 7efe2a99e000-7efe2a9a0000 rw-p 00000000 00:00 0 7efe2a9a0000-7efe2a9a2000 r--p 00000000 00:39 4191829 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 7efe2a9a2000-7efe2a9cc000 r-xp 00002000 00:39 4191829 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 7efe2a9cc000-7efe2a9d7000 r--p 0002c000 00:39 4191829 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 7efe2a9d8000-7efe2a9da000 r--p 00037000 00:39 4191829 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 7efe2a9da000-7efe2a9dc000 rw-p 00039000 00:39 4191829 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 7ffdc11f0000-7ffdc19ef000 rw-p 00000000 00:00 0 [stack] 7ffdc19f7000-7ffdc19fb000 r--p 00000000 00:00 0 [vvar] 7ffdc19fb000-7ffdc19fd000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] Aborted (core dumped) ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:115569] [Ruby master Misc#20035] Command-line settings move from parser to compiler
by kddnewton (Kevin Newton) 12 Dec '23

12 Dec '23

Issue #20035 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Misc #20035: Command-line settings move from parser to compiler https://bugs.ruby-lang.org/issues/20035 * Author: kddnewton (Kevin Newton) * Status: Open * Priority: Normal ---------------------------------------- Right now, when you pass `-n`, `-p`, `-l`, or `-a`, these options are all passed to the parser to manipulate the parse tree into giving you the desired behavior. For example: $ ruby --dump=parsetree -p -e "foo" ``` ruby ########################################################### ## Do NOT use this node dump for any purpose other than ## ## debug and research. Compatibility is not guaranteed. ## ########################################################### # @ NODE_SCOPE (id: 1, line: 1, location: (1,0)-(1,3)) # +- nd_tbl: (empty) # +- nd_args: # | (null node) # +- nd_body: # @ NODE_WHILE (id: 10, line: 1, location: (1,0)-(1,0)) # +- nd_state: 1 (while-end) # +- nd_cond: # | @ NODE_FCALL (id: 9, line: 1, location: (1,0)-(1,0)) # | +- nd_mid: :gets # | +- nd_args: # | @ NODE_LIST (id: 8, line: 1, location: (1,0)-(1,0)) # | +- nd_alen: 1 # | +- nd_head: # | | @ NODE_GVAR (id: 7, line: 1, location: (1,0)-(1,0)) # | | +- nd_entry: :$/ # | +- nd_next: # | (null node) # +- nd_body: # @ NODE_BLOCK (id: 5, line: 1, location: (1,0)-(1,0)) # +- nd_head (1): # | @ NODE_VCALL (id: 0, line: 1, location: (1,0)-(1,3))* # | +- nd_mid: :foo # +- nd_head (2): # @ NODE_FCALL (id: 4, line: 1, location: (1,0)-(1,0)) # +- nd_mid: :print # +- nd_args: # @ NODE_LIST (id: 3, line: 1, location: (1,0)-(1,0)) # +- nd_alen: 1 # +- nd_head: # | @ NODE_GVAR (id: 2, line: 1, location: (1,0)-(1,0)) # | +- nd_entry: :$_ # +- nd_next: # (null node) ``` Could this mutation be moved into the compiler? That way it could be shared by prism, but also because it would make it less confusing when people are running `--dump=parsetree` as to why a loop is being inserted. -- https://bugs.ruby-lang.org/

2 4

[ruby-core:115682] [Ruby master Misc#20056] Dir#chdir inconsistency with Dir.chdir
by zverok (Victor Shepelev) 12 Dec '23

12 Dec '23

Issue #20056 has been reported by zverok (Victor Shepelev). ---------------------------------------- Misc #20056: Dir#chdir inconsistency with Dir.chdir https://bugs.ruby-lang.org/issues/20056 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal * Assignee: jeremyevans0 (Jeremy Evans) ---------------------------------------- I am not sure it is important; I just wanted to understand if this is intentional or accidental. 1. There is no block form for `Dir#chdir`, unlike `Dir.chdir` (the form that will return to the previous directory when the block is finished) 2. `Dir.chdir` returns `0`, while `Dir#chdir` returns `nil` (both seem to be not representing any particular internal value, just a hardcoded return value). -- https://bugs.ruby-lang.org/

2 11

[ruby-core:115701] [Ruby master Bug#20059] TracePoint#enable can be called multiple times, increasing the number of invokations
by zverok (Victor Shepelev) 12 Dec '23

12 Dec '23

Issue #20059 has been reported by zverok (Victor Shepelev). ---------------------------------------- Bug #20059: TracePoint#enable can be called multiple times, increasing the number of invokations https://bugs.ruby-lang.org/issues/20059 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I just stumbled upon this accidentally (created a tracepoint with `TracePoint.trace`, and then `enable`d it). My initial example ```ruby trace = TracePoint.trace(:raise) do |tp| puts "Exception raised: #{tp.raised_exception.inspect} at #{tp.path}:#{tp.lineno}" end trace.enable # shouldn't do this, it was already enabled! raise "foo" ``` This prints ``` Exception raised: #<RuntimeError: foo> at test.rb:5 Exception raised: #<RuntimeError: foo> at test.rb:5 ``` Twice. If I'll remove the "unnecessary" `trace.enable`, it prints it once. So the theory is "multiple enables = multiple invokations of a tracepoint"... ```ruby trace = TracePoint.trace(:raise) do |tp| puts "Exception raised: #{tp.raised_exception.inspect} at #{tp.path}:#{tp.lineno}" end 5.times { trace.enable } raise "foo" ``` ...and indeed, this code prints the "Exception raised:" message 6 times. I don't see anything about this behavior in the [method's docs](https://docs.ruby-lang.org/en/master/TracePoint.html#method-i-enable) or class docs, and can't think of a plausible explanation. But it was this way since Ruby 2.0, and either it _should_ be this way, or it bothers nobody :) I wonder: * is there a reasonable explanation for this? * if so, shouldn't it be documented somewhere?.. Or is it some part of a pattern of how the `TracePoint` works that I am missing here?.. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:115647] [Ruby master Bug#20048] UDPSocket#remote_address spec errors
by vo.x (Vit Ondruch) 11 Dec '23

11 Dec '23

Issue #20048 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #20048: UDPSocket#remote_address spec errors https://bugs.ruby-lang.org/issues/20048 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-12-07 master 071df40495) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Testing of Fedora Rawhide, we have recently started to observe following errors: ~~~ $ make -C redhat-linux-build test-spec MSPECOPT="-fs ../spec/ruby/library/socket/udpsocket" ... snip ... 1) An exception occurred during: before :each UDPSocket#local_address using IPv4 using an implicit hostname the returned Addrinfo uses the correct IP address ERROR Socket::ResolutionError: getaddrinfo: Name or service not known /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:66:in `connect' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:66:in `block (4 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:4:in `<top (required)>' 2) An exception occurred during: before :each UDPSocket#local_address using IPv6 using an implicit hostname the returned Addrinfo uses the correct IP address ERROR Socket::ResolutionError: getaddrinfo: Name or service not known /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:66:in `connect' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:66:in `block (4 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:4:in `<top (required)>' 3) An exception occurred during: before :each UDPSocket#remote_address using IPv4 using an implicit hostname the returned Addrinfo uses the correct IP address ERROR Socket::ResolutionError: getaddrinfo: Name or service not known /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:65:in `connect' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:65:in `block (4 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:4:in `<top (required)>' 4) An exception occurred during: before :each UDPSocket#remote_address using IPv6 using an implicit hostname the returned Addrinfo uses the correct IP address ERROR Socket::ResolutionError: getaddrinfo: Name or service not known /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:65:in `connect' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:65:in `block (4 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:4:in `<top (required)>' Finished in 0.020615 seconds 11 files, 95 examples, 123 expectations, 0 failures, 4 errors, 0 tagged make: *** [uncommon.mk:983: yes-test-spec] Error 1 make: Leaving directory '/builddir/build/BUILD/ruby-3.3.0-071df40495/redhat-linux-build' ~~~ Please note that the build environment does not have network connection enabled by default. As soon as the network connection is available, the test cases pass just fine. This started to happen between these two commits: https://github.com/ruby/ruby/compare/c8b60c8ac2c8bbd077150792b5b207e983ab36… Where the culprit likely is commit:git|d2ba8ea54a4089959afdeecdd963e3c4ff391748 Originally reported [here](https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedorapr… -- https://bugs.ruby-lang.org/

3 8