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

[ruby-core:119513] [Ruby master Bug#20795] Timeout method doesn't check for negative time values
by kanakchaudhari12 (kanak chaudhari) 03 Dec '24

03 Dec '24

Issue #20795 has been reported by kanakchaudhari12 (kanak chaudhari). ---------------------------------------- Bug #20795: Timeout method doesn't check for negative time values https://bugs.ruby-lang.org/issues/20795 * Author: kanakchaudhari12 (kanak chaudhari) * Status: Open * ruby -v: 3.1.0 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ```ruby require 'timeout' # Case 1: Negative timeout with quick execution Timeout.timeout(-5) do puts "This should not execute" end # Case 2: Negative timeout with sleep Timeout.timeout(-5) do sleep(10) end ``` Potential issues with current behaviour: * Inconsistency: The behaviour differs based on the block's content, which may not be immediately apparent * Silent failure: The negative timeout is silently ignored, potentially masking logical errors in the calling code. * Unexpected source of error: one might expect the timeout method to validate its input, rather than relying on methods called within the block to catch invalid time values. I suggest this change for the consistent behaviour regardless of code-block as well as the clear indication of the source of the error ```ruby def timeout(sec, klass = nil, message = nil, &block) raise ArgumentError, "timeout must be positive" if sec.is_a?(Numeric) && sec < 0 # ... end ``` -- https://bugs.ruby-lang.org/

4 4

[ruby-core:120033] [Ruby master Bug#20916] Prism compiler should support ** in Ractor constant
by mame (Yusuke Endoh) 03 Dec '24

03 Dec '24

Issue #20916 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #20916: Prism compiler should support ** in Ractor constant https://bugs.ruby-lang.org/issues/20916 * Author: mame (Yusuke Endoh) * Status: Open * Assignee: prism * ruby -v: ruby 3.4.0dev (2024-11-28T02:34:20Z avoid-uninitialize.. 79ae6e72c8) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The Prism compiler raises an exception against the following code. ``` $ ./miniruby -e '# shareable_constant_value: experimental_everything C = { **{ } }' -e:2: Ractor constant writes do not support ** -e: node type not implemented (NotImplementedError) ``` But the traditional compiler support it, and @ko1 said it should be supported. Also, I feel that this error message `node type not implemented` is a sign of a worse problem. Actually, valgrind reports `Conditional jump or move depends on uninitialised value(s)`against the Prism compiler. An assertion failure is also reported. ``` $ valgrind ./miniruby -e '# shareable_constant_value: experimental_everything C = { **{ } }' ==49978== Memcheck, a memory error detector ==49978== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==49978== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info ==49978== Command: ./miniruby -e #\ shareable_constant_value:\ experimental_everything_C\ =\ {\ **{\ }\ } ==49978== ==49978== Warning: set address range perms: large range [0x64e0000, 0x1e4e0000) (defined) -e:2: Ractor constant writes do not support ** ==49978== Conditional jump or move depends on uninitialised value(s) ==49978== at 0x4BB42A: pm_newline_list_line (pm_newline_list.c:63) ==49978== by 0x1E718A: pm_compile_shareable_constant_value (prism_compile.c:5280) ==49978== by 0x1E7243: pm_compile_shareable_constant_value (prism_compile.c:5318) ==49978== by 0x1E8DC1: pm_compile_constant_write_node.isra.0 (prism_compile.c:5372) ==49978== by 0x1DCB2F: pm_compile_node (prism_compile.c:9823) ==49978== by 0x1DC9C8: pm_compile_node (prism_compile.c:9934) ==49978== by 0x1F3AC9: pm_compile_scope_node.isra.0 (prism_compile.c:6603) ==49978== by 0x1DA66A: pm_compile_node (prism_compile.c:9805) ==49978== by 0x1F61A7: pm_iseq_compile_node (prism_compile.c:10109) ==49978== by 0x2A5303: pm_iseq_new_with_opt_try (iseq.c:1027) ==49978== by 0x23DFF2: rb_protect (eval.c:1033) ==49978== by 0x2AB198: pm_iseq_new_with_opt (iseq.c:1080) ==49978== miniruby: prism/util/pm_newline_list.c:63: pm_newline_list_line: Assertion `cursor >= list->start' failed. ==49978== ==49978== Process terminating with default action of signal 6 (SIGABRT) ==49978== at 0x4AFAB1C: __pthread_kill_implementation (pthread_kill.c:44) ==49978== by 0x4AFAB1C: __pthread_kill_internal (pthread_kill.c:78) ==49978== by 0x4AFAB1C: pthread_kill@@GLIBC_2.34 (pthread_kill.c:89) ==49978== by 0x4AA126D: raise (raise.c:26) ==49978== by 0x4A848FE: abort (abort.c:79) ==49978== by 0x4A8481A: __assert_fail_base.cold (assert.c:94) ==49978== by 0x4A97506: __assert_fail (assert.c:103) ==49978== by 0x4BB49B: pm_newline_list_line (pm_newline_list.c:63) ==49978== by 0x1E718A: pm_compile_shareable_constant_value (prism_compile.c:5280) ==49978== by 0x1E7243: pm_compile_shareable_constant_value (prism_compile.c:5318) ==49978== by 0x1E8DC1: pm_compile_constant_write_node.isra.0 (prism_compile.c:5372) ==49978== by 0x1DCB2F: pm_compile_node (prism_compile.c:9823) ==49978== by 0x1DC9C8: pm_compile_node (prism_compile.c:9934) ==49978== by 0x1F3AC9: pm_compile_scope_node.isra.0 (prism_compile.c:6603) ==49978== ==49978== HEAP SUMMARY: ==49978== in use at exit: 2,645,494 bytes in 10,084 blocks ==49978== total heap usage: 36,662 allocs, 26,578 frees, 6,066,537 bytes allocated ==49978== ==49978== LEAK SUMMARY: ==49978== definitely lost: 0 bytes in 0 blocks ==49978== indirectly lost: 0 bytes in 0 blocks ==49978== possibly lost: 1,050,576 bytes in 4 blocks ==49978== still reachable: 1,594,918 bytes in 10,080 blocks ==49978== suppressed: 0 bytes in 0 blocks ==49978== Rerun with --leak-check=full to see details of leaked memory ==49978== ==49978== Use --track-origins=yes to see where uninitialised values come from ==49978== For lists of detected and suppressed errors, rerun with: -s ==49978== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Aborted (core dumped) ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:120034] [Ruby master Bug#20917] redo/next in nested begin block causes wrong order of execution
by hoshiumiarata (Arata Hoshiumi) 02 Dec '24

02 Dec '24

Issue #20917 has been reported by hoshiumiarata (Arata Hoshiumi). ---------------------------------------- Bug #20917: redo/next in nested begin block causes wrong order of execution https://bugs.ruby-lang.org/issues/20917 * Author: hoshiumiarata (Arata Hoshiumi) * Status: Open * ruby -v: ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x86_64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- It seems that `redo`/`next` in a nested `begin` block can cause the wrong order of execution. For example: ```ruby for _ in [0] puts 0 begin puts 1 begin puts 2 redo ensure puts 3 end ensure puts 4 break end end ``` It prints: ``` 0 1 2 3 4 3 4 => nil ``` But I think it should print: ``` 0 1 2 3 4 => nil ``` Because execution order should be: 1. `puts 0` 2. `puts 1` 3. `puts 2` 4. `redo` 5. unwind to nested `ensure` block 6. `puts 3` 7. unwind to outer `ensure` block 8. `puts 4` 9. `break` 10. end of loop Interestingly enough, if we add an empty `rescue` block before any of the `ensure` blocks, then the execution order is correct. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120002] [Ruby master Bug#20908] Ruby extension builds fail with GCC 15 which defaults to -std=gnu23
by thesamesam (Sam James) 01 Dec '24

01 Dec '24

Issue #20908 has been reported by thesamesam (Sam James). ---------------------------------------- Bug #20908: Ruby extension builds fail with GCC 15 which defaults to -std=gnu23 https://bugs.ruby-lang.org/issues/20908 * Author: thesamesam (Sam James) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Hi! Upcoming GCC 15 defaults to C23 (`-std=gnu23`). One thing C23 changes is removing unprototyped functions, so `void foo()` now means `void foo(void)`, rather than "any arguments". Ruby extensions fail to build as a result with GCC 15. This was reported downstream in Gentoo at https://bugs.gentoo.org/943784 where brotli-0.6.0 is an example: ``` make: Entering directory '/var/tmp/portage/dev-ruby/brotli-0.6.0/work/ruby32/brotli-0.6.0/ext/brotli' x86_64-pc-linux-gnu-gcc -I. -I/usr/include/ruby-3.2.0/x86_64-linux -I/usr/include/ruby-3.2.0/ruby/backward -I/usr/include/ruby-3.2.0 -I. -DHAVE_BROTLI_DECODE_H -DHAVE_BROTLI_ENCODE_H -fPIC -O2 -pipe -march=native -fno-diagnostics-color -o brotli.o -c brotli.c In file included from /usr/include/ruby-3.2.0/ruby/ruby.h:27, from /usr/include/ruby-3.2.0/ruby.h:38, from brotli.h:4, from brotli.c:1: brotli.c: In function ‘Init_brotli’: /usr/include/ruby-3.2.0/ruby/internal/anyargs.h:363:45: error: passing argument 3 of ‘rb_define_singleton_method_m1’ from incompatible pointer type [-Wincompatible-pointer-types] 363 | # define RUBY_METHOD_FUNC(func) RBIMPL_CAST((VALUE (*)(ANYARGS))(func)) | ^ | | | VALUE (*)(void) {aka long unsigned int (*)(void)} /usr/include/ruby-3.2.0/ruby/internal/anyargs.h:308:144: note: in definition of macro ‘rb_define_singleton_method’ 308 | #define rb_define_singleton_method(obj, mid, func, arity) RBIMPL_ANYARGS_DISPATCH_rb_define_singleton_method((arity), (func))((obj), (mid), (func), (arity)) | ^~~~ /usr/include/ruby-3.2.0/ruby/internal/anyargs.h:363:33: note: in expansion of macro ‘RBIMPL_CAST’ 363 | # define RUBY_METHOD_FUNC(func) RBIMPL_CAST((VALUE (*)(ANYARGS))(func)) | ^~~~~~~~~~~ brotli.c:478:55: note: in expansion of macro ‘RUBY_METHOD_FUNC’ 478 | rb_define_singleton_method(rb_mBrotli, "deflate", RUBY_METHOD_FUNC(brotli_deflate), -1); | ^~~~~~~~~~~~~~~~ /usr/include/ruby-3.2.0/ruby/internal/anyargs.h:271:21: note: expected ‘VALUE (*)(int, union <anonymous>, VALUE)’ {aka ‘long unsigned int (*)(int, union <anonymous>, long unsigned int)’} but argument is of type ‘VALUE (*)(void)’ {aka ‘long unsigned int (*)(void)’} 271 | RBIMPL_ANYARGS_DECL(rb_define_singleton_method, VALUE, const char *) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/ruby-3.2.0/ruby/internal/anyargs.h:254:41: note: in definition of macro ‘RBIMPL_ANYARGS_DECL’ 254 | RBIMPL_ANYARGS_ATTRSET(sym) static void sym ## _m1(__VA_ARGS__, VALUE(*)(int, union { VALUE *x; const VALUE *y; } __attribute__((__transparent_union__)), VALUE), int); \ | ^~~ ``` The `ANYARGS` macro can't work in its current form, as defined at e.g. https://github.com/ruby/ruby/blob/f127bcb8294fd417c253dd7acab3ff3b9f0bf555/…: ``` #ifndef ANYARGS # ifdef __cplusplus # define ANYARGS ... # else # define ANYARGS # endif #endif ``` ... because of the change in C23 I mentioned above, i.e. `(ANYARGS)` being `()` now means no arguments, not any. I note that Ruby was adapted in part already for this change, see e.g. https://github.com/ruby/ruby/commit/4e64edb6cd8d1b444c591bfd50ec3d357e794f6e, but it appears that the headers that extensions need to build against aren't yet ready. -- https://bugs.ruby-lang.org/

4 6