From: "Fryguy (Jason Frey)" Date: 2021-09-13T17:01:56+00:00 Subject: [ruby-core:105228] [Ruby master Bug#18164] Segfault after spawn when using modified ENV Issue #18164 has been updated by Fryguy (Jason Frey). I'm at the point where I don't understand the Ruby code anymore but I think what's happening is...roughly: ---------------------------------------- Bug #18164: Segfault after spawn when using modified ENV https://bugs.ruby-lang.org/issues/18164#change-93634 * Author: Fryguy (Jason Frey) * Status: Open * Priority: Normal * ruby -v: ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-darwin20] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- The attached segfault.rb causes a segfault on Ruby 3.0.2 (also on 2.7.2+). This is the smallest reproducer we could get. ```ruby ENV = {} spawn({}, "true") ENV.replace({}) ``` You can also change the last line to `ENV.to_s` and it also segfaults. Note that while this script is the smallest reproducer we could get to, it's unlikely that someone might replace the ENV in this way directly. A more realistic usage scenario (which is how I found this) is using RSpec, having a spec that spawns a subprocess, using `stub_const` to have an alternate ENV, and using `Bundler.with_unbundled_env` to ensure that bundler env vars are not passed to the child process. This is demonstrated in the attached segfault_spec.rb. Here, `stub_const` effectively does the `ENV = {}` portion, and `Bundler.with_unbundled_env` does the `ENV.replace({})` portion (https://github.com/rubygems/rubygems/blob/b737e1c930aaca15618c702f10553992087e2bc4/bundler/lib/bundler.rb#L693) ---Files-------------------------------- segfault.rb (43 Bytes) segfault_spec.rb (255 Bytes) -- https://bugs.ruby-lang.org/ Unsubscribe: