1.7.11 consistently segfaulting

[mscrivo]

Describe the bug
1.7.11 consistently segfaults in our CI environment. 1.7.10 works perfectly fine. The backtrace is:

Finding all unresolved constants, this may take a few seconds... bundler: failed to load command: tapioca (/home/affinity/vendor/bundle/ruby/3.4.0/bin/tapioca)
/home/affinity/vendor/bundle/ruby/3.4.0/gems/spoom-1.7.11/lib/spoom/context/sorbet.rb:22:in 'Spoom::Context::Sorbet#srb': Sorbet segfaulted. (Spoom::Sorbet::Error::Segfault)
        from /home/affinity/vendor/bundle/ruby/3.4.0/gems/tapioca-0.17.10/lib/tapioca/helpers/sorbet_helper.rb:24:in 'Tapioca::SorbetHelper#sorbet'
        from /home/affinity/vendor/bundle/ruby/3.4.0/gems/tapioca-0.17.10/lib/tapioca/commands/todo.rb:86:in 'Tapioca::Commands::Todo#unresolved_constants'
        from /home/affinity/vendor/bundle/ruby/3.4.0/gems/sorbet-runtime-0.6.12897/lib/types/private/methods/_methods.rb:261:in 'UnboundMethod#bind_call'
        from /home/affinity/vendor/bundle/ruby/3.4.0/gems/sorbet-runtime-0.6.12897/lib/types/private/methods/_methods.rb:261:in 'block in Tapioca::Commands::Todo#_on_method_added'
        from /home/affinity/vendor/bundle/ruby/3.4.0/gems/tapioca-0.17.10/lib/tapioca/commands/todo.rb:47:in 'Tapioca::Commands::Todo#execute'
        from /home/affinity/vendor/bundle/ruby/3.4.0/gems/sorbet-runtime-0.6.12897/lib/types/private/methods/_methods.rb:261:in 'UnboundMethod#bind_call'
        from /home/affinity/vendor/bundle/ruby/3.4.0/gems/sorbet-runtime-0.6.12897/lib/types/private/methods/_methods.rb:261:in 'block in Tapioca::Commands::Todo#_on_method_added'
        from /home/affinity/vendor/bundle/ruby/3.4.0/gems/tapioca-0.17.10/lib/tapioca/commands/command.rb:28:in 'block in Tapioca::Commands::Command#run'
        from /home/affinity/vendor/bundle/ruby/3.4.0/gems/tapioca-0.17.10/lib/tapioca/runtime/helpers.rb:15:in 'block in Tapioca::Runtime.silence_warnings'
        from /usr/local/lib/ruby/3.4.0/rubygems/user_interaction.rb:46:in 'Gem::DefaultUserInteraction.use_ui'
        from /home/affinity/vendor/bundle/ruby/3.4.0/gems/tapioca-0.17.10/lib/tapioca/runtime/helpers.rb:14:in 'Tapioca::Runtime.silence_warnings'
        from /home/affinity/vendor/bundle/ruby/3.4.0/gems/tapioca-0.17.10/lib/tapioca/commands/command.rb:27:in 'Tapioca::Commands::Command#run'
        from /home/affinity/vendor/bundle/ruby/3.4.0/gems/tapioca-0.17.10/lib/tapioca/cli.rb:39:in 'Tapioca::Cli#init'
        from /home/affinity/vendor/bundle/ruby/3.4.0/gems/thor-1.5.0/lib/thor/command.rb:28:in 'Thor::Command#run'
        from /home/affinity/vendor/bundle/ruby/3.4.0/gems/thor-1.5.0/lib/thor/invocation.rb:127:in 'Thor::Invocation#invoke_command'
        from /home/affinity/vendor/bundle/ruby/3.4.0/gems/thor-1.5.0/lib/thor.rb:538:in 'Thor.dispatch'
        from /home/affinity/vendor/bundle/ruby/3.4.0/gems/thor-1.5.0/lib/thor/base.rb:585:in 'Thor::Base::ClassMethods#start'
        from /home/affinity/vendor/bundle/ruby/3.4.0/gems/tapioca-0.17.10/exe/tapioca:31:in '<top (required)>'
        from /home/affinity/vendor/bundle/ruby/3.4.0/bin/tapioca:25:in 'Kernel#load'
        from /home/affinity/vendor/bundle/ruby/3.4.0/bin/tapioca:25:in '<top (required)>'
        from /usr/local/lib/ruby/3.4.0/bundler/cli/exec.rb:59:in 'Kernel.load'
        from /usr/local/lib/ruby/3.4.0/bundler/cli/exec.rb:59:in 'Bundler::CLI::Exec#kernel_load'
        from /usr/local/lib/ruby/3.4.0/bundler/cli/exec.rb:23:in 'Bundler::CLI::Exec#run'
        from /usr/local/lib/ruby/3.4.0/bundler/cli.rb:452:in 'Bundler::CLI#exec'
        from /usr/local/lib/ruby/3.4.0/bundler/vendor/thor/lib/thor/command.rb:28:in 'Bundler::Thor::Command#run'
        from /usr/local/lib/ruby/3.4.0/bundler/vendor/thor/lib/thor/invocation.rb:127:in 'Bundler::Thor::Invocation#invoke_command'
        from /usr/local/lib/ruby/3.4.0/bundler/vendor/thor/lib/thor.rb:538:in 'Bundler::Thor.dispatch'
        from /usr/local/lib/ruby/3.4.0/bundler/cli.rb:35:in 'Bundler::CLI.dispatch'
        from /usr/local/lib/ruby/3.4.0/bundler/vendor/thor/lib/thor/base.rb:584:in 'Bundler::Thor::Base::ClassMethods#start'
        from /usr/local/lib/ruby/3.4.0/bundler/cli.rb:29:in 'Bundler::CLI.start'
        from /usr/local/lib/ruby/gems/3.4.0/gems/bundler-2.6.9/exe/bundle:28:in 'block in <top (required)>'
        from /usr/local/lib/ruby/3.4.0/bundler/friendly_errors.rb:117:in 'Bundler.with_friendly_errors'
        from /usr/local/lib/ruby/gems/3.4.0/gems/bundler-2.6.9/exe/bundle:20:in '<top (required)>'
        from /usr/local/bin/bundle:25:in 'Kernel#load'
        from /usr/local/bin/bundle:25:in '<main>'

To Reproduce
Spoom version: 1.7.11

Run:

bundle exec spoom srb coverage timeline --save
bundle exec spoom srb coverage report

on a largish codebase

NOTE: sorbet and tapioca gems are all on the latest versions.

[Morriar]

Sorbet segfaulted. (Spoom::Sorbet::Error::Segfault)

It seems the problem lies with Sorbet rather than Spoom.

Which versions of Sorbet are you using before/after the bump? Are you using RBS comments maybe? We just fixed a segfault related to them: sorbet/sorbet#9842.

Closing as I don't think this is related to Spoom.

[mscrivo]

Sorbet segfaulted. (Spoom::Sorbet::Error::Segfault)

It seems the problem lies with Sorbet rather than Spoom.

Which versions of Sorbet are you using before/after the bump? Are you using RBS comments maybe? We just fixed a segfault related to them: sorbet/sorbet#9842.

Closing as I don't think this is related to Spoom.

That's what you'd think, but I tried this with multiple versions of sorbet & tapioca going back a couple months. The only thing that is consistent is that it doesn't segfault with spoom 1.7.10 with any combination of sorbet, but does with 1.7.11.

[Morriar]

I'm a bit confused since the message you're seeing is because Spoom ran Sorbet and it detected that Sorbet itself segfaulted, see

spoom/lib/spoom/context/sorbet.rb

Lines 12 to 23 in ae2e1ae

	res = if sorbet_bin
	exec("#{sorbet_bin} #{arg.join(" ")}", capture_err: capture_err)
	else
	bundle_exec("srb #{arg.join(" ")}", capture_err: capture_err)
	end
	case res.exit_code
	when Spoom::Sorbet::KILLED_CODE
	raise Spoom::Sorbet::Error::Killed.new("Sorbet was killed.", res)
	when Spoom::Sorbet::SEGFAULT_CODE
	raise Spoom::Sorbet::Error::Segfault.new("Sorbet segfaulted.", res)
	end

.

[mscrivo]

yeah you seem to be right, in that spoom 1.7.11 is now detecting it properly and reporting it. The undesirable result though is that the build is now failing whereas previously it worked. The weird thing is that even if sorbet was always segfaulting, it was somehow working and completing the command it was asked to do. So I don't understand how it could have always been segfaulting and still completing? Anyhow sorry for the incorrect report. I'll try to figure out why it's segfaulting.