iv-m (Ivan Melnikov)
- Login: iv-m
- Email: iv@altlinux.org
- Registered on: 09/26/2019
- Last sign in: 09/26/2019
Issues
| open | closed | Total | |
|---|---|---|---|
| Assigned issues | 0 | 0 | 0 |
| Reported issues | 0 | 1 | 1 |
Activity
09/27/2019
-
10:05 AM Ruby Bug #16184: Entry persists in catch table even though its labels were removed, which may cause [BUG]
- > And having `position` field of labels initialized (as in my attached patch) makes crash totally impossible.
I think having this field properly initialized is a good idea anyway, so I created a pull request: https://github.com/ruby/r... -
- > So whether Ruby crashes or not depends on the contents of the memory where labels are allocated by compile_rescue function.
And having `position` field of labels initialized (as in my attached patch) makes crash totally impossible. -
- > Could you post a reproducer that reliably crashes Ruby?
I guess this is not really possible to crash Ruby reliably via this issue. Here is a reproducer that crashes on my MIPS32 LE machine one out of 20 times or so:
```ruby
puts...
09/26/2019
-
- Of course, while having some strange cache table entries would be pretty ok if they were not used (like it usually happens on x86_64). To make sure they are never used compiler should initialize the `position` field of the labels. I'm at...
-
- When `remove_unreachable_chunk` removes the code from within a rescue block, the catch table entry corresponding the block is not removed. Here is a simple reproducer (tested with ruby 2.5.5):
``` ruby
puts "BEGIN"
if false
b...