From: "travisbell (Travis Bell) via ruby-core" Date: 2025-01-24T16:39:28+00:00 Subject: [ruby-core:120786] [Ruby master Bug#21021] "try to mark T_NONE object" with 3.4.1 Issue #21021 has been updated by travisbell (Travis Bell). Benoit_Tigeot (Benoit Tigeot) wrote in #note-23: > The "good" news, is I am able to reproduce at 100% if I use concurrency. For what it's worth on #21034, that environment is a Falcon environment so yes, concurrency is in play there as well. What's interesting is different service of ours which is also using Falcon, never crashes. So simply "being concurrent" isn't enough to trigger it, although that's what all of these tickets have in common, YJIT + concurrency. ---------------------------------------- Bug #21021: "try to mark T_NONE object" with 3.4.1 https://bugs.ruby-lang.org/issues/21021#change-111655 * Author: Benoit_Tigeot (Benoit Tigeot) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +YJIT +PRISM [x86_64-linux] ��� * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Hello We upgraded to 3.4.1 yesterday but we are seeing crash since then. ``` /bundle/ruby/3.4.0/gems/activejob-7.2.2.1/lib/active_job/enqueuing.rb:93: [BUG] try to mark T_NONE object ``` I saw the other issue related to ffi gem https://bugs.ruby-lang.org/issues/20694 But in our case the `C level backtrace information` looks different. https://gist.github.com/benoittgt/13507c2000281aa7740bc782adab68c5 We migrated this part of the code to parallel->concurrent-ruby and we do not see the error yet again but I am a little bit worried we could see the issue again. -- https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/