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

[ruby-core:113059] [Ruby master Bug#19563] Ripper.tokenize(code).join != code when heredoc and multiline %w[] literal is on the same line
by tompng (tomoya ishida) 11 Apr '23

11 Apr '23

Issue #19563 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #19563: Ripper.tokenize(code).join != code when heredoc and multiline %w[] literal is on the same line https://bugs.ruby-lang.org/issues/19563 * Author: tompng (tomoya ishida) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-03-29T21:57:52Z master 1b06422767) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ~~~ruby Ripper.tokenize "<<EOF || %w[hello\nEOF\n\n\n\nworld]" # actual result ["<<EOF", " ", "||", " ", "%w[", "hello", "\n\n\n\n", "EOF\n", "world", "]"] # expected result ["<<EOF", " ", "||", " ", "%w[", "hello", "\n", "EOF\n", "\n\n\n", "world", "]"] ~~~ same for `%i[]` literal. -- https://bugs.ruby-lang.org/

3 5

[ruby-core:111956] [Ruby master Bug#19363] Fix rb_transient_heap_mark: wrong header (T_STRUCT) segfault
by bkuhlmann (Brooke Kuhlmann) 10 Apr '23

10 Apr '23

Issue #19363 has been reported by bkuhlmann (Brooke Kuhlmann). ---------------------------------------- Bug #19363: Fix rb_transient_heap_mark: wrong header (T_STRUCT) segfault https://bugs.ruby-lang.org/issues/19363 * Author: bkuhlmann (Brooke Kuhlmann) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) +YJIT [arm64-darwin22.2.0] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ## Overview Hello. 👋 I'm hitting an issue where my build is constantly failing with a segfault. The following is a snippet taken from my local machine with YJIT enabled (see attachments for details): ``` /Users/bkuhlmann/.cache/frum/versions/3.2.0/lib/ruby/gems/3.2.0/gems/puma-6.0.2/lib/puma/runner.rb: [BUG] rb_transient_heap_mark: wrong header, T_STRUCT (0x0000000109ea98a0) ruby 3.2.0 (2022-12-25 revision a528908271) +YJIT [arm64-darwin22.2.0] ``` The closest issue I could find that might be related to this issue (but not sure) is this issue: #15358. ## Steps to Recreate You should be able to quickly recreate this issue via these steps: - Download/clone my [Hemo](https://github.com/bkuhlmann/hemo) project. - Run the setup steps. - Run the test suite by running `bin/rspec`. If you need an example of the same segfault (but not on my macOS machine), you can see the same segfault via my [Circle CI Build](https://app.circleci.com/pipelines/github/bkuhlmann/hemo/11/workflow…. My Circle CI build is using my [Docker Alpine Linux Ruby](https://www.alchemists.io/projects/docker-alpine-ruby) image which might be of interest as well. This Docker image is also built with YJIT enabled. Interestingly, is if you were to run the test suite with `bin/guard` instead of `bin/rspec` then the segfault doesn't occur. ## Environment ``` ruby 3.2.0 (2022-12-25 revision a528908271) +YJIT [arm64-darwin22.2.0] 1.43.0 (using Parser 3.2.0.0, rubocop-ast 1.24.1, running on ruby 3.2.0) [arm64-darwin22.2.0] - rubocop-performance 1.15.2 - rubocop-rake 0.6.0 - rubocop-rspec 2.18.1 - rubocop-sequel 0.3.4 - rubocop-thread_safety 0.4.4 ``` ---Files-------------------------------- segfault.txt (237 KB) ruby-2023-01-21-113841.ips (19.6 KB) -- https://bugs.ruby-lang.org/

6 8

[ruby-core:113064] [Ruby master Bug#19566] OptionParser::on raises unsupported argument type: URI (ArgumentError) but shouldn't
by jgomo3 04 Apr '23

04 Apr '23

Issue #19566 has been reported by jgomo3 (Jesús Gómez). ---------------------------------------- Bug #19566: OptionParser::on raises unsupported argument type: URI (ArgumentError) but shouldn't https://bugs.ruby-lang.org/issues/19566 * Author: jgomo3 (Jesús Gómez) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The documentation says > OptionParser comes with a few ready-to-use kinds of type coercion. They are > .. > * URI – Anything accepted by URI.parse > But when I try to use the class `URI` as a coercion class: ``` op = OptionParser.new op.on("--uri URI", URI) ``` I get: `unsupported argument type: URI (ArgumentError)`. The workaround is to register it with `accept`: ``` op = OptionParser.new op.accept(URI, &URI.method(:parse)) op.on("--uri URI", URI) ``` I attached 2 files, the first one `ruby-op-uri-bug.rb` displays the Error. The second one, `ruby-op-uri-workaround.rb` show the proper output. ---Files-------------------------------- ruby-op-uri-bug.rb (340 Bytes) ruby-op-uri-bug-workaround.rb (377 Bytes) -- https://bugs.ruby-lang.org/

3 2

[ruby-core:112990] [Ruby master Bug#19545] lp/hp logic parsing inconsistency
by hurricup (Alexandr Evstigneev) 04 Apr '23

04 Apr '23

Issue #19545 has been reported by hurricup (Alexandr Evstigneev). ---------------------------------------- Bug #19545: lp/hp logic parsing inconsistency https://bugs.ruby-lang.org/issues/19545 * Author: hurricup (Alexandr Evstigneev) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- As far as i get it, low precedence logic should behave the same as high precedence. But: This is ok: ``` puts(false || !false) ``` And this is not: ``` puts(false or not false) ``` Feels like in latter case there is some mess with comma precedence. -- https://bugs.ruby-lang.org/

2 5

[ruby-core:112445] [Ruby master Bug#19441] Closing an IO#dup behaviour
by stac47 (Laurent Stacul) 03 Apr '23

03 Apr '23

Issue #19441 has been reported by stac47 (Laurent Stacul). ---------------------------------------- Bug #19441: Closing an IO#dup behaviour https://bugs.ruby-lang.org/issues/19441 * Author: stac47 (Laurent Stacul) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-darwin20] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Hello amazing ruby folks! I classified that ticket as a "Bug" although it is perhaps something I did not understand. Here is a ruby session: ``` ruby irb(main):001:0> file = Tempfile.new => #<File:/var/folders/m2/bljzrgq160vbf0vk466k_7gw0000gn/T/20230216-39664-davfmj> irb(main):002:0> file.fileno => 9 irb(main):003:0> dup = file.dup => #<File:/var/folders/m2/bljzrgq160vbf0vk466k_7gw0000gn/T/20230216-39664-davfmj> irb(main):004:0> dup.fileno => 10 irb(main):005:0> dup.close => nil irb(main):006:0> dup.closed? => false irb(main):007:0> file.closed? => true ``` The two last lines are unexpected to me. I would have expected the converse: ```ruby irb(main):006:0> dup.closed? => true irb(main):007:0> file.closed? => false ``` I tried this scenario in latest ruby but also in ruby 2.7. Thanks in advance for helping me to understand this behaviour. -- https://bugs.ruby-lang.org/

3 5

[ruby-core:113022] [Ruby master Bug#19548] Ambiguous and confusing syntax for alias/undef arguments
by hurricup (Alexandr Evstigneev) 03 Apr '23

03 Apr '23

Issue #19548 has been reported by hurricup (Alexandr Evstigneev). ---------------------------------------- Bug #19548: Ambiguous and confusing syntax for alias/undef arguments https://bugs.ruby-lang.org/issues/19548 * Author: hurricup (Alexandr Evstigneev) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This was introduced in https://bugs.ruby-lang.org/issues/8851 and looks really confusing at least because of bare `/`. Here are 3 semantically similar methods, but feels like first two should not be valid: ``` def method1 undef :*,<<,/,[] alias :* / end def method2 undef :*, <<, /, [] alias :* / end def method3 undef :* undef :<< undef :/ undef :[] alias :* :/ end puts RubyVM::InstructionSequence.of(method :method1).disasm puts RubyVM::InstructionSequence.of(method :method2).disasm puts RubyVM::InstructionSequence.of(method :method3).disasm ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:113061] [Ruby master Feature#19565] Ignore lower-case/upper-case Proposal
by rubyFeedback (robert heiler) 01 Apr '23

01 Apr '23

Issue #19565 has been reported by rubyFeedback (robert heiler). ---------------------------------------- Feature #19565: Ignore lower-case/upper-case Proposal https://bugs.ruby-lang.org/issues/19565 * Author: rubyFeedback (robert heiler) * Status: Open * Priority: Normal ---------------------------------------- So, first april is on the horizon and in-before-we-go (nobu tends to make quick first april proposals, so let's hurry up!) It is here proposed to ignore case, that is, lower-case, and upper-case, at the least for method calls. This could be for variables too, but I don't care so much about variables. Rationale for the proposal: Given a method such as primary_link I typoed and wrote: primary_LINK Of course ruby complains and insists it must be written "primary_link". (I use that method for ad-hoc HTML hyperreferences in a webpage.) Wouldn't it be nice if we are able to ignore this, and simply assume that, at the least for method names, ruby would ignore the case, that is, whether it is downcased/lowercased or upper cased? Granted, the proposal is about 85% meant as a jest and joke, but the 15% is that this MAY be useful in SOME situations. Kind of like we had in oldschool evil.rb; I distinctly remember we could even change object identities at runtime too (I don't know what happened to evil.rb, but I distinctly remember we had it during the ruby 1.8.x era or so). I actually only propose this to be used on a per-file basis, to simplify it. So, for instance, you have a .rb file, and in that .rb file you need to tell ruby that you want to ignore the case. This could perhaps be via some configuration-call, such as: RbConfig.ignore_case Or something similar. Or more similar to IRB where we treat RbConfig as a Hash via [] e. g. RbConfig[:ignore_case] = true Or something similar like that. Right now there is no method defined on RbConfig, so this should not cause backwards incompatibility issues. Of course one can reason that this is 100% a rubbish proposal. That's ok. Easier to suggest it when it is close to the first april. :) PHP works like this if I recall correctly. Windows also ignores cases of e. g. binaries and directories if I recall correctly. So while this proposal may be rubbish, and as stated more of a joke, I believe there may be a few potential use cases of this too. Kind of like the ruby user telling ruby "ruby, I know by default you look at the case of characters, but for this specific file or project, I want you to ignore the case". (We could extend this to a whole namespace, e. g. per-module and per-class, but for this proposal I want to keep it simpler and just focus on a per-file basis, that is, on a per .rb basis. We could also add more magic comments such as it was with "# frozen_string_literal: true", but I think the ruby core team does not want to add more meta-meaning, so this probably would have zero chance to be implemented. So the focus on a per .rb file basis just seemed simpler to me for this proposal here.) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:113032] [Ruby master Bug#19554] Invalid memory access detected by Valgrind when using Fibers
by peterzhu2118 (Peter Zhu) 31 Mar '23

31 Mar '23

Issue #19554 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #19554: Invalid memory access detected by Valgrind when using Fibers https://bugs.ruby-lang.org/issues/19554 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This issue was originally reported here: https://github.com/Shopify/ruby_memcheck/issues/14 Running the script shown below using `valgrind --trace-children=yes --num-callers=500 ruby test.rb` outputs a lot of invalid memory access errors. I've shown a few sample errors below. I am able to reproduce this issue on the master branch (commit [1e9a218ade](https://github.com/ruby/ruby/commit/1e9a218ade3af90c18f42e3fea0…) 3.2, 3.1, 3.0. ```ruby require "bundler/inline" gemfile do source "https://rubygems.org" gem "graphql" end module Example class FooType < GraphQL::Schema::Object field :id, ID, null: false end class FooSource < GraphQL::Dataloader::Source def fetch(ids) ids end end class QueryType < GraphQL::Schema::Object field :foo, Example::FooType do argument :foo_id, GraphQL::Types::ID, required: false, loads: Example::FooType end def foo(foo: nil); end end class Schema < GraphQL::Schema query Example::QueryType use GraphQL::Dataloader def self.object_from_id(id, ctx) ctx.dataloader.with(Example::FooSource).request(id) end end end Example::Schema.execute(<<-GRAPHQL) { foo(fooId: "Other") { id } } GRAPHQL ``` ``` ==203957== Use of uninitialised value of size 8 ==203957== at 0x3453FD: vm_exec_core (vm.inc:4411) ==203957== by 0x357EFB: rb_vm_exec (vm.c:2366) ==203957== by 0x354E44: invoke_block (vm.c:1384) ==203957== by 0x355759: invoke_iseq_block_from_c (vm.c:1440) ==203957== by 0x355759: invoke_block_from_c_proc (vm.c:1538) ==203957== by 0x355759: vm_invoke_proc (vm.c:1568) ==203957== by 0x355DF4: rb_vm_invoke_proc (vm.c:1589) ==203957== by 0x48F695: rb_fiber_start (cont.c:2513) ==203957== by 0x48CCF8: fiber_entry (cont.c:831) ==203957== ==203957== Invalid write of size 8 ==203957== at 0x48C407: fiber_pool_stack_reset (cont.c:325) ==203957== by 0x48C4E9: fiber_pool_vacancy_reset (cont.c:364) ==203957== by 0x48CBB0: fiber_pool_stack_release (cont.c:752) ==203957== by 0x48CECF: fiber_stack_release (cont.c:874) ==203957== by 0x48FC9F: fiber_switch (cont.c:2726) ==203957== by 0x4901F9: fiber_resume_kw (cont.c:2906) ==203957== by 0x490235: rb_fiber_resume_kw (cont.c:2912) ==203957== by 0x4903B7: rb_fiber_m_resume (cont.c:2973) ==203957== by 0x3337D6: ractor_safe_call_cfunc_m1 (vm_insnhelper.c:3166) ==203957== by 0x33440A: vm_call_cfunc_with_frame_ (vm_insnhelper.c:3357) ==203957== by 0x3345E1: vm_call_cfunc_with_frame (vm_insnhelper.c:3385) ==203957== by 0x3398E5: vm_sendish (vm_insnhelper.c:5225) ==203957== by 0x341203: vm_exec_core (insns.def:835) ==203957== by 0x357EFB: rb_vm_exec (vm.c:2366) ==203957== by 0x354E44: invoke_block (vm.c:1384) ==203957== by 0x355759: invoke_iseq_block_from_c (vm.c:1440) ==203957== by 0x355759: invoke_block_from_c_proc (vm.c:1538) ==203957== by 0x355759: vm_invoke_proc (vm.c:1568) ==203957== by 0x355DF4: rb_vm_invoke_proc (vm.c:1589) ==203957== by 0x48F695: rb_fiber_start (cont.c:2513) ==203957== by 0x48CCF8: fiber_entry (cont.c:831) ==203957== Address 0x9bad008 is in a rw- anonymous segment ``` -- https://bugs.ruby-lang.org/

3 5

[ruby-core:113041] [Ruby master Bug#19558] str.dump.undump crashes when str contains both Unicode and ASCII control characters
by ikaronen-relex (Ilmari Karonen) 30 Mar '23

30 Mar '23

Issue #19558 has been reported by ikaronen-relex (Ilmari Karonen). ---------------------------------------- Bug #19558: str.dump.undump crashes when str contains both Unicode and ASCII control characters https://bugs.ruby-lang.org/issues/19558 * Author: ikaronen-relex (Ilmari Karonen) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-03-29T10:20:29Z master 02ecdf85c5) [x86_64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Recently, as a result of a question I asked on Stack Overflow (https://stackoverflow.com/q/75866159) I learned about the existence of String#dump and String#undump. However, I also found what seems like a bug in them, in that apparently dumping and then undumping a string containing a sufficiently diverse selection of characters (such as at least one ASCII C0 control character and at least one non-ASCII Unicode character) causes the undump to raise a RuntimeError. Specifically, evaluating e.g. any of the following expressions: "\u0000\uFFFF".dump.undump "\u0001\uABCD".dump.undump "\u007F\u0080".dump.undump raises a RuntimeError with the message "hex escape and Unicode escape are mixed". This contradicts the documentation of String#undump, which says that it "does the inverse of String#dump." The behavior is the same on all Ruby versions I have tested this on, including master (3.3.0), 2.6.10 and JRuby 9.3.10.0. The obvious fix would be to simply remove the check for mixed hex and Unicode escape sequences, essentially reverting https://github.com/ruby/ruby/commit/05d1d29d1f4a87620371463d8c7942e170be031f. However, as I don't understand why the check is there in the first place, I'm also not sure if removing it could somehow have some unwanted consequences. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:113016] [Ruby master Bug#19547] `RubyVM::AST.parse("\\", keep_tokens: true)` dumps core
by mame (Yusuke Endoh) 30 Mar '23

30 Mar '23

Issue #19547 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #19547: `RubyVM::AST.parse("\\", keep_tokens: true)` dumps core https://bugs.ruby-lang.org/issues/19547 * Author: mame (Yusuke Endoh) * Status: Assigned * Priority: Normal * Assignee: yui-knk (Kaneko Yuichiro) * ruby -v: ruby 3.3.0dev (2023-03-25T08:17:05Z master 9bc2dbd33c) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ``` $ ./miniruby -e 'RubyVM::AbstractSyntaxTree.parse("\\", keep_tokens: true)' <internal:ast>:59: [BUG] parser_token2id: unknown token 92 ruby 3.3.0dev (2023-03-25T08:17:05Z master 9bc2dbd33c) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0003 p:0003 s:0015 e:000014 METHOD <internal:ast>:59 c:0002 p:0008 s:0006 e:000005 EVAL -e:1 [FINISH] c:0001 p:0000 s:0003 E:001db0 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- -e:1:in `<main>' <internal:ast>:59:in `parse' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- /home/mame/work/ruby/miniruby(rb_print_backtrace+0xd) [0x55ee562be9be] /home/mame/work/ruby/vm_dump.c:785 /home/mame/work/ruby/miniruby(rb_vm_bugreport) /home/mame/work/ruby/vm_dump.c:1101 /home/mame/work/ruby/miniruby(bug_report_end+0x0) [0x55ee560ab94f] /home/mame/work/ruby/error.c:790 /home/mame/work/ruby/miniruby(rb_bug_without_die) /home/mame/work/ruby/error.c:790 /home/mame/work/ruby/miniruby(die+0x0) [0x55ee560092a1] /home/mame/work/ruby/error.c:798 /home/mame/work/ruby/miniruby(rb_bug) /home/mame/work/ruby/error.c:800 /home/mame/work/ruby/miniruby(rb_long2int_inline+0x0) [0x55ee5600a925] /home/mame/work/ruby/parse.y:630 /home/mame/work/ruby/miniruby(add_delayed_token) /home/mame/work/ruby/parse.y:7008 /home/mame/work/ruby/miniruby(add_delayed_token) /home/mame/work/ruby/parse.y:6997 /home/mame/work/ruby/miniruby(parser_dispatch_scan_event+0x25) [0x55ee56174855] /home/mame/work/ruby/parse.y:6222 /home/mame/work/ruby/miniruby(parser_dispatch_scan_event) /home/mame/work/ruby/parse.y:6212 /home/mame/work/ruby/miniruby(yylex+0xf) [0x55ee56184173] /home/mame/work/ruby/parse.y:10492 /home/mame/work/ruby/miniruby(ruby_yyparse) /home/mame/work/ruby/parse.c:9357 /home/mame/work/ruby/miniruby(yycompile0+0xf9) [0x55ee561954c9] /home/mame/work/ruby/parse.y:6767 /home/mame/work/ruby/miniruby(rb_suppress_tracing+0x10c) [0x55ee562c369c] /home/mame/work/ruby/vm_trace.c:483 /home/mame/work/ruby/miniruby(yycompile+0x55) [0x55ee5617b76c] /home/mame/work/ruby/parse.y:6824 /home/mame/work/ruby/miniruby(parser_compile_string) /home/mame/work/ruby/parse.y:6892 /home/mame/work/ruby/miniruby(rb_parser_compile_string_path) /home/mame/work/ruby/parse.y:6905 /home/mame/work/ruby/miniruby(ast_parse_done+0x0) [0x55ee560279a8] /home/mame/work/ruby/ast.c:103 /home/mame/work/ruby/miniruby(rb_ast_parse_str) /home/mame/work/ruby/ast.c:104 /home/mame/work/ruby/miniruby(ast_s_parse) /home/mame/work/ruby/ast.c:90 /home/mame/work/ruby/miniruby(invoke_bf+0x12) [0x55ee562ae7fe] /home/mame/work/ruby/vm_insnhelper.c:6414 /home/mame/work/ruby/miniruby(vm_invoke_builtin_delegate) /home/mame/work/ruby/vm_insnhelper.c:6441 /home/mame/work/ruby/miniruby(vm_exec_core) /home/mame/work/ruby/insns.def:1526 /home/mame/work/ruby/miniruby(rb_vm_exec+0x938) [0x55ee562a14e8] /home/mame/work/ruby/vm.c:2366 /home/mame/work/ruby/miniruby(rb_ec_exec_node+0xb1) [0x55ee560b0ff1] /home/mame/work/ruby/eval.c:287 /home/mame/work/ruby/miniruby(ruby_run_node+0x4c) [0x55ee560b634c] /home/mame/work/ruby/eval.c:328 /home/mame/work/ruby/miniruby(rb_main+0x21) [0x55ee560126c6] ./main.c:39 /home/mame/work/ruby/miniruby(main) ./main.c:58 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_call_main+0x80) [0x7fdc30c23510] ../sysdeps/nptl/libc_start_call_main.h:58 /lib/x86_64-linux-gnu/libc.so.6(call_init+0x0) [0x7fdc30c235c9] ../csu/libc-start.c:381 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main_impl) ../csu/libc-start.c:368 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main) (null):0 [0x55ee56012715] ``` -- https://bugs.ruby-lang.org/

2 1