October 2024 - ruby-core - ml.ruby-lang.org

[ruby-core:117968] [Ruby master Bug#20501] ruby SEGV
by akr (Akira Tanaka) 04 Nov '24

04 Nov '24

Issue #20501 has been reported by akr (Akira Tanaka). ---------------------------------------- Bug #20501: ruby SEGV https://bugs.ruby-lang.org/issues/20501 * Author: akr (Akira Tanaka) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I encountered SEGV of ruby. ``` % ./ruby -v ruby 3.4.0dev (2024-05-22T06:59:19Z master 5613d6e95b) [x86_64-linux] % ./ruby t.rb t.rb:33: [BUG] Segmentation fault at 0x00007fc243696098 ruby 3.4.0dev (2024-05-22T06:59:19Z master 5613d6e95b) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0003 p:0000 s:4294967313 e:000018 METHOD t.rb:33 c:0002 p:0022 s:0006 e:000005 EVAL t.rb:52 [FINISH] c:0001 p:0000 s:0003 E:000350 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- t.rb:52:in '<main>' t.rb:33:in 'create_no_file' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ RIP: 0x000055a1cdc8bb9c RBP: 0x000055a1cee844b0 RSP: 0x00007ffcde5cdae0 RAX: 0x00007fc2436960a0 RBX: 0x00007fba43795f68 RCX: 0x0000000000000000 RDX: 0x000055a1cf115cf0 RDI: 0x0000000000000009 RSI: 0x00007fba28526860 R8: 0x00007fba436960a1 R9: 0x0000000000000000 R10: 0x00007fba28526860 R11: 0x0000000000000003 R12: 0x0000000000000006 R13: 0x00007fba2853b698 R14: 0x0000000d00000009 R15: 0x0000000000000b21 EFL: 0x0000000000010246 -- C level backtrace information ------------------------------------------- /home/ruby/t2/ruby/ruby(rb_print_backtrace+0x14) [0x55a1cdcae243] /home/ruby/t2/ruby/vm_dump.c:820 /home/ruby/t2/ruby/ruby(rb_vm_bugreport) /home/ruby/t2/ruby/vm_dump.c:1151 /home/ruby/t2/ruby/ruby(rb_bug_for_fatal_signal+0xf8) [0x55a1cde5abe8] /home/ruby/t2/ruby/error.c:1108 /home/ruby/t2/ruby/ruby(sigsegv+0x44) [0x55a1cdbf7864] /home/ruby/t2/ruby/signal.c:929 /lib/x86_64-linux-gnu/libc.so.6(0x7fba438f8050) [0x7fba438f8050] /home/ruby/t2/ruby/ruby(vm_exec_handle_exception+0x2ac) [0x55a1cdc8bb9c] /home/ruby/t2/ruby/vm.c:2782 ... ``` `t.rb` and the full crash report are attached. ---Files-------------------------------- t.rb (1.27 KB) crash.txt (15.8 KB) -- https://bugs.ruby-lang.org/

7 14

[ruby-core:119406] [Ruby master Bug#20777] 3.3: `RUBY_DESCRIPTION` is corrupt when `--yjit` and `--parser=prism`
by nobu (Nobuyoshi Nakada) 04 Nov '24

04 Nov '24

Issue #20777 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #20777: 3.3: `RUBY_DESCRIPTION` is corrupt when `--yjit` and `--parser=prism` https://bugs.ruby-lang.org/issues/20777 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: REQUIRED ---------------------------------------- Note the last garbages. ```shell-session $ ruby3.3 -W0 --yjit --parser=prism -e 'p RUBY_DESCRIPTION' "ruby 3.3.5 (2024-09-03 revision ef084cc8f4) +YJIT +PRISM [arm64-darwin\x00\x00\x00" ``` commit:76ea5cde2a0f4834a5228104249b6b3346ddfc94 is needed. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:119124] [Ruby master Bug#20723] `IO#close` is broken on Ruby 3.3+ when using the Fiber scheduler.
by ioquatix (Samuel Williams) 04 Nov '24

04 Nov '24

Issue #20723 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #20723: `IO#close` is broken on Ruby 3.3+ when using the Fiber scheduler. https://bugs.ruby-lang.org/issues/20723 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: kjtsanaktsidis (KJ Tsanaktsidis) * Backport: 3.3: REQUIRED ---------------------------------------- The following program seems to work okay on Ruby 3.2 but hangs on Ruby 3.3: ```ruby #!/usr/bin/env ruby require 'bundler/inline' gemfile do source 'https://rubygems.org' gem 'async' end require 'socket' def close_while_reading(io) thread = Thread.new do Thread.current.report_on_exception = false io.wait_readable end # Wait until the thread is blocked on read: Thread.pass until thread.status == "sleep" Async do io.close end thread.join end begin client, server = Socket.pair(:UNIX, :STREAM) close_while_reading(client) rescue => error $stderr.puts error.full_message end ``` -- https://bugs.ruby-lang.org/

3 5

[ruby-core:119117] [Ruby master Bug#20721] Gem executables have a .lock file in Ruby 3.3.5
by k0kubun (Takashi Kokubun) 04 Nov '24

04 Nov '24

Issue #20721 has been reported by k0kubun (Takashi Kokubun). ---------------------------------------- Bug #20721: Gem executables have a .lock file in Ruby 3.3.5 https://bugs.ruby-lang.org/issues/20721 * Author: k0kubun (Takashi Kokubun) * Status: Closed * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: REQUIRED ---------------------------------------- With Ruby 3.3.5, every gem executable under `$prefix/bin` has a `.lock` file. This is [an unintended change](https://github.com/ruby/ruby/pull/11252#issuecomment-2337520641), which was fixed in rubygems master at https://github.com/rubygems/rubygems/pull/7939. I filed this ticket to make sure we backport that before the Ruby 3.3.6 release. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:119091] [Ruby master Bug#20718] Objects created with Data_Make_Struct and the default free function are not freed
by jcalvert (Jonathan Calvert) 04 Nov '24

04 Nov '24

Issue #20718 has been reported by jcalvert (Jonathan Calvert). ---------------------------------------- Bug #20718: Objects created with Data_Make_Struct and the default free function are not freed https://bugs.ruby-lang.org/issues/20718 * Author: jcalvert (Jonathan Calvert) * Status: Open * ruby -v: ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I discovered a memory leak when using the FFI gem prior to version 1.16 and Ruby 3.3 and up. During debugging I found that this earlier version of FFI uses Data_Make_Struct (https://github.com/ffi/ffi/blob/v1.15.5/ext/ffi_c/Pointer.c#L57) instead of TypedData_Make_Struct and it uses -1 as the free function, which is RUBY_DEFAULT_FREE When the object goes to get garbage collected, it enters into rb_data_free and it is passed to the RTYPEDDATA_EMBEDDED_P macro even though it is not of RTypedData. Because of that, the conditional is evaluated to false and xfree is never called. This was discovered by using jemalloc leak detection. I have attached a somewhat minimal replication of the issue. The fix would appear to check the type of the obj before casting it. ---Files-------------------------------- pointer_bug.rb (418 Bytes) Gemfile.txt (104 Bytes) -- https://bugs.ruby-lang.org/

3 3

[ruby-core:119649] [Ruby master Bug#20856] Incorrect and inconsistent multi-thread eval execution
by hurricup (Alexandr Evstigneev) 04 Nov '24

04 Nov '24

Issue #20856 has been reported by hurricup (Alexandr Evstigneev). ---------------------------------------- Bug #20856: Incorrect and inconsistent multi-thread eval execution https://bugs.ruby-lang.org/issues/20856 * Author: hurricup (Alexandr Evstigneev) * Status: Open * ruby -v: 3.4.0-preview2 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Consider example: ``` s = Thread.new { a = 5 puts eval("a == b") x = 6 } s.join b = 11 ``` As far as I see it, it should not work. Because at the moment of eval, b is unknown and not even declared (it can even be in condition). But it may be available because file `iseq` already compiled and we know that there is b. So, this works in ruby 3.3 in a script we running, wrapped into the method, or required by other file. But in 3.4-preview2: - it works in file - it works in method - it fails if required from other file with: ``` #<Thread:0x00007725530d6a98 /home/hurricup/Projects/ruby-debugger/rdi30/test2.rb:1 run> terminated with exception (report_on_exception is true): (eval at /home/hurricup/Projects/ruby-debugger/rdi30/test2.rb:3):1:in 'block in <top (required)>': undefined local variable or method 'b' for main (NameError) from /home/hurricup/Projects/ruby-debugger/rdi30/test2.rb:3:in 'Kernel#eval' from /home/hurricup/Projects/ruby-debugger/rdi30/test2.rb:3:in 'block in <top (required)>' (eval at /home/hurricup/Projects/ruby-debugger/rdi30/test2.rb:3):1:in 'block in <top (required)>': undefined local variable or method 'b' for main (NameError) from /home/hurricup/Projects/ruby-debugger/rdi30/test2.rb:3:in 'Kernel#eval' from /home/hurricup/Projects/ruby-debugger/rdi30/test2.rb:3:in 'block in <top (required)>' ``` And this ^^ is correct behavior if you ask me :) but atm it is inconsistent between the ruby versions and even in the scope of 3.4-preview2 -- https://bugs.ruby-lang.org/

3 4

[ruby-core:119121] [Ruby master Bug#20722] curious search result order on docs.ruby-lang.org
by masterleep2 (Bill Lipa) 01 Nov '24

01 Nov '24

Issue #20722 has been reported by masterleep2 (Bill Lipa). ---------------------------------------- Bug #20722: curious search result order on docs.ruby-lang.org https://bugs.ruby-lang.org/issues/20722 * Author: masterleep2 (Bill Lipa) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- If you search for "String" on https://docs.ruby-lang.org/en/3.3/ the first four results returned are obscure: 1. Gem::SafeMarshal::Elements::String 2. Prism::StringFlags 3. Prism::StringNode 4. Reline::Terminfo::StringWithTiparm 5. String Would it be possible to change it so that if one types an exact class name, the class of that name is first on the list? This would make it easier to use the search feature. More generally, the prioritization of these results is surprising. Not sure if this is the right place to report a doc website issue. Apologies if not. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:119637] Behavior of raising from rescue blocks when multiple rescue blocks exist
by Rodrigo Rosenfeld Rosas 29 Oct '24

29 Oct '24

Hello, I couldn't find any documentation about the subject, so I thought this behavior should be probably documented. Given the following code: def raise_error raise "runtime error message" rescue => e "StandardError: #{e.message}" rescue RuntimeError => e puts "RuntimeError raised: #{e.message}" raise StandardError, "standard error message" end # same, but the order of the rescue blocks are inverted def raise_error2 raise "runtime error message" rescue RuntimeError => e puts "RuntimeError raised: #{e.message}" raise StandardError, "standard error message" rescue => e "StandardError: #{e.message}" end p ["raise_error", raise_error ] begin p ["raise_error2", raise_error2] rescue => e puts "raise_error2 raised: #{e.message}" end When we run it, this is the output in Ruby 3.3.5: ["raise_error", "StandardError: runtime error message"] RuntimeError raised: runtime error message raise_error2 raised: standard error message In the first case (raise_error), the code raised from the RuntimeError rescue block is rescued by the StandardError block, but when inverting the order of the rescue blocks (raise_error2) then this won't happen. Is this part of the specs? Is this behavior documented somewhere? Could this behavior differ in different Ruby implementations and versions? Or can we rely on such behavior? This chapter doesn't include such case in its examples: https://ruby-doc.com/docs/ProgrammingRuby/html/tut_exceptions.html Or this documentation about Exceptions: https://ruby-doc.org/3.3.5/syntax/exceptions_rdoc.html Is there a recommended way for wrapping exceptions into a particular one and then handling that exception from within the same method rescue blocks? Or is this considered a bad practice?

2 2

[ruby-core:119613] [Ruby master Misc#20814] iseq optimizations on constant condition
by hurricup (Alexandr Evstigneev) 29 Oct '24

29 Oct '24

Issue #20814 has been reported by hurricup (Alexandr Evstigneev). ---------------------------------------- Misc #20814: iseq optimizations on constant condition https://bugs.ruby-lang.org/issues/20814 * Author: hurricup (Alexandr Evstigneev) * Status: Open ---------------------------------------- ruby 3.4-preview2 seems optimizes out some stuff when building iseq and this may lead to user unexpected behavior when debugging, because some lines just optimized out. Example: ``` def foo1 if true nil else 1 end end ``` produces: ``` == disasm: #<ISeq:foo1@/test.rb:1 (1,0)-(7,3)> 0000 putnil ( 3)[LiCa] 0001 leave ( 7)[Re] ``` Two questions: - is there way to disable such optimizations? - are there some specs on things that can be optimized. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:119633] [Ruby master Bug#20819] IO#readline does not process newlines correctly for non-ASCII compatible encodings
by javanthropus (Jeremy Bopp) 28 Oct '24

28 Oct '24

Issue #20819 has been reported by javanthropus (Jeremy Bopp). ---------------------------------------- Bug #20819: IO#readline does not process newlines correctly for non-ASCII compatible encodings https://bugs.ruby-lang.org/issues/20819 * Author: javanthropus (Jeremy Bopp) * Status: Open * ruby -v: ruby 3.3.4 (2024-07-09 revision be1089c8ec) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- When not performing character conversion, IO#readline only processes newline characters as ASCII when reading paragraphs. However, when character conversion is involved, even when converting between 2 ASCII incompatible encodings, newline handling is correct. ```ruby require "tempfile" Tempfile.open(binmode: true) do |f| f.set_encoding("utf-16le") f.write("\n\n\n\nhello\n\nworld") f.rewind # No character conversion case. # Expecting "hello\n\n".encode(Encoding::UTF_16LE) f.readline("") # => "\0".force_encoding(Encoding::UTF_16LE) + "\n\n\nhello\n\nworld".encode(Encoding::UTF_16LE) f.set_encoding("utf-16le:utf-32le") f.rewind # Character conversion case. f.readline("") # => "hello\n\n".encode(Encoding::UTF_32LE) end ``` In the failing case, a newline character appears in the first byte of the input due to the UTF-16LE encoding. This is discarded per the normal behavior of reading paragraphs, but the following null byte is not consumed as required to consume the entire newline character in UTF-16LE encoding. This leads to a leading and invalid null byte in the output of IO#readline. Furthermore, the newlines between "hello" and "world" are not seen as a pair of newline characters sufficient to end the first paragraph because they are not ASCII newlines and instead have a null byte between them. -- https://bugs.ruby-lang.org/

1 0