ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: ko1@atdot.net
To: ruby-core@ruby-lang.org
Subject: [ruby-core:63729] [ruby-trunk - Bug #10037] Since r46798 on Solaris, "[BUG] rb_vm_get_cref: unreachable" during make
Date: Tue, 15 Jul 2014 09:51:45 +0000	[thread overview]
Message-ID: <redmine.journal-47773.20140715095144.7d4cf0e94f21c455@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-10037.20140715053007@ruby-lang.org

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 `<main>'
/XXXXXXXXXX/lib/erb.rb:850:in `result'
/XXXXXXXXXX/lib/erb.rb:850:in `eval'
enc/trans/single_byte.trans:48:in `<main>'
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 `<top (required)>'

-- 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/

  parent reply	other threads:[~2014-07-15  9:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <redmine.issue-10037.20140715053007@ruby-lang.org>
2014-07-15  5:30 ` [ruby-core:63721] [ruby-trunk - Bug #10037] [Open] Since r46798 on Solaris, "[BUG] rb_vm_get_cref: unreachable" during make ngotogenome
2014-07-15  5:53   ` [ruby-core:63722] " Eric Wong
2014-07-15  6:01 ` [ruby-core:63723] [ruby-trunk - Bug #10037] " normalperson
2014-07-15  6:31 ` [ruby-core:63724] " ngotogenome
2014-07-15  7:50   ` [ruby-core:63726] " Eric Wong
2014-07-15  7:51 ` [ruby-core:63727] " normalperson
2014-07-15  9:51 ` ko1 [this message]
2014-07-15 16:38 ` [ruby-core:63743] " ngotogenome
2014-07-15 18:28   ` [ruby-core:63745] " SASADA Koichi
2014-07-15 19:48     ` [ruby-core:63748] " Eric Wong
2014-07-15 17:22 ` [ruby-core:63744] " ngotogenome
2014-07-15 18:31 ` [ruby-core:63746] " ko1
2014-07-15 19:51 ` [ruby-core:63749] " normalperson
2014-07-16 11:50 ` [ruby-core:63771] " ngotogenome
2014-08-06  4:11 ` [ruby-core:64225] [ruby-trunk - Bug #10037] [Assigned] " shibata.hiroshi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-47773.20140715095144.7d4cf0e94f21c455@ruby-lang.org \
    --to=ruby-core@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).