From: xtkoba+ruby@... Date: 2021-03-02T03:13:33+00:00 Subject: [ruby-core:102690] [Ruby master Bug#17540] A segfault due to Clang/LLVM optimization on 32-bit ARM Linux Issue #17540 has been updated by xtkoba (Tee KOBAYASHI). Compilation with `-fno-strict-aliasing` seems to resolve the main issue of the `ruby` crash. It would be nice if this compiler option is added by default, unless it causes a serious performance drawback. user:shyouhei That change might have induced the issue, but I don't think it is the fundamental cause. The trouble would be that the type `struct RBasic` has aliases. In this point of view, yet another workaround would be as follows (although I don't know whether the attribute `may_alias` works with C++): ``` --- a/include/ruby/internal/core/rbasic.h +++ b/include/ruby/internal/core/rbasic.h @@ -66,7 +66,7 @@ RBasic { { } #endif -}; +} __attribute__ ((__may_alias__)); RBIMPL_SYMBOL_EXPORT_BEGIN() VALUE rb_obj_hide(VALUE obj); ``` FYI, some searching told me that CPython had a similar issue until version 2.7 with its object representation in C (cf. https://bugs.python.org/issue30104). ---------------------------------------- Bug #17540: A segfault due to Clang/LLVM optimization on 32-bit ARM Linux https://bugs.ruby-lang.org/issues/17540#change-90685 * Author: xtkoba (Tee KOBAYASHI) * Status: Open * Priority: Normal * ruby -v: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [armv7a-linux-eabi] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- When built with `optflags=-O3` (which is the default), `ruby -e "pp Thread.main"` causes a segfault, which seems to be worked around by the following change: ``` --- a/include/ruby/internal/fl_type.h +++ b/include/ruby/internal/fl_type.h @@ -231,7 +231,7 @@ RBIMPL_ATTR_PURE_UNLESS_DEBUG() RBIMPL_ATTR_ARTIFICIAL() static inline VALUE -RB_FL_TEST_RAW(VALUE obj, VALUE flags) +RB_FL_TEST_RAW(volatile VALUE obj, VALUE flags) { RBIMPL_ASSERT_OR_ASSUME(RB_FL_ABLE(obj)); return RBASIC(obj)->flags & flags; ``` There might be a bug in the optimizer of Clang/LLVM (version 11.0.1). -- https://bugs.ruby-lang.org/ Unsubscribe: