Issue #19284 has been reported by zeke (Zeke Gabrielse).
----------------------------------------
Bug #19284: Integer overflow when using RUBY_GC_HEAP_INIT_SLOTS environment variable
https://bugs.ruby-lang.org/issues/19284
* Author: zeke (Zeke Gabrielse)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) [x86_64-darwin19]
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
If you set the environment variable `RUBY_GC_HEAP_INIT_SLOTS` to anything other than `0`, an integer overflow runtime error occurs:
```ruby
RUBY_GC_HEAP_INIT_SLOTS=2 ruby -e 'puts "hello, world!"'
# => integer overflow: 3689348814741910508 * 8 > 18446744073709551615 (RuntimeError)
```
At this time, I'm not sure if this is platform-specific.
--
https://bugs.ruby-lang.org/
Issue #19320 has been reported by peterzhu2118 (Peter Zhu).
----------------------------------------
Bug #19320: Crash during compaction while traversing the stack
https://bugs.ruby-lang.org/issues/19320
* Author: peterzhu2118 (Peter Zhu)
* Status: Open
* Priority: Normal
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
Fix PR: https://github.com/ruby/ruby/pull/7081
Applying the following patch to test/erb/test_erb.rb and running that file will cause Ruby to crash on my machine (macOS 13.1 on M1 Pro):
```diff
--- a/test/erb/test_erb.rb
+++ b/test/erb/test_erb.rb
@@ -7,6 +7,12 @@
class TestERB < Test::Unit::TestCase
class MyError < RuntimeError ; end
+ def setup
+ GC.auto_compact = true
+ GC.stress = true
+ GC.verify_compaction_references(expand_heap: true, toward: :empty)
+ end
+
```
It crashes with the following log:
```
/Users/peter/src/ruby/lib/erb/compiler.rb:276: [BUG] Segmentation fault at 0x00000001083a8690
...
-- C level backtrace information -------------------------------------------
...
/Users/peter/src/ruby/build/ruby(rb_vm_each_stack_value+0xa8) [0x104cc3a44] ../vm.c:2737
/Users/peter/src/ruby/build/ruby(rb_vm_each_stack_value+0xa8) [0x104cc3a44] ../vm.c:2737
/Users/peter/src/ruby/build/ruby(check_stack_for_moved+0x2c) [0x104b272a4] ../gc.c:5512
/Users/peter/src/ruby/build/ruby(gc_compact_finish) ../gc.c:5534
/Users/peter/src/ruby/build/ruby(gc_sweep_compact) ../gc.c:8653
/Users/peter/src/ruby/build/ruby(gc_sweep) ../gc.c:6196
/Users/peter/src/ruby/build/ruby(has_sweeping_pages+0x0) [0x104b19c54] ../gc.c:9568
/Users/peter/src/ruby/build/ruby(gc_rest) ../gc.c:9570
```
This crash happens because it's reading the VALUE at sp. But since sp points to the top of the stack, it's reading the VALUE above the top of the stack, which is causing this segfault.
I can repro this crash in Ruby 3.2.0, but looking at the code I think it can happen in Ruby 3.1 and 3.0 as well.
--
https://bugs.ruby-lang.org/
Issue #19292 has been reported by matsuda (Akira Matsuda).
----------------------------------------
Bug #19292: Time object's wday, yday, and isdst returns broken value (and so does to_a) when kwarg in: 'UTC' was given
https://bugs.ruby-lang.org/issues/19292
* Author: matsuda (Akira Matsuda)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.3.0dev (2022-12-30T15:31:50Z master 0bb07e5ba4) +YJIT [arm64-darwin21]
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
$ ruby -e "p Time.new(2023, 1, 1, 0, 0, 0, in: 'UTC').wday"
7
$ ruby -e "p Time.new(2023, 1, 1, 0, 0, 0, in: 'UTC').yday"
0
$ ruby -e "p Time.new(2023, 1, 1, 0, 0, 0, in: 'UTC').isdst"
-e:1:in `isdst': isdst is not set yet (RuntimeError)
from -e:1:in `<main>'
$ ruby -e "p Time.new(2023, 1, 1, 0, 0, 0, in: 'UTC').to_a"
[0, 0, 0, 1, 1, 2023, 7, 0, true, "UTC"]
where the expected `to_a` value should be:
[0, 0, 0, 1, 1, 2023, 0, 1, false, "UTC"]
This bug seems to be happening on the following conditions:
- On any given date and time, regardless of past or future
- Either on `Time.new(Integer, Integer, ...)` style or `Time.new(String)` style
- Only when `in: 'UTC'` kwarg was given. Other formats like `in: '+0000'` or `in: 0` seems to be OK
- On all Ruby versions that accept kwarg `in:` (3.1, 3.2, and 3.3)
--
https://bugs.ruby-lang.org/
Issue #19377 has been reported by zverok (Victor Shepelev).
----------------------------------------
Feature #19377: Rename Fiber#storage to Fiber.storage
https://bugs.ruby-lang.org/issues/19377
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
----------------------------------------
Justification:
* `#storage`, which pretends to be an instance method, is always available only on `Fiber.current`, which is [problematic to document](https://github.com/ruby/ruby/pull/6985#discussion_r1055796069), and needs special handling when `storage` is called for non-current Fiber;
* with class method + docs "storage of the current fiber" it all will be self-evident;
* Most of the time, when we declare methods that are available only in the current {something}, they are class methods. (like storage's itself interface of `Fiber::[]` and `Fiber::[]=`, or `Module.used_modules`, which is modules and refinements of the _current context_, but it is not `self.used_modules`, for example)
* Code like
```ruby
Fiber.current.storage = {foo: 'bar'}
Fiber[:foo]
```
...looks like it is two unrelated things (storage of the _current_ fiber vs some "global" key getter/setter?)
I don't see much discussion of this in #19078. Matz in 19078#note-22, while accepting the interface, describes it as homogenous:
> (1) fiber[key]/fiber[key]=val - accepted.
> (2) fiber.storage => hash - accepted
> (3) fiber.storage=hash - should be experimental
> ...
So I believe it should be either `Fiber.current[]` and `Fiber.current.storage`, or `Fiber[]`, and `Fiber.storage`. The latter is preferable to underline it is only one, related to the current fiber, interface, not "every fiber instance has one (but actually you can use only `current`'s)
--
https://bugs.ruby-lang.org/
Issue #19383 has been reported by stringsn88keys (Thomas Powell).
----------------------------------------
Bug #19383: Time.now.zone encoding for German display language in Windows is incorrect
https://bugs.ruby-lang.org/issues/19383
* Author: stringsn88keys (Thomas Powell)
* Status: Open
* Priority: Normal
* ruby -v: 3.1.3
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
OS:
Verified on Windows 10 and Windows Server 2022 and Ruby 2.7.7 through 3.1.3
Display language:
Verified on German, but may impact other languages in which Time.now.zone returns characters that aren't [A-Za-z].
Time zone:
CET (UTC +01:00) Amsterdam, Berlin, ...
Time.now.zone # => "Mitteleuro\xE3ische Zeit"
Time.now.zone.encoding # => #<Encoding:IBM437>
puts Time.now.zone # => "Mitteleurop∑ische Zeit" (should be "Mitteleuropäische Zeit")
Time.now.zone.encode(Encoding::UTF_8) # => "Mitteleurop∑ische Zeit"
Doing a force_encoding on all encodings in Encoding.list reveals that ISO-8859-(1..16) and Windows-125(0,2,4,7) work to coerce the ä out of the time zone string:
Time.now.zone.force_encoding(Encoding::WINDOWS_1252) # => "Mitteleuro\xE3ische Zeit"
... but ...
Time.now.zone.force_encoding(Encoding::WINDOWS_1252).encode(Encoding::UTF_8) #=> "Mitteleuropäische Zeit"
Related issue: This improper encoding/rendering caused Ohai's JSON output to be unparseable. Workaround was forcing to Windows-1252.
https://github.com/chef/ohai/pull/1781
--
https://bugs.ruby-lang.org/
Issue #19378 has been reported by aidog (Andi Idogawa).
----------------------------------------
Bug #19378: Windows: Use less syscalls for faster require of big gems
https://bugs.ruby-lang.org/issues/19378
* Author: aidog (Andi Idogawa)
* Status: Open
* Priority: Normal
* ruby -v: 3.2.0
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
Hello 🙂
## Problem
require is slow on windows for big gems. (example: require 'gtk3'=> 3 seconds+). This is a problem for people who want to make cross platform GUI apps with ruby.
## Possible Reason
As touched on in [#15797](https://bugs.ruby-lang.org/issues/15797) it seems like require uses realpath, which is emulated on windows. It checks every parent directory. The same syscalls run many times.
## Testfile
C:\tmp\speedtest\testrequire.rb:
``` ruby
require __dir__ + "/helloworld1.rb"
require __dir__ + "/helloworld2.rb"
```
``` shell
ruby --disable-gems C:\tmp\speedtest\testrequire.rb
```
### Syscalls per File/Directory:
1. CreateFile
2. QueryInformationVolume
3. QueryIdInformation
4. QueryAllInformationFile
5. QueryNameInformationFile
6. QueryNameInformationFile
7. QueryNormalizedNameInformationFile
8. CloseFile
### Files/Directories checked
1. C:\tmp
2. C:\tmp\speedtest
3. C:\tmp\speedtest\helloworld1.rb
4. C:\tmp
5. C:\tmp\speedtest
6. C:\tmp\speedtest\helloworld2.rb
For two required files Ruby had to do 8*6 = **48** syscalls.
The syscalls orginate from rb_w32_reparse_symlink_p / lstat
Rubygems live in subfolders with 9+ parts: "C:\Ruby32-x64\lib\ruby\gems\3.2.0\gems\glib2-4.0.8\lib\glib2\variant.rb"
Each file takes 8 * 9 = **72**+ calls. For variant.rb it is **80** calls.
The result for the syscalls don't change in such a short time, so it should be possible to cache it.
With require_relative it's twice as many calls.
## Other testcases
Same result:
``` ruby
File.realpath __dir__ + "/helloworld1.rb"
File.realpath __dir__ + "/helloworld2.rb"
```
``` ruby
File.stat __dir__ + "/helloworld1.rb"
File.stat __dir__ + "/helloworld2.rb"
```
It does not happen in $LOAD_PATH.resolve_feature_path(__dir__ + "/helloworld1.rb")
## Request
Would it be possible to cache the stat calls when using require?
I tried to implement a cache inside the ruby source code, but failed.
If not, is there now a way to combine ruby files into one?
I previously talked about require here: [YJIT: Windows support lacking.](https://bugs.ruby-lang.org/issues/19325#note-11)
## How to reproduce
Ruby versions: At least 3.0+, most likely older ones too.
Tested using Ruby Installer 3.1 and 3.2.
[Procmon Software by Sysinternals](https://learn.microsoft.com/en-us/sysinternals/downloads/proc…
--
https://bugs.ruby-lang.org/