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

[ruby-core:116894] [Ruby master Bug#20288] `rb_fiber_scheduler_close` exceptions are not handled in `rb_fiber_scheduler_set`.
by ioquatix (Samuel Williams) 06 Jul '24

06 Jul '24

Issue #20288 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #20288: `rb_fiber_scheduler_close` exceptions are not handled in `rb_fiber_scheduler_set`. https://bugs.ruby-lang.org/issues/20288 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The code responsible for setting a new scheduler on a thread does not properly handle exceptions raised by `rb_fiber_scheduler_close`. If `rb_fiber_scheduler_close` raised an exception, the assignment `thread->scheduler = scheduler` would not be executed. This leaves the thread in an undefined state because it might still hold a reference to the old scheduler, which was supposed to be closed and replaced. ## Steps to Reproduce: 1. Define a custom fiber scheduler that raises an exception in its close method. 2. Set the custom scheduler on a thread. 3. Attempt to replace the custom scheduler with a different scheduler. 4. Observe that if the close method of the original scheduler raises an exception, the thread's scheduler reference is not updated. ## Proposed Fix: The use of `rb_ensure` can be introduced to wrap the call to `rb_fiber_scheduler_close` to ensure that, regardless of whether an exception is raised, `thread->scheduler` is set to `Qnil`, and then `thread->scheduler = scheduler` is safely executed to update the thread's scheduler reference. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:116890] [Ruby master Bug#20286] TracePoint does not emit `thread_end` event when thread exits with exception
by ioquatix (Samuel Williams) 06 Jul '24

06 Jul '24

Issue #20286 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #20286: TracePoint does not emit `thread_end` event when thread exits with exception https://bugs.ruby-lang.org/issues/20286 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Using TracePoint to trace `thread_begin` and `thread_end` events fails to emit the `thread_end` event when an exception (e.g., Interrupt) is raised within a thread. This behavior occurs because the exception handling bypasses the internal thread finishing logic, including trace point and fiber scheduler cleanup code. This issue affects the ability to accurately monitor thread lifecycle events in scenarios involving exception handling or abrupt thread terminations. ## Steps to Reproduce: 1. Set up `TracePoint` to trace `thread_begin` and `thread_end` events. 2. Create a new thread that raises an exception. 3. Join the thread and observe that only the `thread_begin` event is emitted without a corresponding `thread_end` event. ## Expected Behavior: The `TracePoint` should emit both `thread_begin` and `thread_end` events, accurately reflecting the lifecycle of the thread, even when an exception is raised within the thread. ## Actual Behavior: The `TracePoint` emits the `thread_begin` event but fails to emit the `thread_end` event when an exception is raised within the thread, indicating an incomplete tracing of thread lifecycle events. I've confirmed this as far back as Ruby 2.6. ## Example Code ```ruby TracePoint.trace(:thread_begin, :thread_end) do |tp| p [tp.event, tp.lineno, tp.path, tp.defined_class, tp.method_id] end thread = Thread.new do raise Interrupt end thread.join ``` ## Possible Fix Changing the implementation of `thread_do_start` to have what amounts to an "ensure" block. ```c static void thread_do_start(rb_thread_t *th) { native_set_thread_name(th); VALUE result = Qundef; rb_execution_context_t *ec = th->ec; int state; EXEC_EVENT_HOOK(ec, RUBY_EVENT_THREAD_BEGIN, th->self, 0, 0, 0, Qundef); EC_PUSH_TAG(ec); if ((state = EC_EXEC_TAG()) == TAG_NONE) { switch (th->invoke_type) { case thread_invoke_type_proc: result = thread_do_start_proc(th); break; case thread_invoke_type_ractor_proc: result = thread_do_start_proc(th); rb_ractor_atexit(th->ec, result); break; case thread_invoke_type_func: result = (*th->invoke_arg.func.func)(th->invoke_arg.func.arg); break; case thread_invoke_type_none: rb_bug("unreachable"); } } EC_POP_TAG(); VALUE errinfo = ec->errinfo; if (!NIL_P(errinfo) && !RB_TYPE_P(errinfo, T_OBJECT)) { ec->errinfo = Qnil; } rb_fiber_scheduler_set(Qnil); EXEC_EVENT_HOOK(th->ec, RUBY_EVENT_THREAD_END, th->self, 0, 0, 0, Qundef); ec->errinfo = errinfo; if (state) EC_JUMP_TAG(ec, state); th->value = result; } ``` It's possible `rb_fiber_scheduler_set(Qnil);` can emit an exception itself. How do we write the code to handle that case? -- https://bugs.ruby-lang.org/

3 5

[ruby-core:115937] [Ruby master Bug#20099] Ruby 3.3.0 segfaults on s390x musl libc (Alpine Linux)
by jirutka (Jakub Jirutka) 01 Jul '24

01 Jul '24

Issue #20099 has been reported by jirutka (Jakub Jirutka). ---------------------------------------- Bug #20099: Ruby 3.3.0 segfaults on s390x musl libc (Alpine Linux) https://bugs.ruby-lang.org/issues/20099 * Author: jirutka (Jakub Jirutka) * Status: Open * Priority: Normal * ruby -v: 3.3.0 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ``` Configuration summary for ruby version 3.3.0 * Installation prefix: /usr * exec prefix: ${prefix} * arch: s390x-linux-musl * site arch: ${arch} * RUBY_BASE_NAME: ruby * enable shared: yes * ruby lib prefix: ${libdir}/${RUBY_BASE_NAME} * site libraries path: ${rubylibprefix}/${sitearch} * vendor path: ${rubylibprefix}/vendor_ruby * target OS: linux-musl * compiler: gcc * with thread: pthread * with coroutine: ucontext * enable shared libs: yes * dynamic library ext: so * CFLAGS: ${optflags} ${debugflags} ${warnflags} * LDFLAGS: -L. -Wl,--as-needed,-O1,--sort-common \ -fstack-protector-strong -rdynamic \ -Wl,-export-dynamic -Wl,--no-as-needed * DLDFLAGS: -Wl,--as-needed,-O1,--sort-common \ -Wl,--compress-debug-sections=zlib * optflags: -O3 -fno-fast-math * debugflags: -ggdb3 * warnflags: -Wall -Wextra -Wdeprecated-declarations \ -Wdiv-by-zero -Wduplicated-cond \ -Wimplicit-function-declaration -Wimplicit-int \ -Wpointer-arith -Wwrite-strings \ -Wold-style-definition -Wimplicit-fallthrough=0 \ -Wmissing-noreturn -Wno-cast-function-type \ -Wno-constant-logical-operand -Wno-long-long \ -Wno-missing-field-initializers \ -Wno-overlength-strings \ -Wno-packed-bitfield-compat \ -Wno-parentheses-equality -Wno-self-assign \ -Wno-tautological-compare -Wno-unused-parameter \ -Wno-unused-value -Wsuggest-attribute=format \ -Wsuggest-attribute=noreturn -Wunused-variable \ -Wmisleading-indentation -Wundef * strip command: strip -S -x * install doc: rdoc * YJIT support: no * RJIT support: no * man page type: man * search path: /usr/lib/site_ruby/$(ruby_ver)/s390x-linux --- BASERUBY = ./tool/missing-baseruby.bat CC = gcc LD = ld LDSHARED = gcc -shared CFLAGS = -O2 -fstack-clash-protection -Wformat -Werror=format-security -g -fno-omit-frame-pointer -fno-strict-aliasing -fPIC XCFLAGS = -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fno-strict-overflow -fvisibility=hidden -fexcess-precision=standard -DRUBY_EXPORT -I. -I.ext/include/s390x-linux-musl -I./include -I. -I./prism -I./enc/unicode/15.0.0 CPPFLAGS = -fno-omit-frame-pointer -fno-strict-aliasing DLDFLAGS = -Wl,--as-needed,-O1,--sort-common -Wl,--compress-debug-sections=zlib -Wl,-soname,libruby.so.3.3 -fstack-protector-strong SOLIBS = -lz -lrt -lrt -lgmp -ldl -lcrypt -lm -lpthread -lucontext LANG = LC_ALL = LC_CTYPE = MFLAGS = -j8 --jobserver-auth=fifo:/tmp/GMfifo7323 RUSTC = no YJIT_RUSTC_ARGS = --crate-name=yjit --crate-type=staticlib --edition=2021 -g -C lto=thin -C opt-level=3 -C overflow-checks=on '--out-dir=/builds/alpine/aports/main/ruby/src/ruby-3.3.0/yjit/target/release/' ./yjit/src/lib.rs ``` ``` 2023-12-26 20:45:17 +0000 Driver is ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [s390x-linux-musl] Target is ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [s390x-linux-musl] .............................................................................. .............................................................................. .............................................................................. .............................................................................. ................................................................EA core file is found. Saving it at: "/tmp/bootstraptest-core.2023-12-26T20:45:18Z" ["gdb", "/builds/alpine/aports/main/ruby/src/ruby-3.3.0/ruby -I/builds/alpine/aports/main/ruby/src/ruby-3.3.0/lib --disable-gems", "-c", "/tmp/bootstraptest-core.2023-12-26T20:45:18Z", "-ex", "bt", "-batch"] ...EA core file is found. Saving it at: "/tmp/bootstraptest-core.2023-12-26T20:45:19Z" ["gdb", "/builds/alpine/aports/main/ruby/src/ruby-3.3.0/ruby -I/builds/alpine/aports/main/ruby/src/ruby-3.3.0/lib --disable-gems", "-c", "/tmp/bootstraptest-core.2023-12-26T20:45:19Z", "-ex", "bt", "-batch"] .....Fstderr output is not empty [BUG] Segmentation fault at 0x000007fece67a000 ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [s390x-linux-musl] -- Control frame information ----------------------------------------------- c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] -- Threading information --------------------------------------------------- Total ractor count: 2 Ruby thread count for this ractor: 1 -- Other runtime information ----------------------------------------------- * Loaded script: bootstraptest.test_ractor.rb_244_1238.rb * Loaded features: 0 enumerator.so 1 thread.rb 2 fiber.so 3 rational.so 4 complex.so 5 ruby2_keywords.rb 6 /builds/alpine/aports/main/ruby/src/ruby-3.3.0/.ext/s390x-linux-musl/enc/encdb.so 7 /builds/alpine/aports/main/ruby/src/ruby-3.3.0/.ext/s390x-linux-musl/enc/trans/transdb.so * Process memory map: 2aa25e00000-2aa25e01000 r-xp 00000000 fe:00 2520910 /builds/alpine/aports/main/ruby/src/ruby-3.3.0/ruby 2aa25e01000-2aa25e02000 r--p 00000000 fe:00 2520910 /builds/alpine/aports/main/ruby/src/ruby-3.3.0/ruby 2aa25e02000-2aa25e03000 rw-p 00001000 fe:00 2520910 /builds/alpine/aports/main/ruby/src/ruby-3.3.0/ruby 2aa2765d000-2aa2765e000 ---p 00000000 00:00 0 [heap] 2aa2765e000-2aa27664000 rw-p 00000000 00:00 0 [heap] 3ff572a8000-3ff572aa000 ---p 00000000 00:00 0 3ff572aa000-3ff572d0000 rw-p 00000000 00:00 0 3ff572d0000-3ff572d2000 ---p 00000000 00:00 0 3ff572d2000-3ff573f9000 rw-p 00000000 00:00 0 3ff573f9000-3ff573fa000 ---p 00000000 00:00 0 3ff573fa000-3ff5751a000 rw-p 00000000 00:00 0 3ff5751a000-3ff5751b000 ---p 00000000 00:00 0 3ff5751b000-3ff77300000 rw-p 00000000 00:00 0 3ff77300000-3ff77302000 r-xp 00000000 fe:00 2520334 /builds/alpine/aports/main/ruby/src/ruby-3.3.0/.ext/s390x-linux-musl/enc/trans/transdb.so 3ff77302000-3ff77303000 r--p 00002000 fe:00 2520334 /builds/alpine/aports/main/ruby/src/ruby-3.3.0/.ext/s390x-linux-musl/enc/trans/transdb.so 3ff77303000-3ff77304000 rw-p 00003000 fe:00 2520334 /builds/alpine/aports/main/ruby/src/ruby-3.3.0/.ext/s390x-linux-musl/enc/trans/transdb.so 3ff77307000-3ff77309000 rw-p 00000000 00:00 0 3ff7730b000-3ff7730e000 rw-p 00000000 00:00 0 3ff77310000-3ff77330000 rw-p 00000000 00:00 0 3ff77332000-3ff77337000 rw-p 00000000 00:00 0 3ff77339000-3ff7733a000 rw-p 00000000 00:00 0 3ff7733b000-3ff7733e000 rw-p 00000000 00:00 0 3ff77340000-3ff77380000 rw-p 00000000 00:00 0 3ff77380000-3ff77382000 r-xp 00000000 fe:00 2520245 /builds/alpine/aports/main/ruby/src/ruby-3.3.0/.ext/s390x-linux-musl/enc/encdb.so 3ff77382000-3ff77383000 r--p 00001000 fe:00 2520245 /builds/alpine/aports/main/ruby/src/ruby-3.3.0/.ext/s390x-linux-musl/enc/encdb.so 3ff77383000-3ff77384000 rw-p 00002000 fe:00 2520245 /builds/alpine/aports/main/ruby/src/ruby-3.3.0/.ext/s390x-linux-musl/enc/encdb.so 3ff77384000-3ff7739c000 rw-p 00000000 00:00 0 3ff7739c000-3ff7739d000 ---p 00000000 00:00 0 3ff7739d000-3ff773de000 rw-p 00000000 00:00 0 3ff773de000-3ff773df000 ---p 00000000 00:00 0 3ff773df000-3ff77420000 rw-p 00000000 00:00 0 3ff77420000-3ff77421000 ---p 00000000 00:00 0 3ff77421000-3ff77462000 rw-p 00000000 00:00 0 3ff77462000-3ff77463000 ---p 00000000 00:00 0 3ff77463000-3ff774a4000 rw-p 00000000 00:00 0 3ff774a4000-3ff774a5000 ---p 00000000 00:00 0 3ff774a5000-3ff774e6000 rw-p 00000000 00:00 0 3ff774e6000-3ff774e7000 ---p 00000000 00:00 0 3ff774e7000-3ff77528000 rw-p 00000000 00:00 0 3ff77528000-3ff77529000 ---p 00000000 00:00 0 3ff77529000-3ff7756a000 rw-p 00000000 00:00 0 3ff7756a000-3ff7756b000 ---p 00000000 00:00 0 3ff7756b000-3ff775ac000 rw-p 00000000 00:00 0 3ff775ac000-3ff775ad000 ---p 00000000 00:00 0 3ff775ad000-3ff775ee000 rw-p 00000000 00:00 0 3ff775ee000-3ff775ef000 ---p 00000000 00:00 0 3ff775ef000-3ff77630000 rw-p 00000000 00:00 0 3ff77630000-3ff77631000 ---p 00000000 00:00 0 3ff77631000-3ff77672000 rw-p 00000000 00:00 0 3ff77672000-3ff77673000 ---p 00000000 00:00 0 3ff77673000-3ff776b4000 rw-p 00000000 00:00 0 3ff776b4000-3ff776b5000 ---p 00000000 00:00 0 3ff776b5000-3ff776f6000 rw-p 00000000 00:00 0 3ff776f6000-3ff776f7000 ---p 00000000 00:00 0 3ff776f7000-3ff77738000 rw-p 00000000 00:00 0 3ff77738000-3ff77739000 ---p 00000000 00:00 0 3ff77739000-3ff7777a000 rw-p 00000000 00:00 0 3ff7777a000-3ff7777b000 ---p 00000000 00:00 0 3ff7777b000-3ff777bc000 rw-p 00000000 00:00 0 3ff777bc000-3ff777bd000 ---p 00000000 00:00 0 3ff777bd000-3ff777fe000 rw-p 00000000 00:00 0 3ff777fe000-3ff777ff000 ---p 00000000 00:00 0 3ff777ff000-3ff77840000 rw-p 00000000 00:00 0 3ff77840000-3ff77841000 ---p 00000000 00:00 0 3ff77841000-3ff77882000 rw-p 00000000 00:00 0 3ff77882000-3ff77883000 ---p 00000000 00:00 0 3ff77883000-3ff778c4000 rw-p 00000000 00:00 0 3ff778c4000-3ff778c5000 ---p 00000000 00:00 0 3ff778c5000-3ff77906000 rw-p 00000000 00:00 0 3ff77906000-3ff77907000 ---p 00000000 00:00 0 3ff77907000-3ff77948000 rw-p 00000000 00:00 0 3ff77948000-3ff77949000 ---p 00000000 00:00 0 3ff77949000-3ff7798a000 rw-p 00000000 00:00 0 3ff7798a000-3ff7798b000 ---p 00000000 00:00 0 3ff7798b000-3ff779cc000 rw-p 00000000 00:00 0 3ff779cc000-3ff779cd000 ---p 00000000 00:00 0 3ff779cd000-3ff77a0e000 rw-p 00000000 00:00 0 3ff77a0e000-3ff77a0f000 ---p 00000000 00:00 0 3ff77a0f000-3ff77a50000 rw-p 00000000 00:00 0 3ff77a50000-3ff77a51000 ---p 00000000 00:00 0 3ff77a51000-3ff77a92000 rw-p 00000000 00:00 0 3ff77a92000-3ff77a93000 ---p 00000000 00:00 0 3ff77a93000-3ff77ad4000 rw-p 00000000 00:00 0 3ff77ad4000-3ff77ad5000 ---p 00000000 00:00 0 3ff77ad5000-3ff77b16000 rw-p 00000000 00:00 0 3ff77b16000-3ff77b17000 ---p 00000000 00:00 0 3ff77b17000-3ff77b58000 rw-p 00000000 00:00 0 3ff77b58000-3ff77b59000 ---p 00000000 00:00 0 3ff77b59000-3ff77b9a000 rw-p 00000000 00:00 0 3ff77b9a000-3ff77b9b000 ---p 00000000 00:00 0 3ff77b9b000-3ff77bdc000 rw-p 00000000 00:00 0 3ff77bdc000-3ff77bde000 ---p 00000000 00:00 0 3ff77bde000-3ff91100000 rw-p 00000000 00:00 0 3ff91100000-3ff91101000 r-xp 00000000 fe:00 2758431 /lib/libucontext.so.1 3ff91101000-3ff91102000 r--p 00000000 fe:00 2758431 /lib/libucontext.so.1 3ff91102000-3ff91103000 rw-p 00001000 fe:00 2758431 /lib/libucontext.so.1 3ff91103000-3ff9114b000 rw-p 00000000 00:00 0 3ff9114f000-3ff91153000 rw-p 00000000 00:00 0 3ff91155000-3ff91180000 rw-p 00000000 00:00 0 3ff91180000-3ff911fd000 r-xp 00000000 fe:00 2755903 /usr/lib/libgmp.so.10.5.0 3ff911fd000-3ff911ff000 r--p 0007c000 fe:00 2755903 /usr/lib/libgmp.so.10.5.0 3ff911ff000-3ff91200000 rw-p 0007e000 fe:00 2755903 /usr/lib/libgmp.so.10.5.0 3ff91200000-3ff91219000 r-xp 00000000 fe:00 2754145 /lib/libz.so.1.3 3ff91219000-3ff9121a000 r--p 00018000 fe:00 2754145 /lib/libz.so.1.3 3ff9121a000-3ff9121b000 rw-p 00019000 fe:00 2754145 /lib/libz.so.1.3 3ff9121b000-3ff91280000 rw-p 00000000 00:00 0 3ff91280000-3ff91700000 r-xp 00000000 fe:00 2519847 /builds/alpine/aports/main/ruby/src/ruby-3.3.0/libruby.so.3.3.0 3ff91700000-3ff9170c000 r--p 00480000 fe:00 2519847 /builds/alpine/aports/main/ruby/src/ruby-3.3.0/libruby.so.3.3.0 3ff9170c000-3ff9170d000 rw-p 0048c000 fe:00 2519847 /builds/alpine/aports/main/ruby/src/ruby-3.3.0/libruby.so.3.3.0 3ff9170d000-3ff9171f000 rw-p 00000000 00:00 0 3ff9171f000-3ff91780000 rw-p 00000000 00:00 0 3ff91780000-3ff91830000 r-xp 00000000 fe:00 2758095 /lib/ld-musl-s390x.so.1 3ff91830000-3ff91831000 r--p 000b0000 fe:00 2758095 /lib/ld-musl-s390x.so.1 3ff91831000-3ff91832000 rw-p 000b1000 fe:00 2758095 /lib/ld-musl-s390x.so.1 3ff91832000-3ff91835000 rw-p 00000000 00:00 0 3ff91835000-3ff9187c000 rw-p 00000000 00:00 0 3ff9187c000-3ff9187e000 r--p 00000000 00:00 0 [vvar] 3ff9187e000-3ff91880000 r-xp 00000000 00:00 0 [vdso] 3ffe2381000-3ffe2b80000 rw-p 00000000 00:00 0 [stack] ``` …and many more tests fail like this. ---Files-------------------------------- ruby-3.3.0-s390x.log (281 KB) -- https://bugs.ruby-lang.org/

3 2

[ruby-core:116182] [Ruby master Bug#20180] Inconsistent evaluation of `**{}` depending on position in array
by ozydingo (Andrew Schwartz) 15 Jun '24

15 Jun '24

Issue #20180 has been reported by ozydingo (Andrew Schwartz). ---------------------------------------- Bug #20180: Inconsistent evaluation of `**{}` depending on position in array https://bugs.ruby-lang.org/issues/20180 * Author: ozydingo (Andrew Schwartz) * Status: Open * Priority: Normal * ruby -v: 3.3 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Reproduced on ruby:3.3 docker container The evaluation of `**{}` differs if it appears alone (evaluates as empty / no content) in an array vs after another element (evaluates as an empty Hash). ```rb args = []; kwargs = {} [*args] # => [] [**kwargs] # => [] [*args, **kwargs] # => [{}] [*args] + [**kwargs] == [*args, **kwargs] => false ``` I claim this violates the Principle of Least Surprise. I will admit that beyond a thin example I will give below, I am struggling to come up with a more convincing pragmatic reason that this should be addressed, but due to how surprising it is and the bugs it cause our team I wanted to submit it for tracking. This may be related to https://bugs.ruby-lang.org/issues/20064?tab=notes though the issues are distinct. Specifically, in my use case, I am writing a class responsible for adapting arguments in one form to another (json object to method args and vice versa). My tests broken when adding support for keyword args due to expectations of no args: ``` # RSpec expect(foo).to have_received(:bar).with([]) # This now need `with([], {})` ``` Again, this is a bit thin as by itself this isn't problematic as I can add the `{}`. However, this does require that my test knows more about the implementation that it should. That is, my implementation might be ``` if kwargs.present? call(*args, **kwargs) else call(*args) end ``` This change does not change the behavior of the class, but will break the test. I therefore think this behavior of `**kwargs` is problematic. -- https://bugs.ruby-lang.org/

6 7

[ruby-core:116838] [Ruby master Bug#20280] Error at invalid encoding symbols
by nobu (Nobuyoshi Nakada) 15 Jun '24

15 Jun '24

Issue #20280 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #20280: Error at invalid encoding symbols https://bugs.ruby-lang.org/issues/20280 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED, 3.3: REQUIRED ---------------------------------------- Parsing an invalid encoding symbol raises an `EncodingError`. It must be a `SyntaxError`. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:116790] [Ruby master Bug#20270] Options with `--parser=prism`
by nobu (Nobuyoshi Nakada) 12 Jun '24

12 Jun '24

Issue #20270 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #20270: Options with `--parser=prism` https://bugs.ruby-lang.org/issues/20270 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal * Backport: 3.0: DONTNEED, 3.1: DONTNEED, 3.2: DONTNEED, 3.3: REQUIRED ---------------------------------------- ### `--dump` option Currently `parsetree` and `prism_parsetree` bits are separated, but it seems meaningless as far as `--parser` option selects only one parser. Why doesn't simply `--dump=parsetree` dump AST by parse.y, or PRISM AST if `--parser=prism` is given? Actually, `ruby --dump=parsetree --parser=prism` just segfaults, because these bits and `--parser` option are separately handled. ### streaming code from stdin ```sh-session $ echo end | ruby --parser=prism - ruby: warning: The compiler based on the Prism parser is currently experimental and compatibility with the compiler based on parse.y is not yet complete. Please report any issues you find on the `ruby/prism` issue tracker. -: warning: Prism support for streaming code from stdin is not currently supported ``` Nothing reported is fine, since it is not currently supported. I was a bit curious that it looks like trying something after the warning. ```C if (strcmp(opt->script, "-") == 0) { int xflag = opt->xflag; VALUE rb_source = open_load_file(opt->script_name, &xflag); opt->xflag = xflag != 0; rb_warn("Prism support for streaming code from stdin is not currently supported"); error = pm_parse_string(&result, rb_source, opt->script_name); } ``` Note that `open_load_file` returns `rb_stdin` when `-` is given. This object is a `RFile`, not a `RString`, and `RSTRING_PTR(rb_source)` accesses after the object boundary. It should just bail out, not try obviously wrong thing. ### Fix https://github.com/nobu/ruby/tree/options-refactor -- https://bugs.ruby-lang.org/

2 3

[ruby-core:116039] [Ruby master Bug#20154] aarch64: configure overrides `-mbranch-protection` if it was set in CFLAGS via environment
by jprokop (Jarek Prokop) 10 Jun '24

10 Jun '24

Issue #20154 has been reported by jprokop (Jarek Prokop). ---------------------------------------- Bug #20154: aarch64: configure overrides `-mbranch-protection` if it was set in CFLAGS via environment https://bugs.ruby-lang.org/issues/20154 * Author: jprokop (Jarek Prokop) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Recently a GH PR was merged <https://github.com/ruby/ruby/pull/9306> For PAC/BTI support on ARM CPUs for Coroutine.S. Without proper compilation support in configure.ac it segfaults Ruby with fibers on CPUs where PAC is supported: https://bugs.ruby-lang.org/issues/20085 At the time of writing, configure.ac appends the first option from a list for flag `-mbranch-protection` that successfully compiles a program <https://github.com/ruby/ruby/blob/master/configure.ac#L829>, to XCFLAGS and now also ASFLAGS to fix issue 20085 for Ruby master. This is suboptimal for Fedora as we set -mbranch-protection=standard by default in C{,XX}FLAGS: ``` CFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Werror=implicit-function-declaration -Werror=implicit-int -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer ' export CFLAGS CXXFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer' export CXXFLAGS ``` And the appended flag overrides distribution's compilation configuration, which in this case ends up omitting BTI instructions and only using PAC. Would it make sense to check if such flags exist and not overwrite them if they do? Serious proposals: 1. Simplest fix that does not overwrite what is set in the distribution and results in higher security is simply prepending the list of options with `-mbranch-protection=standard`, it should cause no problems on ARMv8 CPUs and forward, BTI similarly to PAC instructions result into NOP, it is only extending the capability. See attached 0001-aarch64-Check-mbranch-protection-standard-first-to-u.patch 2. Other fix that sounds more sane IMO and dodges this kind of guessing where are all the correct places for the flag is what another Fedora contributor Florian Weimer suggested: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… "The reliable way to do this would be to compile a C file and check whether that enables __ARM_FEATURE_PAC_DEFAULT, and if that's the case, define a *different* macro for use in the assembler implementation. This way, you don't need to care about the exact name of the option." IOW instead of using __ARM_FEATURE_* directly in that code, define a macro in the style of "USE_PAC" with value of the feature if it is defined, I think that way we shouldn't need to append ASFLAGS anymore. However it's also important to catch the value of those macros as their values have meaning, I have an idea how to do that but I'd get on that monday earliest. ---Files-------------------------------- 0001-aarch64-Check-mbranch-protection-standard-first-to-u.patch (1004 Bytes) -- https://bugs.ruby-lang.org/

4 10

[ruby-core:116460] [Ruby master Bug#20218] aset/masgn/op_asgn with keyword arguments
by jeremyevans0 (Jeremy Evans) 07 Jun '24

07 Jun '24

Issue #20218 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #20218: aset/masgn/op_asgn with keyword arguments https://bugs.ruby-lang.org/issues/20218 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I found that use of keyword arguments in multiple assignment is broken in 3.3 and master: ```ruby h = {a: 1} o = [] def o.[]=(*args, **kw) replace([args, kw]) end # This segfaults as RHS argument is not a hash o[1, a: 1], _ = [1, 2] # This passes the RHS argument as keywords to the method, treating keyword splat as positional argument o[1, **h], _ = [{b: 3}, 2] o # => [[1, {:a=>1}], {:b=>3}] ``` Before 3.3, keyword arguments were treated as positional arguments. This is similar to #19918, but for keyword arguments instead of block arguments. @matz indicated he wanted to prohibit block arguments in aset/masgn and presumably also op_asgn (making them SyntaxErrors). Can we also prohibit keyword arguments in aset/masgn/op_asgn? Note that aset treats keyword arguments as regular arguments: ```ruby o[1, a: 1] = 2 o # => [[1, {:a=>1}, 2], {}] o[1, **h] = {b: 3} o # => [[1, {:a=>2}, {:b=>3}], {}] ``` While op_asgn treats keyword arguments as keywords: ```ruby h = {a: 2} o = [] def o.[](*args, **kw) concat([:[], args, kw]) x = Object.new def x.+(v) [:x, v] end x end def o.[]=(*args, **kw) concat([:[]=, args, kw]) end o[1, a: 1] += 2 o # => [:[], [1], {:a=>1}, :[]=, [1, [:x, 2]], {:a=>1}] o.clear o[1, **h] += {b: 3} o # => [:[], [1], {:a=>2}, :[]=, [1, [:x, {:b=>3}]], {:a=>2}] ``` -- https://bugs.ruby-lang.org/

7 17

[ruby-core:116117] [Ruby master Misc#20170] Drop support for GCC < 11
by kddnewton (Kevin Newton) 07 Jun '24

07 Jun '24

Issue #20170 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Misc #20170: Drop support for GCC < 11 https://bugs.ruby-lang.org/issues/20170 * Author: kddnewton (Kevin Newton) * Status: Open * Priority: Normal ---------------------------------------- Right now, CI compiles everything from GCC 7+. However, GCC 7-10 are all end-of-life and no longer supported. We should drop support for the end-of-life compilers. -- https://bugs.ruby-lang.org/

4 5

[ruby-core:115595] [Ruby master Bug#20043] `defined?` checks for method existence but only sometimes
by tenderlovemaking (Aaron Patterson) 07 Jun '24

07 Jun '24

Issue #20043 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #20043: `defined?` checks for method existence but only sometimes https://bugs.ruby-lang.org/issues/20043 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-12-05T21:25:34Z master 56eccb350b) [arm64-darwin23] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- When an expression is passed to `defined?`, it will _sometimes_ check if a method in a sub-expression is defined and sometimes it won't. For example: ``` $ ./miniruby -e'p defined?(a)' nil $ ./miniruby -e'p defined?([a])' nil ``` In the above case, Ruby will check whether or not the method `a` is defined, and it returns `nil`. However, if you use a splat, it will not check: ``` $ ./miniruby -e'p defined?([*a])' "expression" ``` The same thing seems to happen with method parameters: ``` $ ./miniruby -e'p defined?(itself)' "method" $ ./miniruby -e'p defined?(itself(a))' nil $ ./miniruby -e'p defined?(itself(*a))' "method" ``` Oddly, `defined?` will check contents of arrays, but _won't_ check contents of hashes: ``` $ ./miniruby -e'p defined?([[[[a]]]])' nil $ ./miniruby -e'p defined?({ a => a })' "expression" ``` I think all of the cases that refer to `a` should check whether or not `a` is defined regardless of splats or hashes. -- https://bugs.ruby-lang.org/

7 9