Secure array slicing when expanding macro for stack trace #11109
Conversation
src/compiler/crystal/exception.cr
Outdated
| @@ -254,7 +254,8 @@ module Crystal | |||
| io << Crystal.with_line_numbers(source, line_number, @color) | |||
| else | |||
| from_index = [0, line_number - MACRO_LINES_TO_SHOW].max | |||
| source_slice = source.lines[from_index...line_number] | |||
| to_index = [source.lines.size, line_number].max | |||
There was a problem hiding this comment.
| to_index = [source.lines.size, line_number].max | |
| to_index = {source.lines.size, line_number}.max |
There was a problem hiding this comment.
Why ? Has it performance benefits ?
In any case, if I do this change, it would be good to modify the line above too, isn't it ?
There was a problem hiding this comment.
Why ? Has it performance benefits ?
Yes, Tuple is stack-allocated, unlike the heap-allocated Array.
There was a problem hiding this comment.
Another alternative is Math.max which behaves slightly differently for floating-point values (not relevant here).
There was a problem hiding this comment.
I'd suggest to clamp both values to 0..source.lines.size to prevent any kind of issue with weird values.
There was a problem hiding this comment.
Shouldn't it be a min? to_index is the upper bound of the slice range.
There was a problem hiding this comment.
@lbguilherme Oopsie.
I'm updating with @straight-shoota suggestion.
There was a problem hiding this comment.
Just updated the code. I also fixed from_index value definition so it keeps consistent with to_index.
HertzDevil
added
kind:bug
pyrsmk
force-pushed
the
fix/exception-expanded-macro
branch
from
83f5096
to
2bd10da
Compare
|
Thanks ;) I just rebased my fixups so this PR is ready to be merged. |
|
Thanks. But please merge master instead of a rebase next time. This preserves review history. |
|
@straight-shoota Mmmh ok. So should it be better to let the rebase to admins next time ? Because keeping fixup commits on the history is not really clean either. |
|
Yeah, we don't want to keep the fixup commits. We're squashing all commits when merging to master. |
As #11008 I fell upon a bug into the stack trace generation. This time, I haven't the stack trace that was occuring with this error, but it wasn't very talkative about the origin of the problem.
Anyway, it is possible the two issues are related. The previous PR was fixing an issue with colum numbers, and this one is dealing with line numbers. This time, there's a crash because the caller is passing an incorrect line number for a macro that is less tinier than expected.
I tried to understand why but sadly I couldn't find a way to know what the original caller of that stack trace printing was.
Since it's the second time I encounter this kind of bug, maybe it would be good to verify the globality of
src/compiler/crystal/exception.crandsrc/compiler/crystal/semantic/exception.crto avoid these errors ?