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

[ruby-core:114497] [Ruby master Bug#16920] TestThread#test_signal_at_join fails on aarch64
by jeremyevans0 (Jeremy Evans) 24 Aug '23

24 Aug '23

Issue #16920 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed I reviewed every recent RubyCI arm/aarch64 failure, and this test did not fail in any of them. So failures must be rare. I'm going to close this. If this is still an issue and someone can come up with a reproducible test case, that would be appreciated. ---------------------------------------- Bug #16920: TestThread#test_signal_at_join fails on aarch64 https://bugs.ruby-lang.org/issues/16920#change-104282 * Author: jaruga (Jun Aruga) * Status: Closed * Priority: Normal * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- I observed the following error on Ruby 2.7.1 building in Fedora aarch64 CI. It was just one time error. It does not always happen. ``` 1) Error: TestThread#test_signal_at_join: Timeout::Error: execution of assert_separately expired timeout (120 sec) pid 2314088 killed by SIGABRT (signal 6) (core dumped) | /builddir/build/BUILD/ruby-2.7.1/test/ruby/test_thread.rb:1346:in `test_signal_at_join' Finished tests in 1379.712832s, 15.2372 tests/s, 1972.9127 assertions/s. ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114491] [Ruby master Feature#19057] Hide implementation of `rb_io_t`.
by ioquatix (Samuel Williams) 24 Aug '23

24 Aug '23

Issue #19057 has been updated by ioquatix (Samuel Williams). - `cool.io` has since been fixed and released. - `unicorn` has merged a fix but it is not released: https://yhbt.net/unicorn.git/63c85c4282d15e22bd32a905883d2d0e149619d1/s/ - `kgio` has a patch submitted. ---------------------------------------- Feature #19057: Hide implementation of `rb_io_t`. https://bugs.ruby-lang.org/issues/19057#change-104276 * Author: ioquatix (Samuel Williams) * Status: Assigned * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Target version: 3.3 ---------------------------------------- In order to make improvements to the IO implementation like <https://bugs.ruby-lang.org/issues/18455>, we need to add new fields to `struct rb_io_t`. By the way, ending types in `_t` is not recommended by POSIX, so I'm also trying to rename the internal implementation to drop `_t` where possible during this conversion. Anyway, we should try to hide the implementation of `struct rb_io`. Ideally, we don't expose any of it, but the problem is backwards compatibility. So, in order to remain backwards compatibility, we should expose some fields of `struct rb_io`, the most commonly used one is `fd` and `mode`, but several others are commonly used. There are many fields which should not be exposed because they are implementation details. ## Current proposal The current proposed change <https://github.com/ruby/ruby/pull/6511> creates two structs: ```c // include/ruby/io.h #ifndef RB_IO_T struct rb_io { int fd; // ... public fields ... }; #else struct rb_io; #endif // internal/io.h #define RB_IO_T struct rb_io { int fd; // ... public fields ... // ... private fields ... }; ``` However, we are not 100% confident this is safe according to the C specification. My experience is not sufficiently wide to say this is safe in practice, but it does look okay to both myself, and @Eregon + @tenderlovemaking have both given some kind of approval. That being said, maybe it's not safe. There are two alternatives: ## Hide all details We can make public `struct rb_io` completely invisible. ```c // include/ruby/io.h #define RB_IO_HIDDEN struct rb_io; int rb_ioptr_descriptor(struct rb_io *ioptr); // accessor for previously visible state. // internal/io.h struct rb_io { // ... all fields ... }; ``` This would only be forwards compatible, and code would need to feature detect like this: ```c #ifdef RB_IO_HIDDEN #define RB_IOPTR_DESCRIPTOR rb_ioptr_descriptor #else #define RB_IOPTR_DESCRIPTOR(ioptr) rb_ioptr_descriptor(ioptr) #endif ``` ## Nested public interface Alternatively, we can nest the public fields into the private struct: ```c // include/ruby/io.h struct rb_io_public { int fd; // ... public fields ... }; // internal/io.h #define RB_IO_T struct rb_io { struct rb_io_public public; // ... private fields ... }; ``` ## Considerations I personally think the "Hide all details" implementation is the best, but it's also the lest compatible. This is also what we are ultimately aiming for, whether we decide to take an intermediate "compatibility step" is up to us. I think "Nested public interface" is messy and introduces more complexity, but it might be slightly better defined than the "Current proposal" which might create undefined behaviour. That being said, all the tests are passing. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114248] [Ruby master Feature#19777] Make `Kernel#lambda` raise when called without a literal block
by alanwu (Alan Wu) 24 Aug '23

24 Aug '23

Issue #19777 has been reported by alanwu (Alan Wu). ---------------------------------------- Feature #19777: Make `Kernel#lambda` raise when called without a literal block https://bugs.ruby-lang.org/issues/19777 * Author: alanwu (Alan Wu) * Status: Open * Priority: Normal ---------------------------------------- Since 3.0.0, released in 2020, calling `Kernel#lambda` without a literal block has been issuing a deprecation warning: ```ruby Warning[:deprecated] = true def foo(&b) lambda(&b) end foo {} # => test.rb:2: warning: lambda without a literal block is deprecated; use the proc without lambda instead ``` I think enough time has passed and we should make it raise in all situations where it currently issues a deprecation warning. The original decision to deprecate is here: https://bugs.ruby-lang.org/issues/15973#note-46 The new behavior allows one to predict whether `Kernel#lambda` will return by inspecting its direct caller, checking whether the call site has a literal block. It will remove some hard-to-predict cases where `Kernel#lambda` receives a non-literal block forwarded with `super` or `rb_funcall_passing_block`. The method will always return a lambda, if it returns. However, note that `send` will be a special exception in this new model: ```ruby Warning[:deprecated] = true singleton_class.send(:public, :lambda) p (send(:lambda) {}).lambda? # => true without warning p (public_send(:lambda) {}).lambda? # => true with warning, would raise instead ``` This newer model is friendlier to some optimization we're investigating for YJIT as it has fewer moving parts. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:114340] [Ruby master Bug#19829] Enumerator.product called with keyword arguments raises exception with not precise message
by andrykonchin (Andrew Konchin) 24 Aug '23

24 Aug '23

Issue #19829 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #19829: Enumerator.product called with keyword arguments raises exception with not precise message https://bugs.ruby-lang.org/issues/19829 * Author: andrykonchin (Andrew Konchin) * Status: Open * Priority: Normal * ruby -v: 3.2.1 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The `Enumerator.product` method, added in Ruby 3.2, when it's called with keyword arguments (but it expects only a list of enums) raises `unknown keyword: ... (ArgumentError)` exception: ```ruby Enumerator.product([], a: 1) # (irb):1:in `product': unknown keyword: :a (ArgumentError) ``` But AFAIK `unknown keyword` is used when a method expects keyword arguments and some not supported keyword arguments were passed. So I would expect raising exception with `no keywords accepted (ArgumentError)` message instead that states clearly that no keywords should be passed. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:113954] [Ruby master Misc#19740] Block taking methods can't differentiate between a non-local return and a throw
by byroot (Jean Boussier) 24 Aug '23

24 Aug '23

Issue #19740 has been reported by byroot (Jean Boussier). ---------------------------------------- Misc #19740: Block taking methods can't differentiate between a non-local return and a throw https://bugs.ruby-lang.org/issues/19740 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- Opening this as Misc, as at this stage I don't have a fully formed feature request. Ref: https://github.com/ruby/ruby/commit/1a3bcf103c582b20e9ea70dfed0ee68b24243f55 Ref: https://github.com/ruby/timeout/pull/30 Ref: https://github.com/rails/rails/pull/29333 ### Context Rails has this problem in the Active Record transaction API. The way it works is that it yields to a block, and if no error was raised the SQL transaction is committed, otherwise it's rolled back: ```ruby User.transaction do do_thing end # COMMIT ``` or ```ruby User.transaction do raise SomeError end # ROLLBACK ``` The problem is that there are more ways a method can be exited: ```ruby User.transaction do return # non-local exit end ``` ```ruby User.transaction do throw :something end ``` In the case of a non-local return, we'd want to commit the transaction, but in the case of a throw, particularly since it's internally used by `Timeout.timeout` since Ruby 2.1, we'd rather consider that an error and rollback. But as far as I'm aware, there is not way to distinguish the two cases. ```ruby def transaction returned = false yield returned = true ensure if $! # error was raised elsif returned # no uniwnd else # non-local return or throw, don't know end end ``` I think it could be useful to have a way to access the currently thrown object, similar to `$!` for such cases, or some other way to tell what is going on. There is some discussion going on in https://github.com/ruby/timeout/pull/30 about whether `Timeout` should throw or raise, and that may solve part of the problem, but regardless of where this leads, I think being able to check if something is being thrown would be valuable. cc @matthewd FYI @jeremyevans0 @Eregon -- https://bugs.ruby-lang.org/

3 2

[ruby-core:114479] [Ruby master Feature#19846] Extend warnings message of bundled gems for gem author
by hsbt (Hiroshi SHIBATA) 24 Aug '23

24 Aug '23

Issue #19846 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Feature #19846: Extend warnings message of bundled gems for gem author https://bugs.ruby-lang.org/issues/19846 * Author: hsbt (Hiroshi SHIBATA) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- This is my task reminder. The current warnings feature of bundled gems only notice for Gemfile. Like this: ``` $ cat Gemfile # frozen_string_literal: true source "https://rubygems.org" gem "activesupport" ``` ``` $ bundle exec irb >> require "active_support/all" /Users/hsbt/.local/share/gem/gems/activesupport-7.0.7.2/lib/active_support/core_ext/big_decimal/conversions.rb:3: warning: bigdecimal will be not part of the default gems since Ruby 3.4.0. Add it to your Gemfile. /Users/hsbt/.local/share/gem/gems/activesupport-7.0.7.2/lib/active_support/notifications/fanout.rb:3: warning: mutex_m will be not part of the default gems since Ruby 3.4.0. Add it to your Gemfile. ``` But we should also notice above message for maintainer of `activesupport` like "Add "mutex_m" with `add_dependency` to `activesupport` gemspec." -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114476] [Ruby master Bug#14543] `make commit` show error of `common-srcs`
by hsbt (Hiroshi SHIBATA) 24 Aug '23

24 Aug '23

Issue #14543 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed svn.ruby-lang.org is already retired. ---------------------------------------- Bug #14543: `make commit` show error of `common-srcs` https://bugs.ruby-lang.org/issues/14543#change-104260 * Author: hsbt (Hiroshi SHIBATA) * Status: Closed * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- When I use `make commit`, it shows following error. ``` ~/D/g/r/ruby (trunk) > mk commit make: Entering directory '/Users/hsbt/Documents/github.com/ruby/ruby/.x86_64-darwin' Committing to svn+ssh://svn@ci.ruby-lang.org/ruby/trunk ... M gems/bundled_gems Committed r62546 M gems/bundled_gems r62546 = 2e1b00647ce1b4d3a6801484d7e76283fac6d202 (refs/remotes/svn/trunk) No changes between 99295842365c9b356a6e8dfec264249cd8e24aad and refs/remotes/svn/trunk Resetting to the latest refs/remotes/svn/trunk dcommitted on a detached HEAD because you gave a revision argument. The rewritten commit is: 2e1b00647ce1b4d3a6801484d7e76283fac6d202 Already on 'trunk' Your branch is ahead of 'origin/trunk' by 1 commit. (use "git push" to publish your local commits) First, rewinding head to replay your work on top of it... Applying: Update minitest-5.11.3 on bundled gems. From github.com:ruby/ruby 26741c97f4..2e1b00647c trunk -> origin/trunk First, rewinding head to replay your work on top of it... make[1]: Entering directory '/Users/hsbt/Documents/github.com/ruby/ruby/.x86_64-darwin' make[1]: *** No rule to make target '../lex.c', needed by 'common-srcs'. Stop. make[1]: *** Waiting for unfinished jobs.... generating ../parse.c M gems/bundled_gems r62546 = 2e1b00647ce1b4d3a6801484d7e76283fac6d202 (refs/remotes/svn/trunk) Current branch trunk is up to date. make[1]: Leaving directory '/Users/hsbt/Documents/github.com/ruby/ruby/.x86_64-darwin' make: *** [../defs/gmake.mk:142: commit] Error 2 make: Leaving directory '/Users/hsbt/Documents/github.com/ruby/ruby/.x86_64-darwin' ``` `mk` is an alias of `make -j`. @nobu Can you investigate it? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114474] [Ruby master Bug#16492] TestBugReporter#test_bug_reporter_add test failures
by jeremyevans0 (Jeremy Evans) 23 Aug '23

23 Aug '23

Issue #16492 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed I checked all recent ruby-master failures in the RHEL 7.1 s390 CI (http://rubyci.s3.amazonaws.com/rhel_zlinux/ruby-master/recent.html) and none show this issue. Considering this error was occuring in 90% of cases, since it hasn't happened recently, I assume this has been fixed. If you are still seeing this error with current Ruby, please reply and we can reopen. ---------------------------------------- Bug #16492: TestBugReporter#test_bug_reporter_add test failures https://bugs.ruby-lang.org/issues/16492#change-104257 * Author: vo.x (Vit Ondruch) * Status: Closed * Priority: Normal * Assignee: jaruga (Jun Aruga) * ruby -v: ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [s390x-linux] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- Building Ruby packages on Fedora, in 90% of cases, I observe the following error on s390: ~~~ 1) Error: TestBugReporter#test_bug_reporter_add: Timeout::Error: execution of assert_in_out_err expired timeout (10 sec) pid 2061293 killed by SIGKILL (signal 9) | | -:1: [BUG] Segmentation fault at 0x001f73ed000003e8 | ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [s390x-linux] | | -- Control frame information ----------------------------------------------- | c:0003 p:---- s:0012 e:000011 CFUNC :kill | c:0002 p:0021 s:0006 e:000005 EVAL -:1 [FINISH] | c:0001 p:0000 s:0003 E:000430 (none) [FINISH] | | -- Ruby level backtrace information ---------------------------------------- | -:1:in `<main>' | -:1:in `kill' | | -- Other runtime information ----------------------------------------------- | | * Loaded script: - | | * Loaded features: | | 0 enumerator.so | 1 thread.rb | 2 rational.so | 3 complex.so | 4 ruby2_keywords.rb | 5 /builddir/build/BUILD/ruby-2.7.0/.ext/s390x-linux/enc/encdb.so | 6 /builddir/build/BUILD/ruby-2.7.0/.ext/s390x-linux/enc/trans/transdb.so | 7 /builddir/build/BUILD/ruby-2.7.0/abrt.rb | 8 /builddir/build/BUILD/ruby-2.7.0/.ext/s390x-linux/-test-/bug_reporter.so | | * Process memory map: | | 2aa27a00000-2aa27a01000 r-xp 00000000 fc:03 1845127 /builddir/build/BUILD/ruby-2.7.0/ruby | 2aa27a01000-2aa27a02000 r--p 00000000 fc:03 1845127 /builddir/build/BUILD/ruby-2.7.0/ruby | 2aa27a02000-2aa27a03000 rw-p 00001000 fc:03 1845127 /builddir/build/BUILD/ruby-2.7.0/ruby | 2aa28a7e000-2aa28bfe000 rw-p 00000000 00:00 0 [heap] | 3ff9ff80000-3ff9ff81000 r-xp 00000000 fc:03 1844756 /builddir/build/BUILD/ruby-2.7.0/.ext/s390x-linux/-test-/bug_reporter.so | 3ff9ff81000-3ff9ff82000 r--p 00000000 fc:03 1844756 /builddir/build/BUILD/ruby-2.7.0/.ext/s390x-linux/-test-/bug_reporter.so | 3ff9ff82000-3ff9ff83000 rw-p 00000000 00:00 0 | 3ffa0000000-3ffa0002000 r-xp 00000000 fc:03 1844387 /builddir/build/BUILD/ruby-2.7.0/.ext/s390x-linux/enc/trans/transdb.so | 3ffa0002000-3ffa0003000 r--p 00001000 fc:03 1844387 /builddir/build/BUILD/ruby-2.7.0/.ext/s390x-linux/enc/trans/transdb.so | 3ffa0003000-3ffa0004000 rw-p 00000000 00:00 0 | 3ffa0036000-3ffa0037000 ---p 00000000 00:00 0 | 3ffa0037000-3ffa0078000 rw-p 00000000 00:00 0 | 3ffa0078000-3ffa0079000 ---p 00000000 00:00 0 | 3ffa0079000-3ffa00ba000 rw-p 00000000 00:00 0 | 3ffa00ba000-3ffa00bb000 ---p 00000000 00:00 0 | 3ffa00bb000-3ffa00fc000 rw-p 00000000 00:00 0 | 3ffa00fc000-3ffa00fd000 ---p 00000000 00:00 0 | 3ffa00fd000-3ffa013e000 rw-p 00000000 00:00 0 | 3ffa013e000-3ffa013f000 ---p 00000000 00:00 0 | 3ffa013f000-3ffa0180000 rw-p 00000000 00:00 0 | 3ffa0180000-3ffa0181000 ---p 00000000 00:00 0 | 3ffa0181000-3ffa01c2000 rw-p 00000000 00:00 0 | 3ffa01c2000-3ffa01c3000 ---p 00000000 00:00 0 | 3ffa01c3000-3ffa0204000 rw-p 00000000 00:00 0 | 3ffa0204000-3ffa0205000 ---p 00000000 00:00 0 | 3ffa0205000-3ffa0246000 rw-p 00000000 00:00 0 | 3ffa0246000-3ffa0247000 ---p 00000000 00:00 0 | 3ffa0247000-3ffa0288000 rw-p 00000000 00:00 0 | 3ffa0288000-3ffa0289000 ---p 00000000 00:00 0 | 3ffa0289000-3ffa02ca000 rw-p 00000000 00:00 0 | 3ffa02ca000-3ffa02cb000 ---p 00000000 00:00 0 | 3ffa02cb000-3ffa030c000 rw-p 00000000 00:00 0 | 3ffa030c000-3ffa030d000 ---p 00000000 00:00 0 | 3ffa030d000-3ffa034e000 rw-p 00000000 00:00 0 | 3ffa034e000-3ffa034f000 ---p 00000000 00:00 0 | 3ffa034f000-3ffa0390000 rw-p 00000000 00:00 0 | 3ffa0390000-3ffa0391000 ---p 00000000 00:00 0 | 3ffa0391000-3ffa03d2000 rw-p 00000000 00:00 0 | 3ffa03d2000-3ffa03d3000 ---p 00000000 00:00 0 | 3ffa03d3000-3ffa0414000 rw-p 00000000 00:00 0 | 3ffa0414000-3ffa0415000 ---p 00000000 00:00 0 | 3ffa0415000-3ffa0456000 rw-p 00000000 00:00 0 | 3ffa0456000-3ffa0457000 ---p 00000000 00:00 0 | 3ffa0457000-3ffa0498000 rw-p 00000000 00:00 0 | 3ffa0498000-3ffa0499000 ---p 00000000 00:00 0 | 3ffa0499000-3ffa04da000 rw-p 00000000 00:00 0 | 3ffa04da000-3ffa04db000 ---p 00000000 00:00 0 | 3ffa04db000-3ffa051c000 rw-p 00000000 00:00 0 | 3ffa051c000-3ffa051d000 ---p 00000000 00:00 0 | 3ffa051d000-3ffa055e000 rw-p 00000000 00:00 0 | 3ffa055e000-3ffa055f000 ---p 00000000 00:00 0 | 3ffa055f000-3ffa05a0000 rw-p 00000000 00:00 0 | 3ffa05a0000-3ffa05a1000 ---p 00000000 00:00 0 | 3ffa05a1000-3ffa05e2000 rw-p 00000000 00:00 0 | 3ffa05e2000-3ffa05e3000 ---p 00000000 00:00 0 | 3ffa05e3000-3ffa0624000 rw-p 00000000 00:00 0 | 3ffa0624000-3ffa0625000 ---p 00000000 00:00 0 | 3ffa0625000-3ffa0666000 rw-p 00000000 00:00 0 | 3ffa0666000-3ffa0667000 ---p 00000000 00:00 0 | 3ffa0667000-3ffa06a8000 rw-p 00000000 00:00 0 | 3ffa06a8000-3ffa06a9000 ---p 00000000 00:00 0 | 3ffa06a9000-3ffa06ea000 rw-p 00000000 00:00 0 | 3ffa06ea000-3ffa06eb000 ---p 00000000 00:00 0 | 3ffa06eb000-3ffa072c000 rw-p 00000000 00:00 0 | 3ffa072c000-3ffa072d000 ---p 00000000 00:00 0 | 3ffa072d000-3ffa076e000 rw-p 00000000 00:00 0 | 3ffa076e000-3ffa076f000 ---p 00000000 00:00 0 | 3ffa076f000-3ffa07b0000 rw-p 00000000 00:00 0 | 3ffa07b0000-3ffa07b1000 ---p 00000000 00:00 0 | 3ffa07b1000-3ffa07f2000 rw-p 00000000 00:00 0 | 3ffa07f2000-3ffa07f3000 ---p 00000000 00:00 0 | 3ffa07f3000-3ffa0834000 rw-p 00000000 00:00 0 | 3ffa0834000-3ffa0835000 ---p 00000000 00:00 0 | 3ffa0835000-3ffa2980000 rw-p 00000000 00:00 0 | 3ffa2980000-3ffa2a17000 r-xp 00000000 fc:03 1813828 /usr/lib64/libm-2.30.9000.so | 3ffa2a17000-3ffa2a18000 r--p 00096000 fc:03 1813828 /usr/lib64/libm-2.30.9000.so | 3ffa2a18000-3ffa2a19000 rw-p 00097000 fc:03 1813828 /usr/lib64/libm-2.30.9000.so | 3ffa2a80000-3ffa2ab2000 r-xp 00000000 fc:03 1814596 /usr/lib64/libcrypt.so.2.0.0 | 3ffa2ab2000-3ffa2ab3000 ---p 00032000 fc:03 1814596 /usr/lib64/libcrypt.so.2.0.0 | 3ffa2ab3000-3ffa2ab4000 r--p 00032000 fc:03 1814596 /usr/lib64/libcrypt.so.2.0.0 | 3ffa2ab4000-3ffa2abd000 rw-p 00000000 00:00 0 | 3ffa2b00000-3ffa2b03000 r-xp 00000000 fc:03 1813826 /usr/lib64/libdl-2.30.9000.so | 3ffa2b03000-3ffa2b04000 r--p 00002000 fc:03 1813826 /usr/lib64/libdl-2.30.9000.so | 3ffa2b04000-3ffa2b05000 rw-p 00000000 00:00 0 | 3ffa2b80000-3ffa2c05000 r-xp 00000000 fc:03 1814658 /usr/lib64/libgmp.so.10.3.2 | 3ffa2c05000-3ffa2c07000 r--p 00084000 fc:03 1814658 /usr/lib64/libgmp.so.10.3.2 | 3ffa2c07000-3ffa2c08000 rw-p 00086000 fc:03 1814658 /usr/lib64/libgmp.so.10.3.2 | 3ffa2c80000-3ffa2c88000 r-xp 00000000 fc:03 1813840 /usr/lib64/librt-2.30.9000.so | 3ffa2c88000-3ffa2c89000 r--p 00007000 fc:03 1813840 /usr/lib64/librt-2.30.9000.so | 3ffa2c89000-3ffa2c8a000 rw-p 00008000 fc:03 1813840 /usr/lib64/librt-2.30.9000.so | 3ffa2d00000-3ffa2d1e000 r-xp 00000000 fc:03 1813836 /usr/lib64/libpthread-2.30.9000.so | 3ffa2d1e000-3ffa2d1f000 r--p 0001d000 fc:03 1813836 /usr/lib64/libpthread-2.30.9000.so | 3ffa2d1f000-3ffa2d20000 rw-p 0001e000 fc:03 1813836 /usr/lib64/libpthread-2.30.9000.so | 3ffa2d20000-3ffa2d24000 rw-p 00000000 00:00 0 | 3ffa2d80000-3ffa2f1e000 r-xp 00000000 fc:03 1813824 /usr/lib64/libc-2.30.9000.so | 3ffa2f1e000-3ffa2f22000 r--p 0019d000 fc:03 1813824 /usr/lib64/libc-2.30.9000.so | 3ffa2f22000-3ffa2f25000 rw-p 001a1000 fc:03 1813824 /usr/lib64/libc-2.30.9000.so | 3ffa2f25000-3ffa2f28000 rw-p 00000000 00:00 0 | 3ffa2f80000-3ffa2f82000 r-xp 00000000 fc:03 1844333 /builddir/build/BUILD/ruby-2.7.0/.ext/s390x-linux/enc/encdb.so | 3ffa2f82000-3ffa2f83000 r--p 00001000 fc:03 1844333 /builddir/build/BUILD/ruby-2.7.0/.ext/s390x-linux/enc/encdb.so | 3ffa2f83000-3ffa2f84000 rw-p 00000000 00:00 0 | 3ffa3000000-3ffa336e000 r-xp 00000000 fc:03 1844256 /builddir/build/BUILD/ruby-2.7.0/libruby.so.2.7.0 | 3ffa336e000-3ffa3377000 r--p 0036d000 fc:03 1844256 /builddir/build/BUILD/ruby-2.7.0/libruby.so.2.7.0 | 3ffa3377000-3ffa3378000 rw-p 00376000 fc:03 1844256 /builddir/build/BUILD/ruby-2.7.0/libruby.so.2.7.0 | 3ffa3378000-3ffa338f000 rw-p 00000000 00:00 0 | 3ffa3400000-3ffa3426000 r-xp 00000000 fc:03 1813817 /usr/lib64/ld-2.30.9000.so | 3ffa3426000-3ffa3427000 r--p 00025000 fc:03 1813817 /usr/lib64/ld-2.30.9000.so | 3ffa3427000-3ffa3428000 rw-p 00026000 fc:03 1813817 /usr/lib64/ld-2.30.9000.so | 3ffa3428000-3ffa3429000 rw-p 00000000 00:00 0 | 3ffa3476000-3ffa347e000 rw-p 00000000 00:00 0 | 3ffa347e000-3ffa3480000 r-xp 00000000 00:00 0 [vdso] | 3ffc5301000-3ffc5b00000 rw-p 00000000 00:00 0 [stack] | | | Sample bug reporter: 12345 /builddir/build/BUILD/ruby-2.7.0/test/-ext-/bug_reporter/test_bug_reporter.rb:22:in `test_bug_reporter_add' Finished tests in 544.051367s, 38.5515 tests/s, 4998.1953 assertions/s. 20974 tests, 2719275 assertions, 0 failures, 1 errors, 68 skips ruby -v: ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [s390x-linux] ~~~ Since the default timeout is 10s, I tried to increase the timeout to 30s via simple `sed -i '/assert_in_out_err/ s/)/, timeout: 30)/' test/-ext-/bug_reporter/test_bug_reporter.rb` and this seems to help to avoid this issue. However, I am not really sure why s390x is so slow handling this test case :/ ---Files-------------------------------- 0001-Timeout-the-test_bug_reporter_add-witout-raising-err.patch (1.45 KB) Time.png (56 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114473] [Ruby master Bug#14480] miniruby crashing when compiled with -O2 or -O1 on aarch64
by jeremyevans0 (Jeremy Evans) 23 Aug '23

23 Aug '23

Issue #14480 has been updated by jeremyevans0 (Jeremy Evans). I submitted a pull request to disable `__builtin_setjmp` for Linux aarch64: https://github.com/ruby/ruby/pull/8272 ---------------------------------------- Bug #14480: miniruby crashing when compiled with -O2 or -O1 on aarch64 https://bugs.ruby-lang.org/issues/14480#change-104256 * 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:114472] [Ruby master Bug#16288] Segmentation fault with finalizers, threads
by jeremyevans0 (Jeremy Evans) 23 Aug '23

23 Aug '23

Issue #16288 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed davidw (David Welton) wrote in #note-7: > ``` > --- a/thread.c > +++ b/thread.c > @@ -682,7 +682,7 @@ thread_do_start(rb_thread_t *th) > else { > args_ptr = RARRAY_CONST_PTR(args); > } > - > + rb_funcallv(NULL, idInspect, 0, 0); > th->value = rb_vm_invoke_proc(th->ec, proc, > (int)args_len, args_ptr, > VM_BLOCK_HANDLER_NONE); > ``` > > > I replaced the funcall with > > RUBY_VM_CHECK_INTS(GET_EC()); > > And everything seems to work ok. I checked and now we have `vm_check_ints_blocking(th->ec);` in that spot, so I think this is fixed. ---------------------------------------- Bug #16288: Segmentation fault with finalizers, threads https://bugs.ruby-lang.org/issues/16288#change-104255 * Author: davidw (David Welton) * Status: Closed * Priority: Normal * ruby -v: ruby 2.6.6p116 (2019-10-02 revision 67825) [x86_64-linux] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- Hi, This is a tricky one and I am still working on narrowing it down, but I will report what I have so far. I compiled a version of 2_6_6 from github: ruby 2.6.6p116 (2019-10-02 revision 67825) [x86_64-linux] I have a minimal Rails project that uses Mongoid. It crashes with a segmentation fault when rspec runs. The concurrent ruby gem is in some way involved, and I have been posting there: https://github.com/ruby-concurrency/concurrent-ruby/issues/808 However, I think there is a deeper problem - I would not expect a user level script to cause a segmentation fault. I have been putting a lot of debugging statements in, and turned on Thread.DEBUG, and have noticed some things. I am not experienced with Ruby's internals, so some of these bits of data might be normal or irrelevant: * The concurrent-ruby gem uses ObjectSpace.define_finalizer to set a finalizer * That finalizer creates a new Thread * However, it appears as if that thread is running after the main thread is already dead, so code that expects to reference the main thread crashes, because it's a NULL reference. I tried the following test code: ``` class Foo def initialize ObjectSpace.define_finalizer(self, proc do Foo.foo_finalizer end) end def bar puts 'bar' end def Foo.foo_finalizer puts "foo_finalizer" t = Thread.new do puts "Thread reporting for duty" end puts "foo_finalizer thread launched" sleep 5 end end f = Foo.new f.bar f = nil ``` While trying to develop a simple test case to demonstrate the problem. It triggers rb_raise(rb_eThreadError, "can't alloc thread"); in thread_s_new, because it looks like the main thread has already been marked as 'killed' in this case. When I check the main thread status in thread_s_new with the above code, it reports 'dead'. When I run my rspec code in the sample Rails project, thread_s_new shows the main thread's status as 'run' even if it should be dead? I have seen some debugging things that shows some exceptions and thread_join interrupts and so on. Is it possible that something like this is happening? Main thread starts doing a cleanup, and gets an exception or something that generates an interrupt, and its KILLED status gets reset to RUNNABLE Then, in the finalizer, it starts creating a Thread, but at this point the main thread actually does get killed, and when that finalizer thread tries to run it runs into a null reference? I can provide the Rails sample project if needs be. Sorry if any of the above isn't clear; I've been staring at the C code for several hours and am a bit cross-eyed! Thank you for any insights. -- https://bugs.ruby-lang.org/

1 0