Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

division by zero panics cannot be recovered #1148

Closed
thehowl opened this issue Sep 18, 2023 · 2 comments
Closed

division by zero panics cannot be recovered #1148

thehowl opened this issue Sep 18, 2023 · 2 comments
Assignees
Labels
🐞 bug Something isn't working 📦 🤖 gnovm Issues or PRs gnovm related

Comments

@thehowl
Copy link
Member

thehowl commented Sep 18, 2023

running the following program:

package main

func main() {
        defer func() {
                println("RECOVER", recover())
        }()
        p := 0
        println(11 / p)
}

it panics with panic running expression main(): runtime error: integer divide by zero. This is to be expected, however seeing as we have a deferred function with recover, this should ideally be catchable by said function.

@petar-dambovaliev
Copy link
Contributor

With further investigation, it seems like this is a more general problem where only explicit panics are handled when the user code has a function call to panic.
The implicit panics are not handled.

slice := []int{1, 2, 3}
println(slice[5])

And

make([]int, -1)

petar-dambovaliev added a commit that referenced this issue Nov 22, 2024
Currently only explicit panic invocations are recovered in the user
code.
This PR covers the implicit panics that happen because of invalid
operations.
Associated [issue](#1148)

This maintains the distinction between VM panics and user panics.

Here is a list of possible runtime panics that we will cover.

- [x] Out-of-Bounds Slice or Array Access
- [x] Invalid Slice Indexing
- [x] Division by Zero and MOD zero
- [x] Type Assertion Failure
- [x] Invalid Memory Allocation (bad call to make())
- [x] Out-of-Bounds String Indexing
- [x] nil pointer dereference
- [x] Write to a nil map

Also, fixed a small bug with the builtint function `make`.
It wasn't panicking when cap > len
@Kouteki
Copy link
Contributor

Kouteki commented Nov 25, 2024

Solved by #3067

@Kouteki Kouteki closed this as completed Nov 25, 2024
@github-project-automation github-project-automation bot moved this from In Progress to Done in 🧙‍♂️gno.land core team Nov 25, 2024
@Kouteki Kouteki removed the in focus Core team is prioritizing this work label Nov 29, 2024
r3v4s pushed a commit to gnoswap-labs/gno that referenced this issue Dec 10, 2024
Currently only explicit panic invocations are recovered in the user
code.
This PR covers the implicit panics that happen because of invalid
operations.
Associated [issue](gnolang#1148)

This maintains the distinction between VM panics and user panics.

Here is a list of possible runtime panics that we will cover.

- [x] Out-of-Bounds Slice or Array Access
- [x] Invalid Slice Indexing
- [x] Division by Zero and MOD zero
- [x] Type Assertion Failure
- [x] Invalid Memory Allocation (bad call to make())
- [x] Out-of-Bounds String Indexing
- [x] nil pointer dereference
- [x] Write to a nil map

Also, fixed a small bug with the builtint function `make`.
It wasn't panicking when cap > len
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐞 bug Something isn't working 📦 🤖 gnovm Issues or PRs gnovm related
Projects
Status: Core
Development

No branches or pull requests

5 participants