- ruby-core - ml.ruby-lang.org

[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

[ruby-core:115377] [Ruby master Bug#11142] Command line argument parser on windows handles double quotes inconsistently.
by pcai (Peter Cai) 13 Nov '23

13 Nov '23

Issue #11142 has been updated by pcai (Peter Cai). Is there a reason the windows parsing doesn't match the linux behavior?: ``` vscode ➜ /workspaces/ruby (master) $ ruby -e "puts ARGV" "foo""bar" foobar vscode ➜ /workspaces/ruby (master) $ ruby -e "puts ARGV" "foo"" bar" foo bar ``` And if so, can someone clarify if "treat two double quotes as a literal double quote" is correct? I think the referenced code block reads as: ``` case '\"': if (!quote) quote = *ptr; else if (quote == *ptr) quote = '\0'; ptr++; break; ``` Note that `quote` is initially '\0' and therefore it seems that upon encountering a second double quote, `if (quote == *ptr)` will always be true, so it seems gratuitous? ---------------------------------------- Bug #11142: Command line argument parser on windows handles double quotes inconsistently. https://bugs.ruby-lang.org/issues/11142#change-105312 * Author: ksubrama (Kartik Cating-Subramanian) * Status: Open * Priority: Normal * Assignee: usa (Usaku NAKAMURA) * ruby -v: ruby 2.1.5p273 (2014-11-13 revision 48405) [x64-mingw32] * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN ---------------------------------------- I believe the issue is with https://github.com/ruby/ruby/blob/trunk/win32/win32.c#L1671 through 1673. C:\Users\ksubrama>ruby -e "puts ARGV" "foo""bar" foo"bar C:\Users\ksubrama>ruby -e "puts ARGV" "foo"" bar" foo" bar I believe the intent is that if ruby encounters "" inside a " quoted string, then it interprets it as a literal " and doesn't close out the string. If that's the case, then the code should read: if (quote == L'"' && quote == ptr[1]) ptr++; else quote = L'\0'; Otherwise, the string gets closed out anyway and the ptr++ here combined with the ptr++ at the bottom of the switch at line 1685 simply skip over both "" characters while considering the string closed. As a further test case consider: C:\Users\ksubrama>ruby -e "puts ARGV" "foo""bar""baz" foo"barbaz The parser is now very confused because the first "" closed out the string and the next "" is not interpreted as a literal " but as "open and close and empty string element" and the trailing " just gets dropped. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115376] [Ruby master Bug#9189] Build failure on Windows in case of nonascii TEMP environment.
by pcai (Peter Cai) 13 Nov '23

13 Nov '23

Issue #9189 has been updated by pcai (Peter Cai). I'm unable to reproduce. Windows presents an ascii-safe alias of the TEMP folder for me so I can't seem to test the handling: * windows 11 (Version 10.0.22621 Build 22621) * Ruby+Devkit 3.2.2-1 (x64) ``` C:\work>ruby -e "system('set TEMP')" TEMP=C:\Users\6863~1\tmp C:\work>set TEMP TEMP=C:\Users\6863~1\tmp C:\work>cd C:\Users\희섭\tmp C:\Users\희섭\tmp>echo %cd% C:\Users\희섭\tmp C:\Users\희섭\tmp>ruby -v ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x64-mingw-ucrt] ``` ---------------------------------------- Bug #9189: Build failure on Windows in case of nonascii TEMP environment. https://bugs.ruby-lang.org/issues/9189#change-105311 * Author: phasis68 (Heesob Park) * Status: Assigned * Priority: Normal * ruby -v: ruby 2.1.0dev (2013-11-30 trunk 43936) [i386-mingw32] * Backport: 1.9.3: DONTNEED, 2.0.0: REQUIRED ---------------------------------------- I experienced a build failure during build extension library with trunk on Windows. make[2]: Entering directory `/c/work/ruby-2.1.0-r43936/ext/bigdecimal' generating bigdecimal-i386-mingw32.def compiling bigdecimal.c In file included from bigdecimal.c:20:0: bigdecimal.h:62:1: error: static declaration of 'labs' follows non-static declar ation make[2]: *** [bigdecimal.o] Error 1 make[2]: Leaving directory `/c/work/ruby-2.1.0-r43936/ext/bigdecimal' make[1]: *** [ext/bigdecimal/all] Error 2 make[1]: Leaving directory `/c/work/ruby-2.1.0-r43936' make: *** [build-ext] Error 2 I found the cause of this error is mkmk failure. Here is a part of mkmf.log have_func: checking for labs() in stdlib.h... -------------------- no "i686-w64-mingw32-gcc -o conftest.exe -I../../.ext/include/i386-mingw32 -I../.././include -I../.././ext/bigdecimal -D_WIN32_WINNT=0x0501 -D_FILE_OFFSET_BITS=64 -O3 -fno-omit-frame-pointer -fno-fast-math -ggdb3 -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wno-long-long -Wno-missing-field-initializers -Wunused-variable -Wpointer-arith -Wwrite-strings -Wdeclaration-after-statement -Wimplicit-function-declaration conftest.c -L. -L../.. -L. -lmsvcrt-ruby210-static -lshell32 -lws2_32 -liphlpapi -limagehlp -lshlwapi " This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Cannot create temporary file in C:\Users\??苑?AppData\Local\Temp\: Invalid argument The TEMP environment varable is C:\work\ruby-2.1.0-r43936>set TEMP TEMP=C:\Users\희섭\AppData\Local\Temp It seems that miniruby cannot handle encoding properly. C:\work\ruby-2.1.0-r43936>miniruby -ve "p ENV['TEMP']" ruby 2.1.0dev (2013-11-30 trunk 43936) [i386-mingw32] "C:\\Users\\\xED\x9D\xAC\xEC\x84\xAD\\AppData\\Local\\Temp" C:\work\ruby-2.1.0-r43936>miniruby.exe -ve "p ENV['TEMP'].encoding" ruby 2.1.0dev (2013-11-30 trunk 43936) [i386-mingw32] #<Encoding:ASCII-8BIT> Whereas, the final ruby can handle encoding properly. C:\work>ruby -ve "p ENV['TEMP']" ruby 2.1.0dev (2013-11-30 trunk 43923) [i386-mingw32] "C:\\Users\\희섭\\AppData\\Local\\Temp" C:\work>ruby -ve "p ENV['TEMP'].encoding" ruby 2.1.0dev (2013-11-30 trunk 43923) [i386-mingw32] #<Encoding:CP949> -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115375] [Ruby master Bug#17400] Incorrect character downcase for Greek Sigma
by katiecaballero2023 (Katie Caballero) 13 Nov '23

13 Nov '23

Issue #17400 has been updated by katiecaballero2023 (Katie Caballero). RubyConf Hack Day: Bug still exists in 3.2.2 ---------------------------------------- Bug #17400: Incorrect character downcase for Greek Sigma https://bugs.ruby-lang.org/issues/17400#change-105308 * Author: xfalcox (Rafael Silva) * Status: Open * Priority: Normal * Assignee: duerst (Martin Dürst) * ruby -v: ruby 3.0.0dev (2020-12-16T18:46:44Z master 93ba3ac036) [x86_64-linux] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- An issue caused by this bug was first reported at Discourse support community at https://meta.discourse.org/t/unicode-username-results-in-error-loading-prof…. The issue is that in Greek, there are two ways to downcase the letter ‘Σ’ - ‘ς’ when it is used at the end of a word - ‘σ’ anywhere else NodeJS follows this rule: ``` ➜ node Welcome to Node.js v12.11.1. Type ".help" for more information. > "ΣΠΥΡΟΣ".toLowerCase() 'σπυρος' ``` Python too: ``` ➜ python Python 3.8.2 (default, Nov 23 2020, 16:33:30) [GCC 10.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> "ΣΠΥΡΟΣ".lower() 'σπυρος' ``` Ruby (both 2.7 and 3) doesn't: ``` ➜ ruby --version ruby 3.0.0dev (2020-12-16T18:46:44Z master 93ba3ac036) [x86_64-linux] ➜ irb irb(main):001:0> "ΣΠΥΡΟΣ".downcase => "σπυροσ" ``` ``` ➜ ruby --version ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux] ➜ irb irb(main):001:0> "ΣΠΥΡΟΣ".downcase => "σπυροσ" ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115374] [Ruby master Bug#16145] regexp match error if mixing /i, character classes, and utf8
by sancheta867 (Steven Ancheta) 13 Nov '23

13 Nov '23

Issue #16145 has been updated by sancheta867 (Steven Ancheta). Confirmed that it's still happening on ruby -v ruby 3.2.2 (2023-03-30 revision e51014f9c0) [arm64-darwin23] irb(main):001:0> 'CAFÉ' =~ /[xé]/i => nil irb(main):002:0> "CAFÉ" =~ /x|é/i => 3 ---------------------------------------- Bug #16145: regexp match error if mixing /i, character classes, and utf8 https://bugs.ruby-lang.org/issues/16145#change-105306 * Author: zenspider (Ryan Davis) * Status: Open * Priority: Normal * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- (reported on behalf of mage(a)mage.gold -- there appears to be an error in registration or login): See: ruby-talk @ X-Mail-Count: 440336 2.6.3 :049 > 'SHOP' =~ /[xo]/i => 2 2.6.3 :050 > 'CAFÉ' =~ /[é]/i => 3 2.6.3 :051 > 'CAFÉ' =~ /[xé]/i => nil 2.6.3 :052 > 'CAFÉ' =~ /[xÉ]/i => 3 Expected result: 2.6.3 :051 > 'CAFÉ' =~ /[xé]/i => 3 I tested it on random regex online pages. It does not match on https://regex101.com/ It matches on: https://regexr.com/ https://www.regextester.com/ https://www.freeformatter.com/regex-tester.html (Ignore case turned on). The reason I suppose it’s more like a bug than a feature is the fact that /[é]/i matches 'CAFÉ'. If the //i didn’t work for UTF-8 characters then the /[é]/i wouldn’t match it either. For example, [é] does not match 'CAFÉ' on https://regex101.com/ I could not find a page or a system that behaves the same way as Ruby does. For example, it matches in PostgreSQL 10 (under FreeBSD 12) too: # select 'CAFÉ'~ '[xé]'; ?column? ---------- f (1 row) # select 'CAFÉ' ~* '[xé]'; ?column? ---------- t (1 row) Tested it in IRB on macOS and FreeBSD. $ uname -a && ruby -v && locale Darwin xxx 18.7.0 Darwin Kernel Version 18.7.0: Thu Jun 20 18:42:21 PDT 2019; root:xnu-4903.270.47~4/RELEASE_X86_64 x86_64 ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-darwin18] LANG="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_CTYPE="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_ALL="en_US.UTF-8" $ uname -a && ruby -v && locale FreeBSD xxx 12.0-RELEASE-p9 FreeBSD 12.0-RELEASE-p9 GENERIC amd64 ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-freebsd12.0] LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_ALL=en_US.UTF-8 I installed Ruby with RVM. -- https://bugs.ruby-lang.org/

1 0