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 D70DD19C026F for ; Thu, 19 Nov 2015 22:16:57 +0900 (JST) Received: from voscc.nagaokaut.ac.jp (voscc.nagaokaut.ac.jp [133.44.1.100]) by kankan.nagaokaut.ac.jp (Postfix) with ESMTP id A2663B5D935 for ; Thu, 19 Nov 2015 22:47:43 +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 1874318CC7B6 for ; Thu, 19 Nov 2015 22:47:43 +0900 (JST) Received: from [221.186.184.76] (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 995A912045C; Thu, 19 Nov 2015 22:47: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 065D712040B for ; Thu, 19 Nov 2015 22:47:38 +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=ETjLhzsFqGqNZ2cTliN6lHmBk5Q=; b=gB6Tj8sSwjnCVgNsXB oylvyeXbKUUTKS/WqemSRu/fNDXcKc9UKjiuVJvBaPojM/pt2iOuddLuoz0xumul RcSktRrsZsv5CfjgXtyD4byaGSH9u7ukDUgDv+nnVrS1SdDzigPOGW2sAIE9EvQX 61H45kBexNDC7has6GaWG3KDk= Received: by filter0417p1mdw1.sendgrid.net with SMTP id filter0417p1mdw1.8087.564DD2F444 2015-11-19 13:47:32.622496064 +0000 UTC Received: from herokuapp.com (ec2-54-145-145-74.compute-1.amazonaws.com [54.145.145.74]) by ismtpd0002p1iad1.sendgrid.net (SG) with ESMTP id 8yOzi4FhR-ishc_M3pz5xA for ; Thu, 19 Nov 2015 13:47:32.584 +0000 (UTC) Date: Thu, 19 Nov 2015 13:47:32 +0000 From: ko1@atdot.net 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: 46251 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 11692 X-Redmine-Issue-Author: gazay X-Redmine-Issue-Assignee: ko1 X-Redmine-Sender: ko1 X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS77qGuqD289qtNKaXWnQs7iSH2v65bQfLIF8c 7TB4SKDmTewNulwM884vJyDfCfd+6q97DzKd97yrT9QSLeSbyRjscbu92yvO3IgtiRV9ECAmQ3k/2v 4Ex2HHmmLV1ly4kYaDFogpaJgKtwnk5SLk2v X-ML-Name: ruby-core X-Mail-Count: 71588 Subject: [ruby-core:71588] [Ruby trunk - Bug #11692] [PATCH] Re-enable GC if stack overflow was caught from signal handler 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 #11692 has been updated by Koichi Sasada. Unfortunately, it is known problem (2nd time machine stack overflow we can not capture correctly). * 1st machine stack overflow * SEGV * check machine stack overflow * raise an error from signal handler (*1) by longjmp. * 2nd machine stack overflow * SEGV * signal status is signaling. So OS can not deliver signal correctly... The correct way is restoring signal status using sigsetjmp/siglongjmp at (*1). However, on Linux 2.x, siglongjmp is too slow than longjmp, so that we continue to use longjmp, at least the last time we had discussed this issue. We can't slow down Ruby interpreter for such a corner case. However, Linux 2.x is older OS. So that we can change. (BTW, I'm using Linux 2.6 on several machines) ---------------------------------------- Bug #11692: [PATCH] Re-enable GC if stack overflow was caught from signal handler https://bugs.ruby-lang.org/issues/11692#change-54971 * Author: Alex Gaziev * Status: Closed * Priority: Normal * Assignee: Koichi Sasada * ruby -v: * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN ---------------------------------------- We got ruby application running on our production server and noticed that it regularly crashes with out of memory errors. After months of investigation, I narrowed the case to the examples (1/2). After digging ruby sources and running test code, I found out that GC stopped working after recovering from native stack overflow error. Probably the relevant code appeared in 2.2 https://github.com/ruby/ruby/commit/0c391a55d3ed4637e17462d9b9b8aa21e64e2340 where ruby_disable_gc_stress became ruby_disable_gc. Patches for trunk and 2.2 branches below. ---Files-------------------------------- example1.rb (311 Bytes) example2.rb (333 Bytes) re-enable-gc-after-stackoverflow-trunk.patch (985 Bytes) re-enable-gc-after-stackoverflow-ruby-2-2.patch (985 Bytes) gc_threads_issue.rb (1.53 KB) -- https://bugs.ruby-lang.org/