From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: poffice@blade.nagaokaut.ac.jp Delivered-To: poffice@blade.nagaokaut.ac.jp Received: from kankan.nagaokaut.ac.jp (kankan.nagaokaut.ac.jp [133.44.2.24]) by blade.nagaokaut.ac.jp (Postfix) with ESMTP id EE3F617DD622 for ; Mon, 23 Feb 2015 09:15:14 +0900 (JST) Received: from funfun.nagaokaut.ac.jp (smtp.nagaokaut.ac.jp [133.44.2.201]) by kankan.nagaokaut.ac.jp (Postfix) with ESMTP id 071CFB5D8D0 for ; Mon, 23 Feb 2015 09:18:48 +0900 (JST) Received: from funfun.nagaokaut.ac.jp (localhost.nagaokaut.ac.jp [127.0.0.1]) by funfun.nagaokaut.ac.jp (Postfix) with ESMTP id EDE9997A826 for ; Mon, 23 Feb 2015 09:18:48 +0900 (JST) X-Virus-Scanned: amavisd-new at nagaokaut.ac.jp Authentication-Results: funfun.nagaokaut.ac.jp (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=sendgrid.me Received: from funfun.nagaokaut.ac.jp ([127.0.0.1]) by funfun.nagaokaut.ac.jp (funfun.nagaokaut.ac.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqYHZxpIuCSl for ; Mon, 23 Feb 2015 09:18:48 +0900 (JST) Received: from voscc.nagaokaut.ac.jp (voscc.nagaokaut.ac.jp [133.44.1.100]) by funfun.nagaokaut.ac.jp (Postfix) with ESMTP id 795F997A820 for ; Mon, 23 Feb 2015 09:18:48 +0900 (JST) Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by voscc.nagaokaut.ac.jp (Postfix) with ESMTP id E269095241E for ; Mon, 23 Feb 2015 09:18:46 +0900 (JST) Received: from [221.186.184.76] (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id CB45B1204A7; Mon, 23 Feb 2015 09:18:42 +0900 (JST) X-Original-To: ruby-core@ruby-lang.org Delivered-To: ruby-core@ruby-lang.org Received: from o2.heroku.sendgrid.net (o2.heroku.sendgrid.net [67.228.50.55]) by neon.ruby-lang.org (Postfix) with ESMTPS id 7A262120491 for ; Mon, 23 Feb 2015 09:18:39 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.me; h=from:to:references:subject:mime-version:content-type:content-transfer-encoding:list-id; s=smtpapi; bh=I40Vg2LXN4LLQlqjfkALtX+8j2Q=; b=OilvRwq97sLt4pcH9R Do98vDZ7UMzrkcvaBGuBauMTMhWL2BLnjD6PeSpTBW59BQlj4X9qPDcT31jedMsg YOwlIkUN9jPo+kmGsQSFz3+nEIUni+LOvO+7CPT8sIY1gw4jczaCe0tFpsLaNHI+ 0WCrK4T4VkyrrpNTVMapw8KpA= Received: by filter0085p1mdw1.sendgrid.net with SMTP id filter0085p1mdw1.8340.54EA71D85 2015-02-23 00:18:33.103380433 +0000 UTC Received: from herokuapp.com (ec2-174-129-166-180.compute-1.amazonaws.com [174.129.166.180]) by ismtpd-043 (SG) with ESMTP id 14bb3ccb7ba.1c89.cdf114 Mon, 23 Feb 2015 00:18:33 +0000 (UTC) Date: Mon, 23 Feb 2015 00:18:32 +0000 From: tenderlove@ruby-lang.org To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Redmine-MailingListIntegration-Message-Ids: 42661 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 10871 X-Redmine-Issue-Author: evanphx X-Redmine-Sender: tenderlovemaking X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: OOF Auto-Submitted: auto-generated X-SG-EID: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS5RH1Lzv0ZaefH3qunWteE6U6nEJlz0Px4AEO TSI99iLVUiLdijLUXU4hb2VDzqMbn9NubiBI6U7fUEMTshL5xLG+JTejxH/460B2mmBhTbeUtbFC1e 8K8EbG0CrNe44HMsfCBTv+0iXZD4Ugc0q0rB X-ML-Name: ruby-core X-Mail-Count: 68233 Subject: [ruby-core:68233] [Ruby trunk - Bug #10871] Sclass thread unsafe due to CREF sharing X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #10871 has been updated by Aaron Patterson. I tried to fix this, but I can't figure it out. :( I tried adding the singleton class to the stack frame. Since the stack frames are thread local, I thought that would at least fix the problem, but it didn't. Here is the patch I tried: https://gist.github.com/tenderlove/a8e30c1f764040de7536 I verified that `putspecialobject 2` would put the right class on the stack, and I verified that `m_core_define_method` got the right class, but still your test failed. I don't understand what I'm doing wrong. :( ---------------------------------------- Bug #10871: Sclass thread unsafe due to CREF sharing https://bugs.ruby-lang.org/issues/10871#change-51593 * Author: Evan Phoenix * Status: Open * Priority: High * Assignee: * ruby -v: 2.2.0p0, trunk * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN ---------------------------------------- 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/