Bug #20174
closedRuby 3.2 jit_cont_free segfault with YJIT enabled
Description
Ruby 3.2 segfaults reproducibly for us on aarch64 (Graviton2) and x86_64 with YJIT enabled ... however all of my attempts to make a minimal reproducible test case have failed. The control frame of the segfault isn't consistent, but the C backtrace is. It doesn't occur in 3.3, so I used the backtrace to find the function (jit_cont_free) and compare it between 3.2 and 3.3. The only change that seemed like a plausible candidate was a one-line guard added by k0kubun in e07e9f8491d9ab8b22d2bdf6a8aeba834dac7eef, so I added .patch to the end of the URL on GitHub and added that as a patch against 3.2. This resolved the problem. I would therefore suggest backporting that change from 3.3 to 3.2 :).
The change that triggered this is a two line change to a gemspec (that we need to refactor) that we made because Rake released a new version, which I will censor and annotate below:
# frozen_string_literal: true
$LOAD_PATH.push File.expand_path('lib', __dir__)
require 'rubygems/dependency_installer'
# before: Gem::DependencyInstaller.new.install(Gem::Dependency.new('rake'))
# after:
Gem::DependencyInstaller.new.install(Gem::Dependency.new('rake', '~> 13.1.0'))
require 'rake/file_list'
Gem::Specification.new do |spec|
spec.name = 'censored'
spec.version = '0.0.1.pre'
spec.author = 'censored'
spec.email = 'censored'
spec.summary = 'censored'
spec.description = 'censored'
spec.homepage = 'censored'
spec.license = 'All rights reserved'
spec.required_ruby_version = '>= 2.6.0'
spec.metadata['homepage_uri'] = spec.homepage
gitignore = File.read('.gitignore').lines.reject { |l| l.match?(/\A\s*#/) || l.match?(/\A\s*\z/) }.map(&:chomp)
spec.files = Rake::FileList.new('\.[a-zA-Z0-9]*', '\.[a-zA-Z0-9]*/*', '**/*')
.exclude(gitignore)
.reject { |f| File.directory?(f) || f.match(%r{\A(test|spec|features|vendor|.git|.bundle)/}) }
to_include = gitignore.select { |l| l.match?(/\A\s*!/) }.map { |l| l.delete_prefix('!') }
spec.files += Rake::FileList.new(to_include).reject { |f| File.directory?(f) }
spec.require_paths = ['lib']
spec.add_development_dependency 'awesome_print', '~> 1.8.0'
spec.add_development_dependency 'pry', '~> 0.14.2'
# before: spec.add_development_dependency 'rake', '~> 13.0.1'
# after:
spec.add_development_dependency 'rake', '~> 13.1.0'
spec.add_development_dependency 'rdoc', '~> 6.3.1'
spec.add_development_dependency 'rspec', '~> 3.11.0'
spec.add_development_dependency 'rspec_junit_formatter', '~> 0.5.1'
spec.add_development_dependency 'rubocop', '~> 1.39.0'
spec.add_development_dependency 'rubocop-packaging', '~> 0.5.2'
spec.add_development_dependency 'rubocop-rake', '~> 0.6.0'
spec.add_development_dependency 'rubocop-rspec', '~> 2.12.1'
spec.add_development_dependency 'simplecov', '~> 0.21.2'
spec.add_development_dependency 'simplecov-cobertura', '~> 2.1.0'
spec.add_development_dependency 'yard', '~> 0.9.25'
spec.add_runtime_dependency 'activesupport', '>= 5.1.7', '< 8'
spec.add_runtime_dependency 'censored-m', '~> 0.1.72'
spec.add_runtime_dependency 'censored-r', '~> 0.1.175'
spec.add_runtime_dependency 'aws-sdk-athena', '~> 1.43'
spec.add_runtime_dependency 'aws-sdk-cloudwatch', '~> 1.5'
spec.add_runtime_dependency 'aws-sdk-core', '~> 3.122'
spec.add_runtime_dependency 'aws-sdk-dynamodb', '~> 1.5'
spec.add_runtime_dependency 'aws-sdk-firehose', '~> 1.1'
spec.add_runtime_dependency 'aws-sdk-glue', '~> 1.108'
spec.add_runtime_dependency 'aws-sdk-kinesis', '~> 1.13'
spec.add_runtime_dependency 'aws-sdk-redshift', '~> 1.2'
spec.add_runtime_dependency 'aws-sdk-s3', '~> 1.9'
spec.add_runtime_dependency 'aws-sdk-sns', '~> 1.3'
spec.add_runtime_dependency 'aws-sdk-sqs', '~> 1.3'
spec.add_runtime_dependency 'aws-sdk-ssm', '~> 1.76'
spec.add_runtime_dependency 'concurrent-ruby', '>= 1.1.5'
spec.add_runtime_dependency 'dry-configurable', '~> 0.13'
end
However, I cannot turn this gemspec into a reproducer on my end. The smallest change makes the segfault go away.
To avoid a gigantic issue description, I have attached the censored segfault backtraces and the RbConfig from the x86_64 build (since I'm compiling my own Ruby). I'll note again that while aarch64 and x86_64 appear to have failed while doing something in optparse this time, it appears random (or more likely: GC pressure related). I've also seen it fail when doing a require_relative much earlier. It always fails with the same C backtrace.
I have absolutely no idea why cont
might be NULL. The backtrace shows it is called by cont_free
, which has a VM_ASSERT
for detecting this condition. Obviously, there must be some situation where jit_cont becomes NULL due to YJIT, but I have no idea what that situation is.
In case someone thinks this might be compiler/compiler option related, I am using the following:
- Amazon Linux 2
- LLVM/Clang 11 except that because Amazon Linux doesn't ship lld, we are using
gcc10-ld.gold
as the linker - rustc 1.68.2 (9eb3afe9e 2023-03-27) (Amazon Linux 1.68.2-1.amzn2.0.3)
- OpenSSL 3.0.12 (self-compiled with corp-dictated hardened configuration options ... I can share if someone thinks this is relevant)
extra_warnflags="-Wno-address-of-packed-member -Wno-declaration-after-statement -Wno-register"
- aarch64:
optflags="-O3 -mcpu=neoverse-n1"
- x86_64:
optflags="-O3 -march=sandybridge"
Files