From: Charles Nutter <headius@...>
Date: 2012-02-16T03:49:10+09:00
Subject: [ruby-core:42666] [ruby-trunk - Bug #6030] Thread-local "leak" in rb_exec_recursive*


Issue #6030 has been updated by Charles Nutter.


I forgot to point out a couple things...

* By "leak" I mean this will hold references to data longer than it should. It's not a true leak in that it is bounded.

* It is bounded, but only by method names; recursive_list_access keys those thread-locals based on the current method name from the current frame, which means it will "leak" as many hash objects as there are unique methods utilizing rb_exec_recursive*.

From recursive_list_access:

...
	VALUE sym = ID2SYM(rb_frame_this_func());
...
	list = rb_hash_new();
	OBJ_UNTRUST(list);
	rb_hash_aset(hash, sym, list);

In JRuby, I fixed this by having rb_exec_recursive_outer clean up the thread-local upon completion, and I added recursive_list_operation (Ruby.java, recursiveListOperation) as a new "outermost" function to wrap our version of rb_exec_recursive. our rb_exec_recursive also gained an safeguard + error if it is called without being inside recursive_list_operation.

The commits are here:

https://github.com/jruby/jruby/commit/8f2ba4214eb070a83951aef1f143ebf6ebcecce4

https://github.com/jruby/jruby/commit/f7c1ffd93f34cef816168f36f5fe4f960a9ac2e2

It was a more severe problem for JRuby because the hash (a RubyHash) held references to the current JRuby instance, keeping it alive for as long as the thread was alive. Still a "leak", but a larger amount of bounded data held for too long.
----------------------------------------
Bug #6030: Thread-local "leak" in rb_exec_recursive*
https://bugs.ruby-lang.org/issues/6030

Author: Charles Nutter
Status: Open
Priority: Normal
Assignee: 
Category: 
Target version: 
ruby -v: 1.9.3 head


I believe there may be a "leak" in the rb_exec_recursive* functions in thread.c.

We have ported these methods for recursion detection in JRuby, and as in MRI they use a map inside a thread-local to track method name + object references. However, none of these method ever clean up the thread local when the recursive walk is complete.

The thread-local data is initialized in thread.c, recursive_list_access, around line 3819 (in 1.9.3 branch):

    if (NIL_P(hash) || TYPE(hash) != T_HASH) {
	hash = rb_hash_new();
	OBJ_UNTRUST(hash);
	rb_thread_local_aset(rb_thread_current(), recursive_key, hash);

As far as I can tell, this thread-local is never cleared, holding a hash reference for as long as the thread is alive.


-- 
http://bugs.ruby-lang.org/