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

[ruby-core:115389] [Ruby master Bug#20006] [Windows] failed to allocate memory (NoMemoryError) - test/ruby/test_ast.rb
by MSP-Greg (Greg L) 14 Nov '23

14 Nov '23

Issue #20006 has been reported by MSP-Greg (Greg L). ---------------------------------------- Bug #20006: [Windows] failed to allocate memory (NoMemoryError) - test/ruby/test_ast.rb https://bugs.ruby-lang.org/issues/20006 * Author: MSP-Greg (Greg L) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- On GitHub Actions, all ruby-loco windows builds are intermittently failing with logs similar to the below: ``` D:\a\ruby-loco\ruby-loco\ruby-mingw\bin\ruby.exe: failed to allocate memory (NoMemoryError) D:\a\ruby-loco\ruby-loco\ruby-mingw\bin\ruby.exe: failed to allocate memory (NoMemoryError) D:\a\ruby-loco\ruby-loco\ruby-mingw\bin\ruby.exe: failed to allocate memory (NoMemoryError) D:\a\ruby-loco\ruby-loco\ruby-mingw\bin\ruby.exe: failed to allocate memory (NoMemoryError) /ruby/tool/lib/test/unit/testcase.rb:173:in `rescue in run': failed to allocate memory (NoMemoryError) < removed /ruby/tool/lib/test/unit/ lines > running file: /ruby/test/ruby/test_ast.rb ``` Of course, I cannot reproduce locally. These errors have been happening for several days. I have not tried to force the test to run single, as it's running parallel currently. Thanks, Greg -- https://bugs.ruby-lang.org/

2 1

[ruby-core:115387] [Ruby master Bug#8444] Regexp vars $~ and friends are not thread local
by nobu (Nobuyoshi Nakada) 14 Nov '23

14 Nov '23

Issue #8444 has been updated by nobu (Nobuyoshi Nakada). Description updated "Thread-local" in that sentence was wrong, and removed at commit:932dd9f10e684fa99b059054fbc934607d85b45a, but "method-local" is removed too. ---------------------------------------- Bug #8444: Regexp vars $~ and friends are not thread local https://bugs.ruby-lang.org/issues/8444#change-105324 * Author: jamespharaoh (James Pharaoh) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: trunk ---------------------------------------- In the docs for the Regexp special variables, `$~` and friends, it says "These global variables are thread-local and method-local variables". However the following gives an unexpected result: ```ruby def get_proc proc do |str| str =~ /(.+)/ sleep 0.1 puts "got #{$1} from #{str}\n" end end proc = get_proc t1 = Thread.new { proc.call "abc" } t2 = Thread.new { proc.call "def" } t1.join t2.join ``` This outputs the following: ``` got abc from abc got abc from def ``` The expected result is of course: ``` got abc from abc got def from def ``` Clearly the variables are being scoped to the `get_proc` method and are being shared by both threads. This runs contrary to the documentation and also to expectations. This behaviour should either be changed, or the documentation updated to reflect the actual behaviour. Interestingly, the following does work as expected: ```ruby proc = proc do |str| str =~ /(.+)/ sleep 0.1 puts "got #{$1} from #{str}\n" end t1 = Thread.new { proc.call "abc" } t2 = Thread.new { proc.call "def" } t1.join t2.join ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115385] [Ruby master Bug#17037] rounding of Rational#to_f
by JesseJohnson (Jesse Johnson) 13 Nov '23

13 Nov '23

Issue #17037 has been updated by JesseJohnson (Jesse Johnson). Test case: ``` def test_rational_with_large_integer_components_to_f r = 450359962737049649/450359962737049600r assert_equal(1.0, r.to_f) end ``` The issue is that large integers, abs > 2 ** 53 - 1, are truncated when converting to double precision floating point and this affects which floating point value is closest after division. This can be fixed by using BigDecimal but I'm not sure that is an appropriate dependency for Rational. ---------------------------------------- Bug #17037: rounding of Rational#to_f https://bugs.ruby-lang.org/issues/17037#change-105321 * Author: akr (Akira Tanaka) * Status: Open * Priority: Normal * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- I found a doubtful rounding behavior of Rational#to_f. ``` % ./ruby -ve ' a = 1r e = Float::EPSILON.to_r puts "e=#{e}" n = 100 (0..n).each {|i| r = a + e * i / n f = r.to_f p [i, f, r] } ' ruby 2.8.0dev (2020-07-20T06:39:31Z master 935d0b3d05) [x86_64-linux] e=1/4503599627370496 [0, 1.0, (1/1)] [1, 1.0, (450359962737049601/450359962737049600)] [2, 1.0, (225179981368524801/225179981368524800)] [3, 1.0, (450359962737049603/450359962737049600)] [4, 1.0, (112589990684262401/112589990684262400)] [5, 1.0, (90071992547409921/90071992547409920)] [6, 1.0, (225179981368524803/225179981368524800)] [7, 1.0, (450359962737049607/450359962737049600)] [8, 1.0, (56294995342131201/56294995342131200)] [9, 1.0, (450359962737049609/450359962737049600)] [10, 1.0, (45035996273704961/45035996273704960)] [11, 1.0, (450359962737049611/450359962737049600)] [12, 1.0, (112589990684262403/112589990684262400)] [13, 1.0, (450359962737049613/450359962737049600)] [14, 1.0, (225179981368524807/225179981368524800)] [15, 1.0, (90071992547409923/90071992547409920)] [16, 1.0, (28147497671065601/28147497671065600)] [17, 1.0, (450359962737049617/450359962737049600)] [18, 1.0, (225179981368524809/225179981368524800)] [19, 1.0, (450359962737049619/450359962737049600)] [20, 1.0, (22517998136852481/22517998136852480)] [21, 1.0, (450359962737049621/450359962737049600)] [22, 1.0, (225179981368524811/225179981368524800)] [23, 1.0, (450359962737049623/450359962737049600)] [24, 1.0, (56294995342131203/56294995342131200)] [25, 1.0, (18014398509481985/18014398509481984)] [26, 1.0, (225179981368524813/225179981368524800)] [27, 1.0, (450359962737049627/450359962737049600)] [28, 1.0, (112589990684262407/112589990684262400)] [29, 1.0, (450359962737049629/450359962737049600)] [30, 1.0, (45035996273704963/45035996273704960)] [31, 1.0, (450359962737049631/450359962737049600)] [32, 1.0, (14073748835532801/14073748835532800)] [33, 1.0000000000000002, (450359962737049633/450359962737049600)] [34, 1.0000000000000002, (225179981368524817/225179981368524800)] [35, 1.0, (90071992547409927/90071992547409920)] [36, 1.0000000000000002, (112589990684262409/112589990684262400)] [37, 1.0000000000000002, (450359962737049637/450359962737049600)] [38, 1.0000000000000002, (225179981368524819/225179981368524800)] [39, 1.0000000000000002, (450359962737049639/450359962737049600)] [40, 1.0, (11258999068426241/11258999068426240)] [41, 1.0000000000000002, (450359962737049641/450359962737049600)] [42, 1.0000000000000002, (225179981368524821/225179981368524800)] [43, 1.0000000000000002, (450359962737049643/450359962737049600)] [44, 1.0000000000000002, (112589990684262411/112589990684262400)] [45, 1.0000000000000002, (90071992547409929/90071992547409920)] [46, 1.0000000000000002, (225179981368524823/225179981368524800)] [47, 1.0000000000000002, (450359962737049647/450359962737049600)] [48, 1.0000000000000002, (28147497671065603/28147497671065600)] [49, 1.0000000000000002, (450359962737049649/450359962737049600)] [50, 1.0, (9007199254740993/9007199254740992)] [51, 1.0000000000000002, (450359962737049651/450359962737049600)] [52, 1.0000000000000002, (112589990684262413/112589990684262400)] [53, 1.0000000000000002, (450359962737049653/450359962737049600)] [54, 1.0000000000000002, (225179981368524827/225179981368524800)] [55, 1.0000000000000002, (90071992547409931/90071992547409920)] [56, 1.0000000000000002, (56294995342131207/56294995342131200)] [57, 1.0000000000000002, (450359962737049657/450359962737049600)] [58, 1.0000000000000002, (225179981368524829/225179981368524800)] [59, 1.0000000000000002, (450359962737049659/450359962737049600)] [60, 1.0000000000000002, (22517998136852483/22517998136852480)] [61, 1.0000000000000002, (450359962737049661/450359962737049600)] [62, 1.0000000000000002, (225179981368524831/225179981368524800)] [63, 1.0000000000000002, (450359962737049663/450359962737049600)] [64, 1.0000000000000002, (7036874417766401/7036874417766400)] [65, 1.0000000000000002, (90071992547409933/90071992547409920)] [66, 1.0000000000000002, (225179981368524833/225179981368524800)] [67, 1.0000000000000002, (450359962737049667/450359962737049600)] [68, 1.0000000000000002, (112589990684262417/112589990684262400)] [69, 1.0000000000000002, (450359962737049669/450359962737049600)] [70, 1.0000000000000002, (45035996273704967/45035996273704960)] [71, 1.0000000000000002, (450359962737049671/450359962737049600)] [72, 1.0000000000000002, (56294995342131209/56294995342131200)] [73, 1.0000000000000002, (450359962737049673/450359962737049600)] [74, 1.0000000000000002, (225179981368524837/225179981368524800)] [75, 1.0000000000000002, (18014398509481987/18014398509481984)] [76, 1.0000000000000002, (112589990684262419/112589990684262400)] [77, 1.0000000000000002, (450359962737049677/450359962737049600)] [78, 1.0000000000000002, (225179981368524839/225179981368524800)] [79, 1.0000000000000002, (450359962737049679/450359962737049600)] [80, 1.0000000000000002, (5629499534213121/5629499534213120)] [81, 1.0000000000000002, (450359962737049681/450359962737049600)] [82, 1.0000000000000002, (225179981368524841/225179981368524800)] [83, 1.0000000000000002, (450359962737049683/450359962737049600)] [84, 1.0000000000000002, (112589990684262421/112589990684262400)] [85, 1.0000000000000002, (90071992547409937/90071992547409920)] [86, 1.0000000000000002, (225179981368524843/225179981368524800)] [87, 1.0000000000000002, (450359962737049687/450359962737049600)] [88, 1.0000000000000002, (56294995342131211/56294995342131200)] [89, 1.0000000000000002, (450359962737049689/450359962737049600)] [90, 1.0000000000000002, (45035996273704969/45035996273704960)] [91, 1.0000000000000002, (450359962737049691/450359962737049600)] [92, 1.0000000000000002, (112589990684262423/112589990684262400)] [93, 1.0000000000000002, (450359962737049693/450359962737049600)] [94, 1.0000000000000002, (225179981368524847/225179981368524800)] [95, 1.0000000000000002, (90071992547409939/90071992547409920)] [96, 1.0000000000000002, (14073748835532803/14073748835532800)] [97, 1.0000000000000002, (450359962737049697/450359962737049600)] [98, 1.0000000000000002, (225179981368524849/225179981368524800)] [99, 1.0000000000000002, (450359962737049699/450359962737049600)] [100, 1.0000000000000002, (4503599627370497/4503599627370496)] ``` This sample program tries to convert rationals between 1.0 and 1.0 + Float::EPSILON to float. Since there is no representable float values between them (except 1.0 and 1.0 + Float::EPSILON), I expect that r.to_f returns 1.0 for r < X and 1.0 + Float::EPSILON for r > X for some X. But my expectation is not valid: ``` [34, 1.0000000000000002, (225179981368524817/225179981368524800)] [35, 1.0, (90071992547409927/90071992547409920)] ``` I.e. `1 + Float::EPSILON.to_r * 34 / 100 < 1 + Float::EPSILON.to_r * 35 / 100` but `(1 + Float::EPSILON.to_r * 34 / 100).to_f > (1 + Float::EPSILON.to_r * 35 / 100).to_f` I guess Rational#to_f should round the rational value to a nearest representable float value. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115384] [Ruby master Bug#18966] Strange behavior when numbered parameters and method definition are both used in a block
by fcheung (Frederick Cheung) 13 Nov '23

13 Nov '23

Issue #18966 has been updated by fcheung (Frederick Cheung). Ruby 3.2.2 exhibits the same behaviour as above but on master ( as of b1f345b1 ) all of these now evaluate to 'a' ---------------------------------------- Bug #18966: Strange behavior when numbered parameters and method definition are both used in a block https://bugs.ruby-lang.org/issues/18966#change-105320 * Author: tompng (tomoya ishida) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0dev (2022-08-19T04:20:20Z :detached: 17d0e5bee7) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- ~~~ruby 'a'.tap { p _1; def f()=42 } #=> "a" 'a'.tap { p _1; def f(a)=42 } #=> nil 'a'.tap { def f()=42; p _1 } #=> "a" 'a'.tap { def f(a)=42; p _1 } # Syntax Error -:1: ordinary parameter is defined ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115383] [Ruby master Bug#18129] Ractor-incompatible global variables can be accessed through alias
by jemmai (Jemma Issroff) 13 Nov '23

13 Nov '23

Issue #18129 has been updated by jemmai (Jemma Issroff). Status changed from Open to Closed Closing, cannot reproduce this. @rm155 please feel free to reopen with reproduction instructions if the bug still exists. ---------------------------------------- Bug #18129: Ractor-incompatible global variables can be accessed through alias https://bugs.ruby-lang.org/issues/18129#change-105319 * Author: rm155 (Rohit Menon) * Status: Closed * Priority: Normal * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- Some global variables are not allowed in non-main Ractors. For example, the following code does not run: ``` ruby Ractor.new do $/ end.take #=> can not access global variables $/ from non-main Ractors (Ractor::IsolationError) ``` This error message is expected because $/ is not allowed outside the main Ractor. However, if the variable is aliased, it sometimes bypasses this. For example, the following code sometimes runs unexpectedly without error: ``` ruby alias $alias_global_variable $/ Ractor.new do $alias_global_variable end.take ``` Sometimes, it correctly fails with the message “can not access global variables $alias_global_variable from non-main Ractors (Ractor::IsolationError)”. However, because the global variable is sometimes accessed without error, this could lead to data races. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111074] [Ruby master Bug#19160] cmp_clamp arguments
by kaiquekandykoga 13 Nov '23

13 Nov '23

Issue #19160 has been reported by kaiquekandykoga (Kaíque Koga). ---------------------------------------- Bug #19160: cmp_clamp arguments https://bugs.ruby-lang.org/issues/19160 * Author: kaiquekandykoga (Kaíque Koga) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-freebsd13.1] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- If clamp receives min higher than max, it will raise an exception. The message says *min argument must be smaller than max argument* , but min can actually be equal to max too. Patch https://github.com/ruby/ruby/pull/6802. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:115381] [Ruby master Bug#18129] Ractor-incompatible global variables can be accessed through alias
by dazuma (Daniel Azuma) 13 Nov '23

13 Nov '23

Issue #18129 has been updated by dazuma (Daniel Azuma). I've tried a number of different variations on this, but never got it to reproduce (tried `ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-darwin22]` and `ruby 3.0.6p216 (2023-03-30 revision 23a532679b) [x86_64-darwin22]` since the original report did not specify the Ruby version/build). I suggest we close, unless the original reporter has additional information. ---------------------------------------- Bug #18129: Ractor-incompatible global variables can be accessed through alias https://bugs.ruby-lang.org/issues/18129#change-105317 * Author: rm155 (Rohit Menon) * Status: Open * Priority: Normal * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- Some global variables are not allowed in non-main Ractors. For example, the following code does not run: ``` ruby Ractor.new do $/ end.take #=> can not access global variables $/ from non-main Ractors (Ractor::IsolationError) ``` This error message is expected because $/ is not allowed outside the main Ractor. However, if the variable is aliased, it sometimes bypasses this. For example, the following code sometimes runs unexpectedly without error: ``` ruby alias $alias_global_variable $/ Ractor.new do $alias_global_variable end.take ``` Sometimes, it correctly fails with the message “can not access global variables $alias_global_variable from non-main Ractors (Ractor::IsolationError)”. However, because the global variable is sometimes accessed without error, this could lead to data races. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115380] [Ruby master Bug#18119] Ractor crashes when instantiating classes
by dazuma (Daniel Azuma) 13 Nov '23

13 Nov '23

Issue #18119 has been updated by dazuma (Daniel Azuma). Reproduces in 3.2.2 (MacOS 14 on x86_64). Again different error message: ``` ruby(17800,0x7000094bd000) malloc: Heap corruption detected, free list is damaged at 0x60000271cfe0 *** Incorrect guard value: 0 ``` ---------------------------------------- Bug #18119: Ractor crashes when instantiating classes https://bugs.ruby-lang.org/issues/18119#change-105316 * Author: peterzhu2118 (Peter Zhu) * Status: Assigned * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 3.1.0dev (2021-08-19T08:44:48Z master 6963f8f743) [x86_64-linux] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- The following script crashes with a segfault (tested on Ubuntu 20.04 and macOS 11.5.2): ```ruby workers = (0...8).map do Ractor.new do loop do 100.times.map { Class.new } Ractor.yield nil end end end 100.times { Ractor.select(*workers) } ``` Crash error: ``` <internal:ractor>:267: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. test.rb:4: [BUG] Segmentation fault at 0x0000000000000040 ruby 3.1.0dev (2021-08-19T08:44:48Z master 6963f8f743) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0010 p:---- s:0033 e:000032 CFUNC :new c:0009 p:0011 s:0029 e:000028 BLOCK test.rb:4 [FINISH] c:0008 p:---- s:0026 e:000025 IFUNC c:0007 p:---- s:0023 e:000022 CFUNC :times c:0006 p:---- s:0020 e:000019 CFUNC :each c:0005 p:---- s:0017 e:000016 CFUNC :map c:0004 p:0007 s:0013 e:000012 BLOCK test.rb:4 [FINISH] c:0003 p:---- s:0010 e:000009 CFUNC :loop c:0002 p:0004 s:0006 e:000005 BLOCK test.rb:3 [FINISH] c:0001 p:---- s:0003 e:000002 (none) [FINISH] -- Ruby level backtrace information ---------------------------------------- test.rb:3:in `block (2 levels) in <main>' test.rb:3:in `loop' test.rb:4:in `block (3 levels) in <main>' test.rb:4:in `map' test.rb:4:in `each' test.rb:4:in `times' test.rb:4:in `block (4 levels) in <main>' test.rb:4:in `new' -- Machine register context ------------------------------------------------ RIP: 0x0000562c1f9cd2cb RBP: 0x00007f6c3736d378 RSP: 0x00007f6c368285f0 RAX: 0x00007f6c1c00e208 RBX: 0x00007f6c3736d378 RCX: 0x0000562c20ed8330 RDX: 0x0000000000000000 RDI: 0x00007f6c100095c0 RSI: 0x0000000000000000 R8: 0x0000000000000007 R9: 0x0000562c20ed8120 R10: 0x0000000000000022 R11: 0x0000562c21180760 R12: 0x0000000000000000 R13: 0x00007f6c3736c000 R14: 0x0000000000000000 R15: 0x00007f6c3736d378 EFL: 0x0000000000010202 -- C level backtrace information ------------------------------------------- /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_print_backtrace+0x11) [0x562c1f995e38] ../vm_dump.c:759 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_vm_bugreport) ../vm_dump.c:1041 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_bug_for_fatal_signal+0xec) [0x562c1f78a0bc] ../error.c:815 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(sigsegv+0x4d) [0x562c1f8ebcbd] ../signal.c:961 /lib/x86_64-linux-gnu/libpthread.so.0(__restore_rt+0x0) [0x7f6c3b2c63c0] /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_class_remove_from_super_subclasses+0x2b) [0x562c1f9cd2cb] ../class.c:99 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(obj_free+0x37a) [0x562c1f7ae95a] ../gc.c:3123 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(gc_plane_sweep+0x21) [0x562c1f7aef3d] ../gc.c:5322 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(gc_page_sweep) ../gc.c:5464 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(gc_sweep_step) ../gc.c:5630 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(gc_heap_prepare_minimum_pages+0x0) [0x562c1f7afd94] ../gc.c:5834 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(gc_sweep) ../gc.c:5837 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(gc_marks+0x1c0) [0x562c1f7b3df8] ../gc.c:8144 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(gc_start) ../gc.c:9013 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(heap_prepare+0x2f) [0x562c1f7b8b6f] ../gc.c:2131 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(heap_next_freepage) ../gc.c:2422 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(ractor_cache_slots) ../gc.c:2454 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(newobj_slowpath) ../gc.c:2495 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(newobj_slowpath_wb_protected) ../gc.c:2519 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(newobj_of0+0x5) [0x562c1f7b8ebd] ../gc.c:2562 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(newobj_of) ../gc.c:2572 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_wb_protected_newobj_of) ../gc.c:2596 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(class_alloc+0x5) [0x562c1f9cd49e] ../class.c:185 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_class_boot) ../class.c:230 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(class_call_alloc_func+0x5) [0x562c1f84e5d3] ../object.c:2075 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_class_alloc) ../object.c:2047 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_class_new_instance_pass_kw) ../object.c:2120 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_cfp_consistent_p+0x0) [0x562c1f96d6bc] ../vm_insnhelper.c:2989 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_call_cfunc_with_frame) ../vm_insnhelper.c:2991 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_sendish+0x303) [0x562c1f978393] ../vm_insnhelper.c:4562 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_exec_core+0xcd) [0x562c1f98316d] ../insns.def:775 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_vm_exec+0x197) [0x562c1f978fc7] ../vm.c:2164 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(collect_i+0x12) [0x562c1fa27bf2] ../enum.c:608 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_vm_pop_frame+0x0) [0x562c1f976ba8] ../vm_insnhelper.c:3795 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_yield_with_cfunc) ../vm_insnhelper.c:3796 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(invoke_block_from_c_bh+0x10) [0x562c1f97d0d3] ../vm.c:1359 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_yield) ../vm.c:1399 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_yield_0) ../vm_eval.c:1350 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_yield_1) ../vm_eval.c:1356 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(int_dotimes+0x5c) [0x562c1f83a49c] ../numeric.c:5014 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_cfp_consistent_p+0x0) [0x562c1f97dd4f] ../vm_eval.c:135 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_call0_cfunc_with_frame) ../vm_eval.c:137 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_call0_cfunc) ../vm_eval.c:149 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_call0_body) ../vm_eval.c:182 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_call0+0x1ea) [0x562c1f9812fa] ../vm_eval.c:72 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(iterate_method+0x3b) [0x562c1f981e9b] ../vm_eval.c:847 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_iterate0+0x101) [0x562c1f973001] ../vm_eval.c:1534 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_block_call_kw+0x76) [0x562c1f9731f6] ../vm_eval.c:1566 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(enumerator_block_call+0x59) [0x562c1fa358e9] ../enumerator.c:553 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_cfp_consistent_p+0x0) [0x562c1f97dd4f] ../vm_eval.c:135 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_call0_cfunc_with_frame) ../vm_eval.c:137 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_call0_cfunc) ../vm_eval.c:149 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_call0_body) ../vm_eval.c:182 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_call0+0x1ea) [0x562c1f9812fa] ../vm_eval.c:72 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(iterate_method+0x3b) [0x562c1f981e9b] ../vm_eval.c:847 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_iterate0+0x101) [0x562c1f973001] ../vm_eval.c:1534 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_lambda_call+0x75) [0x562c1f973295] ../vm_eval.c:1633 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(enum_collect+0x5b) [0x562c1fa29acb] ../enum.c:647 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_cfp_consistent_p+0x0) [0x562c1f96d6bc] ../vm_insnhelper.c:2989 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_call_cfunc_with_frame) ../vm_insnhelper.c:2991 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_sendish+0x303) [0x562c1f978393] ../vm_insnhelper.c:4562 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_exec_core+0x130) [0x562c1f9831d0] ../insns.def:756 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_vm_exec+0x197) [0x562c1f978fc7] ../vm.c:2164 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(invoke_block_from_c_bh+0x130) [0x562c1f97c85a] ../vm.c:1264 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_yield) ../vm.c:1399 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_yield_0) ../vm_eval.c:1350 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(loop_i) ../vm_eval.c:1449 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_vrescue2+0x114) [0x562c1f794694] ../eval.c:1023 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_rescue2+0x8e) [0x562c1f79490e] ../eval.c:1000 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_cfp_consistent_p+0x0) [0x562c1f96d6bc] ../vm_insnhelper.c:2989 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_call_cfunc_with_frame) ../vm_insnhelper.c:2991 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_sendish+0x303) [0x562c1f978393] ../vm_insnhelper.c:4562 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_exec_core+0x130) [0x562c1f9831d0] ../insns.def:756 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_vm_exec+0x197) [0x562c1f978fc7] ../vm.c:2164 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(thread_do_start_proc+0x294) [0x562c1f930f24] ../thread.c:716 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(thread_do_start+0xc) [0x562c1f9336fc] ../thread.c:760 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(thread_start_func_2) ../thread.c:835 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_native_cond_initialize+0x0) [0x562c1f933a09] ../thread_pthread.c:1051 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(register_cached_thread_and_wait) ../thread_pthread.c:1103 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(thread_start_func_1) ../thread_pthread.c:1058 /lib/x86_64-linux-gnu/libpthread.so.0(0x9609) [0x7f6c3b2ba609] /lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7f6c3b044293] ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115379] [Ruby master Bug#17624] Ractor.receive is not thread-safe
by dazuma (Daniel Azuma) 13 Nov '23

13 Nov '23

Issue #17624 has been updated by dazuma (Daniel Azuma). ruby -v changed from ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20] to ruby 3.3.0dev (2023-11-13T21:00:10Z master e8ab3f7010) [x86_64-darwin23] Retested, still reproduces on 3.2.2 and 3.3.0-dev as of 2023 Nov 13. ---------------------------------------- Bug #17624: Ractor.receive is not thread-safe https://bugs.ruby-lang.org/issues/17624#change-105314 * Author: dazuma (Daniel Azuma) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 3.3.0dev (2023-11-13T21:00:10Z master e8ab3f7010) [x86_64-darwin23] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- It does not seem to be possible to have multiple blocked `Ractor.receive` calls concurrently in the same Ractor (but different threads). One may succeed but the others will hang indefinitely, even if messages are present in the queue. Example code below. It does the following: 1. Starts a Ractor `r1` that spawns two "listener threads". Each thread calls `Ractor.receive`, which blocks waiting for messages. 2. The main Ractor pauses briefly to ensure that the threads have started, and then sends two messages to the Ractor `r1`, with the expectation that each thread will receive one of them. 3. What actually happens is, the `Ractor.receive` call in *one* of the threads will pick a message and return. However, the `Ractor.receive` call in the other thread remains blocked, even though the second message is in the queue. 4. Ractor `r1`, after a pause to ensure that both messages have been sent, issues another `Ractor.receive` call. This call does not block (because the second message is in the queue), and successfully returns the message. Meanwhile, the second thread's `Ractor.receive` call remains blocked. This demonstrates that the second message has been sent successfully and is receivable, even though the second thread still hasn't returned it. It appears that the second thread's receive call is in a bad state. ``` r1 = Ractor.new do # Start two listener threads t1 = Thread.new do puts "T1 received #{Ractor.receive}" end t2 = Thread.new do puts "T2 received #{Ractor.receive}" end # Pause to ensure that both messages have been sent. # (One of the messages will have been picked up by a # thread, but the other remains in the queue.) sleep(3) # Receive the second message. This will succeed, even # though the second thread is still blocked. puts "Later received #{Ractor.receive}" # Wait for the threads to finish. # This will never complete because one of the threads will not # receive the second message, and is still blocking. [t1, t2].each(&:join) :ok end # Make sure both receive calls are blocking sleep(1) # Send two messages. r1.send(1) r1.send(2) # This never returns because the ractor never completes. puts r1.take ``` This happens both in 3.0.0 release and on 3.1.0 head. ``` % ruby -v ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20] ``` ``` % ruby -v ruby 3.1.0dev (2021-02-09T13:22:37Z master e7a831de8e) [x86_64-darwin20] ``` Notes: * This also happens when using `receive_if`. * I would expect this use case to be common when writing a Ractor that contains multiple thread-safe "workers". (This was in fact the use case I was trying to implement when I encountered this issue.) Thus, if we decide this is working as intended, we should document it, and possibly suggest to users that they write their Ractor to funnel communication through a single dedicated thread. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115378] [Ruby master Bug#17617] When a Ractor's incoming port is closed, Ractor.receive_if does not raise Ractor::ClosedError, but instead blocks indefinitely
by dazuma (Daniel Azuma) 13 Nov '23

13 Nov '23

Issue #17617 has been updated by dazuma (Daniel Azuma). ruby -v changed from ruby 3.1.0dev (2021-02-09T13:22:37Z master e7a831de8e) [x86_64-darwin20] to ruby 3.3.0dev (2023-11-13T21:00:10Z master e8ab3f7010) [x86_64-darwin23] Retested, still reproduces on 3.2.2 and 3.3.0-dev as of 2023 Nov 13. ---------------------------------------- Bug #17617: When a Ractor's incoming port is closed, Ractor.receive_if does not raise Ractor::ClosedError, but instead blocks indefinitely https://bugs.ruby-lang.org/issues/17617#change-105313 * Author: dazuma (Daniel Azuma) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 3.3.0dev (2023-11-13T21:00:10Z master e8ab3f7010) [x86_64-darwin23] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- If Ractor#close_incoming is called on a Ractor, any pending Ractor.receive call will raise Ractor::ClosedError. However, any pending Ractor.receive_if call will not; instead, it never returns. ``` r1 = Ractor.new do Ractor.receive rescue => e e end r1.close_incoming result = r1.take puts "**** taken: #{result}" # displays the Ractor::ClosedError r2 = Ractor.new do Ractor.receive_if { true } puts "**** never reaches here" rescue => e puts "**** never reaches here" e end r2.close_incoming puts "**** hangs here..." r2.take puts "**** never reaches here" ``` This was tested against both 3.0.0 and 3.1.0 head, with the same result. ``` % ruby -v ruby 3.1.0dev (2021-02-09T13:22:37Z master e7a831de8e) [x86_64-darwin20] ``` ``` % ruby -v ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20 ``` I have also tried including sleep statements to force the Ractor.receive_if to execute both before and after the Ractor#close_incoming call. The result is the same either way. receive_if hangs regardless of whether the incoming port is already closed when receive_if is invoked, or whether the port is closed while the receive_if is already blocking. -- https://bugs.ruby-lang.org/

1 0