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

[ruby-core:112213] [Ruby master Bug#19412] Socket starts queueing and not responding after a certain amount of requests
by brodock (Gabriel Mazetto) 16 Mar '23

16 Mar '23

Issue #19412 has been reported by brodock (Gabriel Mazetto). ---------------------------------------- Bug #19412: Socket starts queueing and not responding after a certain amount of requests https://bugs.ruby-lang.org/issues/19412 * Author: brodock (Gabriel Mazetto) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Here is a an example code: ``` require 'socket' PORT = 8080 BACKLOG = 50 LISTEN = '127.0.0.1' def handle_connection(connection, _addrinfo) request = connection.gets puts request connection.write "HTTP/1.1 200\r\n" connection.write "Content-Type: text/html\r\n" connection.write "\r\n" connection.write "Hello world! Current time is #{Time.now}" ensure connection.close end begin socket = Socket.new(:INET, :STREAM) socket.bind(Addrinfo.tcp(LISTEN, PORT)) socket.listen(BACKLOG) puts "Requested queue size: #{BACKLOG} bigger then limit: #{Socket::SOMAXCONN}" if BACKLOG > Socket::SOMAXCONN loop do listening, = IO.select([socket]) io, = listening connection, addrinfo = io.accept handle_connection(connection, addrinfo) end ensure socket.close end ``` This tries to simulate a TCP server that responds as if it was an HTTP server. The amount of requests it can sustain seems to depend on the OS. On a Linux machine running ubuntu 20.04 I get something around 7.6K to 7.8K until it stops responding. ``` $ uname -a Linux ... 5.17.5-x86_64-linode154 #1 SMP PREEMPT Mon May 2 15:07:22 EDT 2022 x86_64 x86_64 x86_64 GNU/Linux $ ab -n 20000 -c 50 http://127.0.0.1:8080/ This is ApacheBench, Version 2.3 <$Revision: 1843412 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking 127.0.0.1 (be patient) Completed 2000 requests Completed 4000 requests Completed 6000 requests apr_pollset_poll: The timeout specified has expired (70007) Total of 7883 requests completed ``` on MacOS Ventura I get around 16K: ``` $ uname -a Darwin ... 22.2.0 Darwin Kernel Version 22.2.0: Fri Nov 11 02:04:44 PST 2022; root:xnu-8792.61.2~4/RELEASE_ARM64_T8103 arm64 $ ab -n 20000 -c 50 http://127.0.0.1:8080/ This is ApacheBench, Version 2.3 <$Revision: 1901567 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking 127.0.0.1 (be patient) Completed 2000 requests Completed 4000 requests Completed 6000 requests Completed 8000 requests Completed 10000 requests Completed 12000 requests Completed 14000 requests Completed 16000 requests apr_socket_recv: Operation timed out (60) Total of 16375 requests completed ``` in both cases when that limit reaches, if I abort the program (CTRL-C) and try to run it again it takes a while until the port is released: ``` ... GET / HTTP/1.0 GET / HTTP/1.0 GET / HTTP/1.0 ^Csocketserver.rb:29:in `select': Interrupt from socketserver.rb:29:in `block in <main>' from socketserver.rb:28:in `loop' from socketserver.rb:28:in `<main>' $ ruby socketserver.rb socketserver.rb:23:in `bind': Address already in use - bind(2) for 127.0.0.1:8080 (Errno::EADDRINUSE) from socketserver.rb:23:in `<main>' ``` After killing the process it seems no process is holding the port: ``` lsof -wni tcp:8080 ``` Running the command above does not return anything (it does when the program is still running). I think we may be failing to release something when interacting with the Socket on syscalls/kernel level and we endup filling up some queue/buffer that eventually gets freed. -- https://bugs.ruby-lang.org/

4 12

[ruby-core:112899] [Ruby master Bug#4040] SystemStackError with Hash[*a] for Large _a_
by Eregon (Benoit Daloze) 15 Mar '23

15 Mar '23

Issue #4040 has been updated by Eregon (Benoit Daloze). Regarding the original report, there is a clear solution now with `to_h`: ```ruby 1000.times.each_slice(2).to_a.to_h # or 1000.times.each_slice(2).to_h ``` ---------------------------------------- Bug #4040: SystemStackError with Hash[*a] for Large _a_ https://bugs.ruby-lang.org/issues/4040#change-102416 * Author: runpaint (Run Paint Run Run) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 1.9.3dev (2010-11-09 trunk 29737) [x86_64-linux] * Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN ---------------------------------------- =begin I've been hesitating over whether to file a ticket about this, so please feel free to close if I've made the wrong choice. I often use Hash[*array.flatten] in IRB to convert arrays of arrays into hashes. Today I noticed that if the array is big enough, this would raise a SystemStackError. Puzzled, I looked deeper. I assumed I was hitting the maximum number of arguments a method's argc can hold, but realised that the minimum size of the array needed to trigger this exception differed depending on whether I used IRB or not. So, presumably this is indeed exhausting the stack... In IRB, the following is the minimal reproduction of this problem: Hash[*130648.times.map{ 1 }]; true I haven't looked for the minimum value needed with `ruby -e`, but the following reproduces: ruby -e 'Hash[*1380888.times.map{ 1 }]' I suppose this isn't technically a bug, but maybe it offers another argument for either #666 or an extension of #3131. =end -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112898] [Ruby master Bug#4040] SystemStackError with Hash[*a] for Large _a_
by Eregon (Benoit Daloze) 15 Mar '23

15 Mar '23

Issue #4040 has been updated by Eregon (Benoit Daloze). In other words, for efficiency arguments need to be passed on the stack, e.g. for JITed code. Sure it could be possible to have special handling for "too many arguments" and so something else, but that means making Ruby slower in general, which seems clearly not worth for degenerate cases such as this one. ---------------------------------------- Bug #4040: SystemStackError with Hash[*a] for Large _a_ https://bugs.ruby-lang.org/issues/4040#change-102415 * Author: runpaint (Run Paint Run Run) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 1.9.3dev (2010-11-09 trunk 29737) [x86_64-linux] * Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN ---------------------------------------- =begin I've been hesitating over whether to file a ticket about this, so please feel free to close if I've made the wrong choice. I often use Hash[*array.flatten] in IRB to convert arrays of arrays into hashes. Today I noticed that if the array is big enough, this would raise a SystemStackError. Puzzled, I looked deeper. I assumed I was hitting the maximum number of arguments a method's argc can hold, but realised that the minimum size of the array needed to trigger this exception differed depending on whether I used IRB or not. So, presumably this is indeed exhausting the stack... In IRB, the following is the minimal reproduction of this problem: Hash[*130648.times.map{ 1 }]; true I haven't looked for the minimum value needed with `ruby -e`, but the following reproduces: ruby -e 'Hash[*1380888.times.map{ 1 }]' I suppose this isn't technically a bug, but maybe it offers another argument for either #666 or an extension of #3131. =end -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112897] [Ruby master Bug#4040] SystemStackError with Hash[*a] for Large _a_
by Eregon (Benoit Daloze) 15 Mar '23

15 Mar '23

Issue #4040 has been updated by Eregon (Benoit Daloze). My opinion as a TruffleRuby implementer is I don't TruffleRuby will or can support that. So at least it should be clear that's not something really supported by the Ruby language in general. User code shouldn't pass a million arguments, if it's say > 20 arguments or so one should pass an array, splatting on both sides is silly, it just creates extra copies and is slower. It's a Ruby anti-pattern. So IMO there is no point to fix or support this, such code doesn't make sense and changing the user code is the best fix, for performance and simplicity. ---------------------------------------- Bug #4040: SystemStackError with Hash[*a] for Large _a_ https://bugs.ruby-lang.org/issues/4040#change-102414 * Author: runpaint (Run Paint Run Run) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 1.9.3dev (2010-11-09 trunk 29737) [x86_64-linux] * Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN ---------------------------------------- =begin I've been hesitating over whether to file a ticket about this, so please feel free to close if I've made the wrong choice. I often use Hash[*array.flatten] in IRB to convert arrays of arrays into hashes. Today I noticed that if the array is big enough, this would raise a SystemStackError. Puzzled, I looked deeper. I assumed I was hitting the maximum number of arguments a method's argc can hold, but realised that the minimum size of the array needed to trigger this exception differed depending on whether I used IRB or not. So, presumably this is indeed exhausting the stack... In IRB, the following is the minimal reproduction of this problem: Hash[*130648.times.map{ 1 }]; true I haven't looked for the minimum value needed with `ruby -e`, but the following reproduces: ruby -e 'Hash[*1380888.times.map{ 1 }]' I suppose this isn't technically a bug, but maybe it offers another argument for either #666 or an extension of #3131. =end -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112854] [Ruby master Bug#19526] Rails Active Support behavior change since e87d0882910001ef3b0c2ccd43bf00cee8c34a0c
by yahonda (Yasuo Honda) 15 Mar '23

15 Mar '23

Issue #19526 has been reported by yahonda (Yasuo Honda). ---------------------------------------- Bug #19526: Rails Active Support behavior change since e87d0882910001ef3b0c2ccd43bf00cee8c34a0c https://bugs.ruby-lang.org/issues/19526 * Author: yahonda (Yasuo Honda) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-03-06T06:03:06Z master e87d088291) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This issue has been opened while investigating Rails issue https://github.com/rails/rails/issues/47627#issuecomment-1464724436 ### Steps to reproduce - Run this script saves as diag47627.rb ``` options = { hello: "world" } def test(opts) = opts puts test(*[], **options).equal?(options) ``` ### Expected behavior It returns `false` as Ruby 3.2.1 and Ruby 3.3.0dev 0463c5806a does ``` $ ruby -v ruby 3.3.0dev (2023-03-06T05:52:46Z master 0463c5806a) [x86_64-linux] $ ruby diag47627.rb false $ ``` ``` $ ruby -v ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux] $ ruby diag47627.rb false ``` ### Actual behavior It returns `true` ``` $ ruby -v ruby 3.3.0dev (2023-03-06T06:03:06Z master e87d088291) [x86_64-linux] $ ruby diag47627.rb true ``` ### Workaround Duplicate the value inside the method that restores the original behavior. - another_diag47627.rb ```ruby options = { hello: "world" } def test(opts) = opts.dup puts test(*[], **options).equal?(options) ``` ``` $ ruby -v ruby 3.3.0dev (2023-03-06T05:52:46Z master 0463c5806a) [x86_64-linux] $ ruby another_diag47627.rb false $ ``` At the Rails side, reverting https://github.com/rails/rails/commit/9e4ff29f748b05c3a949f0d75167950039b6c… can also workaround it. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:112541] [Ruby master Bug#19459] Is `length` of `IO::Buffer#read` required or optional?
by nobu (Nobuyoshi Nakada) 15 Mar '23

15 Mar '23

Issue #19459 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #19459: Is `length` of `IO::Buffer#read` required or optional? https://bugs.ruby-lang.org/issues/19459 * Author: nobu (Nobuyoshi Nakada) * Status: Assigned * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Backport: 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONTNEED, 3.2: REQUIRED ---------------------------------------- io_buffer.c has warnings. http://ci.rvm.jp/logfiles/brlog.trunk-asserts.20230222-105209#L956 ``` /tmp/ruby/src/trunk-asserts/io_buffer.c: In function 'io_buffer_read': /tmp/ruby/src/trunk-asserts/io_buffer.c:2468:12: warning: 'length' may be used uninitialized in this function [-Wmaybe-uninitialized] 2468 | return rb_io_buffer_read(self, io, length, offset); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /tmp/ruby/src/trunk-asserts/io_buffer.c: In function 'io_buffer_write': /tmp/ruby/src/trunk-asserts/io_buffer.c:2681:12: warning: 'length' may be used uninitialized in this function [-Wmaybe-uninitialized] 2681 | return rb_io_buffer_write(self, io, length, offset); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /tmp/ruby/src/trunk-asserts/io_buffer.c: At top level: cc1: note: unrecognized command-line option '-Wno-self-assign' may have been intended to silence earlier diagnostics cc1: note: unrecognized command-line option '-Wno-parentheses-equality' may have been intended to silence earlier diagnostics cc1: note: unrecognized command-line option '-Wno-constant-logical-operand' may have been intended to silence earlier diagnostics ``` As the `argc` is checked already as `rb_check_arity(argc, 2, 3)`, `length` is a required argument. This means the condition `if (argc >= 2)` is always true and unnecessary, then `length` is initialized. However, in the rdoc of `io_buffer_read`, which has been added at 3.2, states `length` is optional. ```c * call-seq: read(io, [length, [offset]]) -> read length or -errno * * Read at most +length+ bytes from +io+ into the buffer, starting at * +offset+. If an error occurs, return <tt>-errno</tt>. * * If +length+ is not given, read until the end of the buffer. ``` Which is correct? -- https://bugs.ruby-lang.org/

3 3

[ruby-core:112886] [Ruby master Bug#4040] SystemStackError with Hash[*a] for Large _a_
by jeremyevans0 (Jeremy Evans) 14 Mar '23

14 Mar '23

Issue #4040 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Closed to Open I'm reopening this issue. Originally, when commit:2e7bceb34ea858649e1f975a934ce1894d1f06a6 fixed cfuncs to no longer use the VM stack for large array splats, it was thought to have fully fixed this issue, since the issue was fixed for methods defined in Ruby (iseqs) back in Ruby 2.2. After additional research, I determined that the same issue affects almost all types of method calls, not just iseq and cfunc calls. There were two main types of remaining issues, important cases (where large array splat should work) and pedantic cases (where large array splat raised SystemStackError instead of ArgumentError). Important cases: ```ruby # bmethod define_method(:a){|*a|} a(*1380888.times) # send def b(*a); end send(:b, *1380888.times) # symproc :b.to_proc.call(self, *1380888.times) # method to proc def d; yield(*1380888.times) end d(&method(:b)) # method_missing def self.method_missing(*a); end not_a_method(*1380888.times) # Also affects use of C-API with a large number of arguments ``` Pedantic cases: ```ruby # iseq with only required or optional arguments def a; end a(*1380888.times) def b(_); end b(*1380888.times) def c(_=nil); end c(*1380888.times) # attr reader/writer c = Class.new do attr_accessor :a alias b a= end.new c.a(*1380888.times) c.b(*1380888.times) # Struct aref/aset c = Struct.new(:a) do alias b a= end.new c.a(*1380888.times) c.b(*1380888.times) ``` I have submitted a pull request to fix the issue: https://github.com/ruby/ruby/pull/7522. It's fairly invasive, since the use of the VM stack for handling arguments occurs in multiple different places in the VM, and all the different method call handlers need to be updated to support it. This has a runtime cost, but I'm not sure exactly how much. I would appreciate if someone could do some benchmarking with it. We'll need to decide if fixing this issue is worth the potential performance hit (or someone could potentially optimize the approach I used). ---------------------------------------- Bug #4040: SystemStackError with Hash[*a] for Large _a_ https://bugs.ruby-lang.org/issues/4040#change-102402 * Author: runpaint (Run Paint Run Run) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 1.9.3dev (2010-11-09 trunk 29737) [x86_64-linux] * Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN ---------------------------------------- =begin I've been hesitating over whether to file a ticket about this, so please feel free to close if I've made the wrong choice. I often use Hash[*array.flatten] in IRB to convert arrays of arrays into hashes. Today I noticed that if the array is big enough, this would raise a SystemStackError. Puzzled, I looked deeper. I assumed I was hitting the maximum number of arguments a method's argc can hold, but realised that the minimum size of the array needed to trigger this exception differed depending on whether I used IRB or not. So, presumably this is indeed exhausting the stack... In IRB, the following is the minimal reproduction of this problem: Hash[*130648.times.map{ 1 }]; true I haven't looked for the minimum value needed with `ruby -e`, but the following reproduces: ruby -e 'Hash[*1380888.times.map{ 1 }]' I suppose this isn't technically a bug, but maybe it offers another argument for either #666 or an extension of #3131. =end -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112884] [Ruby master Bug#18604] [BUG] ERROR(VpDivd): space for remainder too small
by hsbt (Hiroshi SHIBATA) 14 Mar '23

14 Mar '23

Issue #18604 has been updated by hsbt (Hiroshi SHIBATA). Use [bigdecimal-3.1.2](https://github.com/ruby/bigdecimal/releases/tag/v3.1.2) or later. ---------------------------------------- Bug #18604: [BUG] ERROR(VpDivd): space for remainder too small https://bugs.ruby-lang.org/issues/18604#change-102400 * Author: mentalizer (Jakob Skjerning) * Status: Third Party's Issue * Priority: Normal * ruby -v: ruby 3.1.1p18 (2022-02-18 revision 53f5fc4236) [arm64-darwin21] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- After upgrading to Ruby 3.1 one of our statistical dashboards started crashing with a message saying [BUG] ERROR(VpDivd): space for remainder too small ### How to reproduce This can be reproduced in irb (reproduction script is attached containing the below code): ``` ruby $ irb 3.1.1 :001 > require "bigdecimal" => true 3.1.1 :002 > 1.0 / BigDecimal("0.9652409267836026803310997240835632636973e2") ``` ### Actual result ```ruby (irb):2: [BUG] ERROR(VpDivd): space for remainder too small. ruby 3.1.1p18 (2022-02-18 revision 53f5fc4236) [arm64-darwin21] -- Crash Report log information -------------------------------------------- ... ``` Full output from running reproduction script has been attached. ### Expected results The result of division, which is roughly: ``` => 0.10360107743589181177761764314914637186293143963577706371029263e-1 ``` ### Affected Rubies So far I've been able to reproduce this on... - ruby 3.1.1p18 (2022-02-18 revision 53f5fc4236) [arm64-darwin21] - ruby 3.1.1p18 (2022-02-18 revision 53f5fc4236) [x86_64-linux] - ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [arm64-darwin21] The following seem to work just fine: - ruby 3.0.3p157 (2021-11-24 revision 3fb7d2cadc) [arm64-darwin21] ### Notes Admittedly, the precision here is way higher that we actually need it to be, and our workaround has been to simply convert the BigDecimal to Float before dividing. ```ruby 1.0 / BigDecimal("0.9652409267836026803310997240835632636973e2").to_f # => 0.010360107743589182 ``` ---Files-------------------------------- repro.rb (86 Bytes) ruby-2022-02-24-161721.ips (96 KB) crash.log (469 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112882] [Ruby master Bug#18604] [BUG] ERROR(VpDivd): space for remainder too small
by itsmegrave (Samuel Grave) 14 Mar '23

14 Mar '23

Issue #18604 has been updated by itsmegrave (Samuel Grave). got same issue here with any ruby 3.1.x version:( Any news? ---------------------------------------- Bug #18604: [BUG] ERROR(VpDivd): space for remainder too small https://bugs.ruby-lang.org/issues/18604#change-102398 * Author: mentalizer (Jakob Skjerning) * Status: Third Party's Issue * Priority: Normal * ruby -v: ruby 3.1.1p18 (2022-02-18 revision 53f5fc4236) [arm64-darwin21] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- After upgrading to Ruby 3.1 one of our statistical dashboards started crashing with a message saying [BUG] ERROR(VpDivd): space for remainder too small ### How to reproduce This can be reproduced in irb (reproduction script is attached containing the below code): ``` ruby $ irb 3.1.1 :001 > require "bigdecimal" => true 3.1.1 :002 > 1.0 / BigDecimal("0.9652409267836026803310997240835632636973e2") ``` ### Actual result ```ruby (irb):2: [BUG] ERROR(VpDivd): space for remainder too small. ruby 3.1.1p18 (2022-02-18 revision 53f5fc4236) [arm64-darwin21] -- Crash Report log information -------------------------------------------- ... ``` Full output from running reproduction script has been attached. ### Expected results The result of division, which is roughly: ``` => 0.10360107743589181177761764314914637186293143963577706371029263e-1 ``` ### Affected Rubies So far I've been able to reproduce this on... - ruby 3.1.1p18 (2022-02-18 revision 53f5fc4236) [arm64-darwin21] - ruby 3.1.1p18 (2022-02-18 revision 53f5fc4236) [x86_64-linux] - ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [arm64-darwin21] The following seem to work just fine: - ruby 3.0.3p157 (2021-11-24 revision 3fb7d2cadc) [arm64-darwin21] ### Notes Admittedly, the precision here is way higher that we actually need it to be, and our workaround has been to simply convert the BigDecimal to Float before dividing. ```ruby 1.0 / BigDecimal("0.9652409267836026803310997240835632636973e2").to_f # => 0.010360107743589182 ``` ---Files-------------------------------- repro.rb (86 Bytes) ruby-2022-02-24-161721.ips (96 KB) crash.log (469 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112865] [Ruby master Bug#19527] Object allocation during garbage collection phase
by hjimenez89rb 14 Mar '23

14 Mar '23

Issue #19527 has been reported by hjimenez89rb (Hugo Alberto Jiménez Santos). ---------------------------------------- Bug #19527: Object allocation during garbage collection phase https://bugs.ruby-lang.org/issues/19527 * Author: hjimenez89rb (Hugo Alberto Jiménez Santos) * Status: Open * Priority: Normal * ruby -v: 3.2.1 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- We are currently developing a Ruby based web application which connects to a DB2 Database and we have been using ibm_db-5.4.0 to establish a connection, suddenly we got a error related to RUBY garbage collector PHASE. We have checked the issue with IBM_team to make sure that It was not a IBM_GEM problem but as a result of their tests, IBM_GEM is working in different cases but for us we face up with those errors even with those versions (2.7.6, 3.1.2, 3.2.1): *0x0/usr/local/rvm/gems/ruby-3.1.2/gems/ibm_db-5.4.0/lib/active_record/connection_adapters/ibm_db_adapter.rb:760: [BUG] object allocation during garbage collection phase ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux] *Exception occurred on Step thread ID #SID:34117;RSEQ:911723; wrong instance allocation; backtrace: /usr/local/rvm/gems/ruby-3.1.2/gems/ibm_db-5.4.0/lib/active_record/connection_adapters/ibm_db_adapter.rb:760:in server_info' (RuntimeError) /usr/local/rvm/gems/ruby-3.1.2/gems/ibm_db-5.4.0/lib/active_record/connection_adapters/ibm_db_adapter.rb:760:in initialize'. (all trace is attached in this ticket) OS name: "CentOS" version: "8" architecture: "x86_64" rvm: version: "1.29.12 (latest)" ---Files-------------------------------- LOGS3.txt (12.5 KB) LOGS4.txt (127 KB) LOGS2.txt (9.62 KB) LOGS1.txt (123 KB) -- https://bugs.ruby-lang.org/

4 5