From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.6 required=3.0 tests=AWL,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.1 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 8ADBB1F403 for ; Fri, 8 Jun 2018 08:13:15 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 99DA1120A12; Fri, 8 Jun 2018 17:13:11 +0900 (JST) Received: from o1678916x28.outbound-mail.sendgrid.net (o1678916x28.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id B211C120A12 for ; Fri, 8 Jun 2018 17:13:09 +0900 (JST) Received: by filter0034p3iad2.sendgrid.net with SMTP id filter0034p3iad2-9427-5B1A3A90-5 2018-06-08 08:13:04.588708579 +0000 UTC Received: from herokuapp.com (ec2-54-163-121-170.compute-1.amazonaws.com [54.163.121.170]) by ismtpd0001p1iad1.sendgrid.net (SG) with ESMTP id N47xGSASQGuTm7D-QZHFsQ for ; Fri, 08 Jun 2018 08:13:04.471 +0000 (UTC) Date: Fri, 08 Jun 2018 08:13:05 +0000 (UTC) From: shyouhei@ruby-lang.org To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 62823 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 14834 X-Redmine-Issue-Author: kivikakk X-Redmine-Issue-Assignee: shyouhei X-Redmine-Sender: shyouhei 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/Ymy4QrNMhiuLXJG8OTL2vJD1yS7WkhQFTUENjqZt99XbTsViwMSpJ+W9YsQ6nr ag7efcoeOakvk7I8lWml8N4l7nGCurlyFHO6yvqyyK2b8sl2AlXK2QrMSGA4GCt06qah9cSpEZVyu8 sF17GCkFC1O6xJnCpLDkfjwLrFV/VJTTFxS0xehiITsnOIE7XyDcvABlRA== X-ML-Name: ruby-core X-Mail-Count: 87453 Subject: [ruby-core:87453] [Ruby trunk Bug#14834][Assigned] rb_profile_frames SEGV when PC adjusted on IFUNC 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #14834 has been updated by shyouhei (Shyouhei Urabe). Status changed from Open to Assigned Assignee set to shyouhei (Shyouhei Urabe) Thanks reporting! Will handle it. ---------------------------------------- Bug #14834: rb_profile_frames SEGV when PC adjusted on IFUNC https://bugs.ruby-lang.org/issues/14834#change-72445 * Author: kivikakk (Ashe Connor) * Status: Assigned * Priority: Normal * Assignee: shyouhei (Shyouhei Urabe) * Target version: * ruby -v: ruby 2.6.0dev (2018-06-08 trunk 63606) [x86_64-linux] * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- Since r62052, we increment `ec->cfp->pc` by one pointer width (e.g. 8 bytes) in `gc_event_hook_body` around the `EXEC_EVENT_HOOK` call. This becomes a problem when the hook is on an IFUNC: in this case, `pc == 0x0`, meaning we increment it to a non-zero value during that call. `rb_profile_frames` uses the following check to determine if frame info should be recorded: ~~~ c if (cfp->iseq && cfp->pc) { ~~~ The example here is [`stackprof`](https://github.com/tmm1/stackprof/blob/58d65ffa801ed27f013d573148783694526c7426/ext/stackprof/stackprof.c#L486), which calls `rb_profile_frames` in a gc event hook. This will segfault currently, as the above check will pass. `calc_lineno` then attempts to calculate the line number: ~~~ c size_t pos = (size_t)(pc - iseq->body->iseq_encoded); ~~~ This fails for a variety of reasons: `iseq_encoded` isn't valid because `iseq` isn't an `rb_iseq_t` underneath, producing an essentially random value, and `pc` is 0x8, so we underflow and eventually cause an overrun in `succ_index_lookup` with a huge `pos` argument. We instead only adjust PC if it appears to be a valid pointer in the first place. ---Files-------------------------------- pc-treatment.diff (777 Bytes) -- https://bugs.ruby-lang.org/