Bug #21310: YJIT optimization causes incorrect is_a? method evaluation

• Status: Feedback
• Assignee: jit
• Target version: -
• ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +YJIT +PRISM [arm64-darwin24]
• Backport: 3.2: REQUIRED, 3.3: DONE, 3.4: DONE

[ravron-hb (Riley Avron)]

Our Rails application contains code like the following:

result = a_proc.call

if result.is_a?(Result) && result.nil?
  puts('This should be impossible')
end

With YJIT enabled in dev mode and the yjit-call-threshold set to 2, the seemingly impossible condition always evaluates to true, and the puts is evaluated. If YJIT is disabled, the code behaves as expected: namely, the condition never evaluates to true. If YJIT is enabled but not in dev mode, with the yjit-call-threshold is set to 1,500 (as in our original configuration), the error occurs non-deterministically.

We originally discovered this issue while updating to Rails 7.2. The following code began to occasionally fail with a NoMethodError, complaining that nil:NilClass does not define success?:

result = a_proc.call

raise ResultRollbackError, result if result.is_a?(Result) && !result.success?

Result does define success?, so it seemed impossible that result.success? would be invoked unless result.is_a?(Result), and especially impossible that it would be invoked if result.nil?. After various debugging, we added the if statement shown in the first code block and discovered that YJIT’s optimizations seem to be incorrect.

The inability to predict the possible errors this could cause in our application led us to disable YJIT for our entire application while this behavior persists.

Unfortunately, we have not been able to reproduce the error in a self-contained case, which I know will make investigation more difficult. That said, we would like to assist in solving it however possible. We would appreciate guidance on how to obtain relevant debugging information, or suggestions on how we might generate a self-contained reproduction of the issue. We would also be willing to consider allowing a Ruby maintainer to review the actual code demonstrating the issue, though we would probably request that they sign an NDA in that case.

[k0kubun (Takashi Kokubun)]

• Assignee set to jit

[k0kubun (Takashi Kokubun)]

• Status changed from Open to Feedback

I think it's most likely fixed by https://github.com/ruby/ruby/pull/13245. It's going to be shipped in the next release. I'm thinking of releasing it as soon as we address a few other similar cases.

[nagachika (Tomoyuki Chikanaga)]

• Backport changed from 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN to 3.2: REQUIRED, 3.3: REQUIRED, 3.4: DONE

[nagachika (Tomoyuki Chikanaga)]

• Backport changed from 3.2: REQUIRED, 3.3: REQUIRED, 3.4: DONE to 3.2: REQUIRED, 3.3: DONE, 3.4: DONE

ruby_3_3 380938998415c22ba3ca9bc01f4035d5a73f274d merged revision(s) cbf9c088f8005a49b6aa3f475c70041357774c61.

[nagachika (Tomoyuki Chikanaga)]

Since jump_to_next_insn() has different arguments and return type on ruby_3_3, some follow up changes for 380938998415c22ba3ca9bc01f4035d5a73f274d were pushed.
7230a070e3dffc765fc6617436a2293c459c6c8d
c1c068e43c80aeb2e711b64261323594eca66217