OP_LOADI stores an 8 bit integer to a register, so we renamed the
instruction name to describe the behavior more precisely, like
OP_LOADI16 and OP_LOADI32.
In `src/hash.c`, there are code blocks that are passed as macro arguments.
These code blocks are interpreted as part of the macro function, so breakpoints cannot be set in the debugger.
Also, the gcov command will aggregate them to the caller, and the code in the block will not be counted.
This patch will prevent them from being interpreted as part of a macro, and thus the aforementioned problems will no longer occur.
If a tombstone (a deleted entry slot) is found in searching the entry,
it should be skipped, but we had added the new entry even if the entry
to be replaced might be found in the further search. #6414 and #6421
tried to rehash the table to remove tombstone. But rehashing consumes
memory. So for the time being, we just skip tombstones in the search.
Maybe we will add some heuristics to rehash when the table has too many
tombstones. close#6414
Some functions called by `mrb_vm_exec()` involve re-entry into the mruby VM.
If the `ci` variable is not updated after re-entry, use-after-free is caused.
This patch makes the following after-call fixes.
| called | might call methods
| ----------------------- | ----------------
| `mrb_ary_splat()` | `#to_a`
| `hash_new_from_regs()` | `#eql?` `#hash`
| `mrb_hash_delete_key()` | `#eql?` `#hash`
| `mrb_hash_get()` | `#eql?` `#hash` `#default`
| `mrb_hash_key_p()` | `#eql?` `#hash`
| `mrb_hash_merge()` | `#eql?` `#hash`
| `mrb_hash_set()` | `#eql?` `#hash`
| `mrb_range_new()` | `#<=>`
CRuby 3.4 puts spaces around `=>` since for example `{:a!=>2}` can be
confusing where to separate tokens. mruby should follow the behavior.
Many tests in `test/t` directory assumed no spaces around `=>`, so we
needed to fix them too.
When multiple identical proc objects are placed on the call stack, it is not possible to distinguish where to `return`.
Therefore, use env object comparisons to do this.
fixed#6411
To avoid confusion with pools in irep, we renamed region-based memory
manager from pool to mempool.
- rename pool.c to mempool.c
- separate mempool.h
- rename all mrb_pool to mrb_mempool
So if someone is using pool.c functions (I suppose no one does though),
they need to rename all `mrb_pool` to `mrb_mempool` and include
`mruby/mempool.h` header at the top.
mrb_pool_value is a structure that represents a value in the irep
literal pool and is unrelated to mrb_pool, which performs region-based
memory management. It has been renamed mrb_irep_pool to avoid confusion.
C to Ruby calls using `mrb_exec_irep()` were not forwarding arguments.
There was also a problem in setting the target class and method ID, which is also fixed.
This issue was discovered during the work to fix#6389.
However, on C, there is no easy way to pass keyword arguments.
Therefore, when called `Kernel#instance_exec` on C, keyword arguments are converted to positional arguments.
This is a limitation of current mruby.
fixed#6389
Calling `mrb_gc_unregistor()` from `mrb_data_type::dfree` caused a use-after-free deep inside `mrb_close()`.
The impetus to investigate was <https://github.com/mruby/mruby/pull/6342#pullrequestreview-2292747530>.
Currently, when `mrb_close()` is called, all objects are destroyed first.
The process is done heap page by heap page, and when all objects belonging to a heap page are destroyed, the heap page is released.
If the next heap page contains `RData` objects, the `mrb_gc_unregistor()` function may be called from the `mrb_data_type::dfree` function.
At this time, the `mrb_gc_unregistor()` function gets an array object from a Ruby global variable.
If the array object belongs to a freed heap page, use-after-free is established by referencing this array object.
About the fixes.
First of all, there is the fact that the `mrb_gv_get()` function returns `nil` if `mrb->globals` is `NULL`.
Therefore, before destroying all objects, free `mrb->globals` and set `mrb->globals` to `NULL` at the same time.
Now the `mrb_gv_get()` function will return `nil` to the calling `mrb_gc_unregistor()` function and `mrb_gc_unregistor()` will do nothing more.
ref. https://github.com/mruby/mruby/issues/4618
Once the class is set, objects can be referenced and manipulated from the Ruby side by using `ObjectSpace.each_object`.
Also, currently `mrb_gc_unregister()` assumes that the element is a non-immediate object.
However, `mrb_gc_unregister()` does not read or write to the address, so there was no problem.
As #6359 pointed out, calling const_missing hook from E_XXX_ERROR (that
calls mrb_exc_get_id()) can be an attack vector. Since E_XXX_ERROR is
supposed to be a defined error class, we think that the situation where
it is undefined and the const_missing hook is called should be detected
as an error; fix#6359
The callinfo refers blk since #5786 but not marked at the time. Later we
added reclamation check by #5791 but its repeated heap scans decrease
the performance drastically in some cases. So the original @dearblue's
solution should be taken
Probably we need to always keep the original block at the bottom of
arguments. And the explicit block argument should be a normal local
variable. We will investigate it later.
The new version gives more accurate values for decimal number
representation that are not divisible in binary representations, for
example `0.3`.
The function uses `long double` for precision. Please report if `long
double` causes problems on any platform (especially microcontrollers).
Ref #6182
The `mrb_get_argv()` function and the `*` specifier of `mrb_get_args()` get the address of the argument.
At this time, if it is passed in the form of a splat argument, it will be an address to an element of an array object.
After getting the pointer to the array object, the caller may call `mrb_vm_exec()` directly or indirectly.
At this time, a splat argument with the class set can be retrieved as an array object by searching with `ObjectSpace.each_object`.
If changes are made as array objects, addresses on the heap as arrays may become invalid, or objects in the array may be recycled by the GC.
When the caller references the changed address in a subsequent operation, use-after-free is established.
This patch assigns `NULL` as the class of the array object so that it cannot be detected by `ObjectSpace.each_object` from the Ruby side.
Hoshiumi Arata