[#62297] Re: [ruby-cvs:52906] nari:r45760 (trunk): * gc.c (gc_after_sweep): suppress unnecessary expanding heap. — Eric Wong <normalperson@...>
nari@ruby-lang.org wrote:
7 messages
2014/05/02
[#62307] Re: [ruby-cvs:52906] nari:r45760 (trunk): * gc.c (gc_after_sweep): suppress unnecessary expanding heap.
— SASADA Koichi <ko1@...>
2014/05/03
(2014/05/03 4:41), Eric Wong wrote:
[#62402] Re: [ruby-cvs:52906] nari:r45760 (trunk): * gc.c (gc_after_sweep): suppress unnecessary expanding heap.
— Eric Wong <normalperson@...>
2014/05/05
SASADA Koichi <ko1@atdot.net> wrote:
[#62523] [ruby-trunk - Feature #9632] [PATCH 0/2] speedup IO#close with linked-list from ccan — ko1@...
Issue #9632 has been updated by Koichi Sasada.
3 messages
2014/05/11
[#62556] doxygen (Re: Re: [ruby-trunk - Feature #9632] [PATCH 0/2] speedup IO#close with linked-list from ccan) — Tanaka Akira <akr@...>
2014-05-11 8:50 GMT+09:00 Eric Wong <normalperson@yhbt.net>:
3 messages
2014/05/13
[#62727] [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl — Eric Wong <normalperson@...>
rb_unlink_method_entry may cause old_me to be swept before the new
7 messages
2014/05/24
[#63039] Re: [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl
— SASADA Koichi <ko1@...>
2014/06/10
Hi,
[#63077] Re: [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl
— Eric Wong <normalperson@...>
2014/06/10
SASADA Koichi <ko1@atdot.net> wrote:
[#63086] Re: [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl
— SASADA Koichi <ko1@...>
2014/06/11
(2014/06/11 4:47), Eric Wong wrote:
[#63087] Re: [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl
— Eric Wong <normalperson@...>
2014/06/11
SASADA Koichi <ko1@atdot.net> wrote:
[#62862] [RFC] README.EXT: document rb_gc_register_mark_object — Eric Wong <normalperson@...>
Any comment on officially supporting this as part of the C API?
5 messages
2014/05/30
[ruby-core:62723] [ruby-trunk - Bug #9835] IGNORE signal handler has possible race condition in Ruby 2.1.2
From:
normalperson@...
Date:
2014-05-24 05:58:46 UTC
List:
ruby-core #62723
Issue #9835 has been updated by Eric Wong. nobu@ruby-lang.org wrote: > As signal is asynchronous, it is not guaranteed essentially? The problem is a race with the way we defer signal handling Kyle expected two states for USR1: 1) print children: sighandler, trap_list[sig].cmd === proc 2) ignore: SIG_IGN, trap_list[sig].cmd == 0 However, the problem is we queued a SIGUSR1 at 1), but queue and handle the signal after 2) passes So the queued signal hits cmd==0, leading to rb_threadptr_signal_raise and SignalException. Signals queued after 2) are safe from this condition. > Anyway, the patch doesn't seem evil. OK, I'll wait a bit for Kyle to confirm. However, I just managed to reproduce the issue by limiting to one CPU on one of my machines: schedtool -a 0x1 -e ruby test.rb My proposed patch seems to fix it on my machine. ---------------------------------------- Bug #9835: IGNORE signal handler has possible race condition in Ruby 2.1.2 https://bugs.ruby-lang.org/issues/9835#change-46849 * Author: Kyle Smith * Status: Rejected * Priority: Low * Assignee: * Category: core * Target version: * ruby -v: ruby 2.1.2p95 (2014-05-08 revision 45877) [x86_64-linux] * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN ---------------------------------------- I'm migrating an application from 1.8.7 to 2.1.1/2.1.2, so I'm not sure when this was introduced. Attached is a demo program with some notes about how the IGNORE option to Signal.trap seems to have a race condition whereby receiving that signal shortly after that call, it raises a SignalException with the message including only the name of the signal it received. However, if you trap the signal with an empty block, that race does not occur. I've tested the attached program on 1.8.7 (no issue), 2.1.1 (issue) and 2.1.2 (issue) on a Linux system (Ubuntu lucid). ---Files-------------------------------- test.rb (1.37 KB) -- https://bugs.ruby-lang.org/