Issue #21310 has been updated by hsbt (Hiroshi SHIBATA). Note: http://github.com/ruby/ruby/commit/7afa08ce8d245c7d756ddaeb78daddb61fd0e271 is backport commit for Ruby 3.4 ---------------------------------------- Bug #21310: YJIT optimization causes incorrect is_a? method evaluation https://bugs.ruby-lang.org/issues/21310#change-114144 * Author: ravron-hb (Riley Avron) * Status: Closed * Assignee: jit * 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 ---------------------------------------- Our Rails application contains code like the following: ```ruby 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?`: ```ruby 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. -- https://bugs.ruby-lang.org/