[#90399] [Ruby trunk Feature#14813] [PATCH] gc.c: make gc_enter+gc_exit pairs dtrace probes, too — ko1@...
Issue #14813 has been updated by ko1 (Koichi Sasada).
3 messages
2018/12/10
[#90417] [Ruby trunk Bug#15398] TestThread#test_signal_at_join fails on FreeBSD — naruse@...
Issue #15398 has been reported by naruse (Yui NARUSE).
4 messages
2018/12/11
[#90423] Re: [Ruby trunk Bug#15398] TestThread#test_signal_at_join fails on FreeBSD
— Eric Wong <normalperson@...>
2018/12/11
[email protected] wrote:
[#90519] Spoofing warnings for mail from bugs.ruby-lang.org — Charles Oliver Nutter <headius@...>
I'm getting a spoofing warning for emails sent from bugs.ruby-lang.org when
4 messages
2018/12/13
[#90522] Re: Spoofing warnings for mail from bugs.ruby-lang.org
— Eric Wong <normalperson@...>
2018/12/13
Charles Oliver Nutter <[email protected]> wrote:
[#90533] [Ruby trunk Feature#15413] unmarkable C stack (3rd stack) — normalperson@...
Issue #15413 has been reported by normalperson (Eric Wong).
3 messages
2018/12/14
[#90581] [Ruby trunk Bug#15424] Ruby 2.6.0rc1 & 2.6.0rc2 mutex exception — mat999@...
Issue #15424 has been reported by splitice (Mathew Heard).
3 messages
2018/12/17
[#90595] [Ruby trunk Bug#15430] test_fork_while_parent_locked is failing status on Ruby CI — hsbt@...
Issue #15430 has been reported by hsbt (Hiroshi SHIBATA).
3 messages
2018/12/18
[#90614] [Ruby trunk Bug#15430][Assigned] test_fork_while_parent_locked is failing status on Ruby CI — hsbt@...
Issue #15430 has been updated by hsbt (Hiroshi SHIBATA).
4 messages
2018/12/19
[#90630] Re: [Ruby trunk Bug#15430][Assigned] test_fork_while_parent_locked is failing status on Ruby CI
— Eric Wong <normalperson@...>
2018/12/20
> It still exists. https://rubyci.org/logs/rubyci.s3.amazonaws.com/centos7/ruby-trunk/log/20181218T230003Z.fail.html.gz
[#90820] Re: [ruby-cvs:73697] k0kubun:r66593 (trunk): accept_nonblock_spec.rb: skip spurious failure — Eric Wong <normalperson@...>
[email protected] wrote:
3 messages
2018/12/30
[ruby-core:90451] [Ruby trunk Bug#6030][Feedback] Thread-local "leak" in rb_exec_recursive*
From:
mame@...
Date:
2018-12-12 16:00:42 UTC
List:
ruby-core #90451
Issue #6030 has been updated by mame (Yusuke Endoh).
Status changed from Assigned to Feedback
Assignee changed from nobu (Nobuyoshi Nakada) to headius (Charles Nutter)
This ticket was discussed at today's developer meeting.
Nobu said that per-method entries are removed when it becomes unneeded. So, the "leak" is one hash object per thread. Correct? If so, it is not a big deal. Let us know if we missed something.
----------------------------------------
Bug #6030: Thread-local "leak" in rb_exec_recursive*
https://bugs.ruby-lang.org/issues/6030#change-75612
* Author: headius (Charles Nutter)
* Status: Feedback
* Priority: Normal
* Assignee: headius (Charles Nutter)
* Target version:
* ruby -v: 1.9.3 head
* Backport: 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
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.
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>