maintainer-feedback requested: [Bug 255583] lang/ruby27: odd crash with certain "case" expressions on FreeBSD but not on Linux

[bugzilla-noreply at freebsd.org]

Bugzilla Automation <bugzilla at FreeBSD.org> has asked freebsd-ruby (Nobody)
<ruby at FreeBSD.org> for maintainer-feedback:
Bug 255583: lang/ruby27: odd crash with certain "case" expressions on FreeBSD
but not on Linux
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255583



--- Description ---
ruby -e 'case 1; when 2r; 3; end'

Dies with a SIGSEGV.

Backtrace (with a debug build):

* thread #1, name = 'ruby27', stop reason = signal SIGSEGV
    frame #0: 0x0000000801add4e8
libruby27.so.27`append_compile_error(iseq=0x000000089445a6b8, line=1125956,
fmt="") at compile.c:380:47
    frame #1: 0x00007fffffffc930
  * frame #2: 0x0000000801c4d915 libruby27.so.27`rb_st_lookup [inlined]
do_hash(key=36847331000, tab=0x000000086f314d40) at st.c:326:33
    frame #3: 0x0000000801c4d90b
libruby27.so.27`rb_st_lookup(tab=0x000000086f314d40, key=36847331000,
value=0x00007fffffffc958) at st.c:1104
    frame #4: 0x0000000801b63443 libruby27.so.27`rb_hash_lookup2 [inlined]
hash_stlike_lookup(hash=36847330480, key=<unavailable>,
pval=0x00007fffffffc958) at hash.c:0
    frame #5: 0x0000000801b6339a
libruby27.so.27`rb_hash_lookup2(hash=36847330480, key=36847331000, def=8) at
hash.c:2070
    frame #6: 0x0000000801b0640a
libruby27.so.27`when_vals(iseq=0x000000089445a550, cond_seq=0x00007fffffffcb60,
vals=0x0000000878b93098, l1=<unavailable>, only_special_literals=1,
literals=<unavailable>) at compile.c:4322:18
    frame #7: 0x0000000801afac70 libruby27.so.27`iseq_compile_each0 at
compile.c:5334:27
    frame #8: 0x0000000801afa5c1
libruby27.so.27`iseq_compile_each0(iseq=0x000000089445a550,
ret=0x00007fffffffcd60, node=0x0000000878b93108, popped=0) at compile.c:7162
    frame #9: 0x0000000801b0ab71 libruby27.so.27`setup_args_core [inlined]
compile_args(node=0x0000000878b93140) at compile.c:3923:13
    frame #10: 0x0000000801b0ab59
libruby27.so.27`setup_args_core(iseq=0x000000089445a550,
args=0x00007fffffffcd60, argn=<unavailable>, dup_rest=<unavailable>,
flag=<unavailable>, keywords=0x00007fffffffcd28) at compile.c:5049
    frame #11: 0x0000000801af4dbf libruby27.so.27`iseq_compile_each0 [inlined]
compile_call(iseq=0x000000089445a550, ret=0x00007fffffffce80,
node=0x0000000878b93060, type=<unavailable>, line=1, popped=0) at
compile.c:7046:16
    frame #12: 0x0000000801af4ce1
libruby27.so.27`iseq_compile_each0(iseq=0x000000089445a550,
ret=0x00007fffffffce80, node=0x0000000878b93060, popped=0) at compile.c:7670
    frame #13: 0x0000000801adc735
libruby27.so.27`rb_iseq_compile_node(iseq=0x000000089445a550,
node=<unavailable>) at compile.c:702:6
    frame #14: 0x0000000801b85a47
libruby27.so.27`rb_iseq_new_with_opt(ast=0x000000089445a718,
name=<unavailable>, path=<unavailable>, realpath=<unavailable>, first_lineno=1,
parent=0x0000000819358010, type=ISEQ_TYPE_MAIN, option=0x0000000801cf1d28) at
iseq.c:821:5
    frame #15: 0x0000000801b85b6d
libruby27.so.27`rb_iseq_new_main(ast=<unavailable>, path=<unavailable>,
realpath=<unavailable>, parent=<unavailable>) at iseq.c:787:12
    frame #16: 0x0000000801c40537 libruby27.so.27`ruby_process_options at
ruby.c:1904:9
    frame #17: 0x0000000801c3f433
libruby27.so.27`ruby_process_options(argc=<unavailable>, argv=<unavailable>) at
ruby.c:2413
    frame #18: 0x0000000801b3f513
libruby27.so.27`ruby_options(argc=<unavailable>, argv=<unavailable>) at
eval.c:124:2
    frame #19: 0x0000000000201cca ruby27`main(argc=<unavailable>,
argv=<unavailable>) at main.c:50:23
    frame #20: 0x0000000000201a70 ruby27`_start(ap=<unavailable>,
cleanup=<unavailable>) at crt1.c:76:7

It happens whenever a rational literal is used as a branch in a case
expression.  Happens during the parse/compile phase (e.g. when "require"'ing a
file with a construct like that).  With both package and port.	I tested on
12.2-RELEASE, 12.2-STABLE and 14-CURRENT and they all have the problem.

The problem started happening recently but I'm not sure when or due to what
changes.

It doesn't happen if Ruby is built with GCC (e.g. by setting USE_GCC=yes in the
port).

Looks like it's a case of Clang's optimizer being a bit more aggressive (and/or
header macros being defined in a way that leads to that).

Patch:

diff --git c/lang/ruby27/files/patch-compile.c
i/lang/ruby27/files/patch-compile.c
new file mode 100644
index 000000000000..c766600b8f40
--- /dev/null
+++ i/lang/ruby27/files/patch-compile.c
@@ -0,0 +1,20 @@
+--- compile.c.orig	2021-04-05 08:39:38.000000000 -0400
++++ compile.c	2021-05-03 20:49:59.011745000 -0400
+@@ -1820,7 +1820,7 @@
+	  return rb_float_cmp(lit, val);
+     }
+     else {
+-	  UNREACHABLE_RETURN(-1);
++	  return -1;
+     }
+ }
+ 
+@@ -1838,7 +1838,7 @@
+	case T_FLOAT:
+	  return rb_dbl_long_hash(RFLOAT_VALUE(a));
+	default:
+-	  UNREACHABLE_RETURN(0);
++	  return 0;
+     }
+ }
+ 

The default branches there are NOT unreachable and Clang eliding them seems to
be causing a runaway program counter.

There's actually a flaw in Ruby there that causes a pessimization of the hash
table optimization for the literals of a switch because the hash table doesn't
properly handles all numeric types (but it still tries to insert them in it),
but it harmlessly fallsback to testing the branches one by one.

lang/ruby26 and lang/ruby30 have the same problem and could use the same patch.