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

[ruby-core:116965] [Ruby master Bug#20307] `Hash#update` from compare_by_identity hash can have unfrozen string keys
by nobu (Nobuyoshi Nakada) 13 Jul '24

13 Jul '24

Issue #20307 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #20307: `Hash#update` from compare_by_identity hash can have unfrozen string keys https://bugs.ruby-lang.org/issues/20307 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED, 3.3: REQUIRED ---------------------------------------- I don't think this behavior is expected. ```ruby i = Hash.new.compare_by_identity k = "a" i[k] = 0 h = {}.update(i) p h["a"] # => 0 k.upcase! p h.fetch(k) # in 'Hash#fetch': key not found: "A" (KeyError) ``` -- https://bugs.ruby-lang.org/

5 6

[ruby-core:116643] [Ruby master Bug#20250] Crash with "Object ID seen, but not in mapping table: proc" error
by zetter (Chris Zetter) 13 Jul '24

13 Jul '24

Issue #20250 has been reported by zetter (Chris Zetter). ---------------------------------------- Bug #20250: Crash with "Object ID seen, but not in mapping table: proc" error https://bugs.ruby-lang.org/issues/20250 * Author: zetter (Chris Zetter) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin23] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Hello, I experienced a crash which I was able to reliably reproduce with the following: ``` ruby require 'bundler/inline' gemfile(true) do source 'https://rubygems.org' gem 'activesupport', '7.1.3' end require 'active_support' logger = ActiveSupport::Logger.new('log/log.log', 1, 100 * 1024 * 1024) logger.formatter = proc {|_, _, _, message| "#{message}\n" } logger = ActiveSupport::TaggedLogging.new(logger) logger.tagged("TAG").info "hello" logger.tagged("TAG").info "hello" # usually crashes here GC.start # sometimes need to trigger crash with GC ``` It looks like this is caused by the interaction with the formatter proc and the tagged logging features of activesupport. Let me know if a more minimal example would be useful. I can reproduce this with: * ruby 3.3.0 on arm64-darwin23 * ruby 3.3.0 on x86_64-linux * latest ruby HEAD (5e12b75716) on arm64-darwin23 I cannot reproduce this on ruby 3.2.2. Thanks for any help ---Files-------------------------------- ruby-2024-02-09-092829.ips (13.2 KB) output.log (142 KB) crash_test_2.rb (465 Bytes) -- https://bugs.ruby-lang.org/

4 5

[ruby-core:118513] [Ruby master Bug#20619] Backport bd583ca645ea348a2894f4227fcb1af650ee8dec to ruby 3.3
by ko1 (Koichi Sasada) 12 Jul '24

12 Jul '24

Issue #20619 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Bug #20619: Backport bd583ca645ea348a2894f4227fcb1af650ee8dec to ruby 3.3 https://bugs.ruby-lang.org/issues/20619 * Author: ko1 (Koichi Sasada) * Status: Closed * Target version: 3.3 * Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: REQUIRED ---------------------------------------- commit:bd583ca645ea348a2894f4227fcb1af650ee8dec (https://github.com/ruby/ruby/pull/11037) should be merged. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:118561] [Ruby master Bug#20629] Ruby infinite loop when raising+rescuing inside a RUBY_INTERNAL_EVENT_NEWOBJ
by ivoanjo (Ivo Anjo) 12 Jul '24

12 Jul '24

Issue #20629 has been reported by ivoanjo (Ivo Anjo). ---------------------------------------- Bug #20629: Ruby infinite loop when raising+rescuing inside a RUBY_INTERNAL_EVENT_NEWOBJ https://bugs.ruby-lang.org/issues/20629 * Author: ivoanjo (Ivo Anjo) * Status: Open * ruby -v: ruby 3.3.4 (2024-07-09 revision be1089c8ec) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ### Background Hey! While working on the [Datadog Ruby Profiler](https://github.com/datadog/dd-trace-rb) I ran into a weird situation where the Ruby VM locks up as it gets stuck in an infinite loop in vm_sync.c: ```c while (recorded_lock_rec < current_lock_rec) { RB_VM_LOCK_LEAVE_LEV(&current_lock_rec); } ``` ...because leave is this: ```c static inline void rb_vm_lock_leave(unsigned int *lev, const char *file, int line) { if (rb_multi_ractor_p()) { rb_vm_lock_leave_body(lev APPEND_LOCATION_PARAMS); } } ``` ...and `rb_multi_ractor_p()` is always `false` as I'm not using Ractors. ### How to reproduce (I include a zip with all the files needed to reproduce this, no need to copy-paste from here!) Inside a native extension, I'm creating a `RUBY_INTERNAL_EVENT_NEWOBJ`. Inside it, I'm raising and catching an exception, to simulate a (handled) bug in our code: ```c #include <ruby.h> #include <ruby/thread.h> #include <ruby/thread_native.h> #include <ruby/debug.h> static VALUE raise_exception(VALUE unused) { fprintf(stderr, "Raising!\n"); rb_raise(rb_eRuntimeError, "This is a test!"); } static VALUE ignore_failure(VALUE self_instance, VALUE exception) { fprintf(stderr, "Caught!\n"); return Qnil; } static void on_newobj_event(VALUE tracepoint_data, void *unused) { fprintf(stderr, "Inside on_newobj_event\n"); // VALUE klass = rb_class_of(rb_tracearg_object(rb_tracearg_from_tracepoint(tracepoint_data))); // rb_p(klass); rb_rescue2( raise_exception, Qnil, ignore_failure, Qnil, rb_eException, // rb_eException is the base class of all Ruby exceptions 0 // Required by API to be the last argument ); fprintf(stderr, "Finished on_newobj_event\n"); } static VALUE install_tracepoint(VALUE unused) { VALUE tp = rb_tracepoint_new(Qnil, RUBY_INTERNAL_EVENT_NEWOBJ, on_newobj_event, NULL /* unused */); rb_tracepoint_enable(tp); fprintf(stderr, "Tracepoint installed!\n"); return Qnil; } void Init_exception_bug_repro(void) { rb_define_singleton_method(rb_define_module("Repro"), "install_tracepoint", install_tracepoint, 0); } ``` And my test Ruby script is: ```ruby require_relative './exception_bug_repro' Repro.install_tracepoint while true begin raise('hello') rescue print '.' end end ``` Here's how running it looks: ``` $ bundle exec rake clean compile $ bundle exec ruby testcase.rb Tracepoint installed! Inside on_newobj_event Raising! Caught! Finished on_newobj_event Inside on_newobj_event Raising! Caught! Finished on_newobj_event Inside on_newobj_event Raising! Caught! Finished on_newobj_event Inside on_newobj_event Raising! Caught! Finished on_newobj_event Inside on_newobj_event Raising! # <--- Infinite loop ``` That is, we should always see the raise -> caught, but sometimes the raise doesn't go very well, and from then Ruby eventually locks up. Here's the full backtrace from gdb: ``` #0 rb_multi_ractor_p () at ruby-3_3/vm_sync.h:39 #1 0x00005fdde2534665 in rb_vm_lock_leave (lev=0x7ffc2f1b5f70, file=0x5fdde2783bb5 "vm_sync.c", line=231) at ruby-3_3/vm_sync.h:92 #2 0x00005fdde2534b28 in rb_ec_vm_lock_rec_release (ec=0x5fdde3e9b570, recorded_lock_rec=0, current_lock_rec=1) at vm_sync.c:231 #3 0x00005fdde23088f2 in rb_ec_vm_lock_rec_check (ec=0x5fdde3e9b570, recorded_lock_rec=0) at ruby-3_3/eval_intern.h:144 #4 0x00005fdde2308937 in rb_ec_tag_state (ec=0x5fdde3e9b570) at ruby-3_3/eval_intern.h:155 #5 0x00005fdde230c71e in setup_exception (ec=0x5fdde3e9b570, tag=6, mesg=126196681963080, cause=4) at eval.c:564 #6 0x00005fdde230cdc5 in rb_longjmp (ec=0x5fdde3e9b570, tag=6, mesg=126196681963080, cause=4) at eval.c:660 #7 0x00005fdde230d398 in rb_raise_jump (mesg=126196681963080, cause=36) at eval.c:853 #8 0x00005fdde230d0cc in rb_f_raise (argc=1, argv=0x72c690294048) at eval.c:752 #9 0x00005fdde230d0f4 in f_raise (c=1, v=0x72c690294048, _=126197147684320) at eval.c:789 #10 0x00005fdde2502d24 in ractor_safe_call_cfunc_m1 (recv=126197147684320, argc=1, argv=0x72c690294048, func=0x5fdde230d0cc <f_raise>) at ruby-3_3/vm_insnhelper.c:3311 #11 0x00005fdde250395b in vm_call_cfunc_with_frame_ (ec=0x5fdde3e9b570, reg_cfp=0x72c690393fa0, calling=0x7ffc2f1b66a0, argc=1, argv=0x72c690294048, stack_bottom=0x72c690294040) at ruby-3_3/vm_insnhelper.c:3502 #12 0x00005fdde2503b30 in vm_call_cfunc_with_frame (ec=0x5fdde3e9b570, reg_cfp=0x72c690393fa0, calling=0x7ffc2f1b66a0) at ruby-3_3/vm_insnhelper.c:3530 #13 0x00005fdde2503c48 in vm_call_cfunc_other (ec=0x5fdde3e9b570, reg_cfp=0x72c690393fa0, calling=0x7ffc2f1b66a0) at ruby-3_3/vm_insnhelper.c:3556 #14 0x00005fdde2504070 in vm_call_cfunc (ec=0x5fdde3e9b570, reg_cfp=0x72c690393fa0, calling=0x7ffc2f1b66a0) at ruby-3_3/vm_insnhelper.c:3638 #15 0x00005fdde2506b9f in vm_call_method_each_type (ec=0x5fdde3e9b570, cfp=0x72c690393fa0, calling=0x7ffc2f1b66a0) at ruby-3_3/vm_insnhelper.c:4429 #16 0x00005fdde25076e0 in vm_call_method (ec=0x5fdde3e9b570, cfp=0x72c690393fa0, calling=0x7ffc2f1b66a0) at ruby-3_3/vm_insnhelper.c:4566 #17 0x00005fdde250784d in vm_call_general (ec=0x5fdde3e9b570, reg_cfp=0x72c690393fa0, calling=0x7ffc2f1b66a0) at ruby-3_3/vm_insnhelper.c:4599 #18 0x00005fdde2509ed2 in vm_sendish (ec=0x5fdde3e9b570, reg_cfp=0x72c690393fa0, cd=0x5fdde3f4f7e0, block_handler=0, method_explorer=mexp_search_method) at ruby-3_3/vm_insnhelper.c:5593 #19 0x00005fdde25114b9 in vm_exec_core (ec=0x5fdde3e9b570) at ruby-3_3/insns.def:834 #20 0x00005fdde252829b in rb_vm_exec (ec=0x5fdde3e9b570) at vm.c:2486 #21 0x00005fdde25290fa in rb_iseq_eval_main (iseq=0x72c674667ad0) at vm.c:2752 #22 0x00005fdde230be59 in rb_ec_exec_node (ec=0x5fdde3e9b570, n=0x72c674667ad0) at eval.c:287 #23 0x00005fdde230bfd6 in ruby_run_node (n=0x72c674667ad0) at eval.c:328 #24 0x00005fdde2307245 in rb_main (argc=2, argv=0x7ffc2f1b7618) at ./main.c:39 #25 0x00005fdde23072bd in main (argc=2, argv=0x7ffc2f1b7618) at ./main.c:58 ``` In this minimal reproducer, usually it's when allocating a `Thread::Backtrace` object that triggers the issue, but on the original codebase where I was experimenting I saw this issue even with other objects (I think??). To be honest, maybe the problem is on the extension side -- this code assumes it's ok to raise/rescue in the `RUBY_INTERNAL_EVENT_NEWOBJ` tracepoint as it usually works fine, but maybe it's not? ---Files-------------------------------- exception-bug-repo.zip (3.79 KB) -- https://bugs.ruby-lang.org/

2 2

[ruby-core:118581] [Ruby master Bug#20632] madvise(MADV_FREE) failure should not crash the process
by kjtsanaktsidis (KJ Tsanaktsidis) 12 Jul '24

12 Jul '24

Issue #20632 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Bug #20632: madvise(MADV_FREE) failure should not crash the process https://bugs.ruby-lang.org/issues/20632 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Assignee: kjtsanaktsidis (KJ Tsanaktsidis) * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The M:N threading stack cleanup machinery here tries to call `MADV_FREE` on the native thread's stack, and calls `rb_bug` if it fails: https://github.com/ruby/ruby/blob/371055979f4e367e90d7af4140e92fd3824bce2a/… Unfortunately, there's no way to distinguish between "You passed bad parameters to madvise" and "MADV_FREE is not supported on the kernel you are running on"; both cases just return `EINVAL`. This means that if you have a Ruby on a system that was built on a system with MADV_FREE and run it on a system without it, you get a crash in `nt_free_stack`. I ran into this because `rr` actually emulates `MADV_FREE` by just returning EINVAL and pretending it's not supported (since it can otherwise introduce nondeterministic behaviour). So if you run `bootstraptest/test_ractor.rb` under rr, you get this crash. I think we should just get rid of the error handling here; freeing memory like this is strictly optional anyway. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118419] [Ruby master Bug#20604] Performance regression in C++ extensions due to lack of optimization flags by default since Ruby 2.7
by ntkme (Natsuki Natsume) 11 Jul '24

11 Jul '24

Issue #20604 has been reported by ntkme (Natsuki Natsume). ---------------------------------------- Bug #20604: Performance regression in C++ extensions due to lack of optimization flags by default since Ruby 2.7 https://bugs.ruby-lang.org/issues/20604 * Author: ntkme (Natsuki Natsume) * Status: Open * ruby -v: ruby 3.3.3 (2024-06-12 revision f1c7b6f435) [arm64-darwin23] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I found a significant performance regression in `sassc` gem when comparing Ruby 2.6 and later, that the extension is running more than 10x slower. I have tracked it down to this commit: https://github.com/ruby/ruby/commit/733aa2f8b578d03bbcb91d2f496b01e3b990c7e8 This commit removed all default CXXFLAGS from RbConfig that were previously set, including `$optflags`, which has `-O3`. Many of the C++ extensions like sassc use extconf/mkmf to compile, and they have assumed optflags are already set for CXXFLAGS. Without `-O3` as part of the default, the extensions are compiled without any optimizations and thus become extremely slow. It is difficult for a regular user to find out the reason of the slowness, nor to say figuring out how to override CXXFLAGS for a native extension. I'm not sure what was the reason of the change, but I think we should at least set `$optflags` in CXXFLAGS by default. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:118569] [Ruby master Misc#20630] Potential optimizations for `NODE_CONST` compilation
by zack.ref＠gmail.com (Zack Deveau) 11 Jul '24

11 Jul '24

Issue #20630 has been reported by zack.ref(a)gmail.com (Zack Deveau). ---------------------------------------- Misc #20630: Potential optimizations for `NODE_CONST` compilation https://bugs.ruby-lang.org/issues/20630 * Author: zack.ref(a)gmail.com (Zack Deveau) * Status: Open ---------------------------------------- ### Description I would like to propose two potential optimizations to the way we currently compile `NODE_CONST` nodes in `compile.c`. I've included commits for each on a related PR. - PR: https://github.com/ruby/ruby/pull/11154 - `NODE_CONST` compilation: [9b6d613](https://github.com/ruby/ruby/commit/9b6d613e19c1132ace64583ac23c94… - `opt_getconstant_path` peephole optimization: [b8ece8c](https://github.com/ruby/ruby/commit/b8ece8ca6e2d60cb7c627927aa89c1… These commits pass `test-all` locally. ### `NODE_CONST` Compilation From what I can tell `NODE_CONST` doesn't appear to follow the conventional use of `popped` found in other similar nodes. For example `NODE_IVAR`, when `popped` (return value not used), will avoid adding the YARV instruction altogether: ```C case NODE_IVAR:{ debugi("nd_vid", RNODE_IVAR(node)->nd_vid); if (!popped) { ADD_INSN2(ret, node, getinstancevariable, ID2SYM(RNODE_IVAR(node)->nd_vid), get_ivar_ic_value(iseq, RNODE_IVAR(node)->nd_vid)); } break; } ``` When compiling a `NODE_CONST` that is `popped`, we instead add either `get_constant` or the optimized `opt_getconstant_path` instruction, followed by adding a `pop`. I've modified it to follow the convention found elsewhere to avoid adding either instruction(s) in cases where we don't need the return value. `test-all` passes locally and I can't think of meaningful side effects (other than we avoid exercising the cache). Please let me know if I'm missing any! ### `opt_getconstant_path` peephole optimization `iseq_peephole_optimize` includes an optimization for `insn -> pop` sequences. Most of the `get_x` instructions are included but we don't appear to include `opt_getconstant_path`. (potentially since it was only recently added in 2022 by @jhawthorn ?) I've included it and attempted to account for any meaningful side effects (here again I can't think of any other than we avoid exercising the cache). Please let me know if I missed any. ### Results `test.rb` ```Ruby NETSCAPE = "navigator" [NETSCAPE, NETSCAPE, NETSCAPE, NETSCAPE] 1 ``` `ruby 3.4.0dev (2024-07-11T19:49:14Z master 6fc83118bb) [arm64-darwin23]` ``` 💾 ➜ ruby --dump insn ./test.rb == disasm: #<ISeq:<main>@./test.rb:1 (1,0)-(3,1)> 0000 putchilledstring "navigator" ( 1)[Li] 0002 putspecialobject 3 0004 setconstant :NETSCAPE 0006 opt_getconstant_path <ic:0 NETSCAPE> ( 2)[Li] 0008 pop 0009 opt_getconstant_path <ic:1 NETSCAPE> 0011 pop 0012 opt_getconstant_path <ic:2 NETSCAPE> 0014 pop 0015 opt_getconstant_path <ic:3 NETSCAPE> 0017 pop 0018 putobject_INT2FIX_1_ ( 3)[Li] 0019 leave ``` `with optimizations` ``` 💾 ➜ ./build/miniruby --dump insn ./test.rb == disasm: #<ISeq:<main>@./test.rb:1 (1,0)-(3,1)> 0000 putchilledstring "navigator" ( 1)[Li] 0002 putspecialobject 3 0004 setconstant :NETSCAPE 0006 putobject_INT2FIX_1_ ( 3)[Li] 0007 leave ``` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:118524] [Ruby master Bug#20622] irb: invalid byte sequence in UTF-8
by chmaynard (Craig Maynard) 11 Jul '24

11 Jul '24

Issue #20622 has been reported by chmaynard (Craig Maynard). ---------------------------------------- Bug #20622: irb: invalid byte sequence in UTF-8 https://bugs.ruby-lang.org/issues/20622 * Author: chmaynard (Craig Maynard) * Status: Open * ruby -v: ruby 3.3.3 (2024-06-12 revision f1c7b6f435) [arm64-darwin23] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Ruby $ irb /opt/homebrew/Cellar/ruby/3.3.3/lib/ruby/3.3.0/reline/config.rb:172:in `match': invalid byte sequence in UTF-8 (ArgumentError) next if line.match(/\A\s*#/) ^^^^^^^^ -- https://bugs.ruby-lang.org/

2 3

[ruby-core:117644] [Ruby master Feature#20443] Allow Major GC's to be disabled
by eightbitraptor (Matthew Valentine-House) 11 Jul '24

11 Jul '24

Issue #20443 has been reported by eightbitraptor (Matthew Valentine-House). ---------------------------------------- Feature #20443: Allow Major GC's to be disabled https://bugs.ruby-lang.org/issues/20443 * Author: eightbitraptor (Matthew Valentine-House) * Status: Open ---------------------------------------- [[Github PR #10598]](https://github.com/ruby/ruby/pull/10598) ## Background Ruby's GC running during Rails requests can have negative impacts on currently running requests, causing applications to have high tail-latency. A technique to mitigate this high tail-latency is Out-of-band GC (OOBGC). This is basically where the application is run with GC disabled, and then GC is explicitly started after each request, or when no requests are in progress. This can reduce the tail latency, but also introduces problems of its own. Long GC pauses after each request reduce throughput. This is more pronounced on threading servers like Puma because all the threads have to finish processing user requests and be "paused" before OOBGC can be triggered. This throughput decrease happens for a couple of reasons: 1. There are few heuristics available for users to determine when GC should run, this means that in OOBGC scenarios, it's possible that major GC's are being run more than necessary. 2. The lack of any GC during a request means that lots of garbage objects have been created and not cleaned up, so the process is using more memory than it should - requiring major GC's run as part of OOBGC to do more work and therefore take more time. This ticket attempts to address these issues by: 1. Provide `GC.disable_major` and its antonym `GC.enable_major` to disable and enable only major GC 2. Provide `GC.needs_major?` as a basic heuristic allowing users to tell when Ruby should run a Major GC. These ideas were originally proposed by @ko1 and @byroot in [this rails issue](https://github.com/rails/rails/issues/50449) Disabling GC major's would still allow minor GC's to run during the request, avoiding the ballooning memory usage caused by not running GC at all, and reducing the time that a major takes when we do run it, because the nursery objects have been cleaned up during the request already so there is less work for a major GC to do. This can be used in combination with `GC.needs_major?` to selectively run an OOBGC only when necessary ## Implementation This PR adds 3 new methods to the `GC` module - `GC.disable_major` This prevents major GC's from running automatically. It does not restrict minors. When `objspace->rgengc.need_major_gc` is set and a GC is run, instead of running a major, new heap pages will be allocated and a minor run instead. `objspace->rgengc.need_major_gc` will remain set until a major is manually run. If a major is not manually run then the process will eventually run out of memory. When major GC's are disabled, object promotion is disabled. That is, no objects will increment their ages during a minor GC. This is to attempt to minimise heap growth during the period between major GC's, by restricting the number of old-gen objects that will remain unconsidered by the GC until the next major. When `GC.start` is run, then major GC's will be enabled, a GC triggered with the options passed to `GC.start`, and then `disable_major` will be set to the state it was in before `GC.start` was called. - `GC.enable_major` This simply unsets the bit preventing major GC's. This will revert the GC to normal generational behaviour. Everything behaves as default again. - `GC.needs_major?` This exposes the value of `objspace->rgengc.need_major_gc` to the user level API. This is already exposed in `GC.latest_gc_info[:need_major_by]` but I felt that a simpler interface would make this easier to use and result in more readable code. eg. ```ruby out_of_band do GC.start if GC.needs_major? end ``` Because object aging is disabled when majors are disabled it is recommended to use this in conjunction with `Process.warmup`, which will prepare the heap by running a major GC, compacting the heap, and promoting every remaining object to old-gen. This ensures that minor GC's are running over the smallets possible set of young objects when `GC.disable_major` is true. ## Benchmarks We ran some tests in production on Shopify's core monolith over a weekend and found that: **Mean time spent in GC, as well as p99.9 and p99.99 GC times are all improved.** <img width="1000" alt="Screenshot 2024-04-22 at 16 41 49" src="https://github.com/ruby/ruby/assets/31869/6cff5b11-2e21-40c1-bb84-d994e0e17…"> **p99 GC time is slightly higher.** <img width="1000" alt="Screenshot 2024-04-22 at 16 44 55" src="https://github.com/ruby/ruby/assets/31869/dc645cbe-9495-46f0-8485-24e790c42…"> We're running far fewer OOBGC major GC's now that we have `GC.needs_major?` than we were before, and we believe that this is contributing to a slightly increased number of minor GC's. raising the p99 slightly. **App response times are all improved** We see a 9% reduction in average and p99 response times when compared against standard GC (4% p99.9 and p99.99). <img width="1000" alt="Screenshot 2024-04-22 at 16 55 53" src="https://github.com/ruby/ruby/assets/31869/8a80c102-1564-4bc9-ba44-6e9a8b85f…"> This drops slightly to an 8% reduction in average and p99 response times when compared against standard OOBGC (3.59 p99.9 and 4% p99.99) <img width="1000" alt="Screenshot 2024-04-22 at 16 56 10" src="https://github.com/ruby/ruby/assets/31869/1baef7ea-0155-4ff9-8ba4-a967b7574…"> -- https://bugs.ruby-lang.org/

7 24

[ruby-core:118566] [Ruby master Bug#9115] Logger traps all exceptions; breaks Timeout
by jeremyevans0 (Jeremy Evans) 11 Jul '24

11 Jul '24

Issue #9115 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Assigned to Closed I merged https://github.com/ruby/logger/pull/37 to fix this issue. ---------------------------------------- Bug #9115: Logger traps all exceptions; breaks Timeout https://bugs.ruby-lang.org/issues/9115#change-109088 * Author: cphoenix (Chris Phoenix) * Status: Closed * Assignee: sonots (Naotoshi Seo) * ruby -v: ruby 2.0.0p247 (2013-06-27) [i386-mingw32] ---------------------------------------- Line 577-579 of logger.rb rescue Exception => ignored warn("log writing failed. #{ignored}") end Thus, when the system times out in the middle of writing a log message, it warns "log writing failed. execution expired" and just keeps right on running. This is true in 1.9.3 as well. I haven't looked at older versions. Pardon me while I go grep "rescue Exception" in the entire Ruby codebase, and see whether I can reliably use Timeout at all... OK, you might check out C:\Ruby200\lib\ruby\gems\2.0.0\gems\activerecord-3.2.13\lib\active_record\railties\databases.rake All the other "rescue Exception" seem to re-raise it, except maybe C:\Ruby200\lib\ruby\2.0.0\xmlrpc\server.rb and C:\Ruby200\lib\ruby\gems\2.0.0\gems\activesupport-3.2.13\lib\active_support\callbacks.rb -- https://bugs.ruby-lang.org/

1 0