From e75cb61d4645b9833b14a0cc4190cceffc9b6551 Mon Sep 17 00:00:00 2001 From: Alan Wu Date: Wed, 14 Jul 2021 19:44:26 -0400 Subject: Fix nested bmethod TracePoint and memory leak df317151a5b4e0c5a30fcc321a9dc6abad63f7ed removed the code to free rb_hook_list_t, so repeated targeting of the same bmethod started to leak the hook list. You can observe how the maximum memory use scales with input size in the following script with `/usr/bin/time -v`. ```ruby o = Object.new o.define_singleton_method(:foo) {} trace = TracePoint.new(:return) {} bmethod = o.method(:foo) ARGV.first.to_i.times { trace.enable(target:bmethod){} } 4.times {GC.start} ``` After this change the maximum doesn't grow as quickly. To plug the leak, check whether the hook list is already allocated when enabling the targeting TracePoint for the bmethod. This fix also allows multiple TracePoints to target the same bmethod, similar to other valid TracePoint targets. Finally, free the rb_hook_list_t struct when freeing the method definition it lives on. Freeing in the GC is a good way to avoid lifetime problems similar to the one fixed in df31715. [Bug #18031] --- vm_method.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'vm_method.c') diff --git a/vm_method.c b/vm_method.c index b12d134dce..7cd9fee754 100644 --- a/vm_method.c +++ b/vm_method.c @@ -405,7 +405,9 @@ rb_method_definition_release(rb_method_definition_t *def, int complemented) if (alias_count + complemented_count == 0) { if (METHOD_DEBUG) fprintf(stderr, "-%p-%s:%d,%d (remove)\n", (void *)def, rb_id2name(def->original_id), alias_count, complemented_count); - VM_ASSERT(def->type == VM_METHOD_TYPE_BMETHOD ? def->body.bmethod.hooks == NULL : TRUE); + if (def->type == VM_METHOD_TYPE_BMETHOD && def->body.bmethod.hooks) { + xfree(def->body.bmethod.hooks); + } xfree(def); } else { -- cgit v1.2.1