- mrb_clear_error(): clear error status of mrb_state
- mrb_check_error(): check if error caused in the previous API
Note that `mrb_check_error` clears error status, so if you call
`mrb_check_error` more than once, latter calls will return FALSE.
Move the detachment of the "env" object, now done by `mrb_top_run()` by #5904, to `mrb_vm_run()`.
This is because `mrb_vm_run()` can remove `mrb_env_unshare()` which is called from `bin/mirb`.
Also, even if the mruby VM is already running, either of the following conditions should be used to detach "env":
- If the `stack_keep` variable is 0.
- If the stack length of "env" is longer than `irep->nlocals`.
The reason for the change is that the stack beyond `irep->nlocals` is used inside the called method, and previously it was possible to reference and manipulate the state inside the method via "env".
env stack | |
main stack | top | m1 | m2 |
|<--------------->|
operable via env stack (including self)
If the problematic block is called from the `m2` method above, it is possible to replace `self` in `m1` and `m2` as well as the internal variables.
This change may cause compatibility problems, but I believe it is better to make `MRB_API`, `mrb_vm_run()` safe.
If a dangerous procedure is absolutely necessary, `mrb_vm_exec()` can still be called as before.
This is to keep the local variables of the previously created blocks consistent in case the `mrbc_context` passed to `mrb_load_exec()` is `NULL` or different.
Switching between `mrbc_context` pointers that are non `NULL` can be done safely by calling `mrbc_cleanup_local_variables()`.
Before this patch, the result of the following code is not as expected.
```console
% cat loadstr.c
#include <mruby.h>
#include <mruby/compile.h>
int
main(int argc, char *argv[])
{
mrb_state *mrb = mrb_open();
mrb_load_string(
mrb,
"(a, b, c, d, e, f, g) = [1, 2, 3, 4, 5, 6, 7] \n"
"$lambda = -> { p [a, b, c, d, e, f, g] }");
mrb_load_string(mrb, "$lambda.call");
mrb_close(mrb);
return 0;
}
% $(bin/mruby-config --cc --cflags --ldflags) loadstr.c $(bin/mruby-config --libs) && ./a.out
[main, nil, nil, main, nil, nil, main]
```
Also, since `mrb_env_unshare()` was not used before, the internal stack of simply detached `env` objects could show invalid addresses by `stack_extend()`.
ref. https://github.com/kou/mruby-pp/commit/ef5951aca870183d8767cb61f6414240988ca35e
It fixes a bug that instance_eval for immediate objects defines methods
in Object, instead of raising error.
```ruby
1.instance_eval do
def foo
p :foo
end
end
```
If pre-allocate object is modified (e.g. singleton class added) in
certain timing, some objects may be swept even if it's alive.
The problem was reported by Denis Kasak via private communication.
- In case of `NoMemoryError` exceptions, the error message is now printed directly.
- Replaced `mrb_p()` used by #4250 with `mrb_print_error()`.
ref. squashed commit f1523d2404
ref. subcommit da7d7f881b
ref. subcommit d9c7b6be6e
- Now that it is called after `cipush()`, pass in a new ci pointer.
- Removed the parameters `clsp`, `a`, and `c`, which are no longer needed since they now operate directly on `ci`.
- Change the parameter `super`, which is treated as a boolean, to `mrb_bool`.
- Leave the parameter `mid`.
Because if `prepare_missing()` raises the exception `NoMethodError`, `ci->mid` must not be set when suppressing extra information on the stack trace.
However, set `ci->mid` here, since the preparation is completed at the end of the function.
Raising a `SystemStackError` exception in an out-of-memory situation will generate backtrace information.
This can eventually lead to a `NoMemoryError` exception, and this process flow is completely undesirable.
In effect, this change means that it will include a revert of commit 0dbb9e6e41.
Yukihiro "Matz" Matsumoto