From 39a2ba5cc559900c30c3143da32446c2f20a7484 Mon Sep 17 00:00:00 2001 From: Alan Wu Date: Tue, 11 May 2021 12:05:06 -0400 Subject: Method cache: fix refinement entry handling To invalidate some callable method entries, we replace the entry in the class. Most types of method entries are on the method table of the origin class, but refinement entries without an orig_me are housed in the method table of the class itself. They are there because refinements take priority over prepended methods. By unconditionally inserting a copy of the refinement entry into the origin class, clearing the method cache created situations where there are refinement entry duplicates in the lookup chain, leading to infinite loops and other problems. Update the replacement logic to use the right class that houses the method entry. Also, be more selective about cache invalidation when moving refinement entries for prepend. This avoids calling clear_method_cache_by_id_in_class() before refinement entries are in the place it expects. [Bug #17806] --- class.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'class.c') diff --git a/class.c b/class.c index 6784540a9e..9ac2b3ff47 100644 --- a/class.c +++ b/class.c @@ -1181,10 +1181,12 @@ cache_clear_refined_method(ID key, VALUE value, void *data) { rb_method_entry_t *me = (rb_method_entry_t *) value; - if (me->def->type == VM_METHOD_TYPE_REFINED) { + if (me->def->type == VM_METHOD_TYPE_REFINED && me->def->body.refined.orig_me) { VALUE klass = (VALUE)data; rb_clear_method_cache(klass, me->called_id); } + // Refined method entries without an orig_me is going to stay in the method + // table of klass, like before the move, so no need to clear the cache. return ID_TABLE_CONTINUE; } -- cgit v1.2.1