From: "peterzhu2118 (Peter Zhu) via ruby-core" <ruby-core@...>
Date: 2026-10-07T14:23:34+00:00
Subject: [ruby-core:126981] [Ruby Bug#22412] Assertion Failed: vm_ep_in_heap_p_:env->ep == ep

Issue #22412 has been updated by peterzhu2118 (Peter Zhu).

Backport changed from 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN to 3.3: DONTNEED, 3.4: DONTNEED, 4.0: DONTNEED

Thank you for the bug report. I have a fix here: https://github.com/ruby/ruby/pull/19251

----------------------------------------
Bug #22412: Assertion Failed: vm_ep_in_heap_p_:env->ep == ep
https://bugs.ruby-lang.org/issues/22412#change-119376

* Author: 0599jiangyc@gmail.com (Yuancheng Jiang)
* Status: Open
* Backport: 3.3: DONTNEED, 3.4: DONTNEED, 4.0: DONTNEED
----------------------------------------
The following code:

```ruby
pr = proc {|a, b| }.curry.dup
pr.call(1)
```

(also `lambda {|a, b| }.curry.clone[1]`, or `define_method(:m, &proc {|a, b| }.curry); m(1)` which dups the proc internally)

Resulted in this output (RUBY_DEBUG build):

```
../vm.c:281: Assertion Failed: vm_ep_in_heap_p_:env->ep == ep
ruby 4.1.0dev (2026-10-07) +PRISM [x86_64-linux]

-- Ruby level backtrace information ----------------------------------------
min.rb:2:in '<main>'
min.rb:2:in 'proc'

-- C level backtrace information -------------------------------------------
(vm_ep_in_heap_p_+0x1a2) vm.c:281
(VM_ENV_ESCAPED_P+0xae) vm.c:295
(vm_make_env_each+0x133) vm.c:1120
(vm_make_env_object+0x8) vm.c:1217
(rb_vm_make_proc_lambda) vm.c:1720
(vm_call0_body+0x100a) ../vm_eval.c:164
(rb_call0+0x4c5) ../vm_eval.c:101
(iterate_method+0x144) ../vm_eval.c:896
(rb_iterate0+0x298) ../vm_eval.c:1506
(rb_block_call_kw+0x42) ../vm_eval.c:1580
(make_curry_proc) proc.c:4525
(curry+0x118) proc.c:4545
(vm_yield_with_cfunc+0x172) ../vm_insnhelper.c:5275
```

`rb_func_proc_dup` (proc.c) gives the copy its own ep inside the new `cfunc_proc_t`, but copies
`ep[VM_ENV_DATA_INDEX_ENV]` from the source. For a curried proc that slot already holds an env object
(created when `curry` called `Kernel#proc`/`lambda` on the ifunc block), whose `env->ep` points into the
*source* proc's storage. The duplicate's ep and its env therefore disagree. Only the debug assertion fires
in our testing; we did not observe a crash or ASan report on a non-debug build, even after dropping the
source proc and running `GC.start`/`GC.compact`. (Related area: Bug #20950, whose backport note mentions a
`vm_ep_in_heap_p_` VM_ASSERT failure; possibly also related to Bug #22113.)

To reproduce:

```
ruby ./min.rb
```

Commit:
```
3296d5c99ce005e4698fb27a405e01d766ad2647 (2026-09-15); also reproduced on master 9ce0df671980d669cbab8afc48124c7453897533 (2026-10-07)
```

Build configuration:
```
../configure --disable-install-doc CC=clang-18 cflags="-fsanitize=address -fno-omit-frame-pointer -DUSE_MN_THREADS=0" cppflags="-DRUBY_DEBUG=1" optflags="-O1" debugflags="-g"
```

Operating System:
```
Ubuntu 24.04.4 LTS (x86_64), clang 18.1.3
```

*This bug was found by [fusion-fuzz](https://github.com/fusion-fuzz/fusion-fuzz)*



-- 
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/