- ruby-core - ml.ruby-lang.org

[ruby-core:117487] [Ruby master Bug#18455] `IO#close` has poor performance and difficult to understand semantics.
by ioquatix (Samuel Williams) 11 Apr '24

11 Apr '24

Issue #18455 has been updated by ioquatix (Samuel Williams). Assignee set to ioquatix (Samuel Williams) ---------------------------------------- Bug #18455: `IO#close` has poor performance and difficult to understand semantics. https://bugs.ruby-lang.org/issues/18455#change-107877 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- `IO#close` should be responsible for closing the file descriptor referred to by the IO instance. When dealing with buffered IO, one can also expect this to flush the internal buffers if possible. Currently, all blocking IO operations release the GVL and perform the blocking system call using `rb_thread_io_blocking_region`. The current implementation takes a file descriptor and adds an entry to the VM global `waiting_fds` list. When the operation is completed, the entry is removed from `waiting_fds`. When calling `IO#close`, this list is traversed and any threads performing blocking operations with a matching file descriptor are interrupted. The performance of this is O(number of blocking IO operations) which in practice the performance of `IO#close` can take milliseconds with 10,000 threads performing blocking IO. This performance is unacceptable. ``` ruby #!/usr/bin/env ruby require 'benchmark' class Reading def initialize @r, @w = IO.pipe @thread = Thread.new do @r.read rescue IOError # Ignore. end end attr :r attr :w attr :thread def join @thread.join end end def measure(count = 10) readings = count.times.map do Reading.new end sleep 10 duration = Benchmark.measure do readings.each do |reading| reading.r.close reading.w.close end end average = (duration.total / count) * 1000.0 pp count: count, average: sprintf("%0.2fms", average) readings.each(&:join) end measure( 10) measure( 100) measure( 1000) measure(10000) ``` In addition, the semantics of this operation are confusing at best. While Ruby programs are dealing with IO instances, the VM is dealing with file descriptors, in effect performing some internal de-duplication of IO state. In practice, this leads to strange behaviour: ``` ruby #!/usr/bin/env ruby r, w = IO.pipe r2 = IO.for_fd(r.to_i) pp r: r, r2: r2 t = Thread.new do r2.read rescue nil r2.read # EBADF end sleep 0.5 r.close t.join rescue nil pp r: r, r2: r2 # r is closed, r2 is valid but will raise EBADF on any operation. ``` In addition, this confusing behaviour extends to Ractor and state is leaked between the two: ``` ruby r, w = IO.pipe ractor = Ractor.new(r.to_i) do |fd| r2 = IO.for_fd(fd) r2.read # r2.read # EBADF end sleep 0.5 r.close pp take: ractor.take ``` I propose the following changes to simplify the semantics and improve performance: - Move the semantics of `waiting_fds` from per-fd to per-IO. This means that `IO#close` only interrupts blocking operations performed on the same IO instance rather than ANY IO which refers to the same file descriptor. I think this behaviour is easier to understand and still protects against the vast majority of incorrect usage. - Move the details of `struct rb_io_t` to `internal/io.h` so that the implementation details are not part of the public interface. ## Benchmarks Before: ``` {:count=>10, :average=>"0.19ms"} {:count=>100, :average=>"0.11ms"} {:count=>1000, :average=>"0.18ms"} {:count=>10000, :average=>"1.16ms"} ``` After: ``` {:count=>10, :average=>"0.20ms"} {:count=>100, :average=>"0.11ms"} {:count=>1000, :average=>"0.15ms"} {:count=>10000, :average=>"0.68ms"} ``` After investigating this further I found that the `rb_thread_io_blocking_region` using `ubf_select` can be incredibly slow, proportional to the number of threads. I don't know whether it's advisable but: ``` c BLOCKING_REGION(blocking_node.thread, { val = func(data1); saved_errno = errno; }, NULL /* ubf_select */, blocking_node.thread, FALSE); ``` Disabling the UBF function and relying on `read(fd, ...)`/`write(fd, ...)` blocking operations to fail when `close(fd)` is invoked might be sufficient? This needs more investigation but after making this change, we have constant-time IO#close. ``` {:count=>10, :average=>"0.13ms"} {:count=>100, :average=>"0.06ms"} {:count=>1000, :average=>"0.04ms"} {:count=>10000, :average=>"0.09ms"} ``` Which is ideally what we want. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117484] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError
by nithinbekal (Nithin Bekal) 10 Apr '24

10 Apr '24

Issue #18915 has been updated by nithinbekal (Nithin Bekal). > What name candidate do you have? What do you think about the name `SubclassResponsibilityError`? As @citizen428 explains [here](https://ruby.social/@citizen428@chaos.social/112239323523258221): > Smalltalk had the idiom of implementing abstract methods with the body `self subclassResponsibility` which raises an error. The name gives a pretty clear indication of what is wrong, and it seems fitting considering Ruby's Smalltalk heritage. ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-107873 * Author: Quintasan (Michał Zając) * Status: Open ---------------------------------------- # Abstract Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception # Background `NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html) However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing) However I have seen this being discussed numerous times: * https://github.com/rubocop/ruby-style-guide/issues/458 * http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/ * https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd… * https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of) * https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`) * https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-… # Proposal Create `NotImplementedYetError` exception OR Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities # Evaluation ### Add `NotImplementedYetError` I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception. ### Change scope of `NotImplementedError` This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever. ---Files-------------------------------- not-implemented-error-docs.patch (1.57 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117483] [Ruby master Bug#20419] [BUG] inconsistent freelist length with cppflags='-DRGENGC_CHECK_MODE -DUSE_RUBY_DEBUG_LOG=1'
by znz (Kazuhiro NISHIYAMA) 10 Apr '24

10 Apr '24

Issue #20419 has been reported by znz (Kazuhiro NISHIYAMA). ---------------------------------------- Bug #20419: [BUG] inconsistent freelist length with cppflags='-DRGENGC_CHECK_MODE -DUSE_RUBY_DEBUG_LOG=1' https://bugs.ruby-lang.org/issues/20419 * Author: znz (Kazuhiro NISHIYAMA) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- `TestGc#test_gc_stress_at_startup` failed on my environment, so I check which configure flags affect. How to reproduce: ``` ./configure cppflags='-DRGENGC_CHECK_MODE -DUSE_RUBY_DEBUG_LOG=1' make miniruby env RUBY_DEBUG=gc_stress ./miniruby -v ``` I can't reproduce with `cppflags='-DRGENGC_CHECK_MODE'` or `cppflags='-DUSE_RUBY_DEBUG_LOG=1'`. ---Files-------------------------------- output.txt (9.44 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117481] [Ruby master Bug#18993] Inconsistent Range#size for Float and Rational
by jeremyevans0 (Jeremy Evans) 09 Apr '24

09 Apr '24

Issue #18993 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed This appears fixed in Ruby 3.3: ``` $ ruby32 -ve "p (5.quo(3)...5).size" ruby 3.2.3 (2024-01-18 revision 52bb2ac0a6) [x86_64-openbsd] 3 $ ruby33 -ve "p (5.quo(3)...5).size" ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-openbsd] 4 ``` ---------------------------------------- Bug #18993: Inconsistent Range#size for Float and Rational https://bugs.ruby-lang.org/issues/18993#change-107868 * Author: masasakano (Masa Sakano) * Status: Closed * ruby -v: ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-darwin20] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- The returned values of Range#size between Rational and Float and also with regard to `exclude_end` of true and false are inconsistent. The example below highlights the difference. The first and second should return the same value. The difference between the first and third seems strange - if this is the specification, it should be clearly described in the [doc](https://ruby-doc.org/core-3.1.2/Range.html#method-i-size "Ruby-3.1.2 official doc of Range"). This point may be related to the issue "Misc #18984". ```ruby (5.quo(3)...5).size # => 3 (5.quo(3).to_f...5).size # => 4 (5.quo(3)..5).size # => 4 (5.quo(3).to_f..5).size # => 4 ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117121] [Ruby master Bug#20332] AFter upgrading to ruby v 3.2.3 rb_scan_args() skips argument value
by praveenrocket (Praveen N) 09 Apr '24

09 Apr '24

Issue #20332 has been reported by praveenrocket (Praveen N). ---------------------------------------- Bug #20332: AFter upgrading to ruby v 3.2.3 rb_scan_args() skips argument value https://bugs.ruby-lang.org/issues/20332 * Author: praveenrocket (Praveen N) * Status: Open * ruby -v: 3.2.3 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Hi, Note: I am not an expert at ruby. I am working on ibm_db gem, its an adapter developed using ruby C extension, which helps ruby & rails applications to connect to DB2 database. Here is a github link for its source https://github.com/ibmdb/ruby-ibmdb/tree/master As of now ibm_db gem is compatible with ruby v 3.1. Now I am trying to make ibm_db gem compatible with ruby v 3.2.3. All my test cases were working for ruby v 3.1, but post upgrading to ruby v 3.2.3, most of my test cases are failing. After debugging using gdb what I see is, my ruby test cases calls ruby C extension API passing required arguments, but inside C extension code arguments are not parsed, indeed nothing is read. Because of this most of test cases are failing. Below is a sample ruby script which when run calls ibm_db extension, `$ irb irb(main):001:0> require 'ibm_db' => true irb(main):002:0> conn = IBM_DB.connect("DATABASE=sample;HOSTNAME=waldevdbclnxtst06.dev.rocketsoftware.com;PORT=60000;PROTOCOL=TCPIP;UID=zurbie;PWD=A2m8test;",'','') (irb):2: warning: undefining the allocator of T_DATA class IBM_DB::Connection => #<IBM_DB::Connection:0x00007ff60314ce58> irb(main):003:0> stmt = IBM_DB.exec conn,'create table abc(C1 int)' => false irb(main):004:0> irb(main):005:0> IBM_DB.close(conn) => true irb(main):006:0> exit ` Above, If you observe IBM_DB.exec is called passing two arguments conn & string with create table query. In extension code https://github.com/ibmdb/ruby-ibmdb/blob/master/IBM_DB_Driver/ibm_db.c, below function will be called VALUE ibm_db_exec(int argc, VALUE *argv, VALUE self) { .... rb_scan_args(argc, argv, "21", &connection, &stmt, &options); ...... } Note: Please refer https://github.com/ibmdb/ruby-ibmdb/blob/master/IBM_DB_Driver/ibm_db.c for complete code. rb_scan_args used to parse arguments very well in ruby v 3.1, but now its failing to do so. I see stmt parameter doesnt hold anything. I just want to know whats issue here, Am I passing arguments in wrong way (in ruby script), or am I not using rb_scan_args properly ? To reproduce, Install ruby v 3.2.3, Install ibm_db gem version 5.4.1 (latest) Run above sample ruby script using IRB. Response at earliest is much appreciated. Thanks Praveen -- https://bugs.ruby-lang.org/

2 2

[ruby-core:117477] [Ruby master Bug#20417] RubyVM::AbstractSyntaxTree.parse warns about block local variables
by kddnewton (Kevin Newton) 09 Apr '24

09 Apr '24

Issue #20417 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20417: RubyVM::AbstractSyntaxTree.parse warns about block local variables https://bugs.ruby-lang.org/issues/20417 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ``` $ ./ruby -c -w -e '->(; foo) {}' Syntax OK ``` ``` $ ./ruby -w -e 'RubyVM::AbstractSyntaxTree.parse("->(; foo) {}")' (none):1: warning: assigned but unused variable - foo ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117390] [Ruby master Feature#20404] `2pi`
by mame (Yusuke Endoh) 09 Apr '24

09 Apr '24

Issue #20404 has been reported by mame (Yusuke Endoh). ---------------------------------------- Feature #20404: `2pi` https://bugs.ruby-lang.org/issues/20404 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- I propose a new Float literal: `2pi`. ```ruby p 2pi #=> 6.283185307179586 == 2 * Math::PI ``` I am not proposing `1pi`, `3pi` or `4pi`. I do only `2pi`. Because in most cases, all you need is `2pi`. Any other multiple of pi is rarely needed. I've got the statistics. GitHub code search revealed that more than 80% of the occurrences of `n * Math::PI` and `Math::PI * n` had n = 2. [1] | n |`n * Math::PI`|`Math::PI * n`|sum | % | |--:|-------------:|-------------:|----:|---:| | 0 | 48| 1| 49|1.4%| | 1 | 58| 3| 61|1.7%| | 2 | 2300| 534| 2834|80.4%| | 3 | 218| 17| 235|6.7%| | 4 | 200| 23| 223|6.3%| | 5 | 24| 2| 26|0.7%| | 6 | 41| 3| 44|1.2%| | 7 | 14| 0| 14|0.4%| | 8 | 6| 2| 8|0.2%| | 9 | 8| 0| 8|0.2%| |10 | 17| 0| 17|0.5%| |11 | 2| 0| 2|0.1%| |12 | 2| 0| 2|0.1%| Here is the PIe chart ![](https://gist.github.com/assets/21557/1c077af3-f753-4ee1-bc75-5b38a3bd6487) I know that a new constant name "Tau" is proposed (#4897, #17496). But notice: "2pi" and "Tau" have the same number of characters. Then, it is obvious that familiarity is better. In fact, `2 * Math::PI` is 4 times more than `Math::PI * 2`, indicating that all programmers are copying "2pi" in their textbook. The idea of 2pi came up regularly in chats among committers. The discussion quickly shifted to its generalization: should we treat `3e` as `3 * Math::E`, or even `42foo` as `42 * foo`? However, I noticed such a generalization is unnecessary because all we need is 2pi. Unneeded generalization is evil. Here is a patch. ```diff diff --git a/parse.y b/parse.y index 55619273b8..93b16a16ac 100644 --- a/parse.y +++ b/parse.y @@ -10208,6 +10208,13 @@ parse_numeric(struct parser_params *p, int c) return set_number_literal(p, tINTEGER, suffix, 10, 0); } } + else if (c == '2' && peek(p, 'p') && peek_n(p, 'i', 1)) { + tokadd(p, c); + tokadd(p, nextc(p)); + tokadd(p, nextc(p)); + tokfix(p); + return set_number_literal(p, tFLOAT, 0, 0, 0); + } for (;;) { switch (c) { diff --git a/ruby_parser.c b/ruby_parser.c index 6d85a72c5b..3a6e0b5704 100644 --- a/ruby_parser.c +++ b/ruby_parser.c @@ -936,6 +936,9 @@ VALUE rb_node_float_literal_val(const NODE *n) { const rb_node_float_t *node = RNODE_FLOAT(n); + if (strcmp(node->val, "2pi") == 0) { + return DBL2NUM(2 * M_PI); + } double d = strtod(node->val, 0); if (node->minus) { d = -d; P I Happy a r l fool ``` [1] I used these queries: [`/[^.]\b2 ?\* ?Math::PI/ language:Ruby`](https://github.com/search?type=code&q=%2F%5B%5E.%5D%5Cb2+%3… and [`/Math::PI *\* *2\b *[^.\/]/ language:Ruby`](https://github.com/search?type=code&q=%2FMath%3A%3API+*%5C*… -- https://bugs.ruby-lang.org/

7 8

[ruby-core:117449] [Ruby master Bug#20412] UTF-8 String encoding behavior differs between 3.2, 3.3 and master
by bannable (Joe Truba) 09 Apr '24

09 Apr '24

Issue #20412 has been reported by bannable (Joe Truba). ---------------------------------------- Bug #20412: UTF-8 String encoding behavior differs between 3.2, 3.3 and master https://bugs.ruby-lang.org/issues/20412 * Author: bannable (Joe Truba) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- When a String that contains only a `\0` byte is mutated by an extension to an invalid UTF-8 sequence, calling `.encode('UTF-8')` does not consistently raise `UndefinedConversionError` across ruby versions. When the string is longer than 1 byte, all versions I've tested correctly raise `UndefinedConversionError`. For Ruby 3.2, `UndefinedConversionError` being raised appears to depend on where the string was originally allocated. For Ruby 3.3, `UndefinedConversionError` is never raised. For master ad90fdd24c, `UndefinedConversionError` is always correctly raised. I haven't been able to find a bug for this, but it seems like there is a fix in master that should be backported to at least 3.2 and 3.3. I have not tested 3.1. The attached reproducer depends on `rbnacl` because it is minimized from a cryptographic project, and I wasn't able to ## Expected Output For all versions: ``` $ ruby repro.rb 1 "RUBY: [version]" "OK: ciphertext_rbnacl is not valid UTF-8" "OK: ciphertext_local is not valid UTF-8" "OK: plaintext_rbnacl is not valid UTF-8" "OK: plaintext_local is not valid UTF-8" $ ruby repro.rb 2 "RUBY: [version]" "OK: ciphertext_rbnacl is not valid UTF-8" "OK: ciphertext_local is not valid UTF-8" "OK: plaintext_rbnacl is not valid UTF-8" "OK: plaintext_local is not valid UTF-8" ``` ## Actual Output ### Ruby 3.2 ``` $ ASDF_RUBY_VERSION=3.2.3 ruby -v; ASDF_RUBY_VERSION=3.2.3 ruby repro.rb 1 ruby 3.2.3 (2024-01-18 revision 52bb2ac0a6) [x86_64-linux] "RUBY: 3.2.3" "OK: ciphertext_rbnacl is not valid UTF-8" "FAIL: ciphertext_local is not valid UTF-8 and did not error during encoding to UTF-8" "OK: plaintext_rbnacl is not valid UTF-8" "FAIL: plaintext_local is not valid UTF-8 and did not error during encoding to UTF-8" $ ASDF_RUBY_VERSION=3.2.3 ruby -v; ASDF_RUBY_VERSION=3.2.3 ruby repro.rb 2 ruby 3.2.3 (2024-01-18 revision 52bb2ac0a6) [x86_64-linux] "RUBY: 3.2.3" "OK: ciphertext_rbnacl is not valid UTF-8" "OK: ciphertext_local is not valid UTF-8" "OK: plaintext_rbnacl is not valid UTF-8" "OK: plaintext_local is not valid UTF-8" ``` ### Ruby 3.3 ``` $ ASDF_RUBY_VERSION=3.3.0 ruby -v; ASDF_RUBY_VERSION=3.3.0 ruby repro.rb 1 ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux] "RUBY: 3.3.0" "FAIL: ciphertext_rbnacl is not valid UTF-8 and did not error during encoding to UTF-8" "FAIL: ciphertext_local is not valid UTF-8 and did not error during encoding to UTF-8" "FAIL: plaintext_rbnacl is not valid UTF-8 and did not error during encoding to UTF-8" "FAIL: plaintext_local is not valid UTF-8 and did not error during encoding to UTF-8" $ ASDF_RUBY_VERSION=3.3.0 ruby -v; ASDF_RUBY_VERSION=3.3.0 ruby repro.rb 2 ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux] "RUBY: 3.3.0" "OK: ciphertext_rbnacl is not valid UTF-8" "OK: ciphertext_local is not valid UTF-8" "OK: plaintext_rbnacl is not valid UTF-8" "OK: plaintext_local is not valid UTF-8" ``` ### Ruby Master ``` $ ASDF_RUBY_VERSION=ruby-dev ruby -v; ASDF_RUBY_VERSION=ruby-dev ruby repro.rb 1 ruby 3.4.0dev (2024-04-06T17:33:16Z master ad90fdd24c) [x86_64-linux] "RUBY: 3.4.0" "OK: ciphertext_rbnacl is not valid UTF-8" "OK: ciphertext_local is not valid UTF-8" "OK: plaintext_rbnacl is not valid UTF-8" "OK: plaintext_local is not valid UTF-8" $ ASDF_RUBY_VERSION=ruby-dev ruby -v; ASDF_RUBY_VERSION=ruby-dev ruby repro.rb 2 ruby 3.4.0dev (2024-04-06T17:33:16Z master ad90fdd24c) [x86_64-linux] "RUBY: 3.4.0" "OK: ciphertext_rbnacl is not valid UTF-8" "OK: ciphertext_local is not valid UTF-8" "OK: plaintext_rbnacl is not valid UTF-8" "OK: plaintext_local is not valid UTF-8" ``` ---Files-------------------------------- repro.rb (2.31 KB) -- https://bugs.ruby-lang.org/

3 3

[ruby-core:117034] [Ruby master Misc#20320] Using OSU Open Source Lab native ppc64le/s390x CI services trigged on pull-requests
by jaruga (Jun Aruga) 08 Apr '24

08 Apr '24

Issue #20320 has been reported by jaruga (Jun Aruga). ---------------------------------------- Misc #20320: Using OSU Open Source Lab native ppc64le/s390x CI services trigged on pull-requests https://bugs.ruby-lang.org/issues/20320 * Author: jaruga (Jun Aruga) * Status: Open ---------------------------------------- We have been using Travis CI to run unit tests the native arm64/ppc64le/s390x in the ruby/ruby, ruby/zlib and ruby/prism repositories in the Ruby project. One of the challenges is Travis CI's chronic unstable infra issues. To be fair, folks at Travis CI support are helpful, usually responding quickly, sometimes not. And I hope Travis CI will find the root causes of the issues. However, I would like to find alternative way to run the native ppc64le/s390x pipelines on pull-requests to change the current challenge fundamentally. And I heard from folks at IBM that the there were CI services that we could run on the pull-requests. The CI services are Jenkins services provided by Oregon State University (OSU) Open Source Lab below. The CI services are the only alternative of running the native ppc64le/s390x pipelines on pull-requests as far as I know. As a note, we are already using SSH-accessing servers provided by OSU Open Source Lab. * PowerPC64 (ppc64le): https://osuosl.org/services/powerdev/ - POWER Continuous Integration (POWER CI) * IBM Z (s390x): https://osuosl.org/services/ibm-z/ - IBM Z Continuous Integration (IBM Z CI) Today I requested the CI services from the request form pages above. And I will try the services by myself first. Then if it looks good to us, I want to migrate the Travis CI ppc64le/s390x pipelines to the OSU Open Source Lab's ones. I will comment on this ticket when there are updates. -- https://bugs.ruby-lang.org/

1 3

[ruby-core:115649] [Ruby master Bug#20050] Segfault on Ruby 3.2.2 on x86_64 Darwin 20 (maybe in Array#hash)
by martinemde (Martin Emde) 08 Apr '24

08 Apr '24

Issue #20050 has been reported by martinemde (Martin Emde). ---------------------------------------- Bug #20050: Segfault on Ruby 3.2.2 on x86_64 Darwin 20 (maybe in Array#hash) https://bugs.ruby-lang.org/issues/20050 * Author: martinemde (Martin Emde) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-darwin20] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Hi, In the rubygems & bundler repositories we've now had two segfaults in the same exact code within days of merging a change to that code, both on ruby 3.2.2 on darwin20. 1. https://github.com/rubygems/rubygems/actions/runs/7110489973/job/1935706778… 2. https://github.com/rubygems/rubygems/actions/runs/7131889001/job/1942130416… The specific error seems to happen when calculating the hash of the array in Gem::NameTuple#hash. The array contents that is being `.hash`ed both times should be exactly: `["has_metadata", "1.0", "ruby"]`. If I'm reading this correctly, this indicates that the crash is related either to creating this hash or storing this hash in the hash table (I'm not quite sure which is triggering the crash). An excerpt of the C backtrace shows the same backtrace for both crashes: ``` -- C level backtrace information ------------------------------------------- /Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_vm_bugreport+0x7c4) [0x10cb0f994] /Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_bug_for_fatal_signal+0x1d0) [0x10c9158c0] /Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(sigsegv+0x5b) [0x10ca609ab] /usr/lib/system/libsystem_platform.dylib(_sigtramp+0x1d) [0x7ff810c14dfd] /Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_id_table_lookup+0x16) [0x10caa2a56] /Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(callable_method_entry_or_negative+0x5e) [0x10cae9c8e] /Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_check_funcall_basic_kw+0x129) [0x10caf0039] /Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(obj_any_hash+0x3c) [0x10c94bd2c] /Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(any_hash+0x52) [0x10c94bc12] /Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_st_add_direct+0x1d) [0x10ca69b7d] /Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(ar_try_convert_table+0x85) [0x10c94d015] /Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_hash_aset+0x18f) [0x10c94e26f] ``` I'm not sure how to follow this instruction in this case on GitHub actions: "Don't forget to include the Crash Report log file under DiagnosticReports directory in bug reports." I have not been able to reproduce this locally with the same version of ruby (but I'm on darwin22 instead of 20). I will follow up if we continue to see this same crash. -- https://bugs.ruby-lang.org/

6 10