Issue #10037 has been updated by Eric Wong. ngotogenome / gmail.com wrote: > 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. That sounds strange. I'll wait for ko1 to comment. I tried valgrind, but that did not report errors on x86-64 when I tried "make newline.c". tool/transcode-tblgen.rb ran without errors. > 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. I agree, that may be changed to int. Since enum is also signed int type, maybe having 32-bit signed and unsigned types next to each other is confusing the compiler? Can you try "int stack_max"? Thanks. ---------------------------------------- Bug #10037: Since r46798 on Solaris, "[BUG] rb_vm_get_cref: unreachable" during make https://bugs.ruby-lang.org/issues/10037#change-47769 * 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/