| Age | Commit message (Collapse) | Author |
|
|
|
The following improvements are made according to Ruby's behavior:
- Match location number to index.
- Remove duplicate most recent call output.
- Fix that first call is not output when array (unpacked) backtrace.
### Example
```ruby
def a; raise "error!" end
def b; a end
begin
b
rescue => e
e.backtrace if ARGV[0] == "unpack" # unpack backtrace
raise e
end
```
#### Before this patch:
```
$ bin/mruby example.rb unpack
trace (most recent call last):
[0] example.rb:2:in b
[1] example.rb:1:in a
example.rb:1: error! (RuntimeError)
```
#### After this patch:
```
$ bin/mruby example.rb unpack
trace (most recent call last):
[2] example.rb:4
[1] example.rb:2:in b
example.rb:1:in a: error! (RuntimeError)
```
|
|
`struct backtrace_location` is created only in `each_backtrace()`, and
the `filename` field will never be null (it will be `(unknown)` if null).
|
|
* mrb_sym2name -> mrb_sym_name
* mrb_sym2name_len -> mrb_sym_name_len
* mrb_sym2str -> mrb_sym_str
|
|
|
|
The binary sizes (gems are only `mruby-bin-mruby`) are reduced slightly in
my environment than before the introduction of new specifiers/modifiers
(5116789a) with this change.
------------+-------------------+-------------------+--------
BINARY | BEFORE (5116789a) | AFTER (This PR) | RATIO
------------+-------------------+-------------------+--------
mruby | 593416 bytes | 593208 bytes | -0.04%
libmruby.a | 769048 bytes | 767264 bytes | -0.23%
------------+-------------------+-------------------+--------
BTW, I accidentally changed `tasks/toolchains/visualcpp.rake` at #4613,
so I put it back.
|
|
|
|
The addresses for packed inline symbols reference `mrb->symbuf` that
could be overridden by the later call of `mrb_sym2name_len`. Since
file names in call stack information are kept as symbols, keeping the
address in the C structures could cause problems like #4342.
This changes small incompatible changes in function prototypes:
* `mrb_parser_get_filename`: return value changed to `mrb_sym`.
* `mrb_debug_get_filename`: add `mrb_state*` as a first argument.
* `mrb_debug_get_line`: ditto.
I believe above functions are almost internal, and no third-party
mrbgem use them.
|
|
|
|
- Move calling `mrb_debug_get_filename()` to after `lineno` check.
- Remove unneeded array check in `print_backtrace()`.
- Add a few `const` qualifier.
|
|
shuujii/reorder-members-in-struct-backtrace_location
Reorder members in `struct backtrace_location`
|
|
`sizeof(struct backtrace_location)` is 24 bytes -> 16 bytes in LP64
data model etc.
|
|
|
|
|
|
|
|
|
|
|
|
'int', possible loss of data
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Instead of preserving a backtrace in `mrb_state`, `mrb_exc_set`
keeps packed backtrace in an exception object. `#backtrace` unpacks
it to an array of strings.
|
|
|
|
|
|
|
|
ref #3492 #3515 #3517
|
|
|
|
|
|
|
|
|
|
|
|
According to the valgrind log attached to #3438, proc->body.irep
may be NULL in some cases.
|
|
|
|
|
|
|
|
This reverts commit bf7719fe8da1b704c2cb72dd629dc75135fd1ad5, reversing
changes made to 4f4fa0ade0fd80a3a6fa64bebcb5f71b0d4a8648.
We should get backtrace while irep is alive.
|
|
|
|
|
|
It looks like the logic to reallocate the backtrace was flawed,
based on the wrong variable (loc_raw->i, which, as I have verified,
decreases from 16 to 0 instead of increasing)
I am not sure if this is the correct fix
|
|
The code to iterate over backtrace locations was changed in #3065, but
unfortunately output_backtrace was not correctly updated to forward the
callback.
|
|
There is a problem when MRB_INT64 is enabled.
|
|
GitHub: fix #2902, #2917
The current implementation traverses stack to retrieve backtrace. But
stack will be changed when some operations are occurred. It means that
backtrace may be broken after some operations.
This change (1) saves the minimum information to retrieve backtrace when
exception is raised and (2) restores backtrace from the minimum
information when backtrace is needed. It reduces overhead for creating
backtrace Ruby objects.
The space for the minimum information is reused by multiple
exceptions. So memory allocation isn't occurred for each exception.
|