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 0D5ED17D93F4 for ; Tue, 15 Jul 2014 18:27:27 +0900 (JST) Received: from funfun.nagaokaut.ac.jp (funfun.nagaokaut.ac.jp [133.44.2.201]) by kankan.nagaokaut.ac.jp (Postfix) with ESMTP id 34D85B5D8A6 for ; Tue, 15 Jul 2014 18:52:05 +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 7DC5097A82B for ; Tue, 15 Jul 2014 18:52:07 +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 w3NMhZwCSmE1 for ; Tue, 15 Jul 2014 18:52:07 +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 02E9B97A820 for ; Tue, 15 Jul 2014 18:52:07 +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 220D7952446 for ; Tue, 15 Jul 2014 18:52:03 +0900 (JST) Received: from [221.186.184.76] (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 0F757120493; Tue, 15 Jul 2014 18:51:56 +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 02D13120485 for ; Tue, 15 Jul 2014 18:51:51 +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=lY9fG3eYVUZFIHbA1teBqfCKIEU=; b=jji7B+ab5eJlUdt1P1 8F6xAZWggM2953LYtUAYH4EQ0QIzvvjqaDLqxDsP9KoMdW8BxDeZMrLJhK6UBUYW 5xm/FVFu+QzsmGkpxkk5FVk3YEDl7rv1AaeaJspT05wNyP01hT7URosyDuipghpo 9/jZi+Mo9bjE+zpLo43bvANnw= Received: by mf142.sendgrid.net with SMTP id mf142.7227.53C4F9B418 2014-07-15 09:51:48.5226008 +0000 UTC Received: from herokuapp.com (ec2-107-22-82-76.compute-1.amazonaws.com [107.22.82.76]) by ismtpd-019.iad1.sendgrid.net (SG) with ESMTP id 147396f5cfa.5851.2d0879 for ; Tue, 15 Jul 2014 09:51:45 +0000 (GMT) Date: Tue, 15 Jul 2014 09:51:45 +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: 37844 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 10037 X-Redmine-Issue-Author: ngoto 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: OOF Auto-Submitted: auto-generated X-SG-EID: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS4nU/KXsJ5eR3sy3k/xcLXbmhP+KlLxa06qMmbWbPywwuuPt0r+MJN8VsRN/YAv6ldrLXVL9MJcROL20Au9QB4XV47jDOI5SjYw/ieZ4XP9tAaRGYxooo3/tpnM6NXlEFI= X-ML-Name: ruby-core X-Mail-Count: 63729 Subject: [ruby-core:63729] [ruby-trunk - Bug #10037] Since r46798 on Solaris, "[BUG] rb_vm_get_cref: unreachable" during make 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 #10037 has been updated by Koichi Sasada. ```c enum iseq_type { ISEQ_TYPE_TOP, ISEQ_TYPE_METHOD, ISEQ_TYPE_BLOCK, ISEQ_TYPE_CLASS, ISEQ_TYPE_RESCUE, ISEQ_TYPE_ENSURE, ISEQ_TYPE_EVAL, ISEQ_TYPE_MAIN, ISEQ_TYPE_DEFINED_GUARD } type; /* instruction sequence type */ uint32_t stack_max; /* for stack overflow check */ ... #define RUBY_VM_IFUNC_P(ptr) (BUILTIN_TYPE(ptr) == T_NODE) #define RUBY_VM_NORMAL_ISEQ_P(ptr) \ ((ptr) && !RUBY_VM_IFUNC_P(ptr)) ``` On little endian, first 8 bytes (corresponds to RBasic::flags) of rb_iseq_t can not become T_NODE bit pattern. However, big endian can become. Goto-san, could you check it? Like that: ```diff Index: iseq.c =================================================================== --- iseq.c (revision 46821) +++ iseq.c (working copy) @@ -450,6 +450,8 @@ prepare_iseq_build(iseq, name, path, absolute_path, first_lineno, parent, type, bopt, option); rb_iseq_compile_node(self, node); cleanup_iseq_build(iseq); + + if (BUILTIN_TYPE((VALUE)iseq) == T_NODE) rb_bug("unreachable"); return self; } ``` ---------------------------------------- Bug #10037: Since r46798 on Solaris, "[BUG] rb_vm_get_cref: unreachable" during make https://bugs.ruby-lang.org/issues/10037#change-47773 * Author: Naohisa Goto * Status: Open * Priority: Normal * Assignee: Koichi Sasada * Category: * Target version: * ruby -v: ruby 2.2.0dev (2014-07-13) [sparc64-solaris2.10] * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN ---------------------------------------- Since r46798, failed to build on Solaris 10 running on SPARC64. ~~~ (snip) converter from WINDOWS-874 to UTF-8 converter from UTF-8 to WINDOWS-874 enc/trans/single_byte.trans:22: [BUG] rb_vm_get_cref: unreachable ruby 2.2.0dev (2014-07-13) [sparc64-solaris2.10] -- Control frame information ----------------------------------------------- c:0008 p:---- s:0056 e:000053 TOP [FINISH] c:0007 p:---- s:0052 e:000051 CFUNC :require c:0006 p:0015 s:0048 e:000047 METHOD enc/trans/single_byte.trans:22 c:0005 p:0244 s:0041 E:0011d8 EVAL enc/trans/single_byte.trans:48 [FINISH] c:0004 p:---- s:0037 e:000036 CFUNC :eval c:0003 p:0045 s:0030 e:000029 METHOD /XXXXXXXXXX/lib/erb.rb:850 c:0002 p:1228 s:0026 E:000cf8 EVAL ./tool/transcode-tblgen.rb:1043 [FINISH] c:0001 p:0000 s:0002 E:001d68 TOP [FINISH] -- Ruby level backtrace information ---------------------------------------- ./tool/transcode-tblgen.rb:1043:in `
' /XXXXXXXXXX/lib/erb.rb:850:in `result' /XXXXXXXXXX/lib/erb.rb:850:in `eval' enc/trans/single_byte.trans:48:in `
' enc/trans/single_byte.trans:22:in `transcode_tblgen_singlebyte' enc/trans/single_byte.trans:22:in `require' /XXXXXXXXXX/enc/trans/windows-1250-tbl.rb:1:in `' -- Other runtime information ----------------------------------------------- * Loaded script: ./tool/transcode-tblgen.rb * Loaded features: 0 enumerator.so 1 /XXXXXXXXXX/lib/optparse.rb 2 /XXXXXXXXXX/lib/cgi/util.rb 3 /XXXXXXXXXX/lib/erb.rb 4 /XXXXXXXXXX/lib/fileutils.rb 5 /XXXXXXXXXX/lib/prettyprint.rb 6 /XXXXXXXXXX/lib/pp.rb 7 /XXXXXXXXXX/enc/trans/iso-8859-1-tbl.rb 8 /XXXXXXXXXX/enc/trans/iso-8859-2-tbl.rb 9 /XXXXXXXXXX/enc/trans/iso-8859-3-tbl.rb 10 /XXXXXXXXXX/enc/trans/iso-8859-4-tbl.rb 11 /XXXXXXXXXX/enc/trans/iso-8859-5-tbl.rb 12 /XXXXXXXXXX/enc/trans/iso-8859-6-tbl.rb 13 /XXXXXXXXXX/enc/trans/iso-8859-7-tbl.rb 14 /XXXXXXXXXX/enc/trans/iso-8859-8-tbl.rb 15 /XXXXXXXXXX/enc/trans/iso-8859-9-tbl.rb 16 /XXXXXXXXXX/enc/trans/iso-8859-10-tbl.rb 17 /XXXXXXXXXX/enc/trans/iso-8859-11-tbl.rb 18 /XXXXXXXXXX/enc/trans/iso-8859-13-tbl.rb 19 /XXXXXXXXXX/enc/trans/iso-8859-14-tbl.rb 20 /XXXXXXXXXX/enc/trans/iso-8859-15-tbl.rb 21 /XXXXXXXXXX/enc/trans/iso-8859-16-tbl.rb 22 /XXXXXXXXXX/enc/trans/windows-874-tbl.rb [NOTE] You may have encountered a bug in the Ruby interpreter or extension libraries. Bug reports are welcome. For details: http://www.ruby-lang.org/bugreport.html Abort make[1]: *** [enc/trans/single_byte.c] Error 134 make[1]: Leaving directory `/XXXXXXXXXX' make: *** [srcs-enc] Error 2 ~~~ The following patch fixed the problem (tested with r46821), but this completely breaks the benefit of r46798. ~~~ Index: vm_core.h =================================================================== --- vm_core.h (revision 46821) +++ vm_core.h (working copy) @@ -205,6 +205,7 @@ ISEQ_TYPE_MAIN, ISEQ_TYPE_DEFINED_GUARD } type; /* instruction sequence type */ + uint32_t dummy; uint32_t stack_max; /* for stack overflow check */ rb_iseq_location_t location; ~~~ I think it is possbile that the first 8 byte (in 64-bit architecture) of "struct rb_iseq_struct" is sometimes used for some other purposes (maybe VALUE ?), and on big-endian 64-bit architecture (including SPARC64), it is frequently misunderstood as the other type. By the way, I think "int stack_max" is better than "uint32_t stack_max" because it seems that all calculations of stack_max in compile.c(iseq_set_sequence) and vm_insnhelper.c(vm_push_frame) are conducted using int. -- https://bugs.ruby-lang.org/