summaryrefslogtreecommitdiff
path: root/test/ruby
AgeCommit message (Collapse)Author
5 daysmerge revision(s) fa85d23ff4a02985ebfe0716b0ff768f5b4fe13d: [Backport #21380]ruby_3_3nagachika
[Bug #21380] Prohibit modification in String#split block Reported at https://hackerone.com/reports/3163876
2025-05-24merge revision(s) 056497319658cbefe22351c6ec5c9fa6e4df72bd: [Backport #21357]nagachika
[Bug #21357] Fix crash in Hash#merge with block Prior to https://github.com/ruby/ruby/commit/49b306ecb9e2e9e06e0b1590bacc5f4b38169c3c the `optional_arg` passed from `rb_hash_update_block_i` to `tbl_update` was a hash value (i.e. a VALUE). After that commit it changed to an `update_call_args`. If the block sets or changes the value, `tbl_update_modify` will set the `arg.value` back to an actual value and we won't crash. But in the case where the block returns the original value we end up calling `RB_OBJ_WRITTEN` with the `update_call_args` which is not expected and may crash. `arg.value` appears to only be used to pass to `RB_OBJ_WRITTEN` (others who need the `update_call_args` get it from `arg.arg`), so I don't think it needs to be set to anything upfront. And `tbl_update_modify` will set the `arg.value` in the cases we need the write barrier.
2025-05-24merge revision(s) 49b306ecb9e2e9e06e0b1590bacc5f4b38169c3c: [Backport #21333]nagachika
[Bug #21333] Prohibit hash modification inside Hash#update block
2025-05-18merge revision(s) b959263b58e26ef630c085f9f7ddc04373a998c7: [Backport #21344]nagachika
Fix Exception#detailed_message for GC compaction Before this commit, the test fails with RGENGC_CHECK_MODE enabled: TestException#test_detailed_message_under_gc_compact_stress [test/ruby/test_exception.rb:1466]: <"\e[1mfoo (\e[1;4mRuntimeError\e[m\e[1m)\e[m\n" + "\e[1mbar\e[m\n" + "\e[1mbaz\e[m"> expected but was <"\e[1mfoo (\e[1;4mRuntimeError\e[m\e[1m)\e[m\n" + "\e[1m\x00\x00\x00\x00\x00\x00\x00\e[m">.
2025-05-17merge revision(s) 7793b59c8d2a13c124fe276e11723db23facce04: [Backport #21331]nagachika
[Bug #21331] Prohibit hash modification during stlike loop
2025-04-07merge revision(s) 3a7b9ca93b91dcc086b9ac8b9957e59268f9493b: [Backport #21217]nagachika
Fix `Integer.sqrt` to never exceed actual value `Integer.sqrt` uses `sqrt(3)` from libm for small values. This method must return a value less than or equal to the actual integer square root, but libm's sqrt does not always guarantee that. This change corrects that by decrementing the result if necessary. Fixes [Bug #21217]
2025-04-02merge revision(s) d78ff6a767ca813ac5fa178dd7611f20a993c191: [Backport #20984]nagachika
[Bug #20984] Fix test with locale encoding
2025-03-30merge revision(s) 5f77f9bea61fb4cc8447a76e191fdfb28f076862: [Backport #21195]nagachika
Fix handling of `error`/`errno` in `io_internal_wait`. (#12961) [Bug #21195]
2025-03-29merge revision(s) f69ad0e810e1fdc18dc12f77bbecfa49999ef3bf: [Backport #21094]nagachika
[Bug #21094] Update nested module names when setting temporary name
2025-03-29merge revision(s) 1acfb29015dbc38fd345d8786aa78aad59f7dcd1: [Backport #21186]nagachika
[Bug #21186] multibyte char literal should be a single letter word
2025-03-29merge revision(s) 9459bedd84d479bb1d7d3d40bada1cecb4701c37: [Backport #19841]nagachika
[Bug #19841] Refine error on marshaling recursive USERDEF
2025-03-16merge revision(s) f423f6e10c0c226dfed98e7cb7a5d489191dfa35: [Backport #21131]nagachika
Ensure IO.copy_stream buffer is an independent string Otherwise, changes to the buffer by the destination write method could result in data changing for supposedly independent strings. Fixes [Bug #21131]
2025-03-16merge revision(s) 931ac960b6d11937364b6c4e847fdd575ee67980: [Backport #21159]nagachika
[Bug #21159] module names should not be modifiable
2025-03-08Replace tombstone when converting AR to ST hashJohn Hawthorn
[Bug #21170] st_table reserves -1 as a special hash value to indicate that an entry has been deleted. So that that's a valid value to be returned from the hash function, do_hash replaces -1 with 0 so that it is not mistaken for the sentinel. Previously, when upgrading an AR table to an ST table, rb_st_add_direct_with_hash was used which did not perform the same conversion, this could lead to a hash in a broken state where one if its entries which was supposed to exist being marked as a tombstone. The hash could then become further corrupted when the ST table required resizing as the falsely tombstoned entry would be skipped but it would be counted in num entries, leading to an uninitialized entry at index 15. In most cases this will be really rare, unless using a very poorly implemented custom hash function. This also adds two debug assertions, one that st_add_direct_with_hash does not receive the reserved hash value, and a second in rebuild_table_with, which ensures that after we rebuild/compact a table it contains the expected number of elements. Co-authored-by: Alan Wu <[email protected]>
2025-01-14merge revision(s) b176d4f52e4af67654814dab3e9c5f4bf9170e54: [Backport #21008]Takashi Kokubun
[Bug #21008] Normalize before sum to float After switching to `Float`-mode when summing `Numeric` objects, normalization for `Float` is still needed.
2025-01-14merge revision(s) 8034e9c3d001ca3dff124ab42972684eac8af2ae: [Backport #20995]Takashi Kokubun
[Bug #20995] Protect `IO.popen` block from exiting by exception
2025-01-14merge revision(s) 19c39e4cfaa467e69b9848c9c5496d7f50d39c7f: [Backport #20984]Takashi Kokubun
[Bug #20984] ENV.inspect should be encoding aware
2025-01-14merge revision(s) e0d600ec190c64aff76cfcbd6009cffb927da166: [Backport #21012]Takashi Kokubun
Avoid opt_aset_with optimization inside multiple assignment Previously, since the opt_aset_with optimization was introduced, use of the opt_aset_with optimization inside multiple assignment would result in a segfault or incorrect instructions. Fixes [Bug #21012] Co-authored-by: Nobuyoshi Nakada <[email protected]>
2025-01-14merge revision(s) 92dd9734a967c20e628c8f77c5ce700058dcd58c: [Backport #20950]Takashi Kokubun
Fix use-after-free in ep in Proc#dup for ifunc procs [Bug #20950] ifunc proc has the ep allocated in the cfunc_proc_t which is the data of the TypedData object. If an ifunc proc is duplicated, the ep points to the ep of the source object. If the source object is freed, then the ep of the duplicated object now points to a freed memory region. If we try to use the ep we could crash. For example, the following script crashes: p = { a: 1 }.to_proc 100.times do p = p.dup GC.start p.call rescue ArgumentError end This commit changes ifunc proc to also duplicate the ep when it is duplicated.
2025-01-14merge revision(s) e90b447655dd39ad1eb645cdaae450efd605db00: [Backport #20924]Takashi Kokubun
[Bug #20924] Fix reading with delimiter in wide character encodings
2025-01-14merge revision(s) 660b995365f719fa59ed6f2809bb1527e6470d14: [Backport #20915]Takashi Kokubun
[Bug #20915] Fix SEGV with `TracePoint#parameters` and aliased C method The following snippet results with a SEGV: ```ruby C = Class.new do alias_method :new_to_s, :to_s end TracePoint.new(:c_call, &:parameters).enable { C.new.new_to_s } ``` at MRI 3.3.6 and ruby 3.4.0dev The root cause of the issue lies in the `rb_tracearg_parameters` function within the `RUBY_EVENT_C_RETURN` branch. Specifically, when the invoked method is an alias for a C function, `rb_method_entry_without_refinements(..., trace_arg->called_id, ...)` may return NULL. In that case we can fallback to `trace_arg->id`.
2025-01-14merge revision(s) 02b70256b5171d4b85ea7eeab836d3d7cfb3dbfc, ↵Takashi Kokubun
6b4f8945d600168bf530d21395da8293fbd5e8ba: [Backport #20909] Check negative integer underflow Many of Oniguruma functions need valid encoding strings
2025-01-14merge revision(s) 3b7892b6e4d1a1a5d6019987f9b46ed443dd104f: [Backport #20871]Takashi Kokubun
Fix a bug in rb_include_module that stops nested inclusion into module subclasses This bug was present since the code was originally added by me in 3556a834a2847e52162d1d3302d4c64390df1694. Fixes [Bug #20871]
2025-01-14merge revision(s) d71be7274bd2623bb521be72c245c08fc38d6ae4: [Backport #20873]Takashi Kokubun
[Bug #20873] Consider `-FIXNUM_MIN` overflow `-FIXNUM_MIN` is usually greater than `FIXNUM_MAX` on platforms using two's complement representation.
2025-01-14merge revision(s) 56ecc243e230e8e99761ec0ffc5116601f094bb0: [Backport #20868]Takashi Kokubun
[Bug #20868] Fix Method#hash to not change after compaction The hash value of a Method must remain constant after a compaction, otherwise it may not work as the key in a hash table. For example: def a; end # Need this method here because otherwise the iseq may be on the C stack # which would get pinned and not move during compaction def get_hash method(:a).hash end puts get_hash # => 2993401401091578131 GC.verify_compaction_references(expand_heap: true, toward: :empty) puts get_hash # => -2162775864511574135
2025-01-14merge revision(s) 773d140f65c1c8b726e107915bc003c186f38677: [Backport #20787]Takashi Kokubun
[Bug #20787] Check the separator in `IO#readline` as well as 3.2
2024-11-20Revert "Skip tests that suddenly started failing for MinGW"Hiroshi SHIBATA
This reverts commit f72eb702f29574b85889d3ea6447efa29c8a8789.
2024-11-12[Bug #20886] Avoid double-free in regex timeout after stack_double (#12063)John Hawthorn
Fix regex timeout double-free after stack_double As of 10574857ce167869524b97ee862b610928f6272f, it's possible to crash on a double free due to `stk_alloc` AKA `msa->stack_p` being freed twice, once at the end of match_at and a second time in `FREE_MATCH_ARG` in the parent caller. Fixes [Bug #20886]
2024-11-09[Bug #20883] Fix coderange for sprintf on binary strings (#12040)John Hawthorn
Fix update_coderange for binary strings Although a binary (aka ASCII-8BIT) string will never have a broken coderange, it still has to differentiate between "valid" and "7bit". On Ruby 3.4/trunk this problem is masked because we now clear the coderange more agressively in rb_str_resize, and we happened to always be strinking this string, but we should not assume that. On Ruby 3.3 this created strings where `ascii_only?` was true in cases it shouldn't be as well as other problems. Fixes [Bug #20883] Co-authored-by: Daniel Colson <[email protected]> Co-authored-by: Matthew Draper <[email protected]>
2024-11-04Skip tests that suddenly started failing for MinGWTakashi Kokubun
These test failures first appeared on irrelevant changes. It probably came from changes in GitHub Actions instead of CRuby's. Until we figure out how to fix these tests, let's skip them to make the CI usable.
2024-11-04merge revision(s) 29c480dd6fca993590c82078ba797e2c4e876ac7: [Backport #20853]Takashi Kokubun
[Bug #20853] Fix Proc#hash to not change after compaction The hash value of a Proc must remain constant after a compaction, otherwise it may not work as the key in a hash table.
2024-11-04merge revision(s) 6118e8a47394409b53164b60e79fadf348b97db3: [Backport #20716]Takashi Kokubun
Fix method caching bug when including/prepend module A that prepends module B Fix by always adding the generated iclass to the subclasses list, otherwise the method cache for the iclass is not cleared when the method in the module is overwritten. Fixes [Bug #20716]
2024-11-04merge revision(s) 35e124832e29b65c84d4e0e4e434616859f9bdf5: [Backport #20755]Takashi Kokubun
[Bug #20755] Frozen string should not be writable via IO::Buffer
2024-11-04merge revision(s) 637067440f74043c6d79fc649ab8acf1afea25a5: [Backport #20752]Takashi Kokubun
[Bug #20752] Slice of readonly `IO::Buffer` also should be readonly
2024-11-04merge revision(s) c1862cbb89a6bf42dcd07d92fe4f4bfeebca5775: [Backport #20719]Takashi Kokubun
[Bug #20719] `Float` argument must be ASCII compatible
2024-11-04merge revision(s) d33e3d47b84a73b38644f2a3d41881ce9be6ef18: [Backport #20704]Takashi Kokubun
[Bug #20704] Win32: Fix chdir to non-ASCII path On Windows, `chdir` in compilers' runtime libraries uses the active code page, but command line arguments in ruby are always UTF-8, since commit:33ea2646b98adb49ae2e1781753bf22d33729ac0.
2024-11-04merge revision(s) 76ea5cde2a0f4834a5228104249b6b3346ddfc94: [Backport #20777]Takashi Kokubun
Refactor RUBY_DESCRIPTION assertions in test_rubyoptions
2024-09-02merge revision(s) a3562c2a0abf1c2bdd1d50377b4f929580782594: [Backport #20701]Takashi Kokubun
Remove incorrect setting of KW_SPLAT_MUT flag Fixes [Bug #20701] Co-authored-by: Pablo Herrero <[email protected]>
2024-09-02merge revision(s) 992596fb7af18a7f472589a607d0eb3fbb03b49a: [Backport #20344]Takashi Kokubun
Fix next inside block argument stack underflow [Bug #20344] Fix compile_next adding removable adjust label
2024-09-02merge revision(s) 1870505f478cc75993b296b7144a45137ace6937: [Backport #20651]Takashi Kokubun
Fix wrong unreachable chunk remove when jump destination label is unremovable
2024-08-23[Backport 3.3] [Bug #20691] Fix use-after-free in WeakKeyMap#clear (#11443)Peter Zhu
Fix use-after-free in WeakKeyMap#clear [Bug #20691] If the WeakKeyMap has been marked but sweeping hasn't started yet and we cann WeakKeyMap#clear, then there could be a use-after-free because we do not call rb_gc_remove_weak to remove the key from the GC. For example, the following code triggers use-after-free errors in Valgrind: map = ObjectSpace::WeakKeyMap.new 1_000.times do 1_000.times do map[Object.new] = nil end map.clear end Output from Valgrind: ==61230== Invalid read of size 8 ==61230== at 0x25CAF8: gc_update_weak_references (default.c:5593) ==61230== by 0x25CAF8: gc_marks_finish (default.c:5641) ==61230== by 0x26031C: gc_marks_continue (default.c:5987) ==61230== by 0x26031C: gc_continue (default.c:2255) ==61230== by 0x2605FC: newobj_cache_miss (default.c:2589) ==61230== by 0x26111F: newobj_alloc (default.c:2622) ==61230== by 0x26111F: rb_gc_impl_new_obj (default.c:2701) ==61230== by 0x26111F: newobj_of (gc.c:890) ==61230== by 0x26111F: rb_wb_protected_newobj_of (gc.c:917) ==61230== by 0x2DE218: rb_class_allocate_instance (object.c:131) ==61230== by 0x2E32A8: class_call_alloc_func (object.c:2141) ==61230== by 0x2E32A8: rb_class_alloc (object.c:2113) ==61230== by 0x2E32A8: rb_class_new_instance_pass_kw (object.c:2172) ==61230== by 0x4296BC: vm_call_cfunc_with_frame_ (vm_insnhelper.c:3788) ==61230== by 0x44A9CD: vm_sendish (vm_insnhelper.c:5955) ==61230== by 0x44A9CD: vm_exec_core (insns.def:898) ==61230== by 0x43A0E4: rb_vm_exec (vm.c:2564) ==61230== by 0x2341B4: rb_ec_exec_node (eval.c:281) ==61230== by 0x236258: ruby_run_node (eval.c:319) ==61230== by 0x15D665: rb_main (main.c:43) ==61230== by 0x15D665: main (main.c:62) ==61230== Address 0x2159cb00 is 0 bytes inside a block of size 8 free'd ==61230== at 0x4849B2C: free (vg_replace_malloc.c:989) ==61230== by 0x248EF1: rb_gc_impl_free (default.c:8512) ==61230== by 0x248EF1: rb_gc_impl_free (default.c:8493) ==61230== by 0x248EF1: ruby_sized_xfree.constprop.0 (gc.c:4178) ==61230== by 0x4627EC: wkmap_free_table_i (weakmap.c:652) ==61230== by 0x3A54AF: apply_functor (st.c:1633) ==61230== by 0x3A54AF: st_general_foreach (st.c:1543) ==61230== by 0x3A54AF: rb_st_foreach (st.c:1640) ==61230== by 0x46203C: wkmap_clear (weakmap.c:973) ==61230== by 0x4296BC: vm_call_cfunc_with_frame_ (vm_insnhelper.c:3788) ==61230== by 0x44A9CD: vm_sendish (vm_insnhelper.c:5955) ==61230== by 0x44A9CD: vm_exec_core (insns.def:898) ==61230== by 0x43A0E4: rb_vm_exec (vm.c:2564) ==61230== by 0x2341B4: rb_ec_exec_node (eval.c:281) ==61230== by 0x236258: ruby_run_node (eval.c:319) ==61230== by 0x15D665: rb_main (main.c:43) ==61230== by 0x15D665: main (main.c:62) ==61230== Block was alloc'd at ==61230== at 0x484680F: malloc (vg_replace_malloc.c:446) ==61230== by 0x25C68E: rb_gc_impl_malloc (default.c:8527) ==61230== by 0x4622E9: wkmap_aset_replace (weakmap.c:817) ==61230== by 0x3A4D02: rb_st_update (st.c:1487) ==61230== by 0x4623E4: wkmap_aset (weakmap.c:854) ==61230== by 0x4296BC: vm_call_cfunc_with_frame_ (vm_insnhelper.c:3788) ==61230== by 0x44A9CD: vm_sendish (vm_insnhelper.c:5955) ==61230== by 0x44A9CD: vm_exec_core (insns.def:898) ==61230== by 0x43A0E4: rb_vm_exec (vm.c:2564) ==61230== by 0x2341B4: rb_ec_exec_node (eval.c:281) ==61230== by 0x236258: ruby_run_node (eval.c:319) ==61230== by 0x15D665: rb_main (main.c:43) ==61230== by 0x15D665: main (main.c:62) ==61230== ==61230== Invalid write of size 8 ==61230== at 0x25CB3B: gc_update_weak_references (default.c:5598) ==61230== by 0x25CB3B: gc_marks_finish (default.c:5641) ==61230== by 0x26031C: gc_marks_continue (default.c:5987) ==61230== by 0x26031C: gc_continue (default.c:2255) ==61230== by 0x2605FC: newobj_cache_miss (default.c:2589) ==61230== by 0x26111F: newobj_alloc (default.c:2622) ==61230== by 0x26111F: rb_gc_impl_new_obj (default.c:2701) ==61230== by 0x26111F: newobj_of (gc.c:890) ==61230== by 0x26111F: rb_wb_protected_newobj_of (gc.c:917) ==61230== by 0x2DE218: rb_class_allocate_instance (object.c:131) ==61230== by 0x2E32A8: class_call_alloc_func (object.c:2141) ==61230== by 0x2E32A8: rb_class_alloc (object.c:2113) ==61230== by 0x2E32A8: rb_class_new_instance_pass_kw (object.c:2172) ==61230== by 0x4296BC: vm_call_cfunc_with_frame_ (vm_insnhelper.c:3788) ==61230== by 0x44A9CD: vm_sendish (vm_insnhelper.c:5955) ==61230== by 0x44A9CD: vm_exec_core (insns.def:898) ==61230== by 0x43A0E4: rb_vm_exec (vm.c:2564) ==61230== by 0x2341B4: rb_ec_exec_node (eval.c:281) ==61230== by 0x236258: ruby_run_node (eval.c:319) ==61230== by 0x15D665: rb_main (main.c:43) ==61230== by 0x15D665: main (main.c:62) ==61230== Address 0x2159cb00 is 0 bytes inside a block of size 8 free'd ==61230== at 0x4849B2C: free (vg_replace_malloc.c:989) ==61230== by 0x248EF1: rb_gc_impl_free (default.c:8512) ==61230== by 0x248EF1: rb_gc_impl_free (default.c:8493) ==61230== by 0x248EF1: ruby_sized_xfree.constprop.0 (gc.c:4178) ==61230== by 0x4627EC: wkmap_free_table_i (weakmap.c:652) ==61230== by 0x3A54AF: apply_functor (st.c:1633) ==61230== by 0x3A54AF: st_general_foreach (st.c:1543) ==61230== by 0x3A54AF: rb_st_foreach (st.c:1640) ==61230== by 0x46203C: wkmap_clear (weakmap.c:973) ==61230== by 0x4296BC: vm_call_cfunc_with_frame_ (vm_insnhelper.c:3788) ==61230== by 0x44A9CD: vm_sendish (vm_insnhelper.c:5955) ==61230== by 0x44A9CD: vm_exec_core (insns.def:898) ==61230== by 0x43A0E4: rb_vm_exec (vm.c:2564) ==61230== by 0x2341B4: rb_ec_exec_node (eval.c:281) ==61230== by 0x236258: ruby_run_node (eval.c:319) ==61230== by 0x15D665: rb_main (main.c:43) ==61230== by 0x15D665: main (main.c:62) ==61230== Block was alloc'd at ==61230== at 0x484680F: malloc (vg_replace_malloc.c:446) ==61230== by 0x25C68E: rb_gc_impl_malloc (default.c:8527) ==61230== by 0x4622E9: wkmap_aset_replace (weakmap.c:817) ==61230== by 0x3A4D02: rb_st_update (st.c:1487) ==61230== by 0x4623E4: wkmap_aset (weakmap.c:854) ==61230== by 0x4296BC: vm_call_cfunc_with_frame_ (vm_insnhelper.c:3788) ==61230== by 0x44A9CD: vm_sendish (vm_insnhelper.c:5955) ==61230== by 0x44A9CD: vm_exec_core (insns.def:898) ==61230== by 0x43A0E4: rb_vm_exec (vm.c:2564) ==61230== by 0x2341B4: rb_ec_exec_node (eval.c:281) ==61230== by 0x236258: ruby_run_node (eval.c:319) ==61230== by 0x15D665: rb_main (main.c:43) ==61230== by 0x15D665: main (main.c:62) Co-authored-by: Jean Boussier <[email protected]>
2024-08-22[Backport 3.3] [Bug #20688] Fix use-after-free for WeakMap and WeakKeyMap ↵Peter Zhu
(#11439) * Add struct weakmap_entry for WeakMap entries * Refactor wmap_foreach to pass weakmap_entry * Use wmap_foreach for wmap_mark * Refactor wmap_compact to use wmap_foreach * Remove wmap_free_entry * Fix WeakMap use-after-free [Bug #20688] We cannot free the weakmap_entry before the ST_DELETE because it could hash the key which would read the weakmap_entry and would cause a use-after-free. Instead, we store the entry and free it on the next iteration. For example, the following script triggers a use-after-free in Valgrind: weakmap = ObjectSpace::WeakMap.new 10_000.times { weakmap[Object.new] = Object.new } ==25795== Invalid read of size 8 ==25795== at 0x462297: wmap_cmp (weakmap.c:165) ==25795== by 0x3A2B1C: find_table_bin_ind (st.c:930) ==25795== by 0x3A5EAA: st_general_foreach (st.c:1599) ==25795== by 0x3A5EAA: rb_st_foreach (st.c:1640) ==25795== by 0x25C991: gc_mark_children (default.c:4870) ==25795== by 0x25C991: gc_marks_wb_unprotected_objects_plane (default.c:5565) ==25795== by 0x25C991: rgengc_rememberset_mark_plane (default.c:5557) ==25795== by 0x25C991: rgengc_rememberset_mark (default.c:6233) ==25795== by 0x25C991: gc_marks_start (default.c:6057) ==25795== by 0x25C991: gc_marks (default.c:6077) ==25795== by 0x25C991: gc_start (default.c:6723) ==25795== by 0x260F96: heap_prepare (default.c:2282) ==25795== by 0x260F96: heap_next_free_page (default.c:2489) ==25795== by 0x260F96: newobj_cache_miss (default.c:2598) ==25795== by 0x26197F: newobj_alloc (default.c:2622) ==25795== by 0x26197F: rb_gc_impl_new_obj (default.c:2701) ==25795== by 0x26197F: newobj_of (gc.c:890) ==25795== by 0x26197F: rb_wb_protected_newobj_of (gc.c:917) ==25795== by 0x2DEA88: rb_class_allocate_instance (object.c:131) ==25795== by 0x2E3B18: class_call_alloc_func (object.c:2141) ==25795== by 0x2E3B18: rb_class_alloc (object.c:2113) ==25795== by 0x2E3B18: rb_class_new_instance_pass_kw (object.c:2172) ==25795== by 0x429DDC: vm_call_cfunc_with_frame_ (vm_insnhelper.c:3786) ==25795== by 0x44B08D: vm_sendish (vm_insnhelper.c:5953) ==25795== by 0x44B08D: vm_exec_core (insns.def:898) ==25795== by 0x43A7A4: rb_vm_exec (vm.c:2564) ==25795== by 0x234914: rb_ec_exec_node (eval.c:281) ==25795== Address 0x21603710 is 0 bytes inside a block of size 16 free'd ==25795== at 0x4849B2C: free (vg_replace_malloc.c:989) ==25795== by 0x249651: rb_gc_impl_free (default.c:8527) ==25795== by 0x249651: rb_gc_impl_free (default.c:8508) ==25795== by 0x249651: ruby_sized_xfree.constprop.0 (gc.c:4178) ==25795== by 0x4626EC: ruby_sized_xfree_inlined (gc.h:277) ==25795== by 0x4626EC: wmap_free_entry (weakmap.c:45) ==25795== by 0x4626EC: wmap_mark_weak_table_i (weakmap.c:61) ==25795== by 0x3A5CEF: apply_functor (st.c:1633) ==25795== by 0x3A5CEF: st_general_foreach (st.c:1543) ==25795== by 0x3A5CEF: rb_st_foreach (st.c:1640) ==25795== by 0x25C991: gc_mark_children (default.c:4870) ==25795== by 0x25C991: gc_marks_wb_unprotected_objects_plane (default.c:5565) ==25795== by 0x25C991: rgengc_rememberset_mark_plane (default.c:5557) ==25795== by 0x25C991: rgengc_rememberset_mark (default.c:6233) ==25795== by 0x25C991: gc_marks_start (default.c:6057) ==25795== by 0x25C991: gc_marks (default.c:6077) ==25795== by 0x25C991: gc_start (default.c:6723) ==25795== by 0x260F96: heap_prepare (default.c:2282) ==25795== by 0x260F96: heap_next_free_page (default.c:2489) ==25795== by 0x260F96: newobj_cache_miss (default.c:2598) ==25795== by 0x26197F: newobj_alloc (default.c:2622) ==25795== by 0x26197F: rb_gc_impl_new_obj (default.c:2701) ==25795== by 0x26197F: newobj_of (gc.c:890) ==25795== by 0x26197F: rb_wb_protected_newobj_of (gc.c:917) ==25795== by 0x2DEA88: rb_class_allocate_instance (object.c:131) ==25795== by 0x2E3B18: class_call_alloc_func (object.c:2141) ==25795== by 0x2E3B18: rb_class_alloc (object.c:2113) ==25795== by 0x2E3B18: rb_class_new_instance_pass_kw (object.c:2172) ==25795== by 0x429DDC: vm_call_cfunc_with_frame_ (vm_insnhelper.c:3786) ==25795== by 0x44B08D: vm_sendish (vm_insnhelper.c:5953) ==25795== by 0x44B08D: vm_exec_core (insns.def:898) ==25795== by 0x43A7A4: rb_vm_exec (vm.c:2564) ==25795== Block was alloc'd at ==25795== at 0x484680F: malloc (vg_replace_malloc.c:446) ==25795== by 0x25CE9E: rb_gc_impl_malloc (default.c:8542) ==25795== by 0x462A39: wmap_aset_replace (weakmap.c:423) ==25795== by 0x3A5542: rb_st_update (st.c:1487) ==25795== by 0x462B8E: wmap_aset (weakmap.c:452) ==25795== by 0x429DDC: vm_call_cfunc_with_frame_ (vm_insnhelper.c:3786) ==25795== by 0x44B08D: vm_sendish (vm_insnhelper.c:5953) ==25795== by 0x44B08D: vm_exec_core (insns.def:898) ==25795== by 0x43A7A4: rb_vm_exec (vm.c:2564) ==25795== by 0x234914: rb_ec_exec_node (eval.c:281) ==25795== by 0x2369B8: ruby_run_node (eval.c:319) ==25795== by 0x15D675: rb_main (main.c:43) ==25795== by 0x15D675: main (main.c:62) * Fix use-after-free for WeakKeyMap [Bug #20688] We cannot free the key before the ST_DELETE because it could hash the key which would read the key and would cause a use-after-free. Instead, we store the key and free it on the next iteration.
2024-08-06parse.y: const_decl_path don't replace destination node by a literal (#11314)Jean byroot Boussier
[Bug #20668] The `dest` node is assumed to be a `CDECL`, so overwriting it with a `LIT` cause a crash on the next iteration. Co-authored-by: Jean Boussier <[email protected]>
2024-07-30[Bug #20654] Fix floor and ceil when ndigits is large (#11277)Peter Zhu
* Fix floor when ndigits is large [Bug #20654] This commit fixes Integer#floor and Float#floor when the number is negative and ndigits is large such that 10**ndigits is a bignum. Previously, it would return 0 in such cases. However, this would cause unexpected behaviour such as: puts -1.floor(-5) # => -100000 puts -1.floor(-10) # => -10000000000 puts -1.floor(-20) # => 0 This commit changes the last result so that it will return -100000000000000000000. * Fix ceil when ndigits is large [Bug #20654] This commit fixes Integer#ceil and Float#ceil when the number is negative and ndigits is large such that 10**ndigits is a bignum. Previously, it would return 0 in such cases. However, this would cause unexpected behaviour such as: puts 1.ceil(-5) # => 100000 puts 1.ceil(-10) # => 10000000000 puts 1.ceil(-20) # => 0 This commit changes the last result so that it will return 100000000000000000000.
2024-07-29[Bug #20653] Fix memory leak in String#start_with? when regexp times out ↵Peter Zhu
(#11255) Fix memory leak in String#start_with? when regexp times out [Bug #20653] This commit refactors how Onigmo handles timeout. Instead of raising a timeout error, onig_search will return a ONIGERR_TIMEOUT which the caller can free memory, and then raise a timeout error. This fixes a memory leak in String#start_with when the regexp times out. For example: regex = Regexp.new("^#{"(a*)" * 10_000}x$", timeout: 0.000001) str = "a" * 1000000 + "x" 10.times do 100.times do str.start_with?(regex) rescue end puts `ps -o rss= -p #{$$}` end Before: 33216 51936 71152 81728 97152 103248 120384 133392 133520 133616 After: 14912 15376 15824 15824 16128 16128 16144 16144 16160 16160
2024-07-25[Bug #20650] Fix memory leak in Regexp capture group when timeout (#11244)Peter Zhu
Fix memory leak in Regexp capture group when timeout [Bug #20650] The capture group allocates memory that is leaked when it times out. For example: re = Regexp.new("^#{"(a*)" * 10_000}x$", timeout: 0.000001) str = "a" * 1000000 + "x" 10.times do 100.times do re =~ str rescue Regexp::TimeoutError end puts `ps -o rss= -p #{$$}` end Before: 34688 56416 78288 100368 120784 140704 161904 183568 204320 224800 After: 16288 16288 16880 16896 16912 16928 16944 17184 17184 17200
2024-07-08merge revision(s) fc33559c: [Backport #20570]Takashi Kokubun
clear `kw_flag` if given hash is nil https://bugs.ruby-lang.org/issues/20570 is caused I missed to clear the `kw_flag` even if `keyword_hash` is nil.
2024-07-08merge revision(s) 2dd46bb82ffc4dff01d7ea70922f0e407acafb4e: [Backport #20468]Takashi Kokubun
[Bug #20468] Fix safe navigation in `for` variable
2024-06-28[Bug #20598] Fix corruption of internal encoding string (#11069)Peter Zhu
Fix corruption of internal encoding string [Bug #20598] Just like [Bug #20595], Encoding#name_list and Encoding#aliases can have their strings corrupted when Encoding.default_internal is set to nil. Co-authored-by: Matthew Valentine-House <[email protected]>
2024-06-27[Bug #20595] Fix corruption of encoding name string (#11063)Peter Zhu
Fix corruption of encoding name string [Bug #20595] enc_set_default_encoding will free the C string if the encoding is nil, but the C string can be used by the encoding name string. This will cause the encoding name string to be corrupted. Consider the following code: Encoding.default_internal = Encoding::ASCII_8BIT names = Encoding.default_internal.names p names Encoding.default_internal = nil p names It outputs: ["ASCII-8BIT", "BINARY", "internal"] ["ASCII-8BIT", "BINARY", "\x00\x00\x00\x00\x00\x00\x00\x00"] Co-authored-by: Matthew Valentine-House <[email protected]>