[#70252] Re: [ruby-cvs:58640] nobu:r51492 (trunk): node.c: NODE_ALLOCA for ALLOCV — Eric Wong <normalperson@...>
Besides possible backwards compatibility, can we drop volatile
3 messages
2015/08/05
[#70257] [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI — ko1@...
Issue #11420 has been reported by Koichi Sasada.
11 messages
2015/08/06
[#70337] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/11
Nice. Thank you guys for looking into this.
[#70349] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/12
Btw, did you consider using flexible array to avoid extra malloc
[#70355] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Юрий Соколов <funny.falcon@...>
2015/08/12
I thought to suggest to embed hash_id_table directly into places when it is
[#70356] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— SASADA Koichi <ko1@...>
2015/08/12
On 2015/08/13 4:29, Юрий Соколов wrote:
[#70358] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/12
SASADA Koichi <ko1@atdot.net> wrote:
[#70509] [Ruby trunk - Misc #11276] [RFC] compile.c: convert to use ccan/list — ko1@...
Issue #11276 has been updated by Koichi Sasada.
3 messages
2015/08/21
[#70639] the undefined behavior of an iterator if it is modified inside of the block to which it yields — Daniel Doubrovkine <dblock@...>
(this is my first time e-mailing list list, so apologies for any misstep :)
4 messages
2015/08/31
[ruby-core:70574] [Ruby trunk - Bug #10871] Sclass thread unsafe due to CREF sharing
From:
nagachika00@...
Date:
2015-08-24 16:26:44 UTC
List:
ruby-core #70574
Issue #10871 has been updated by Tomoyuki Chikanaga.
Backport changed from 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN to 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: DONE
Hello,
I've applied ko1's workaround patch for this issue to `ruby_2_2` branch at r51673.
I'm worried about the wrong side effects of this patch.
Please test on `ruby_2_2` branch HEAD.
If you use rbenv/ruby-build, you can install `ruby_2_2` HEAD via
rbenv install 2.2.0-dev
Regards,
----------------------------------------
Bug #10871: Sclass thread unsafe due to CREF sharing
https://bugs.ruby-lang.org/issues/10871#change-53982
* Author: Evan Phoenix
* Status: Closed
* Priority: Normal
* Assignee: Koichi Sasada
* ruby -v: 2.2.0p0, trunk
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: DONE
----------------------------------------
When entering an sclass, the context is tracked via the same cref mechanism used for class and module, specifically on the iseq->cref_stack. The bug is that the cref_stack is the wrong place to put the new cref because the scope is specific only to that sclass body. Mutating and using the iseq->cref_stack causes any code that reads the cref via this cref_stack to incorrectly pick up the sclass instance instead of the proper scope!
This is major thread safety bug because it means that all uses of `class << obj` are thread-unsafe and can cause random code to fail.
Here is a simple reproduction of the bug: https://gist.github.com/evanphx/6eef92f2c40662a4171b
I attempted to fix the bug by treating an sclass body the same as an eval, which already has special handling for cref's but I don't understand the code enough to make that change quickly.
I believe this is a major bug and hope that ruby-core can address it soon.
Thank you!
--
https://bugs.ruby-lang.org/