Skip to content

Conversation

@pull
Copy link

@pull pull bot commented Dec 4, 2025

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

byroot and others added 13 commits December 3, 2025 19:51
Attempt to fix the following SEGV:

```
ruby(gc_mark) ../src/gc/default/default.c:4429
ruby(gc_mark_children+0x45) [0x560b380bf8b5] ../src/gc/default/default.c:4625
ruby(gc_mark_stacked_objects) ../src/gc/default/default.c:4647
ruby(gc_mark_stacked_objects_all) ../src/gc/default/default.c:4685
ruby(gc_marks_rest) ../src/gc/default/default.c:5707
ruby(gc_marks+0x4e7) [0x560b380c41c1] ../src/gc/default/default.c:5821
ruby(gc_start) ../src/gc/default/default.c:6502
ruby(heap_prepare+0xa4) [0x560b380c4efc] ../src/gc/default/default.c:2074
ruby(heap_next_free_page) ../src/gc/default/default.c:2289
ruby(newobj_cache_miss) ../src/gc/default/default.c:2396
ruby(RB_SPECIAL_CONST_P+0x0) [0x560b380c5df4] ../src/gc/default/default.c:2420
ruby(RB_BUILTIN_TYPE) ../src/include/ruby/internal/value_type.h:184
ruby(newobj_init) ../src/gc/default/default.c:2136
ruby(rb_gc_impl_new_obj) ../src/gc/default/default.c:2500
ruby(newobj_of) ../src/gc.c:996
ruby(rb_imemo_new+0x37) [0x560b380d8bed] ../src/imemo.c:46
ruby(imemo_fields_new) ../src/imemo.c:105
ruby(rb_imemo_fields_new) ../src/imemo.c:120
```

I have no reproduction, but my understanding based on the backtrace
and error is that GC is triggered inside `newobj_init` causing the
new object to be marked while in a incomplete state.

I believe the fix is to pass the `shape_id` down to `newobj_init`
so it can be set before the GC has a chance to trigger.
If GC trigger in the middle of `struct_alloc`, and the struct has more
than 3 elements, then `fields_obj` reference is garbage.

We must first check the shape to know if it was actually initialized.
This commit adds a specialized instruction iterator to the assembler
with a custom "peek" method.  The reason is that we want to add basic
blocks to LIR.  When we split instructions, we need to add any new
instructions to the correct basic block.  The custom iterator will
maintain the correct basic block inside the assembler, that way when we
push any new instructions they will be appended to the correct place.
This commit uses the custom instruction iterator in arm64 / x86_64
instruction splitting.  Once we introduce basic blocks to LIR, the
custom iterator will ensure that instructions are added to the correct
place.
This should never be true. I added an `rb_bug` in case it was and it
wasn't true in any of btest or test-all.

Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>
Not every caller (for example, YJIT) actually needs to pass the object.
YJIT (and, in the future, ZJIT) only need to pass the class.
In the past parse.y and ripper had different `value_expr` definition
so that `value_expr` does nothing for ripper.

```c
// parse.y
#define value_expr(node) value_expr_gen(p, (node))

// ripper
#define value_expr(node) ((void)(node))
```

However Rearchitect Ripper (89cfc15)
removed `value_expr` definition for ripper then this commit removes
needless parse.y macro and uses `value_expr_gen` directly.
In the past parse.y and ripper had different `new_nil` definition
so that `new_nil` returns `nil` for ripper.

```c
// parse.y
#define new_nil(loc) NEW_NIL(loc)

// ripper
#define new_nil(loc) Qnil
```

However Rearchitect Ripper (89cfc15)
removed `new_nil` definition for ripper then this commit removes
needless parse.y macro and uses `NEW_NIL` directly.
Fixes: #685

This feature can easily break how you use other gems like factory_bot or prawn.

ruby/psych#747 (comment)
> But I kind of think we should leave `psych/y` around. If people really want to use it they could require the file.

If you miss the function in Kernel, you can require it interactively or add it to `.irbrc`:
```ruby
require 'psych/y'
```

ruby/psych@f1610b3f05
@pull pull bot locked and limited conversation to collaborators Dec 4, 2025
@pull pull bot added the ⤵️ pull label Dec 4, 2025
@pull pull bot merged commit 0e7e685 into turkdevops:master Dec 4, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants