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

[ruby-core:114876] [Ruby master Bug#14480] miniruby crashing when compiled with -O2 or -O1 on aarch64
by vo.x (Vit Ondruch) 22 Sep '23

22 Sep '23

Issue #14480 has been updated by vo.x (Vit Ondruch). Please note that on Fedora this was not issue for past ~5 years. This has beend workarounded on GCC side: https://bugzilla.redhat.com/show_bug.cgi?id=1545239#c42 And it seems that the GCC folks position is that this should behave consistently everywhere. So I am not sure why the PR above extends the special casing of some platforms instead of removing it. ---------------------------------------- Bug #14480: miniruby crashing when compiled with -O2 or -O1 on aarch64 https://bugs.ruby-lang.org/issues/14480#change-104727 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 2.5.0p0 (2017-12-25 revision 61468) [aarch64-linux] * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- Recently, it is not possible to build Ruby 2.5.0 on aarch64 on Fedora Rawhide, because miniruby fails during build: ~~~ ... snip ... ./miniruby -I./lib -I. -I.ext/common -n \ -e 'BEGIN{version=ARGV.shift;mis=ARGV.dup}' \ -e 'END{abort "UNICODE version mismatch: #{mis}" unless mis.empty?}' \ -e '(mis.delete(ARGF.path); ARGF.close) if /ONIG_UNICODE_VERSION_STRING +"#{Regexp.quote(version)}"/o' \ 10.0.0 ./enc/unicode/10.0.0/casefold.h ./enc/unicode/10.0.0/name2ctype.h generating encdb.h ./miniruby -I./lib -I. -I.ext/common ./tool/generic_erb.rb -c -o encdb.h ./template/encdb.h.tmpl ./enc enc generating prelude.c ./miniruby -I./lib -I. -I.ext/common ./tool/generic_erb.rb -I. -c -o prelude.c \ ./template/prelude.c.tmpl ./prelude.rb ./gem_prelude.rb ./abrt_prelude.rb *** stack smashing detected ***: <unknown> terminated encdb.h updated ... snip ... ~~~ This might by Ruby or gcc issue. Not sure yet. However, there is already lengthy analysis available in Fedora's Bugzilla [1]. Would be anybody able to help to resolve this issue? [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1545239 ---Files-------------------------------- Dockerfile (573 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114874] [Ruby master Bug#19897] Please backport fixes from #18914 into Ruby 3.1 / 3.0
by vo.x (Vit Ondruch) 22 Sep '23

22 Sep '23

Issue #19897 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #19897: Please backport fixes from #18914 into Ruby 3.1 / 3.0 https://bugs.ruby-lang.org/issues/19897 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I cannot modify the backport field anymore, therefore please backport the fixes from #18914 to Ruby 3.1 / 3.0. Ruby 3.2 should already contain the fixes. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:114796] [Ruby master Feature#19889] Let `Kernel.#require` search for files relative to the current working directory for non ./, ../ relative paths
by sawa (Tsuyoshi Sawada) 22 Sep '23

22 Sep '23

Issue #19889 has been reported by sawa (Tsuyoshi Sawada). ---------------------------------------- Feature #19889: Let `Kernel.#require` search for files relative to the current working directory for non ./, ../ relative paths https://bugs.ruby-lang.org/issues/19889 * Author: sawa (Tsuyoshi Sawada) * Status: Open * Priority: Normal ---------------------------------------- My understanding is that `./` and `../` in the given path argument are interpreted relative to: (1) * The current working directory (for `load` or `require`) * The requiring file's path (for `require_relative`) which shows a division of labor between the methods, and seems reasonable. However, when it comes to other relative paths (e.g., `foo/bar.rb`), they are interpreted relative to: (2) * Paths in `$LOAD_PATH` (for `require`) * Paths in `$LOAD_PATH` or **the current working directory** (for `load` or `require_relative`) The search path in (2) for `require` is a proper subset of that of `load` and `require_relative`. There is no division of labor here; there is only inconvenience for `require`. Furthermore, in (1), `require` (as well as `load`) is concerned with the current working directory while `require_relative` is not, but in (2), the relation is reversed: `require_relative` (as well as `load`) is concerned with the current working directory while `require` is not. This situation is making the specification of `relative` versus `require_relative` difficult to understand, as well as inconvenience. **Proposal**: For non-`./`-or-`../` relative paths, I propose to let `Kernel.#require` search relative to the current working directory if the file is not found relative to the paths in `$LOAD_PATH`, so that the methods `load`, `require`, and `require_relative` all work the same in this respect. -- https://bugs.ruby-lang.org/

4 5

[ruby-core:114869] [Ruby master Feature#13933] Add Range#empty?
by duerst 22 Sep '23

22 Sep '23

Issue #13933 has been updated by duerst (Martin Dürst). Dan0042 (Daniel DeLorme) wrote in #note-9: > because `true<=>true` is 0 (and arguably it should be nil but that's another topic). Are you saying that true shouldn't be equal to true? That would be strange, at least to me. ---------------------------------------- Feature #13933: Add Range#empty? https://bugs.ruby-lang.org/issues/13933#change-104717 * Author: ted (Ted Johansson) * Status: Open * Priority: Normal ---------------------------------------- Range already responds to #size. It would be nice if it also responded to predicate #empty? :-) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114866] [Ruby master Bug#18286] Universal arm64/x86_84 binary built on an x86_64 machine segfaults/is killed on arm64
by ccaviness (Clay Caviness) 21 Sep '23

21 Sep '23

Issue #18286 has been updated by ccaviness (Clay Caviness). https://github.com/ruby/ruby/pull/7367 fixes this, and just needs to be merged. ---------------------------------------- Bug #18286: Universal arm64/x86_84 binary built on an x86_64 machine segfaults/is killed on arm64 https://bugs.ruby-lang.org/issues/18286#change-104714 * Author: ccaviness (Clay Caviness) * Status: Open * Priority: Normal * ruby -v: 3.0.2 * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- A universal arm64/x86_84 ruby binary for macOS built on a x86_64 machine segfaults/is killed when executed on an arm64 machine. To reproduce: * On an Intel Mac: `git clone https://github.com/ruby/ruby && cd ruby && git checkout v3_0_2 && ./autogen.sh && ./configure --with-arch=arm64,x86_64 && make -j$(sysctl -n hw.ncpu)` * Copy the built `./ruby` binary to an Apple Silicon machine * Attempt to execute it Expected: The universal `ruby` binary works correctly on both devices Actual: The universal `ruby` binary crashes with either `Segmentation fault: 11` or `Killed: 9` (this seems to occur if `arm64e` is used instead of `arm64`). Details: I'm attempting to build a universal Ruby for macOS that will run on both Intel (x86_64) and Apple Silicon (arm64) machines. It seemed initially that this was as easy as adding `--with-arch=arm64,x86_64` to `./configure` would do it, as it produced a `ruby` binary that reports as `Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]` This `ruby` works correctly on the Intel machine I built in on, but does not work when copied to an Apple Silicon device. The reverse, however, seems to work. That is, if I build the universal ruby on an Apple Silicon machine, the `ruby` binary that's built seems to work correctly on both Intel and Apple Silicon machines. Intel: ``` $ ./ruby -v ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [universal.x86_64-darwin21] ``` Apple Silicon: ``` $ ./ruby -v Segmentation fault: 11 $ lldb ./ruby (lldb) target create "./ruby" Current executable set to '/Users/crc/ruby' (arm64). (lldb) run Process 77071 launched: '/Users/crc/ruby' (arm64) Process 77071 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8) frame #0: 0x00000001002176b8 ruby`ruby_vm_special_exception_copy + 16 ruby`ruby_vm_special_exception_copy: -> 0x1002176b8 <+16>: ldr x0, [x0, #0x8] 0x1002176bc <+20>: bl 0x10011fed8 ; rb_class_real 0x1002176c0 <+24>: bl 0x10012070c ; rb_obj_alloc 0x1002176c4 <+28>: mov x20, x0 Target 0: (ruby) stopped. (lldb) ^D ``` I also attempted the same thing with ruby 2.7.4 source, with the same result. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114865] [Ruby master Bug#18911] Process._fork hook point is not called when Process.daemon is used
by Dan0042 (Daniel DeLorme) 21 Sep '23

21 Sep '23

Issue #18911 has been updated by Dan0042 (Daniel DeLorme). Note for future readers coming here from the `Process._fork` documentation. If you need to restart threads, you should override both `_fork` and `daemon` ```ruby module RestartWatcherThread def _fork pid = super restart_thread if pid == 0 pid end def daemon(...) super.tap{ restart_thread } end prepend_features(Process.singleton_class) end ``` ---------------------------------------- Bug #18911: Process._fork hook point is not called when Process.daemon is used https://bugs.ruby-lang.org/issues/18911#change-104713 * Author: ivoanjo (Ivo Anjo) * Status: Closed * Priority: Normal * Assignee: akr (Akira Tanaka) * ruby -v: ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-darwin20] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Hello there! I'm working at Datadog [on the `ddtrace` gem](https://github.com/DataDog/dd-trace-rb), and we need to hook into fork operations to make sure that our products work correctly/automatically even in environments that fork. As part as #17795 a new `Process._fork` method was added to allow libraries and frameworks to easily hook into fork operations. I was investigating its use in `ddtrace` and noticed the following gap: the `Process.daemon` API internally makes use of `fork`, but the new hook point is not called for that API. Testcase: ```ruby puts RUBY_DESCRIPTION module ForkHook def _fork(*args) puts " #{Process.pid} Before fork!" res = super puts " #{Process.pid} After fork!" res end end Process.singleton_class.prepend(ForkHook) puts "#{Process.pid} Regular fork:" fork { exit } Process.wait puts "#{Process.pid} Process.daemon:" Process.daemon(nil, true) puts "#{Process.pid} Finishing!" ``` Testcase output: ``` ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-darwin20] 48136 Regular fork: # <-- original process 48136 Before fork! 48136 After fork! # <-- original process 48137 After fork! # <-- child process 48136 Process.daemon: # <-- original process 48139 Finishing! # <-- forks and pid changes, but the hook isn't called ``` This was surprising to me since the advantage of this hook point would not not needing to hook into the many other places where `fork` can get called from. Thanks a lot :) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114863] [Ruby master Feature#13933] Add Range#empty?
by Dan0042 (Daniel DeLorme) 21 Sep '23

21 Sep '23

Issue #13933 has been updated by Dan0042 (Daniel DeLorme). akr (Akira Tanaka) wrote in #note-8: > Range#empty? should work with them. Ok for `Float::INFINITY, [], ""`, but I don't think `true, false, Object.new` are relevant. A Range object normally has a begin and end, and if the values are not comparable (like `"a"..1`) we get "ArgumentError (bad value for range)". With `true..true` we happen to coincidentally pass that validation because `true<=>true` is 0 (and arguably it should be nil but that's another topic). But semantically, as a range, `true..true` doesn't mean anything. The introduction of beginless/endless ranges also mean that we can now create all kinds of ranges that skip the normal validation. `(true..true)` and `(true..)` and `(..true)` are not semantically meaningful ranges, there is no use case for them, and therefore it doesn't matter that `#include?` raises an error, and it shouldn't matter what is returned by `#empty?` But unlike `true`, arrays truly are comparable. The Comparable module is not mixed in, but <=> can return -1 and 1. So `[]` is truly a minimum value for arrays. It could be special-cased. Although I'm not sure it's worth the trouble. Or maybe we can define a range "r" as empty if `r.begin.nil? and r.exclude_end? and r.end.respond_to?(:empty?) and r.end.empty?` Random idea: beginless/endless ranges may only be created for objects that mix in `Comparable`. So `(Time.now..)` is ok but `(Object.new..)` raises "ArgumentError (bad value for range)" ---------------------------------------- Feature #13933: Add Range#empty? https://bugs.ruby-lang.org/issues/13933#change-104711 * Author: ted (Ted Johansson) * Status: Open * Priority: Normal ---------------------------------------- Range already responds to #size. It would be nice if it also responded to predicate #empty? :-) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114862] [Ruby master Feature#13933] Add Range#empty?
by akr (Akira Tanaka) 21 Sep '23

21 Sep '23

Issue #13933 has been updated by akr (Akira Tanaka). I described that this is difficult to implement in https://bugs.ruby-lang.org/issues/19839#note-18. The problem is not only with -Float::INFINITY. There are many minimum values other than -Float::INFINITY : [], "", true, false, Object.new, etc. Of course, a user may define a class with a minimum value. Range#empty? should work with them. ---------------------------------------- Feature #13933: Add Range#empty? https://bugs.ruby-lang.org/issues/13933#change-104710 * Author: ted (Ted Johansson) * Status: Open * Priority: Normal ---------------------------------------- Range already responds to #size. It would be nice if it also responded to predicate #empty? :-) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114332] [Ruby master Bug#19794] Ruby 3.2.2 fails to build on macOS Sonoma betas
by jhaungs (Jim Haungs) 21 Sep '23

21 Sep '23

Issue #19794 has been reported by jhaungs (Jim Haungs). ---------------------------------------- Bug #19794: Ruby 3.2.2 fails to build on macOS Sonoma betas https://bugs.ruby-lang.org/issues/19794 * Author: jhaungs (Jim Haungs) * Status: Open * Priority: Normal * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- With Big Sur, Apple deprecated putting dylibs in /usr/local/lib. In Sonoma (beta 4), this directory has disappeared completely. However, ruby's configure script depends on its existence. So, virtually every ruby installer (RVM, rbenv, asdf, ruby-build, and even building from source tarball) fails. When building ruby 3.2.2 from source, the configure step outputs the irritatingly useless "something wrong with LDFLAGS" error message and fails to build. The solution was to `cd /usr/local; sudo mkdir lib` to create the missing lib directory under /usr/local. It would be nice to remove this dependency from the configure script. -- https://bugs.ruby-lang.org/

5 6

[ruby-core:114855] [Ruby master Feature#13933] Add Range#empty?
by Dan0042 (Daniel DeLorme) 21 Sep '23

21 Sep '23

Issue #13933 has been updated by Dan0042 (Daniel DeLorme). It was an ad-hoc example that just seemed to me like it should return true. As to how to define it... maybe we can say that numeric ranges are equivalent to `begin == -Float::INFINITY` if beginless, and `end == +Float::INFINITY` if endless. Then it would be like saying `(k...k).empty?` with `k == -Float::INFINITY` ---------------------------------------- Feature #13933: Add Range#empty? https://bugs.ruby-lang.org/issues/13933#change-104702 * Author: ted (Ted Johansson) * Status: Open * Priority: Normal ---------------------------------------- Range already responds to #size. It would be nice if it also responded to predicate #empty? :-) -- https://bugs.ruby-lang.org/

1 0