Codestin Search App

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

16 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/

5 16

[ruby-core:123804] [Ruby Bug#21686] In combination with IO#ungetbyte, the write position may become unpredictable.
by YO4 (Yoshinao Muramatsu) 16 Nov '25

16 Nov '25

Issue #21686 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #21686: In combination with IO#ungetbyte, the write position may become unpredictable. https://bugs.ruby-lang.org/issues/21686 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x64-mingw-ucrt] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- In the current implementation, using `IO#ungetbyte` can cause `IO#pos` to become negative. Writing to the same file descriptor in this state will result in unexpected write positions. ```ruby require 'tempfile' Tempfile.open do |f| f.write("0123456789") f.rewind f.getbyte # rbuf filled f.ungetbyte("-") # f.pos => 0 f.ungetbyte("-") # f.pos => -1 f.write("x") # seek to -1 failed in io_unread f.rewind p f.read # => "0123456789x", wrote at the end, questionable end ``` When internal `io_unread()` in `io.c` is called to prepare for a write operation while the actual file position is advancing due to reading, lseek fails because it attempts to reset to a negative file position. `IO#seek` has a similar issue. ```ruby Tempfile.open do |f| f.write("0123456789") f.rewind f.getbyte # rbuf filled f.ungetbyte("-") # f.pos => 0 f.ungetbyte("-") # f.pos => -1 f.seek(0, File::SEEK_CUR) p f.pos # => 10, this points to the last of rbuf. end ``` I am preparing the PR, but I understand that there is discussion about the position where the write occurs and the possibility of the pos becoming negative. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:123806] [Ruby Bug#21687] IO＃pos goes wrong after EOF character(ctrl-z) met.
by YO4 (Yoshinao Muramatsu) 16 Nov '25

16 Nov '25

Issue #21687 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #21687: IO＃pos goes wrong after EOF character(ctrl-z) met. https://bugs.ruby-lang.org/issues/21687 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * ruby -v: ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [x64-mingw-ucrt] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- In Windows environment, when opening a file with the "r", encountering an EOF character (Ctrl-Z, "\x1A") during reading causes the IO to report END-OF-FILE. ```ruby require 'tempfile' Tempfile.open do |f| str = "0123456789\x1A" f.write(str + "x"*(1024_0 - str.bytesize)) f.rewind p f.readline.size # => 10 p f.pos # => 8191, shuld be 10 but equals rbuf size end ``` When the file reaches its end, the file position moves to the position after the last character. Therefore, when encountering the EOF character, the file position is expected to move to the position of the EOF character. This is somewhat unrelated, but I understand that self.seek(0, File::SEEK_END) not positioning at the EOF character is a known limitation. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123626] [Ruby Bug#21659] rstring.h error: missing initializer for field ‘len’ of ‘struct RString’ [-Werror=missing-field-initializers] starting in ruby-3.3.10
by wsfulton (William Fulton) 15 Nov '25

15 Nov '25

Issue #21659 has been reported by wsfulton (William Fulton). ---------------------------------------- Bug #21659: rstring.h error: missing initializer for field ‘len’ of ‘struct RString’ [-Werror=missing-field-initializers] starting in ruby-3.3.10 https://bugs.ruby-lang.org/issues/21659 * Author: wsfulton (William Fulton) * Status: Open * ruby -v: ruby 3.3.10 (2025-10-23 revision 343ea05002) [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- All extensions now have this error when using -Werror -Wmissing-field-initializers: ``` In file included from /home/runner/.rvm/rubies/ruby-3.3.10/include/ruby-3.3.0/ruby/internal/arithmetic/char.h:29, from /home/runner/.rvm/rubies/ruby-3.3.10/include/ruby-3.3.0/ruby/internal/arithmetic.h:24, from /home/runner/.rvm/rubies/ruby-3.3.10/include/ruby-3.3.0/ruby/ruby.h:28, from /home/runner/.rvm/rubies/ruby-3.3.10/include/ruby-3.3.0/ruby.h:38, from example_wrap.c:1008: /home/runner/.rvm/rubies/ruby-3.3.10/include/ruby-3.3.0/ruby/internal/core/rstring.h: In function ‘rbimpl_rstring_getmem’: /home/runner/.rvm/rubies/ruby-3.3.10/include/ruby-3.3.0/ruby/internal/core/rstring.h:398:16: error: missing initializer for field ‘len’ of ‘struct RString’ [-Werror=missing-field-initializers] 398 | struct RString retval = {RBASIC_INIT}; | ^~~~~~~ /home/runner/.rvm/rubies/ruby-3.3.10/include/ruby-3.3.0/ruby/internal/core/rstring.h:206:10: note: ‘len’ declared here 206 | long len; | ^~~ ``` Can you please test with warnings turned on as this now breaks all extensions that rely on Ruby.h being warning free. Looks like it is due to commit https://github.com/ruby/ruby/commit/5a8d7642168f4ea0d9331fded3033c225bbc36c5 and expect that ```c++ struct RString retval = {RBASIC_INIT}; ``` should have been changed to: ```c++ struct RString retval = {RBASIC_INIT, 0}; ``` in rstring.h as well as all in the actual Ruby code base. -- https://bugs.ruby-lang.org/

6 12

[ruby-core:123754] [Ruby Feature#21678] Enumerable#rfind
by kddnewton (Kevin Newton) 15 Nov '25

15 Nov '25

Issue #21678 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Feature #21678: Enumerable#rfind https://bugs.ruby-lang.org/issues/21678 * Author: kddnewton (Kevin Newton) * Status: Open ---------------------------------------- I'd like to introduce `rfind` to enumerable, which would effectively be the same as `reverse_each.find`. I've found myself using this a surprising number of times, and have been surprised at its omission. That means either falling back to `reverse_each` or `rindex`. For context, here are a couple of examples of this in the wild: * [pry](https://github.com/pry/pry/blob/80816f596774d00afdc81a555724b0819bf267… * [bundler](https://github.com/ruby/rubygems/blob/e4fd4ee3fad005fce1dbcbeffd47… * [textbringer](https://github.com/shugo/textbringer/blob/738d318558045efc9d97… -- https://bugs.ruby-lang.org/

3 4

[ruby-core:120743] [Ruby master Bug#21049] Reconsider handling of the numbered parameters and "it" parameter in `Binding#local_variables`
by mame (Yusuke Endoh) 14 Nov '25

14 Nov '25

Issue #21049 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #21049: Reconsider handling of the numbered parameters and "it" parameter in `Binding#local_variables` https://bugs.ruby-lang.org/issues/21049 * Author: mame (Yusuke Endoh) * Status: Open * Assignee: matz (Yukihiro Matsumoto) * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Currently, `Binding#local_variable*` APIs wrongly handles the numbered parameters. ```ruby # Binding#local_variables includes numbered parameters that should not be visible "foo".tap do _1 "bar".tap do p binding.local_variables #=> expected: [], actual: [:_1] end end # Binding#local_variable_get can read numbered parameters that should not be readable "foo".tap do _1 "bar".tap do p binding.local_variable_get(:_1) #=> expected: NameError, actual: "foo" end end # Binding#local_variable_set can update numbered parameter "foo".tap do p _1 #=> "foo" binding.local_variable_set(:_1, "bar") # expected: NameError, actual: updates _1 p _1 #=> "bar" end ``` My proposal is to stop handling numbered parameters and "it" parameter in `Binding#local_variable*` APIs. ```ruby "foo".tap do _1 binding.local_variables #=> proposed: [] binding.local_variable_get(:_1) #=> proposed: NameError end ``` Here is a proof-of-concept patch. https://github.com/ruby/ruby/pull/12601 It would be theoretically possible to fix `Binding#local_variable*` APIs to handle numbered parameters while maintaining compatibility as much as possible. However, I think the implicit “it” parameter introduced in Ruby 3.4 poses a spec-level problem. This is because there is no way to distinguish between the implicit “it” parameter and a true local variable named "it". Also, I don't think numbered parameters are local variables, so I feel uncomfortable handling them by `Binding#local_variable*` APIs. If it is absolutely necessary to access numbered parameters or "it" parameter via binding, it would be good to introduce dedicated APIs for the purpose, as: * Binding#numbered_parameters #=> [:_1, :_2, :_3, ...] * Binding#numbered_parameter_get(:_1) #=> obj * Binding#numbered_parameter_defined?(:_1) #=> true or false * Binding#it_get #=> obj * Binding#it_defined? #=> true or false Personally, however, I do not see the need for these APIs currently. I implemented them as proof-of-concept in PR, but I am okay that they are not introduced. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:123795] [Ruby Bug#21685] Unnecessary context-switching, especially bad on multi-core machines.
by jpl-coconut (Jacob Lacouture) 14 Nov '25

14 Nov '25

Issue #21685 has been reported by jpl-coconut (Jacob Lacouture). ---------------------------------------- Bug #21685: Unnecessary context-switching, especially bad on multi-core machines. https://bugs.ruby-lang.org/issues/21685 * Author: jpl-coconut (Jacob Lacouture) * Status: Open * ruby -v: ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [aarch64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- While debugging a performance issue in a large rails application, I wrote a minimal microbenchmark that reproduces the issue. [[here]](https://gist.github.com/jpl-coconut/cb3679ce885eb578e1071c4b3a525d5c) I was surprised to see that the benchmark takes ~3.6sec on a single-core machine, and ~36sec **(10x slower) on a machine with 2 or more cores** . Initially I thought this was a bug in the implementation of Thread::Queue, but soon realized it relates to how the ruby reschedules threads around system calls. I prepared a fix in [[this branch]](https://github.com/jpl-coconut/ruby/tree/deferred_thread_wait) which is based off ruby 3.4.7. I can apply the fix to a different branch or to master if that's helpful. The fix simply defers suspending the thread until the syscall has been running for some short interval. I chose 100usec initially, but this could easily be made configurable. I pasted raw benchmark results below from a single run (though I did many runs and the results are stable). My CPU is an Apple M4. After the fix: - Single-core performance improves by 55%, from 3.6sec to 2sec. - Adding cores causes performance to be flat (at 2sec), rather than getting 10x slower. - Multi-core context-switch count reduces by 99.995%, from 1.4 million to ~80 - system_time/user_time ratio drops from (1.2 - 1.6) to 0.65 Here are the benchmark results before my change: ``` # time taskset --cpu-list 1 ./ruby qtest_simple.rb voluntary_ctxt_switches: 1140773 nonvoluntary_ctxt_switches: 9487 real 0m3.619s user 0m1.653s sys 0m1.950s # time taskset --cpu-list 1,2 ./ruby qtest_simple.rb voluntary_ctxt_switches: 1400110 nonvoluntary_ctxt_switches: 3 real 0m36.223s user 0m9.380s sys 0m14.927s ``` And after: ``` # time taskset --cpu-list 1 ./ruby qtest_simple.rb voluntary_ctxt_switches: 88 nonvoluntary_ctxt_switches: 899 real 0m2.031s user 0m1.209s sys 0m0.743s # time taskset --cpu-list 1,2 ./ruby qtest_simple.rb voluntary_ctxt_switches: 75 nonvoluntary_ctxt_switches: 8 real 0m2.062s user 0m1.279s sys 0m0.783s ``` I was concerned these results might still be reflective of a bug in Thread::Queue, so I also came up with a repro that doesn't rely on it. That one is [[here]](https://gist.github.com/jpl-coconut/aa14e59354abf98f808daaf39baa9a72). Results summary: - Single-core performance improves (this time by only 30%) - Multi-core penalty drops from 4x to 0. - No change to context-switching rates. - system_time/user_time ratio drops from (0.5-1) to 0.15 Before fix: ``` # time taskset --cpu-list 1 ./ruby mbenchmark.rb voluntary_ctxt_switches: 60 real 0m0.336s user 0m0.211s sys 0m0.118s # time taskset --cpu-list 1,2 ./ruby mbenchmark.rb voluntary_ctxt_switches: 60 real 0m1.424s user 0m0.468s sys 0m0.496s ``` After fix: ``` # time taskset --cpu-list 1 ./ruby mbenchmark.rb voluntary_ctxt_switches: 59 real 0m0.241s user 0m0.202s sys 0m0.032s # time taskset --cpu-list 1,2 ./ruby mbenchmark.rb voluntary_ctxt_switches: 60 real 0m0.238s user 0m0.195s sys 0m0.035s ``` -- https://bugs.ruby-lang.org/

2 1

[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:123768] [Ruby Bug#21679] Segfault when ruby calls pthread_detach in rb_getnameinfo
by luke-gru (Luke Gruber) 14 Nov '25

14 Nov '25

Issue #21679 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #21679: Segfault when ruby calls pthread_detach in rb_getnameinfo https://bugs.ruby-lang.org/issues/21679 * Author: luke-gru (Luke Gruber) * Status: Open * ruby -v: 3.4.7 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- We're seeing an issue on our servers running ruby 3.4.7 where we get a SEGV after ruby calls `pthread_detach` on a short-lived pthread that calls `getaddrinfo`. I believe it's related to this glibc bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19951. Our servers are using glibc version 2.39, which is from January 2024. This bug hasn't been fixed in glibc yet but I haven't been able to reproduce it on my Linux desktop. Regardless, there's a simple workaround for it that avoids calling `pthread_detach` on the thread. My PR is here: https://github.com/ruby/ruby/pull/15142. Thanks, Luke -- https://bugs.ruby-lang.org/

1 1

[ruby-core:123793] [Ruby Bug#15773] Net::HTTP doesn't try next IP address in case of timeout
by adrienjarthon (Adrien Jarthon) 14 Nov '25

14 Nov '25

Issue #15773 has been updated by adrienjarthon (Adrien Jarthon). I was surprised to notice this is still the case in Ruby 3.3. I understand it could be a lot of work and I'm not asking for it to be implemented by other people right away of course. But at least was there any change in the refusal of implementing this behavior? It's implemented by most other software as already pointed out and strongly recommend for years in the RFC. If there is any ongoing work or if the team is now open to the idea I could provide some help. Thanks! ---------------------------------------- Bug #15773: Net::HTTP doesn't try next IP address in case of timeout https://bugs.ruby-lang.org/issues/15773#change-115192 * Author: nicolasnoble (Nicolas Noble) * Status: Rejected * Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- This example requires to have a working IPv6 address. Since IPv6 is used in first priority, I am using it to demonstrate the problem, but it exists with plain IPv4, which will be more round-robin-style, so less deterministic to show a reproduction case. I have made two URLs that have both IPv4 and IPv6 addresses: http://ipv6.grumpycoder.net/ and http://bad-ipv6.grumpycoder.net/ - both URLs should work in an IPv6-enabled web browser, as well as curl or wget for instance. The difference is that the bad-ipv6 subdomain doesn't have an IPv6 that will actually connect. Therefore, browsers, curl and wget will fallback to using the IPv4 when the initial IPv6 connection attempt failed: ``` $ wget -T1 http://bad-ipv6.grumpycoder.net -O - # demonstrating using wget because its output is more clear than curl's verbose --2019-04-16 15:56:52-- http://bad-ipv6.grumpycoder.net/ Resolving bad-ipv6.grumpycoder.net (bad-ipv6.grumpycoder.net) 2001:bc8:3690:200::2, 62.210.214.144 Connecting to bad-ipv6.grumpycoder.net (bad-ipv6.grumpycoder.net)|2001:bc8:3690:200::2|:80... failed: Connection timed out. Connecting to bad-ipv6.grumpycoder.net (bad-ipv6.grumpycoder.net)|62.210.214.144|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 45 [text/html] Saving to: ‘STDOUT’ - 0%[ ] 0 --.-KB/s <html><body><h1>It works!</h1></body></html> - 100%[=====================================================================>] 45 --.-KB/s in 0s 2019-04-16 15:56:53 (6.55 MB/s) - written to stdout [45/45] ``` However, in Ruby, using Net::HTTP (or OpenURI), that's not going to be the case: ``` $ ruby bad-ipv6.rb http://ipv6.grumpycoder.net <html><body><h1>It works!</h1></body></html> http://bad-ipv6.grumpycoder.net Net::OpenTimeout: execution expired ``` Contents of my test file: ```ruby require 'open-uri' ['ipv6', 'bad-ipv6'].each do |s| url = 'http://%s.grumpycoder.net' %[s] puts url begin puts open(url).read rescue StandardError => e puts "#{e.class}: #{e.message}" next end end ``` The proper behavior should be to retry the next IP address and exhaust all of the IPs in the DNS resolution results before throwing out an error. -- https://bugs.ruby-lang.org/

1 0

ruby-core

November 2025