Issue #21021 has been updated by tenderlovemaking (Aaron Patterson). Odd. This may be a weak map bug as @alanwu is saying. The C level back trace has these lines: ``` /usr/local/lib/libruby.so.3.4(rb_gc_mark_vm_stack_values) /usr/include/ruby-3.4.1/gc.c:2346 /usr/local/lib/libruby.so.3.4(rb_execution_context_mark+0x39) [0x7f329134af49] /usr/include/ruby-3.4.1/vm.c:3415 ``` The GC is scanning the VM stack marking any Ruby objects it finds in the stack. This means something has pushed an invalid reference on the Ruby stack. Do you know if any of the code in your Ruby level backtrace are using WeakMaps? ---------------------------------------- Bug #21021: "try to mark T_NONE object" with 3.4.1 https://bugs.ruby-lang.org/issues/21021#change-111535 * 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/