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

[ruby-core:115701] [Ruby master Bug#20059] TracePoint#enable can be called multiple times, increasing the number of invokations
by zverok (Victor Shepelev) 12 Dec '23

12 Dec '23

Issue #20059 has been reported by zverok (Victor Shepelev). ---------------------------------------- Bug #20059: TracePoint#enable can be called multiple times, increasing the number of invokations https://bugs.ruby-lang.org/issues/20059 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I just stumbled upon this accidentally (created a tracepoint with `TracePoint.trace`, and then `enable`d it). My initial example ```ruby trace = TracePoint.trace(:raise) do |tp| puts "Exception raised: #{tp.raised_exception.inspect} at #{tp.path}:#{tp.lineno}" end trace.enable # shouldn't do this, it was already enabled! raise "foo" ``` This prints ``` Exception raised: #<RuntimeError: foo> at test.rb:5 Exception raised: #<RuntimeError: foo> at test.rb:5 ``` Twice. If I'll remove the "unnecessary" `trace.enable`, it prints it once. So the theory is "multiple enables = multiple invokations of a tracepoint"... ```ruby trace = TracePoint.trace(:raise) do |tp| puts "Exception raised: #{tp.raised_exception.inspect} at #{tp.path}:#{tp.lineno}" end 5.times { trace.enable } raise "foo" ``` ...and indeed, this code prints the "Exception raised:" message 6 times. I don't see anything about this behavior in the [method's docs](https://docs.ruby-lang.org/en/master/TracePoint.html#method-i-enable) or class docs, and can't think of a plausible explanation. But it was this way since Ruby 2.0, and either it _should_ be this way, or it bothers nobody :) I wonder: * is there a reasonable explanation for this? * if so, shouldn't it be documented somewhere?.. Or is it some part of a pattern of how the `TracePoint` works that I am missing here?.. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:115647] [Ruby master Bug#20048] UDPSocket#remote_address spec errors
by vo.x (Vit Ondruch) 11 Dec '23

11 Dec '23

Issue #20048 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #20048: UDPSocket#remote_address spec errors https://bugs.ruby-lang.org/issues/20048 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-12-07 master 071df40495) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Testing of Fedora Rawhide, we have recently started to observe following errors: ~~~ $ make -C redhat-linux-build test-spec MSPECOPT="-fs ../spec/ruby/library/socket/udpsocket" ... snip ... 1) An exception occurred during: before :each UDPSocket#local_address using IPv4 using an implicit hostname the returned Addrinfo uses the correct IP address ERROR Socket::ResolutionError: getaddrinfo: Name or service not known /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:66:in `connect' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:66:in `block (4 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:4:in `<top (required)>' 2) An exception occurred during: before :each UDPSocket#local_address using IPv6 using an implicit hostname the returned Addrinfo uses the correct IP address ERROR Socket::ResolutionError: getaddrinfo: Name or service not known /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:66:in `connect' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:66:in `block (4 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/local_address_spec.rb:4:in `<top (required)>' 3) An exception occurred during: before :each UDPSocket#remote_address using IPv4 using an implicit hostname the returned Addrinfo uses the correct IP address ERROR Socket::ResolutionError: getaddrinfo: Name or service not known /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:65:in `connect' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:65:in `block (4 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:4:in `<top (required)>' 4) An exception occurred during: before :each UDPSocket#remote_address using IPv6 using an implicit hostname the returned Addrinfo uses the correct IP address ERROR Socket::ResolutionError: getaddrinfo: Name or service not known /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:65:in `connect' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:65:in `block (4 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.3.0-071df40495/spec/ruby/library/socket/udpsocket/remote_address_spec.rb:4:in `<top (required)>' Finished in 0.020615 seconds 11 files, 95 examples, 123 expectations, 0 failures, 4 errors, 0 tagged make: *** [uncommon.mk:983: yes-test-spec] Error 1 make: Leaving directory '/builddir/build/BUILD/ruby-3.3.0-071df40495/redhat-linux-build' ~~~ Please note that the build environment does not have network connection enabled by default. As soon as the network connection is available, the test cases pass just fine. This started to happen between these two commits: https://github.com/ruby/ruby/compare/c8b60c8ac2c8bbd077150792b5b207e983ab36… Where the culprit likely is commit:git|d2ba8ea54a4089959afdeecdd963e3c4ff391748 Originally reported [here](https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedorapr… -- https://bugs.ruby-lang.org/

3 8

[ruby-core:115686] Ruby 3.3.0-rc1 Released"
by NARUSE, Yui 11 Dec '23

11 Dec '23

We are pleased to announce the release of Ruby 3.3.0-rc1. Ruby 3.3 adds a new parser named Prism, uses Lrama as a parser generator, adds a new pure-Ruby JIT compiler named RJIT, and many performance improvements especially YJIT. After the release of RC1, we will avoid introducing ABI incompatibilities wherever possible. If we need to do, we'll announce it in the release note. ## Prism * Introduced [the Prism parser](https://github.com/ruby/prism) as a default gem * Prism is a portable, error tolerant, and maintainable recursive descent parser for the Ruby language * Prism is production ready and actively maintained, you can use it in place of Ripper * There is [extensive documentation](https://ruby.github.io/prism/) on how to use Prism * Prism is both a C library that will be used internally by CRuby and a Ruby gem that can be used by any tooling which needs to parse Ruby code * Notable methods in the Prism API are: * `Prism.parse(source)` which returns the AST as part of a ParseResult * `Prism.dump(source, filepath)` which returns the serialized AST as a String * `Prism.parse_comments(source)` which returns the comments * You can make pull requests or issues directly on [the Prism repository](https://github.com/ruby/prism) if you are interested in contributing ## Use Lrama instead of Bison * Replace Bison with [Lrama LALR parser generator](https://github.com/ruby/lrama) [Feature #19637](https://bugs.ruby-lang.org/issues/19637) * If you have interest, please see [The future vision of Ruby Parser](https://rubykaigi.org/2023/presentations/spikeolaf.html) * Lrama internal parser is replaced with LR parser generated by Racc for maintainability * Parameterizing Rules `(?, *, +)` are supported, it will be used in Ruby parse.y ## RJIT * Introduced a pure-Ruby JIT compiler RJIT and replaced MJIT. * RJIT supports only x86-64 architecture on Unix platforms. * Unlike MJIT, it doesn't require a C compiler at runtime. * RJIT exists only for experimental purposes. * You should keep using YJIT in production. * If you are interested in developing JIT for Ruby, please check out [k0kubun's presentation on Day 3 of RubyKaigi](https://rubykaigi.org/2023/presentations/k0kubun.html#day3). ## YJIT * Major performance improvements over 3.2 * Support for splat and rest arguments has been improved. * Registers are allocated for stack operations of the virtual machine. * More calls with optional arguments are compiled. * Exception handlers are also compiled. * Instance variables no longer exit to the interpreter with megamorphic object shapes. * Unsupported call types no longer exit to the interpreter. * `Integer#!=`, `String#!=`, `Kernel#block_given?`, `Kernel#is_a?`, `Kernel#instance_of?`, `Module#===` are specially optimized. * Now more than 3x faster than the interpreter on optcarrot! * Significantly improved memory usage over 3.2 * Metadata for compiled code uses a lot less memory. * Generate more compact code on ARM64 * Compilation speed is now slightly faster than 3.2. * Add `RubyVM::YJIT.enable` that can enable YJIT at run-time * You can start YJIT without modifying command-line arguments or environment variables. * This can also be used to enable YJIT only once your application is done booting. `--yjit-disable` can be used if you want to use other YJIT options while disabling YJIT at boot. * Code GC is now disabled by default, and `--yjit-exec-mem-size` is treated as a hard limit where copilation of new code stops. * Better copy-on-write behavior on servers using unicorn and forking * No sudden drops in performance due to code GC. * You can still enable code GC if desired with `--yjit-code-gc` * `ratio_in_yjit` stat produced by `--yjit-stats` is now available in release builds, a special stats or dev build is no longer required to access most stats. * Exit tracing option now supports sampling * `--trace-exits-sample-rate=N` * `--yjit-perf` is added to facilitate profiling with Linux perf. * More thorough testing and multiple bug fixes ### M:N thread scheduler * M:N thread scheduler was introduced. [[Feature #19842]](https://bugs.ruby-lang.org/issues/19842) * M Ruby threads are managed by N native threads (OS threads) so the thread creation and management cost are reduced. * It can break C-extension compatibility so that M:N thread scheduler is disabled on the main Ractor by default. * `RUBY_MN_THREADS=1` environment variable enables M:N threads on the main Ractor. * M:N threads are enabled on non-main Ractors. * `RUBY_MAX_CPU=n` environment variable sets maximum number of `N` (maximum number of native threads). The default value is 8. * Since only one Ruby thread per Ractor can run at the same time, the number of native threads will be used, which is the smaller of the number specified in `RUBY_MAX_CPU` and the number of running Ractors. So that single Ractor applications (most of applications) will use 1 native thread. * To support blocking operations, more than `N` native threads can be used. ## Other Notable New Features ### Language ## Performance improvements * `defined?(@ivar)` is optimized with Object Shapes. * Name resolution such as `Socket.getaddrinfo` can now be interrupted (in environments where pthreads are available). [Feature #19965](https://bugs.ruby-lang.org/issues/19965) * For this purpose, a pthread is now created whenever calling getaddrinfo or getnameinfo. This incurs some overhead in name resolution (about 2.5x in our experiments). We do not expect the name resolution overhead to be a problem for most applications, but if you observe such, or if you see unexpected affects that you believe are due to this change, please report them. * Several performance improvements to the Garbage Collector * Young objects referenced by old objects are no longer immediately promoted to the old generation. This significantly reduces the frequency of major GC collections. [[Feature #19678]](https://bugs.ruby-lang.org/issues/19678) * A new `REMEMBERED_WB_UNPROTECTED_OBJECTS_LIMIT_RATIO` tuning variable was introduced to control the number of unprotected objects cause a major GC collection to trigger. The default is set to `0.01` (1%). This significantly reduces the frequency of major GC collection. [[Feature #19571]](https://bugs.ruby-lang.org/issues/19571) * Write Barriers were implemented for many core types that were missing them, notably `Time`, `Enumerator`, `MatchData`, `Method`, `File::Stat`, `BigDecimal` and several others. This significantly reduces minor GC collection time and major GC collection frequency. * Most core classes are now using Variable Width Allocation, notably `Hash`, `Time`, `Thread::Backtrace`, `Thread::Backtrace::Location`, `File::Stat`, `Method`. This makes these classes faster to allocate and free, use less memory and reduce heap fragmentation. * Support for weak references has been added to the garbage collector. [[Feature #19783]](https://bugs.ruby-lang.org/issues/19783) ## Other notable changes since 3.2 ### IRB IRB has received several enhancements, including but not limited to: - Advanced `irb:rdbg` integration that provides an equivalent debugging experience to `pry-byebug` ([doc](https://github.com/ruby/irb#debugging-with-irb)) - Pager support for `ls`, `show_source` and `show_cmds` commands. - More accurate and helpful information provided by the `ls` and `show_source` commands. - Experimental autocompletion using type analysis ([doc](https://github.com/ruby/irb#type-based-completion)) - It is now possible to change the font color and font style in the completion dialog by a newly introduced class Reline::Face ([doc](https://github.com/ruby/ruby/blob/master/doc/reline/face.md)) In addition, IRB has also undergone extensive refactoring and received dozens of bug fixes to facilitate easier future enhancements. ## Compatibility issues Note: Excluding feature bug fixes. * `it` calls without arguments in a block with no ordinary parameters are deprecated. `it` will be a reference to the first block parameter in Ruby 3.4. [Feature #18980](https://bugs.ruby-lang.org/issues/18980) ### Removed constants The following deprecated constants are removed. ### Removed methods The following deprecated methods are removed. ### Removed environment variables The following deprecated methods are removed. * Environment variable `RUBY_GC_HEAP_INIT_SLOTS` has been deprecated and is a no-op. Please use environment variables `RUBY_GC_HEAP_{0,1,2,3,4}_INIT_SLOTS` instead. [Feature #19785](https://bugs.ruby-lang.org/issues/19785) ## Stdlib compatibility issues ### `ext/readline` is retired * We have `reline` that is pure Ruby implementation compatible with `ext/readline` API. We rely on `reline` in the future. If you need to use `ext/readline`, you can install `ext/readline` via rubygems.org with `gem install readline-ext`. * We no longer need to install libraries like `libreadline` or `libedit`. ## C API updates ### Updated C APIs The following APIs are updated. ### Removed C APIs The following deprecated APIs are removed. ## Standard library updates RubyGems and Bundler warn if users require gem that is scheduled to become the bundled gems in the future version of Ruby. Targeted libraries are: * abbrev * base64 * bigdecimal * csv * drb * getoptlong * mutex_m * nkf * observer * racc * resolv-replace * rinda * syslog The following default gem is added. * prism 0.15.1 The following default gems are updated. * RubyGems 3.5.0.dev * base64 0.2.0 * benchmark 0.3.0 * bigdecimal 3.1.5 * bundler 2.5.0.dev * cgi 0.4.0 * csv 3.2.8 * date 3.3.4 * delegate 0.3.1 * drb 2.2.0 * english 0.8.0 * erb 4.0.3 * etc 1.4.3.dev.1 * fcntl 1.1.0 * fiddle 1.1.2 * fileutils 1.7.2 * find 0.2.0 * getoptlong 0.2.1 * io-console 0.6.1.dev * irb 1.8.3 * logger 1.6.0 * mutex_m 0.2.0 * net-http 0.4.0 * net-protocol 0.2.2 * nkf 0.1.3 * observer 0.1.2 * open-uri 0.4.0 * open3 0.2.0 * openssl 3.2.0 * optparse 0.4.0 * ostruct 0.6.0 * pathname 0.3.0 * pp 0.5.0 * prettyprint 0.2.0 * pstore 0.1.3 * psych 5.1.1.1 * rdoc 6.6.0 * reline 0.3.9 * rinda 0.2.0 * securerandom 0.3.0 * shellwords 0.2.0 * singleton 0.2.0 * stringio 3.0.9 * strscan 3.0.7 * syntax_suggest 1.1.0 * tempfile 0.2.0 * time 0.3.0 * timeout 0.4.1 * tmpdir 0.2.0 * tsort 0.2.0 * un 0.3.0 * uri 0.13.0 * weakref 0.1.3 * win32ole 1.8.10 * yaml 0.3.0 * zlib 3.1.0 The following bundled gem is promoted from default gems. * racc 1.7.3 The following bundled gems are updated. * minitest 5.20.0 * rake 13.1.0 * test-unit 3.6.1 * rexml 3.2.6 * rss 0.3.0 * net-imap 0.4.4 * net-smtp 0.4.0 * rbs 3.2.2 * typeprof 0.21.8 * debug 1.8.0 See GitHub releases like [Logger](https://github.com/ruby/logger/releases) or changelog for details of the default gems or bundled gems. See [NEWS](https://github.com/ruby/ruby/blob/v3_3_0_rc1/NEWS.md) or [commit logs](https://github.com/ruby/ruby/compare/v3_2_0...v3_3_0_rc1) for more details. With those changes, [5414 files changed, 306141 insertions(+), 183575 deletions(-)](https://github.com/ruby/ruby/compare/v3_2_0...v3_3_0_rc1#file… since Ruby 3.2.0! ## Download * <https://cache.ruby-lang.org/pub/ruby/3.3/ruby-3.3.0-rc1.tar.gz> SIZE: 21783575 SHA1: c75a860e06f27b7f69b874757417277c21d1d3f4 SHA256: c4ff82395a90ef76c7f906b7687026e0ab96b094dcf3a532d9ab97784a073222 SHA512: 265fb2ffe55af47d8349edffcebe749cc170291227cef55529fe4e67363e4e84b88daa34ffb5364a99c8a0e32110266a34c9a11d62f3bd6f6d47fa76eca641f4 * <https://cache.ruby-lang.org/pub/ruby/3.3/ruby-3.3.0-rc1.tar.xz> SIZE: 16163884 SHA1: 26503f9bdc7d0a05aaa9836f54d3aa9e74a9ead9 SHA256: 051815637f1fa75a1edf2c54b66d5d5b69563daad777da8dc39543b7754b5290 SHA512: 82f4acfaad1dc47db27ee3eb952481a95b3474a98059e9e9f5ceb035b690d1faabe99f2ec52371c4089ed1615eb10c395f029088418fec4d26399b65b4f259b9 * <https://cache.ruby-lang.org/pub/ruby/3.3/ruby-3.3.0-rc1.zip> SIZE: 26735443 SHA1: 35583453a7734216b08829ef0ec9ea1bc0d4ae7f SHA256: 56dd82e1dd714f2889ca975ae7befbe005675de08839c2cc4a484de2ae65201c SHA512: 7fbe414c230aedc9f364512bcbc213038f8f6e4268929a559d2527e2f3e32a140b394e37098ab7e59161236eca8b89cc9e52d73a3be8d7bd44faa91681483f5d ## What is Ruby Ruby was first developed by Matz (Yukihiro Matsumoto) in 1993, and is now developed as Open Source. It runs on multiple platforms and is used all over the world especially for web development.

1 0

[ruby-core:112119] [Ruby master Bug#19392] Endless method vs and/or
by zverok (Victor Shepelev) 09 Dec '23

09 Dec '23

Issue #19392 has been reported by zverok (Victor Shepelev). ---------------------------------------- Bug #19392: Endless method vs and/or https://bugs.ruby-lang.org/issues/19392 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal * Backport: 2.7: DONTNEED, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- [Discovered](https://twitter.com/lucianghinda/status/1617783952353406977) by Lucian Ghinda: ```ruby def test = puts("foo") and puts("bar") # prints "bar" immediately test # prints "foo" ``` It seems that it is a parser error, right?.. ```ruby RubyVM::AbstractSyntaxTree.parse('def test = puts("foo") and puts("bar")') # => # (SCOPE@1:0-1:38 # tbl: [] # args: nil # body: # (AND@1:0-1:38 # (DEFN@1:0-1:22 # mid: :test # body: # (SCOPE@1:0-1:22 # tbl: [] # args: # (ARGS@1:0-1:8 pre_num: 0 pre_init: nil opt: nil first_post: nil post_num: 0 post_init: nil rest: nil kw: nil kwrest: nil block: nil) # body: (FCALL@1:11-1:22 :puts (LIST@1:16-1:21 (STR@1:16-1:21 "foo") nil)))) # (FCALL@1:27-1:38 :puts (LIST@1:32-1:37 (STR@1:32-1:37 "bar") nil)))) ``` E.g. it is parsed as ```ruby (def test = puts("foo")) and (puts("bar")) ``` ...which is hardly intentional or have any practical use. The rightly parsed code in this case _can_ have practical use, like ```ruby def write(data) = File.write(@filename, data) == data.size or raise "Something went wrong" ``` -- https://bugs.ruby-lang.org/

12 19

[ruby-core:115653] [Ruby master Bug#20051] Op asgn calls handle keywords and keyword splats as positional arguments
by jeremyevans0 (Jeremy Evans) 08 Dec '23

08 Dec '23

Issue #20051 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #20051: Op asgn calls handle keywords and keyword splats as positional arguments https://bugs.ruby-lang.org/issues/20051 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Ruby passes a keywords given to op asgn method calls as a positional hash argument, both to `[]` and `[]=`: ```ruby foo[kw: 1] += bar ``` This seems wrong, because `foo[kw: 1]` passes `kw: 1` as keywords. Worse, Ruby passes a keyword splat given to the op asgn method calls as a regular positional argument to `[]` and `[]=`, with no `to_hash` conversion: ```ruby foo[**kw] += bar ``` Example: ```ruby [1][**0] += 2 # => 3 ``` I'll try to fix this before the 3.3 release if I have time, but if anyone else wants to work on a fix, please do so. -- https://bugs.ruby-lang.org/

1 2

[ruby-core:115430] [Ruby master Bug#20012] Fix keyword splat passing as regular argument
by jeremyevans0 (Jeremy Evans) 08 Dec '23

08 Dec '23

Issue #20012 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #20012: Fix keyword splat passing as regular argument https://bugs.ruby-lang.org/issues/20012 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-11-12 master 60e19a0b5f) [x86_64-openbsd] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Since Ruby 3.0, Ruby has passed a keyword splat as a regular argument in the case of a call to a Ruby method where the method does not accept keyword arguments, if the method call does not contain an argument splat: ```ruby def self.f(obj) obj end def self.fs(*obj) obj[0] end h = {a: 1} f(**h).equal?(h) # Before: true; After: false fs(**h).equal?(h) # Before: true; After: false a = [] f(*a, **h).equal?(h) # Before and After: false fs(*a, **h).equal?(h) # Before and After: false ``` The fact that the behavior differs when passing an empty argument splat makes it obvious that something is not working the way it is intended. The fact that the hash is copied for C methods also makes it obvious. Ruby 2 always copied the keyword splat hash, and I think that is the expected behavior in Ruby 3. This bug is because of a missed check in setup_parameters_complex. If the keyword splat passed is not mutable, then it points to an existing object and not a new object, and therefore it must be copied. I did not bisect to find the commit that introduced the problem, but this seems likely to be something I introduced during keyword argument separation. I'm surprised that this has not been filed as a bug sooner. Maybe it just rarely comes up in practice, and I only discovered it recently. Possibly, other developers that may have discovered this may have decided against submitting this as an issue, as we have had specs for two years that give the impression that the broken behavior was expected. I've submitted a pull request to fix this: https://github.com/ruby/ruby/pull/8970 -- https://bugs.ruby-lang.org/

4 5

[ruby-core:115645] [Ruby master Bug#20047] ConditionVariable#wait has spurious wakeups from signal traps
by Eregon (Benoit Daloze) 07 Dec '23

07 Dec '23

Issue #20047 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #20047: ConditionVariable#wait has spurious wakeups from signal traps https://bugs.ruby-lang.org/issues/20047 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-11-27T17:17:52Z master cc05a60c16) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ```ruby Signal.trap("INT") { p :SIGINT } Thread.new do sleep 0.6 `kill -INT #{$$}` end m, cv = Mutex.new, ConditionVariable.new m.synchronize do r = ARGV[0] ? cv.wait(m, 2) : cv.wait(m) p ["ConditionVariable#wait returned", r] end ``` The above program should hang on `.wait` and not return. That's the behavior on TruffleRuby and JRuby, but not on CRuby, where `.wait` wakes up spuriously. ``` $ ruby -v spurious_cv.rb ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux] :SIGINT ["ConditionVariable#wait returned", 1] $ ruby -v spurious_cv.rb truffleruby 23.1.1, like ruby 3.2.2, Oracle GraalVM Native [x86_64-linux] :SIGINT # hangs as expected $ ruby -v spurious_cv.rb jruby 9.4.5.0 (3.1.4) 2023-11-02 1abae2700f OpenJDK 64-Bit Server VM 17.0.8+7 on 17.0.8+7 +jit [x86_64-linux] :SIGINT # hangs as expected ``` When given an argument, it should wait 2 seconds. But on CRuby it wakes up spuriously: ``` $ ruby -v spurious_cv.rb timeout ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux] :SIGINT ["ConditionVariable#wait returned", 0] $ ruby -v spurious_cv.rb timeout truffleruby 23.1.1, like ruby 3.2.2, Oracle GraalVM Native [x86_64-linux] :SIGINT ["ConditionVariable#wait returned", #<ConditionVariable:0x188>] $ ruby -v spurious_cv.rb timeout jruby 9.4.5.0 (3.1.4) 2023-11-02 1abae2700f OpenJDK 64-Bit Server VM 17.0.8+7 on 17.0.8+7 +jit [x86_64-linux] :SIGINT ["ConditionVariable#wait returned", #<Thread::ConditionVariable:0x482ba4b1>] ``` `ConditionVariable#wait` needs to be interrupted to execute the signal handler, which does `{ p :SIGINT }` on the main thread. However, `ConditionVariable#wait` should automatically be restarted internally after that, with the remaining timeout. That is what I think is the bug in CRuby. While it's good practice to have a loop around ConditionVariable#wait (at least when there is no timeout), it still seems highly unexpected in a high-level language like Ruby to have ConditionVariable#wait return when neither ConditionVariable#{signal,broadcast} are used (i.e., spurious wakeups). Also adding a loop is non-trivial for the case where a timeout argument is passed, as then one needs to manually account the remaining timeout instead of letting ConditionVariable#wait do its job correctly. And also need to check that if ConditionVariable#wait returns nil then one should break the loop, which is quite error-prone. Instead of just using `cv.wait(mutex, timeout)` when it works correctly. From https://github.com/ruby-concurrency/concurrent-ruby/issues/1015 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114722] [Ruby master Bug#19877] Non intuitive behavior of syntax only applied to literal value
by tompng (tomoya ishida) 07 Dec '23

07 Dec '23

Issue #19877 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #19877: Non intuitive behavior of syntax only applied to literal value https://bugs.ruby-lang.org/issues/19877 * Author: tompng (tomoya ishida) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-09-08T23:08:32Z master b635a66e95) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Non intuitive behavior of syntax only applied to literal value Some ruby syntax is only applied to literal value. ~~~ruby def 1.foo; end # receiver is a literal, it is Syntax Error /(?<a>)/ =~ s # receiver is regexp literal, it will assign to local variable if cond1..cond2; end # range-like syntax appears in condition, it is flipflop ~~~ If it is wrapped with parenthesis, the behavior seems not intuitive for me, and YARP parses it differently. ~~~ruby def (1).foo; end # Syntax Error def ((1;1)).foo; end # Syntax Error def ((;1)).foo; end # Syntax OK def ((1+1;1)).foo; end # Syntax OK def ((%s();1)).foo; end # Syntax Error def ((%w();1)).foo; end # Syntax OK def ("#{42}").foo; end # Syntax Error def (:"#{42}").foo; end # Syntax OK (/(?<a>)/) =~ s # assigns to a (;/(?<a>)/) =~ s # does not assigns (%s();/(?<a>)/) =~ s # assigns to a (%w();/(?<a>)/) =~ s # does not assigns (1; (2; 3; (4; /(?<a>)/))) =~ s # assigns to a (1+1; /(?<a>)/) =~ s # does not assign if ((cond1..cond2)); end # flipflop if (; cond1..cond2); end # range if (1; cond1..cond2); end # flipflop if (%s(); cond1..cond2); end # flipflop if (%w(); cond1..cond2); end # range if (1; (2; (3; 4; cond1..cond2))); end # flipflop if (1+1; cond1..cond2); end # range ~~~ I expect YARP and parse.y parses same. I expect all parenthesis-wrapped result same. I think it is simple and intuitive if parenthesis-wrapped code always behaves different from non-wrapped code because there are more complex variation like this ~~~ruby def (class A; 1; end).foo; end (break; /?<a>/) =~ s class A; /?<a>/; end =~ s ~~~ -- https://bugs.ruby-lang.org/

4 5

[ruby-core:114251] [Ruby master Bug#19779] `eval "return"` at top level raises `LocalJumpError`
by andrykonchin (Andrew Konchin) 07 Dec '23

07 Dec '23

Issue #19779 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #19779: `eval "return"` at top level raises `LocalJumpError` https://bugs.ruby-lang.org/issues/19779 * Author: andrykonchin (Andrew Konchin) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Wondering whether it's intentional behaviour. It seems it's the only difference I've noticed between calling `return` with and without `eval`: ``` ruby -e 'return' ruby -e 'eval "return"' (eval):1:in `<main>': unexpected return (LocalJumpError) from -e:1:in `eval' from -e:1:in `<main>' ``` -- https://bugs.ruby-lang.org/

4 3

[ruby-core:115462] [Ruby master Feature#20018] Get the error codes as Socket::EAI_XXX when getaddrinfo and getnameinfo fail
by shioimm (Misaki Shioi) 07 Dec '23

07 Dec '23

Issue #20018 has been reported by shioimm (Misaki Shioi). ---------------------------------------- Feature #20018: Get the error codes as Socket::EAI_XXX when getaddrinfo and getnameinfo fail https://bugs.ruby-lang.org/issues/20018 * Author: shioimm (Misaki Shioi) * Status: Open * Priority: Normal ---------------------------------------- Feature for implementing Happy Eyeballs version 2 (RFC 8305) in `Socket.tcp`. ### Probrem I would like to implement Happy Eyeballs version 2 (RFC 8305) in `Socket.tcp`. In HEv2, `EAI_ADDRFAMILY` and `EAI_AGAIN` should be ignored when `getaddrinfoo` returns them in hostname resolution. However, there is currently no way to ask `SocketError` for errors returned by `getaddrinfo` ### Proposal I opened a PR to get errors when `getaddrinfo` and `getnameinfo` returns them. https://github.com/ruby/ruby/pull/9018 Todo this, - I added `Socket::ResolutionError` as a subclass of `SocketError` - I added an attribute of `Socket::ResolutionError` to get error code via `#error_code - I replaced `SocketError` (`rb_eSocket`) with `Socket::ResolutionError (`rb_eResolutionError`) in `rsock_raise_socket_error` because this function is only called when `getaddrinfo` and `getnameinfo` fail - I renamed `rsock_raise_socket_error` to `rock_raise_resolution_error` for the same reason In addition, `Socket::ResolutionError` is a subclass of `SocketError`, so it does not affect `rescue SocketError` in source codes. -- https://bugs.ruby-lang.org/

2 1