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

[ruby-core:112438] [Ruby master Feature#19440] Deprecate ThreadGroup

by Eregon (Benoit Daloze)

Issue #19440 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #19440: Deprecate ThreadGroup https://bugs.ruby-lang.org/issues/19440 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal ---------------------------------------- I looked at the ThreadGroup methods, and none of them seem really useful. `enclose` has super confusing semantics, in that it surprisingly allows creating new threads from a thread already in that group, but forbids `#add`. So the new thread is not the same as "adding" a thread, very confusing. This weird restriction results for instance in `Timeout` not being able to move the Thread it creates to the default ThreadGroup: https://github.com/ruby/timeout/issues/24 And there is also no method to create a Thread in the given ThreadGroup. `add` and `list` could just be simulated with an Array. Maybe it's time we deprecate ThreadGroup or at least `enclose`/`enclosed?` since those seem to have unusable/useless semantics? If not, how do we cleanly solve https://github.com/ruby/timeout/issues/24? -- https://bugs.ruby-lang.org/

1 year, 2 months

5
5
0 0

[ruby-core:112200] [Ruby master Feature#19406] Allow declarative reference definition for rb_typed_data_struct

by eightbitraptor (Matthew Valentine-House)

Issue #19406 has been reported by eightbitraptor (Matthew Valentine-House). ---------------------------------------- Feature #19406: Allow declarative reference definition for rb_typed_data_struct https://bugs.ruby-lang.org/issues/19406 * Author: eightbitraptor (Matthew Valentine-House) * Status: Open * Priority: Normal ---------------------------------------- [Github PR 7153](https://github.com/ruby/ruby/pull/7153) ## Summary This PR proposes an additional API for C extension authors to define wrapped struct members that point to Ruby objects, when the struct being wrapped contains only members with primitive types (ie. no arrays or unions). The new interface passes an offset from the top of the data structure, rather than the reference `VALUE` itself, allowing the GC to manipulate both the reference edge (the address holding the pointer), as well as the underlying object. This allows Ruby's GC to handle marking, object movement and reference updating independently without calling back into user supplied code. ## Implementation When a wrapped struct contains a simple list of members (such as the `struct enumerator` in `enumerator.c`). We can declare all of the struct members that may point to valid Ruby objects as `RUBY_REF_EDGE` in a static array. If we choose to do this, then we can mark the corresponding `rb_data_type_t` as `RUBY_TYPED_DECL_MARKING` and pass a pointer to the references array in the `data` field. To avoid having to also find space in the `rb_data_type_t` to define a length for the references list, I've chosen to require list termination with `RUBY_REF_END` - defined as `UINTPTR_MAX`. My assumption is that no single wrapped struct will ever be large enough that `UINTPTR_MAX` is actually a valid reference. We don't have to then define `dmark` or `dcompact` callback functions. Marking, object movement, and reference updating will be handled for us by the GC. ```C struct enumerator { VALUE obj; ID meth; VALUE args; VALUE fib; VALUE dst; VALUE lookahead; VALUE feedvalue; VALUE stop_exc; VALUE size; VALUE procs; rb_enumerator_size_func *size_fn; int kw_splat; }; static const size_t enumerator_refs[] = { RUBY_REF_EDGE(enumerator, obj), RUBY_REF_EDGE(enumerator, args), RUBY_REF_EDGE(enumerator, fib), RUBY_REF_EDGE(enumerator, dst), RUBY_REF_EDGE(enumerator, lookahead), RUBY_REF_EDGE(enumerator, feedvalue), RUBY_REF_EDGE(enumerator, stop_exc), RUBY_REF_EDGE(enumerator, size), RUBY_REF_EDGE(enumerator, procs), RUBY_REF_END }; static const rb_data_type_t enumerator_data_type = { "enumerator", { NULL, enumerator_free, enumerator_memsize, NULL, }, 0, (void *)enumerator_refs, RUBY_TYPED_FREE_IMMEDIATELY | RUBY_TYPED_DECL_MARKING }; ``` ### Benchmarking Benchmarking shows that this reference declaration style does not degrade performance when compared to the callback style. To benchmark this we created a C extension that initialized a struct with 20 `VALUE` members, all set to point to Ruby strings. We wrapped each struct using `TypedData_Make_Struct` in an object. One object was configured with callback functions and one was configured with declarative references. In separate scripts we then created 500,000 of these objects, added them to a list, so they would be marked and not swept and used `GC.verify_compaction_references` to make sure everything that could move, did. Finally we created a wrapper script that used seperate processes to run each GC type (to ensure that the GC's were completely independent), ran each benchmark 50 times, and collected the results of `GC.stat[:time]`. We did this on an M1 Pro MacBook (aarch64), and a Ryzen 3600 We then plotted the results: ![chart showing GC time between callback and declarative marking on arm64 and x86_64](https://user-images.githubusercontent.com/31869/216573409-ddafa3bd-… As we can see from this, there has been no real impact to GC performance in our benchmarks. Benchmark code and harnesses is [available in this Github repo](https://github.com/eightbitraptor/test_decl_marking) ## Justification Requiring extension authors to implement seperate `dmark` and `dcompact` callbacks can be error-prone, and pushes GC responsibilities from the GC into user supplied code. This can be a source of bugs arising from the `dmark` and `dcompact` functions being implemented incorrectly, or becoming out of sync with each other. There has already been work done by @Peterzhu2118 [to try and unify these callbacks](https://github.com/ruby/ruby/pull/7140), so that authors can define a single function, that will be used for both marking and compacting, removing the risk of these callbacks becoming out of sync. This proposal works alongside Peter's earlier work to eliminate the callbacks entirely for the "simple reference" case. This means that extension authors with simple structs to wrap can declare which of their struct members point to Ruby objects to get GC marking and compaction support. And extension authors with more complex requirements will only have to implement a single function, using Peter's work. In addition to this, passing the GC the address of a reference rather than the reference itself (edge based, rather than object based enqueing), allows the GC itself to have more control over how it manipulates that reference. This means that when considering alternative GC implementations for Ruby (such as our [ongoing work integrating MMTk into Ruby](https://github.com/mmtk/mmtk-ruby)[^1]), We don't need to call from Ruby into library code, and then back into Ruby code as often; which can increase performance, and allow more complex algorithms to be implemented. [^1]: [MMtk](https://www.mmtk.io/) is the Memory Management Toolkit. A framework for implementing automatic memory management strategies ## Trade-offs This PR provides another method for defining references in C extensions, in addition to the callback based approach, effectively widening the extension API. Extension authors will now need to choose whether to use the declarative approach, or a callback based approach depending on their use case. This is more complex for extension authors. However because the callback's do still exist, this does mean that extension authors can migrate their own code to this new, faster approach at their leisure. ## Further work As part of this work we inspected all uses of `rb_data_type_t` in the Ruby source code and of 134 separete instances, 60 wrapped structs that contained `VALUE` members that could point to Ruby objects. Out of these 27 were "simple" structs that would benefit from this approach, 28 contained complex references (unions, loops etc) that won't work with this approach, and 5 were situations that were unsure, that we believe we could make work given some slight refactors. -- https://bugs.ruby-lang.org/

1 year, 2 months

5
5
0 0

[ruby-core:112427] [Ruby master Feature#19437] Add marking and sweeping time to GC.stat

by peterzhu2118 (Peter Zhu)

Issue #19437 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Feature #19437: Add marking and sweeping time to GC.stat https://bugs.ruby-lang.org/issues/19437 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Priority: Normal ---------------------------------------- Pull Request: https://github.com/ruby/ruby/pull/7304 There is a `time` key in GC.stat that gives us the total time spent in GC. However, we don't know what proportion of the time is spent between marking and sweeping. This makes it difficult to tune the GC as we're not sure where to focus our efforts on. This PR adds keys `marking_time` and `sweeping_time` to GC.stat for the time spent marking and sweeping, in milliseconds. -- https://bugs.ruby-lang.org/

1 year, 2 months

6
6
0 0

[ruby-core:112841] [Ruby master Bug#18464] RUBY_INTERNAL_EVENT_NEWOBJ tracepoint causes an interpreter crash when combined with Ractors

by byroot (Jean Boussier)

Issue #18464 has been updated by byroot (Jean Boussier). Backport changed from 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN to 2.6: DONTNEED, 2.7: DONTNEED, 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED The fix was merged as 7bd7aee02e303de27d2cddfc5ef47e612d6782cb ---------------------------------------- Bug #18464: RUBY_INTERNAL_EVENT_NEWOBJ tracepoint causes an interpreter crash when combined with Ractors https://bugs.ruby-lang.org/issues/18464#change-102352 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Assigned * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [x86_64-darwin20] * Backport: 2.6: DONTNEED, 2.7: DONTNEED, 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- When a Ractor is created whilst a tracepoint for `RUBY_INTERNAL_EVENT_NEWOBJ` is active (registered with `rb_tracepoint_new`/`rb_tracepoint_enabled`), the interpreter crashes with a null pointer dereference with the following backtrace: ``` [BUG] Segmentation fault at 0x0000000000000000 ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [x86_64-darwin20] ... -- C level backtrace information ------------------------------------------- /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_print_backtrace+0xf) [0x10a15fadd] vm_dump.c:759 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_vm_bugreport) vm_dump.c:1045 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_vm_bugreport) (null):0 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(bug_report_end+0x0) [0x109f96b81] error.c:820 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_bug_for_fatal_signal) error.c:820 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(sigsegv+0x52) [0x10a0be3a2] signal.c:964 /usr/lib/system/libsystem_platform.dylib(_sigtramp+0x1d) [0x7fff20934d7d] /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(gc_event_hook_body+0x4) [0x109fb9d21] gc.c:2214 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_slowpath) gc.c:2486 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_slowpath_wb_unprotected) gc.c:2507 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_fill+0x0) [0x109fac92e] gc.c:2543 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_of0) gc.c:2553 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_of) gc.c:2552 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_wb_unprotected_newobj_of) gc.c:2567 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(io_alloc+0x12) [0x109fd341c] io.c:1047 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(prep_io) io.c:8483 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(prep_stdio) io.c:8514 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_io_prep_stdin) io.c:8532 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(thread_start_func_2+0xf7) [0x10a1058a7] thread.c:802 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_native_cond_initialize+0x0) [0x10a1055fb] ./thread_pthread.c:1047 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(register_cached_thread_and_wait) ./thread_pthread.c:1099 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(thread_start_func_1) ./thread_pthread.c:1054 /usr/lib/system/libsystem_pthread.dylib(_pthread_start+0xe0) [0x7fff208ef8fc] ``` (full output is attached). This seems to be because the new Ractor sets up stdio objects (`rb_io_prep_stdin` et. al.), which in turn allocate Ruby objects, before `rb_ec_initialize_vm_stack` is called to set up the initial stack frame. I've attached a patch which works around this by not firing GC event hooks if there is no control frame on the execution context. The patch also includes a test which reproduces the issue using the `objspace` extension; creating a Ractor within an `ObjectSpace.trace_object_allocations` block is enough to trigger the crash. The patch seems to fix things, but if you folk prefer I can also try swapping around the order of `prep_stdio` and `rb_ec_initialize_vm_stack`. ---Files-------------------------------- 0001-Fix-interpreter-crash-caused-by-RUBY_INTERNAL_EVENT_.patch (1.91 KB) crash.log (26.1 KB) ruby_2022-01-08-151326_8927-ktsanaktsidis.crash (18.8 KB) -- https://bugs.ruby-lang.org/

1 year, 2 months

1
0
0 0

[ruby-core:112840] [Ruby master Bug#18464] RUBY_INTERNAL_EVENT_NEWOBJ tracepoint causes an interpreter crash when combined with Ractors

by ivoanjo (Ivo Anjo)

Issue #18464 has been updated by ivoanjo (Ivo Anjo). The PR to fix this has been merged ( https://github.com/ruby/ruby/pull/5990 ). Would it be possible for the fix to be backported to 3.0/3.1/3.2? There's a few features in the [ddtrace](https://github.com/datadog/dd-trace-rb) gem that can trigger this crash and that we've had to disable for these Rubies. ---------------------------------------- Bug #18464: RUBY_INTERNAL_EVENT_NEWOBJ tracepoint causes an interpreter crash when combined with Ractors https://bugs.ruby-lang.org/issues/18464#change-102351 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Assigned * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [x86_64-darwin20] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- When a Ractor is created whilst a tracepoint for `RUBY_INTERNAL_EVENT_NEWOBJ` is active (registered with `rb_tracepoint_new`/`rb_tracepoint_enabled`), the interpreter crashes with a null pointer dereference with the following backtrace: ``` [BUG] Segmentation fault at 0x0000000000000000 ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [x86_64-darwin20] ... -- C level backtrace information ------------------------------------------- /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_print_backtrace+0xf) [0x10a15fadd] vm_dump.c:759 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_vm_bugreport) vm_dump.c:1045 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_vm_bugreport) (null):0 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(bug_report_end+0x0) [0x109f96b81] error.c:820 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_bug_for_fatal_signal) error.c:820 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(sigsegv+0x52) [0x10a0be3a2] signal.c:964 /usr/lib/system/libsystem_platform.dylib(_sigtramp+0x1d) [0x7fff20934d7d] /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(gc_event_hook_body+0x4) [0x109fb9d21] gc.c:2214 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_slowpath) gc.c:2486 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_slowpath_wb_unprotected) gc.c:2507 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_fill+0x0) [0x109fac92e] gc.c:2543 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_of0) gc.c:2553 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_of) gc.c:2552 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_wb_unprotected_newobj_of) gc.c:2567 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(io_alloc+0x12) [0x109fd341c] io.c:1047 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(prep_io) io.c:8483 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(prep_stdio) io.c:8514 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_io_prep_stdin) io.c:8532 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(thread_start_func_2+0xf7) [0x10a1058a7] thread.c:802 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_native_cond_initialize+0x0) [0x10a1055fb] ./thread_pthread.c:1047 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(register_cached_thread_and_wait) ./thread_pthread.c:1099 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(thread_start_func_1) ./thread_pthread.c:1054 /usr/lib/system/libsystem_pthread.dylib(_pthread_start+0xe0) [0x7fff208ef8fc] ``` (full output is attached). This seems to be because the new Ractor sets up stdio objects (`rb_io_prep_stdin` et. al.), which in turn allocate Ruby objects, before `rb_ec_initialize_vm_stack` is called to set up the initial stack frame. I've attached a patch which works around this by not firing GC event hooks if there is no control frame on the execution context. The patch also includes a test which reproduces the issue using the `objspace` extension; creating a Ractor within an `ObjectSpace.trace_object_allocations` block is enough to trigger the crash. The patch seems to fix things, but if you folk prefer I can also try swapping around the order of `prep_stdio` and `rb_ec_initialize_vm_stack`. ---Files-------------------------------- 0001-Fix-interpreter-crash-caused-by-RUBY_INTERNAL_EVENT_.patch (1.91 KB) crash.log (26.1 KB) ruby_2022-01-08-151326_8927-ktsanaktsidis.crash (18.8 KB) -- https://bugs.ruby-lang.org/

1 year, 2 months

1
0
0 0

[ruby-core:112834] [Ruby master Feature#8948] Frozen regex

by Eregon (Benoit Daloze)

Issue #8948 has been updated by Eregon (Benoit Daloze). Assignee changed from matz (Yukihiro Matsumoto) to Eregon (Benoit Daloze) I'll try it when I get some time. ---------------------------------------- Feature #8948: Frozen regex https://bugs.ruby-lang.org/issues/8948#change-102345 * Author: sawa (Tsuyoshi Sawada) * Status: Assigned * Priority: Normal * Assignee: Eregon (Benoit Daloze) ---------------------------------------- =begin I see that frozen string was accepted for Ruby 2.1, and frozen array and hash are proposed in https://bugs.ruby-lang.org/issues/8909. I feel there is even more use case for a frozen regex, i.e., a regex literal that generates a regex only once. It is frequent to have a regex within a frequently repeated portion of code, and generating the same regex each time is a waste of resource. At the moment, we can have a code like: class Foo RE1 = /pattern1/ RE2 = /pattern1/ RE3 = /pattern1/ def classify case self when RE1 then 1 when RE2 then 2 when RE3 then 3 else 4 end end end but suppose we have a frozen `Regexp` literal `//f`. Then we can write like: class Foo def classify case self when /pattern1/f then 1 when /pattern1/f then 2 when /pattern1/f then 3 else 4 end end end =end -- https://bugs.ruby-lang.org/

1 year, 2 months

1
0
0 0

[ruby-core:112833] [Ruby master Feature#8948] Frozen regex

by Eregon (Benoit Daloze)

Issue #8948 has been updated by Eregon (Benoit Daloze). TruffleRuby has all Regexp objects frozen since a while, it would be great to do the same in CRuby for consistency. ---------------------------------------- Feature #8948: Frozen regex https://bugs.ruby-lang.org/issues/8948#change-102344 * Author: sawa (Tsuyoshi Sawada) * Status: Assigned * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- =begin I see that frozen string was accepted for Ruby 2.1, and frozen array and hash are proposed in https://bugs.ruby-lang.org/issues/8909. I feel there is even more use case for a frozen regex, i.e., a regex literal that generates a regex only once. It is frequent to have a regex within a frequently repeated portion of code, and generating the same regex each time is a waste of resource. At the moment, we can have a code like: class Foo RE1 = /pattern1/ RE2 = /pattern1/ RE3 = /pattern1/ def classify case self when RE1 then 1 when RE2 then 2 when RE3 then 3 else 4 end end end but suppose we have a frozen `Regexp` literal `//f`. Then we can write like: class Foo def classify case self when /pattern1/f then 1 when /pattern1/f then 2 when /pattern1/f then 3 else 4 end end end =end -- https://bugs.ruby-lang.org/

1 year, 2 months

1
0
0 0

[ruby-core:112832] [Ruby master Feature#17684] Remove `--disable-gems` from release version of Ruby

by hsbt (Hiroshi SHIBATA)

Issue #17684 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Open to Assigned Assignee set to hsbt (Hiroshi SHIBATA) ---------------------------------------- Feature #17684: Remove `--disable-gems` from release version of Ruby https://bugs.ruby-lang.org/issues/17684#change-102339 * Author: hsbt (Hiroshi SHIBATA) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- In my understand, `--disable-gems` is only debugging feature for ruby-core team. But some users enabled its option in test environment for performance or etc. So, `--disable-gems` option is wrong usage for some users. * https://github.com/rubygems/bundler/issues/7487#issuecomment-569901549 * https://github.com/rubygems/rubygems/pull/4440#issue-587031184 We should remove it from package version of ruby. -- https://bugs.ruby-lang.org/

1 year, 2 months

1
0
0 0

[ruby-core:112831] [Ruby master Bug#18789] make test-bundled-gems failed after make install

by hsbt (Hiroshi SHIBATA)

Issue #18789 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Open to Assigned Assignee set to hsbt (Hiroshi SHIBATA) ---------------------------------------- Bug #18789: make test-bundled-gems failed after make install https://bugs.ruby-lang.org/issues/18789#change-102338 * Author: znz (Kazuhiro NISHIYAMA) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * ruby -v: ruby 3.2.0dev (2022-05-17T22:12:44Z master e2bad65eab) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- On snapshot-master CI, `make test-bundled-gems` failed. https://github.com/ruby/actions/runs/6476724416?check_suite_focus=true#step… ``` ./tool/test-bundled-gems.rb:10:in `realpath': No such file or directory @ realpath_rec - /home/runner/work/actions/actions/snapshot-master/.bundle/bin/rake (Errno::ENOENT) from ./tool/test-bundled-gems.rb:10:in `<main>' make: *** [uncommon.mk:1410: test-bundled-gems-run] Error 1 ``` I investigated it, it causes after `make install`. How to reproduce: 1. Run configure 2. `make install` 3. `make test-bundled-gems` or In already built directory 1. `rm -rf path/to/srcdir/.bundle` 2. `make install` 3. `make test-bundled-gems` If I run `rm -rf path/to/srcdir/.bundle` and `make test-bundled-gems` without `make install`, `.bundle/bin/rake` exists. -- https://bugs.ruby-lang.org/

1 year, 2 months

1
0
0 0

[ruby-core:112794] [Ruby master Bug#19524] Garbage Collector is not working as expected.

by hjimenez89rb

Issue #19524 has been reported by hjimenez89rb (Hugo Alberto Jiménez Santos). ---------------------------------------- Bug #19524: Garbage Collector is not working as expected. https://bugs.ruby-lang.org/issues/19524 * Author: hjimenez89rb (Hugo Alberto Jiménez Santos) * Status: Open * Priority: Normal * ruby -v: 3.1.2 * 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 . WE have been using ibm_db-5.4.0 to establish a connection. We are currently following the IBM and Ruby documentation but the application crashes by garbage collector Ruby error. 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): */usr/local/rvm/gems/ruby-3.2.1/gems/ibm_db-5.4.0/lib/active_record/connection_adapters/ibm_db_adapter.rb:3104: warning: undefining the allocator of T_DATA class IBM_DB::Statement /usr/local/rvm/rubies/ruby-3.2.1/lib/ruby/3.2.0/rubygems/specification.rb:1048: [BUG] object allocation during garbage collection phase *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)" As an extra error, we're not sure if Warning! PATH is not properly set up, /usr/local/rvm/gems/ruby-3.2.1/bin is not at first place. Usually this is caused by shell initialization files. Search for PATH=... entries. You can also re-add RVM to your profile by running: rvm get stable --auto-dotfiles To fix it temporarily in this shell session run: rvm use ruby-3.2.1 To ignore this error add rvm_silence_path_mismatch_check_flag=1 to your ~/.rvmrc file. Garbage collector leack test this code we have been running manually garbage collector, if you can see in this example:T_STRING. is not deceasing the stings in live memory, Even executig GC manualy. (log is attached) GC.disable # Only run GC when manually called an_array = [] loop do 1000.times { an_array << "A" + "B" + "C" } puts "Array is #{an_array.size} items long" GC.start # Run a major GC - use full_mark: false for minor GC pp ObjectSpace.count_objects sleep 1 end ---Files-------------------------------- LOGS3.txt (12.5 KB) LOGS4.txt (127 KB) LOGS2.txt (9.62 KB) LOGS1.txt (123 KB) leacky.txt (3.64 KB) -- https://bugs.ruby-lang.org/

1 year, 2 months

3
2
0 0

2024

2023

2022

ruby-core March 2023