September 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:122798] [Ruby Bug#21516] Segfault in String#succ! on 32-bit i686
by leahneukirchen (Leah Neukirchen) 26 Nov '25

26 Nov '25

Issue #21516 has been reported by leahneukirchen (Leah Neukirchen). ---------------------------------------- Bug #21516: Segfault in String#succ! on 32-bit i686 https://bugs.ruby-lang.org/issues/21516 * Author: leahneukirchen (Leah Neukirchen) * Status: Open * ruby -v: 3.4.5 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I noticed segfaults in the test suite of Ruby 3.4.5, related to String#succ! A very easy reproducer is: ./miniruby -e 'puts "ZZZZ999".succ!' $ ./miniruby -e 'puts "ZZZZ999".succ!' -e:1: [BUG] Segmentation fault at 0x9e968041 ruby 3.4.5 (2025-07-16 revision 20cda200d3) +PRISM [x86_64-linux-x32] -- Control frame information ----------------------------------------------- c:0003 p:---- s:0011 e:000010 CFUNC :succ! c:0002 p:0005 s:0007 e:000005 EVAL -e:1 [FINISH] c:0001 p:0000 s:0003 E:0017b8 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- -e:1:in '<main>' -e:1:in 'succ!' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ GS: 0x00000063 FS: 0x00000000 ES: 0x0000002b DS: 0x0000002b EDI: 0x9e968049 ESI: 0x9e968041 EBP: 0x5896c1a0 ESP: 0xff97d638 EBX: 0x9e968046 EDX: 0x9e968049 ECX: 0x5896c1a0 EAX: 0x9e968041 TRA: 0x0000000e ERR: 0x00000004 EIP: 0x5681ea07 CS: 0x00000023 EFL: 0x00010293 UES: 0xff97d638 SS: 0x0000002b -- C level backtrace information ------------------------------------------- /builddir/ruby/ruby/miniruby(rb_print_backtrace+0x14) [0x568ae631] /builddir/ruby/ruby/vm_dump.c:823 /builddir/ruby/ruby/miniruby(rb_vm_bugreport) /builddir/ruby/ruby/vm_dump.c:1155 /builddir/ruby/ruby/miniruby(rb_bug_for_fatal_signal+0x86) [0x566e4ee6] /builddir/ruby/ruby/error.c:1130 /builddir/ruby/ruby/miniruby(sigsegv+0x4f) [0x5680e98f] /builddir/ruby/ruby/signal.c:934 linux-gate.so.1(__kernel_rt_sigreturn+0x0) [0xf7f475a0] /builddir/ruby/ruby/miniruby(search_nonascii+0x17) [0x5681ea07] /builddir/ruby/ruby/string.c:728 /builddir/ruby/ruby/miniruby(coderange_scan+0x59) [0x56821d09] /builddir/ruby/ruby/string.c:767 /builddir/ruby/ruby/miniruby(rbimpl_fl_unset_raw_raw+0x0) [0x56824715] /builddir/ruby/ruby/string.c:895 /builddir/ruby/ruby/miniruby(RB_FL_UNSET_RAW) ./include/ruby/internal/fl_type.h:669 /builddir/ruby/ruby/miniruby(RB_ENC_CODERANGE_SET) ./include/ruby/internal/encoding/coderange.h:131 /builddir/ruby/ruby/miniruby(rb_enc_str_coderange) /builddir/ruby/ruby/string.c:911 /builddir/ruby/ruby/miniruby(str_succ+0x69c) [0x5682545c] /builddir/ruby/ruby/string.c:5364 /builddir/ruby/ruby/miniruby(rb_str_succ_bang+0x15) [0x56829f85] /builddir/ruby/ruby/string.c:5380 /builddir/ruby/ruby/miniruby(vm_call_cfunc_with_frame_+0x106) [0x568860e6] /builddir/ruby/ruby/vm_insnhelper.c:3794 /builddir/ruby/ruby/miniruby(vm_call_method_each_type+0x76) [0x56894636] /builddir/ruby/ruby/vm_insnhelper.c:4772 /builddir/ruby/ruby/miniruby(vm_sendish+0xa2) [0x5689fecb] /builddir/ruby/ruby/vm_insnhelper.c:5961 /builddir/ruby/ruby/miniruby(vm_exec_core) /builddir/ruby/ruby/insns.def:898 /builddir/ruby/ruby/miniruby(vm_exec_loop+0x38) [0x56893d68] /builddir/ruby/ruby/vm.c:2622 /builddir/ruby/ruby/miniruby(rb_vm_exec) /builddir/ruby/ruby/vm.c:2598 /builddir/ruby/ruby/miniruby(rb_ec_exec_node+0x7f) [0x566eb0ef] /builddir/ruby/ruby/eval.c:281 /builddir/ruby/ruby/miniruby(ruby_run_node+0x58) [0x566ee558] /builddir/ruby/ruby/eval.c:319 /builddir/ruby/ruby/miniruby(main+0x70) [0x56648460] ./main.c:43 -- Other runtime information ----------------------------------------------- * Loaded script: -e * Loaded features: 0 enumerator.so 1 thread.rb 2 fiber.so 3 rational.so 4 complex.so 5 ruby2_keywords.rb * Process memory map: 56622000-56642000 r--p 00000000 fe:02 9210459 /builddir/ruby/ruby/miniruby 56642000-56941000 r-xp 00020000 fe:02 9210459 /builddir/ruby/ruby/miniruby 56941000-56b4c000 r--p 0031f000 fe:02 9210459 /builddir/ruby/ruby/miniruby 56b4c000-56b54000 r--p 0052a000 fe:02 9210459 /builddir/ruby/ruby/miniruby 56b54000-56b55000 rw-p 00532000 fe:02 9210459 /builddir/ruby/ruby/miniruby 56b55000-56b5e000 rw-p 00000000 00:00 0 58967000-58abb000 rw-p 00000000 00:00 0 [heap] f43b8000-f5a48000 r--s 00000000 fe:02 9210459 /builddir/ruby/ruby/miniruby f5a48000-f5a4b000 r--p 00000000 fe:02 11307369 /usr/lib/libgcc_s.so.1 f5a4b000-f5a79000 r-xp 00003000 fe:02 11307369 /usr/lib/libgcc_s.so.1 f5a79000-f5a7e000 r--p 00031000 fe:02 11307369 /usr/lib/libgcc_s.so.1 f5a7e000-f5a7f000 r--p 00035000 fe:02 11307369 /usr/lib/libgcc_s.so.1 f5a7f000-f5a80000 rw-p 00036000 fe:02 11307369 /usr/lib/libgcc_s.so.1 f5a80000-f5ab0000 rw-p 00000000 00:00 0 [anon:Ruby:GC:default:heap_page_body_allocate] f5abf000-f5ac0000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5ac0000-f5b11000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5b11000-f5b12000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5b12000-f5b63000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5b63000-f5b64000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5b64000-f5bb5000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5bb5000-f5bb6000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5bb6000-f5c07000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5c07000-f5c08000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5c08000-f5c59000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5c59000-f5c5a000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5c5a000-f5cab000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5cab000-f5cac000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5cac000-f5cfd000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5cfd000-f5cfe000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5cfe000-f5d4f000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] f5d4f000-f5d50000 ---p 00000000 00:00 0 f5d50000-f6550000 rw-p 00000000 00:00 0 f6550000-f6590000 rw-p 00000000 00:00 0 [anon:Ruby:GC:default:heap_page_body_allocate] f659f000-f759f000 rw-p 00000000 00:00 0 [anon:Ruby:Init_default_shapes:shape_cache] f759f000-f765f000 rw-p 00000000 00:00 0 [anon:Ruby:Init_default_shapes:shape_list] f765f000-f7690000 rw-p 00000000 00:00 0 f7690000-f76a0000 rw-p 00000000 00:00 0 [anon:Ruby:GC:default:heap_page_body_allocate] f76a9000-f772a000 rw-p 00000000 00:00 0 f772a000-f79a4000 r--p 00074000 fe:02 11307480 /usr/lib/locale/locale-archive f79a4000-f7ba4000 r--p 00000000 fe:02 11307480 /usr/lib/locale/locale-archive f7ba4000-f7ba6000 rw-p 00000000 00:00 0 f7ba6000-f7bc9000 r--p 00000000 fe:02 11307064 /usr/lib/libc.so.6 f7bc9000-f7d69000 r-xp 00023000 fe:02 11307064 /usr/lib/libc.so.6 f7d69000-f7dc5000 r--p 001c3000 fe:02 11307064 /usr/lib/libc.so.6 f7dc5000-f7dc7000 r--p 0021f000 fe:02 11307064 /usr/lib/libc.so.6 f7dc7000-f7dc8000 rw-p 00221000 fe:02 11307064 /usr/lib/libc.so.6 f7dc8000-f7dd2000 rw-p 00000000 00:00 0 f7dd2000-f7de0000 r--p 00000000 fe:02 11307059 /usr/lib/libm.so.6 f7de0000-f7ead000 r-xp 0000e000 fe:02 11307059 /usr/lib/libm.so.6 f7ead000-f7edf000 r--p 000db000 fe:02 11307059 /usr/lib/libm.so.6 f7edf000-f7ee0000 r--p 0010c000 fe:02 11307059 /usr/lib/libm.so.6 f7ee0000-f7ee1000 rw-p 0010d000 fe:02 11307059 /usr/lib/libm.so.6 f7ee1000-f7ee2000 r--p 00000000 fe:02 11307767 /usr/lib/libcrypt.so.2.0.0 f7ee2000-f7efe000 r-xp 00001000 fe:02 11307767 /usr/lib/libcrypt.so.2.0.0 f7efe000-f7f18000 r--p 0001d000 fe:02 11307767 /usr/lib/libcrypt.so.2.0.0 f7f18000-f7f19000 r--p 00036000 fe:02 11307767 /usr/lib/libcrypt.so.2.0.0 f7f19000-f7f1a000 rw-p 00037000 fe:02 11307767 /usr/lib/libcrypt.so.2.0.0 f7f1a000-f7f22000 rw-p 00000000 00:00 0 f7f22000-f7f24000 r--p 00000000 fe:02 11307365 /usr/lib/libz.so.1.3.1 f7f24000-f7f34000 r-xp 00002000 fe:02 11307365 /usr/lib/libz.so.1.3.1 f7f34000-f7f3a000 r--p 00012000 fe:02 11307365 /usr/lib/libz.so.1.3.1 f7f3a000-f7f3b000 r--p 00017000 fe:02 11307365 /usr/lib/libz.so.1.3.1 f7f3b000-f7f3c000 rw-p 00018000 fe:02 11307365 /usr/lib/libz.so.1.3.1 f7f41000-f7f43000 rw-p 00000000 00:00 0 f7f43000-f7f45000 r--p 00000000 00:00 0 [vvar] f7f45000-f7f47000 r--p 00000000 00:00 0 [vvar_vclock] f7f47000-f7f49000 r-xp 00000000 00:00 0 [vdso] f7f49000-f7f4a000 r--p 00000000 fe:02 11307070 /usr/lib/ld-linux.so.2 f7f4a000-f7f72000 r-xp 00001000 fe:02 11307070 /usr/lib/ld-linux.so.2 f7f72000-f7f7d000 r--p 00029000 fe:02 11307070 /usr/lib/ld-linux.so.2 f7f7d000-f7f7f000 r--p 00034000 fe:02 11307070 /usr/lib/ld-linux.so.2 f7f7f000-f7f80000 rw-p 00036000 fe:02 11307070 /usr/lib/ld-linux.so.2 ff95d000-ff97e000 rw-p 00000000 00:00 0 [stack] Segmentation fault Backtrace in gdb: Thread 1 "miniruby" received signal SIGSEGV, Segmentation fault. search_nonascii (p=<optimized out>, e=0xb3b91049 <error: Cannot access memory at address 0xb3b91049>) at string.c:729 729 if (*s & NONASCII_MASK) { (gdb) bt #0 search_nonascii (p=<optimized out>, e=0xb3b91049 <error: Cannot access memory at address 0xb3b91049>) at string.c:729 #1 0x56754d09 in coderange_scan (p=0xb3b91041 <error: Cannot access memory at address 0xb3b91041>, len=8, enc=0x56a961a0) at string.c:767 #2 0x56757715 in enc_coderange_scan (str=4122077840, enc=<optimized out>) at ./include/ruby/internal/core/rstring.h:430 #3 rb_enc_str_coderange (str=4122077840) at string.c:910 #4 0x5675845c in str_succ (str=str@entry=4122077840) at string.c:5364 #5 0x5675cf85 in rb_str_succ_bang (str=4122077840) at string.c:5380 #6 0x567b90e6 in vm_call_cfunc_with_frame_ (ec=0x56a9598c, reg_cfp=0xf77a6fd8, calling=<optimized out>, argc=0, argv=0xf7727030, stack_bottom=0xf772702c) at /builddir/ruby/ruby/vm_insnhelper.c:3794 #7 0x567c7636 in vm_call_method_each_type (ec=0x56a9598c, cfp=0xf77a6fd8, calling=0xffffd9e8) at /builddir/ruby/ruby/vm_insnhelper.c:4772 #8 0x567d2ecb in vm_sendish (ec=<optimized out>, reg_cfp=<optimized out>, cd=<optimized out>, block_handler=<optimized out>, method_explorer=<optimized out>) at /builddir/ruby/ruby/vm_callinfo.h:415 #9 vm_exec_core (ec=0xb3b91041, ec@entry=0x56a9598c) at /builddir/ruby/ruby/insns.def:898 #10 0x567c6d68 in vm_exec_loop (ec=<optimized out>, state=<optimized out>, tag=<optimized out>, result=10) at vm.c:2622 #11 rb_vm_exec (ec=0x56a9598c) at vm.c:2598 #12 0x5661e0ef in rb_ec_exec_node (ec=ec@entry=0x56a9598c, n=n@entry=0xf5b1eaf4) at eval.c:281 #13 0x56621558 in ruby_run_node (n=0xf5b1eaf4) at eval.c:319 #14 0x5657b460 in rb_main (argc=5, argv=0xffffdc34) at ./main.c:43 #15 main (argc=<optimized out>, argv=<optimized out>) at ./main.c:68 I can trigger this with "./configure CFLAGS="-O2 -g" The -O2 is important. With -flto=auto it goes away, with -O0 or -O3 too. I use gcc (GCC) 14.2.1 20250405 on Void Linux with glibc 2.41. On 64-bit x86_64 it works fine with same versions. I have bisected the issue to https://github.com/ruby/ruby/commit/14d154076876 but I don't see how this can introduce the bug. I assume it's some undefined behavior that is potentially triggered. (However reverting that patch works...) I think the behavior is related to the embedded string being expanded into a proper string, but my internal-fu isn't good enough. I hope this helps to debug the issue. -- https://bugs.ruby-lang.org/

3 6

[ruby-core:122643] [Ruby Bug#21498] Windows - Ruby Overrides C Library APIs thus breaking them
by cfis (Charlie Savage) 25 Nov '25

25 Nov '25

Issue #21498 has been reported by cfis (Charlie Savage). ---------------------------------------- Bug #21498: Windows - Ruby Overrides C Library APIs thus breaking them https://bugs.ruby-lang.org/issues/21498 * Author: cfis (Charlie Savage) * Status: Open * ruby -v: *all* on windows (testing with ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [x64-mswin64_140]) * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I am trying to wrap a simple C++ library, https://github.com/baderouaich/BitmapPlusPlus, as a Ruby extension. However when I use the extension to write a bitmap to disk the bitmap is corrupted. This is because the library uses std::ofstream which eventually uses the C API fclose to write the final bytes to the bitmap file and then closes it. The problem is that Ruby overrides `fclose` and replaces it with `rb_w32_fclose`. It then *exports* its custom version from from x64-vcruntime140-ruby340.dll. And the exported version is broken (at least from the standpoint of the C standard library). Note this has been a long standing issue. The first report I see is from 2013: https://bugs.ruby-lang.org/issues/8569 More recently in 2020 (which explains the issue very well): https://github.com/NREL/OpenStudio/issues/3942#issuecomment-610673401 I understand that Ruby is trying to provide a platform independent API. But the problem is this solution breaks any third party libraries that rely on these C APIs (which of course are very common). And there is no good workaround (see https://github.com/NREL/OpenStudio/issues/3942#issuecomment-611072774) So would it be possible for Ruby to stop exporting custom versions of basic C APIs? The code that does it is here: https://github.com/ruby/ruby/blob/master/win32/mkexports.rb#L41 Ruby of course could still use its custom versions of fclose, read, write etc within ruby.exe and x64-vcruntime140-ruby340.dll. But they should not be exported from x64-vcruntime140-ruby340.dll and thus be off limits to extensions. If a case comes up where an extension really needs access to rb_w32_fclose instead of fclose then an extension developer can use an `#ifdef _WIN32` to do so and work across platforms. That at least puts the developer in control versus now where I don't see any way I can to wrap the bitmap library for usage in Ruby. From my experience the biggest problem is the replacing of fclose with rb_w32_fclose. But I propose removing all such mappings, which include: FD_CLR=rb_w32_fdclr FD_ISSET=rb_w32_fdisset Sleep=rb_w32_Sleep accept=rb_w32_accept access=rb_w32_uaccess bind=rb_w32_bind close=rb_w32_close connect=rb_w32_connect dup2=rb_w32_dup2 fclose=rb_w32_fclose fstat=rb_w32_fstati128 get_osfhandle=rb_w32_get_osfhandle getcwd=rb_w32_ugetcwd getenv=rb_w32_ugetenv gethostbyaddr=rb_w32_gethostbyaddr gethostbyname=rb_w32_gethostbyname gethostname=rb_w32_gethostname getpeername=rb_w32_getpeername getpid=rb_w32_getpid getppid=rb_w32_getppid getprotobyname=rb_w32_getprotobyname getprotobynumber=rb_w32_getprotobynumber getservbyname=rb_w32_getservbyname getservbyport=rb_w32_getservbyport getsockname=rb_w32_getsockname getsockopt=rb_w32_getsockopt inet_ntop=rb_w32_inet_ntop inet_pton=rb_w32_inet_pton ioctlsocket=rb_w32_ioctlsocket isatty=rb_w32_isatty listen=rb_w32_listen lseek=rb_w32_lseek lstat=rb_w32_ulstati128 mkdir=rb_w32_umkdir mmap=rb_w32_mmap mprotect=rb_w32_mprotect munmap=rb_w32_munmap pipe=rb_w32_pipe pread=rb_w32_pread pwrite=rb_w32_pwrite read=rb_w32_read recv=rb_w32_recv recvfrom=rb_w32_recvfrom rename=rb_w32_urename rmdir=rb_w32_urmdir select=rb_w32_select send=rb_w32_send sendmsg sendto=rb_w32_sendto setsockopt=rb_w32_setsockopt shutdown=rb_w32_shutdown socket=rb_w32_socket stati128=rb_w32_ustati128 strcasecmp=msvcrt.stricmp strerror=rb_w32_strerror strncasecmp=msvcrt.strnicmp times=rb_w32_times unlink=rb_w32_uunlink utime=rb_w32_uutime utimensat=rb_w32_uutimensat utimes=rb_w32_uutimes write=rb_w32_write -- https://bugs.ruby-lang.org/

6 32

[ruby-core:122296] [Ruby Bug#21374] FrozenError message is inconsistent when a singleton method is defined on a frozen object
by andrykonchin (Andrew Konchin) 23 Nov '25

23 Nov '25

Issue #21374 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #21374: FrozenError message is inconsistent when a singleton method is defined on a frozen object https://bugs.ruby-lang.org/issues/21374 * Author: andrykonchin (Andrew Konchin) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I would expect a message to contain an object class (e.g. `can't modify frozen <class>: <object#inspect>`) when an ordinary frozen object (non a module or class) is being modified. It works this way in the following example: ```ruby object = []; object.freeze; object.instance_variable_set(:@a, 42) # (irb):5:in `instance_variable_set': can't modify frozen Array: [] (FrozenError) ``` But it doesn't in the following example: ```ruby object = []; object.freeze; def object.x; end # (irb):4:in `<main>': can't modify frozen object: [] (FrozenError) ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:119239] [Ruby master Feature#20750] Expose ruby_thread_has_gvl_p in ruby/thread.h
by kbrock (Keenan Brock) 19 Nov '25

19 Nov '25

Issue #20750 has been reported by kbrock (Keenan Brock). ---------------------------------------- Feature #20750: Expose ruby_thread_has_gvl_p in ruby/thread.h https://bugs.ruby-lang.org/issues/20750 * Author: kbrock (Keenan Brock) * Status: Open ---------------------------------------- Hello All, I'm hoping we can make `ruby_thread_has_gvl_p` a public method and no longer experimental. I saw the following code in a gem that was not compiling with ruby 3.3: ``` c // int ruby_thread_has_gvl_p(void); // <== line of concern if (ruby_thread_has_gvl_p()) { method_call(&context); } else { rb_thread_call_with_gvl(method_call, &context); } ``` 400 unique projects on github added the line listed above to fix compilation. [1] Some of the projects detected the method first in `extconf.rb`, but a majority just referenced it. `ffi` used to have the detection code but dropped it since the method was in all supported ruby versions. It feels like this method is now part of the undocumented public interface. My suggestion is to add the method to the real public interface in `ruby/thread.h`. PR with possible solution: https://github.com/ruby/ruby/pull/11619 Also included a patch if that is easier Thank you for your consideration, Keenan Timeline: - Dec 30 2008 - `rb_thread_call_with_gvl` introduced via 9c04a06 [2] - Jan 12 2009 - `ruby_thread_has_gvl_p` introduced via 6f09fc2 [4] - Jul 18 2012 - `rb_thread_call_with_gvl` made public via e9a91d2 [3] Current references to code: `rb_thread_call_with_gvl` [5] `ruby_thread_has_gvl_p` [6]: [1]: https://github.com/search?q=ruby_thread_has_gvl_p+language%3AC++NOT+is%3Afo… [2]: https://github.com/ruby/ruby/commit/9c04a0647fb99f7554cb2e04385ddbb970631e02 [3]: https://github.com/ruby/ruby/commit/e9a91d2c95dfe22ad0487952f7a1053ef9a5fd16 [4]: https://github.com/ruby/ruby/commit/6f09fc2efd1915c4337ce6dded52a8a8771c3222 [5]: https://github.com/ruby/ruby/blob/master/thread.c#L1878 [6]: https://github.com/ruby/ruby/blob/master/thread.c#L1923 ---Files-------------------------------- 11618.patch (3.18 KB) -- https://bugs.ruby-lang.org/

3 8

[ruby-core:121837] [Ruby Feature#21311] Namespace on read (revised)
by tagomoris (Satoshi Tagomori) 19 Nov '25

19 Nov '25

Issue #21311 has been reported by tagomoris (Satoshi Tagomori). ---------------------------------------- Feature #21311: Namespace on read (revised) https://bugs.ruby-lang.org/issues/21311 * Author: tagomoris (Satoshi Tagomori) * Status: Open ---------------------------------------- This replaces #19744 ## Concept This proposes a new feature to define virtual top-level namespaces in Ruby. Those namespaces can require/load libraries (either .rb or native extension) separately from other namespaces. Dependencies of required/loaded libraries are also required/loaded in the namespace. This feature will be disabled by default at first, and will be enabled by an env variable `RUBY_NAMESPACE=1` as an experimental feature. (It could be enabled by default in the future possibly.) ### "on read" approach The "on write" approach here is the design to define namespaces on the loaded side. For example, Java packages are defined in the .java files and it is required to separate namespaces from each other. It can be implemented very easily, but it requires all libraries to be updated with the package declaration. (In my opinion, it's almost impossible in the Ruby ecosystem.) The "on read" approach is to create namespaces and then require/load applications and libraries in them. Programmers can control namespace separation at the "read" time. So, we can introduce the namespace separation incrementally. ## Motivation The "namespace on read" can solve the 2 problems below, and can make a path to solve another problem: * Avoiding name conflicts between libraries * Applications can require two different libraries safely which use the same module name. * Avoiding unexpected globally shared modules/objects * Applications can make an independent/unshared module instance. * Multiple versions of gems can be required * Application developers will have fewer version conflicts between gem dependencies if rubygems/bundler will support the namespace on read. (Support from RubyGems/Bundler and/or other packaging systems will be needed) For the motivation details, see [Feature #19744]. ## How we can use Namespace ```ruby # app1.rb PORT = 2048 class App def self.port = ::PORT def val = PORT.to_s end p App.port # 2048 # app2.rb class Number def double = self * 2 end PORT = 2048.double class App def self.port = ::PORT def val = PORT.double.to_s end p App.port # 4096 # main.rb - executed as `ruby main.rb` ns1 = Namespace.new ns1.require('./app1') # 2048 ns2 = Namespace.new ns2.require('./app2') # 4096 PORT = 8080 class App def self.port = ::PORT def val = PORT.to_s end p App.port # 8080 p App.val # "8080" p ns1::App.port # 2048 p ns1::App.val # "2048" p ns2::App.port # 4096 p ns2::App.val # "8192" 1.double # NoMethodError ``` ## Namespace specification ### Types of namespaces There are two namespace types, "root" and "user" namespace. "Root" namespace exists solely in a Ruby process, and "user" namespaces can be created as many as Ruby programmers want. ### Root namespace Root namespace is a unique namespace to be defined when a Ruby process starts. It only contains built-in classes/modules/constants, which are available without any `require` calls, including RubyGems itself (when `--disable-gems` is not specified). ### User namespace User namespace is a namespace to run users' Ruby scripts. The "main" namespace is the namespace to run the user's `.rb` script specified by the `ruby` command-line argument. Other user namespaces ("optional" namespaces) can be created by `Namespace.new` call. In user namespace (both main and optional namespaces), built-in class/module definitions are copied from the root namespace, and other new classes/modules are defined in the namespace, separately from other (root/user) namespaces. The newly defined classes/modules are top-level classes/modules in the main namespace like `App`, but in optional namespaces, classes/modules are defined under the namespace (subclass of Module), like `ns::App`. In that namespace `ns`, `ns::App` is accessible as `App` (or `::App`). There is no way to access `App` in the main namespace from the code in the different namespace `ns`. ### Constants, class variables and global variables Constants, Class variables of built-in classes and global variables are also separated by namespace. Values set to class/global variables in a namespace are invisible in other namespaces. ### Methods and procs Methods defined in a namespace run with the defined namespace, even when called from other namespaces. Procs created in a namespace run with the defined namespace too. ### Dynamic link libraries Dynamic link libraries (typically .so files) are also loaded in namespaces as well as .rb files. ### Open class (Changes on built-in classes) In user namespaces, built-in class definitions can be modified. But those operations are processed as copy-on-write of class definition from the root namespace, and the changed definitions are visible only in the (user) namespace. Definitions in the root namespace are not modifiable from other namespaces. Methods defined in the root namespace run only with root-namespace definitions. ## Enabling Namespace Specify `RUBY_NAMESPACE=1` environment variable when starting Ruby processes. `1` is the only valid value here. Namespace feature can be enabled only when Ruby processes start. Setting `RUBY_NAMESPACE=1` after starting Ruby scripts performs nothing. ## Pull-request https://github.com/ruby/ruby/pull/13226 -- https://bugs.ruby-lang.org/

19 110

[ruby-core:122303] [Ruby Bug#21375] Set[] does not call #initialize
by Ethan (Ethan -) 18 Nov '25

18 Nov '25

Issue #21375 has been reported by Ethan (Ethan -). ---------------------------------------- Bug #21375: Set[] does not call #initialize https://bugs.ruby-lang.org/issues/21375 * Author: Ethan (Ethan -) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-26T17:42:35Z master 909a0daab6) +PRISM [x86_64-darwin22] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I have a subclass of Set that overrides #initialize. Following #21216, .new does call #initialize but .[] does not. ```ruby class MySet < Set def initialize(enum = nil) compare_by_identity super end end MySet.new.compare_by_identity? # => true MySet[].compare_by_identity? # => false ``` -- https://bugs.ruby-lang.org/

6 10

[ruby-core:122411] [Ruby Bug#21396] Set#initialize should call Set#add on items passed in
by tenderlovemaking (Aaron Patterson) 18 Nov '25

18 Nov '25

Issue #21396 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #21396: Set#initialize should call Set#add on items passed in https://bugs.ruby-lang.org/issues/21396 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ```ruby class Foo < Set def add(item) = super(item.bytesize) end x = Foo.new(["foo"]) p x p x.include?(3) ``` On Ruby 3.4 the output is this: ``` > ruby -v test.rb ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [arm64-darwin24] #<Foo: {3}> true ``` On Ruby master the output is this: ``` > make run ./miniruby -I./lib -I. -I.ext/common -r./arm64-darwin24-fake ./test.rb #<Set: {"foo"}> false ``` The bug is that `initialize` is not calling `add` for the elements passed in, so the subclass doesn't get a chance to change them. I've sent a PR here: https://github.com/ruby/ruby/pull/13518 -- https://bugs.ruby-lang.org/

5 13

[ruby-core:119998] [Ruby master Bug#20907] Fiber scheduler does not correctly re-lock mutex if `Mutex#sleep` is interrupted.
by ioquatix (Samuel Williams) 17 Nov '25

17 Nov '25

Issue #20907 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #20907: Fiber scheduler does not correctly re-lock mutex if `Mutex#sleep` is interrupted. https://bugs.ruby-lang.org/issues/20907 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) * Backport: 3.1: REQUIRED, 3.2: REQUIRED, 3.3: REQUIRED ---------------------------------------- The following test fails with a `ThreadError` instead of a `RuntimeError`: ```ruby def test_condition_variable condition_variable = ::Thread::ConditionVariable.new mutex = ::Thread::Mutex.new error = nil thread = Thread.new do Thread.current.report_on_exception = false scheduler = Scheduler.new Fiber.set_scheduler scheduler fiber = Fiber.schedule do begin mutex.synchronize do condition_variable.wait(mutex) end rescue => error end end fiber.raise(RuntimeError) end thread.join assert_kind_of RuntimeError, error end ``` Fix: https://github.com/ruby/ruby/pull/12158 -- https://bugs.ruby-lang.org/

3 3

[ruby-core:121688] [Ruby Feature#21275] Update to Unicode 17.0
by duerst 14 Nov '25

14 Nov '25

Issue #21275 has been reported by duerst (Martin Dürst). ---------------------------------------- Feature #21275: Update to Unicode 17.0 https://bugs.ruby-lang.org/issues/21275 * Author: duerst (Martin Dürst) * Status: Open * Assignee: duerst (Martin Dürst) * Target version: 3.5 ---------------------------------------- Unicode 17.0 is currently in alpha. Beta is planned for late May, release for September 2025. We just updated to Unicode 16.0, so we can start testing with alpha/beta. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:119895] [Ruby master Bug#20889] IO#ungetc and IO#ungetbyte should not cause IO#pos to report an inaccurate position
by javanthropus (Jeremy Bopp) 13 Nov '25

13 Nov '25

Issue #20889 has been reported by javanthropus (Jeremy Bopp). ---------------------------------------- Bug #20889: IO#ungetc and IO#ungetbyte should not cause IO#pos to report an inaccurate position https://bugs.ruby-lang.org/issues/20889 * Author: javanthropus (Jeremy Bopp) * Status: Open * ruby -v: ruby 3.3.6 (2024-11-05 revision 75015d4c1f) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ```ruby require 'tempfile' Tempfile.open(encoding: 'utf-8') do |f| f.write('0123456789') f.rewind f.ungetbyte(93) f.pos # => -1; negative value is surprising! end Tempfile.open(encoding: 'utf-8') do |f| f.write('0123456789') f.rewind f.ungetc('a'.encode('utf-8')) f.pos # => -1; similar to the ungetbyte case end Tempfile.open(encoding: 'utf-8:utf-16le') do |f| f.write('0123456789') f.rewind f.ungetc('a'.encode('utf-16le')) f.pos # => 0; maybe should be -2 to match the previous ungetc case? end ``` It doesn't seem logical that `IO#pos` should ever be affected by `IO#ungetc` or `IO#ungetbyte`. The pushed characters or bytes aren't really in the stream source. The value of `IO#pos` implies that jumping directly to that position via `IO#seek` and reading from there would return the same character or byte that was pushed, but the pushed characters or bytes are lost when the operation to seek in the stream is performed. In the case where `IO#pos` is a negative value, attempting to seek to that position actually raises an exception. In the `IO#ungetc` with character conversion case above, it seems unreasonable to make `IO#pos` report an even less correct position. In that case, the position would need to be adjusted by 2 bytes in reverse due to the internal encoding of the stream, but that is completely inconsistent with the behavior of `IO#pos` when reading from the stream normally where it reports the underlying stream's byte position and not the number of transcoded bytes that have been read: ```ruby require 'tempfile' Tempfile.open(encoding: 'utf-8:utf-16le') do |f| f.write('0123456789') f.rewind f.getc.bytesize # => 2; due to the internal encoding of the stream f.pos # => 1; reports actual bytes read from the stream, not transcoded bytes end ``` Attempting to use `IO#pos` when there are characters or bytes pushed into the read buffer by way of `IO#ungetc` or `IO#ungetbyte` should result in one of the following behaviors: 1. Raise and exception 2. Return the stream's position, clearing the read buffer entirely 3. Return the stream's position, ignoring the pushed characters or bytes, and produce a warning -- https://bugs.ruby-lang.org/

2 1