If GC occurs in `mrb_realloc()` in `ht_init()` called from `ar_set()`, the following inconsistency occurs:
- If `h_ht_on()` is called before `mrb_realloc()`, `hash->hsh.ht` is referenced instead of `hash->hsh.ea` during GC.
- If the pointer is changed by `ea_adjust()` in `ar_set()`, `hash->hsh.ea` (`hash->hsh.ht`) is referenced in GC before the change.
These modifications can be resolved by changing the order of processing.
However, if a `NoMemoryError` exception is raised, it is presumed that the size of the "AR" will be exceeded and the unintended state will continue.
To prevent this, elements should be added after they have been converted to "HT".
GC may occur in the `c->stbase = mrb_malloc()` part of the `fiber_init()` function.
The `SIGSEGV` happens because it references the `c->ci->stack` field without checking `c->ci`.
This is caused by #5272.
Exception raising can now be controlled by the caller.
The main purpose on this patch is:
- Suppress exceptions from `obj_free()` in `src/gc.c` with `mrb_env_unshare()`.
- Consider the possibility that calls to `mrb_malloc()` may cause `e` objects to be subject to GC.
When control is returned to `mrb_env_unshare()`, `struct free_obj::next` in the same offset as `struct REnv::stack` is rewritten.
Unexpected results then occur when the object is reused.
Also, if `mrb_heap_page` containing an `e` object is freed, it may cause `SIGSEGV` at that point.
- Protects the value of the stack on `callinfo` that just exits if GC occurs inside `mrb_env_unshare()`.
```ruby
def m
b = -> { b }
end
p m.call
# => print block object, not nil
```
This patch does not raise a `NoMemoryError` exception in `mrb_env_unshare()` and can detect that error.
Thus, the problem fixed in # 3087 is not resurrected.
Also, it may seem that this patch should suppress exceptions raised by `cipop()` during `mrb_protect_error()` and `mrb_vm_exec()` unwinds.
However, `mrb_callinfo::u.env` by `CINFO_DIRECT` is not seen to be set.
So in that case `mrb_env_unshare()` is assumed to be originally exception-free.
`mrb_class_find_path` resolves a `char*` pointer to a class name string
by calling `mrb_class_name`. It then allocates a new string with
capacity 40 to copy that `char*` into.
https://github.com/mruby/mruby/blob/e04184185ab43b94980550e850d8813a415fa438/src/variable.c#L1111-L1112
`mrb_class_name` resolves the class name via `class_name_str`, which
returns an `mrb_value` with type tag `MRB_TT_STRING` and backed by an
`RString*`. Then `mrb_class_name` extracts the `RSTRING_PTR`:
https://github.com/mruby/mruby/blob/e04184185ab43b94980550e850d8813a415fa438/src/class.c#L2133-L2134
That `RString*`-backed `mrb_value` ultimately comes from `mrb_class_path`
which resolves the string from the symbol table:
https://github.com/mruby/mruby/blob/e04184185ab43b94980550e850d8813a415fa438/src/class.c#L2111
The allocation of the target `str` after resolving the class name
`mrb_value` and extracting its pointer is fragile and assumes the
`RString*` is "static". If the `RString*` is not static, the
interleaving of extracting the `RSTRING_PTR` followed by a subsequent
allocation might result in the class name `mrb_value` being garbage
collected, which will leave the extracted pointer invalid.
Fix this bad interleaving by allocating the destination string first
before taking a raw pointer to an `RString*`.
`OP_SEND R4 :allocate 0` requires an an invisible `nil` block to `R5`.
If `R5` is not allocated, this can lead to unexpected results due to buffer overflow.
This problem is caused by #5565.
ref. commit 33792c2a02
- mrb_div_int() does integer division in Ruby way (mdiv)
returns mrb_int
- mrb_div_int_value() division with zero div and overflow checks.
returns mrb_value
Yukihiro "Matz" Matsumoto