aboutsummaryrefslogtreecommitdiff
path: root/src/runtime/mpallocbits.go
diff options
context:
space:
mode:
authorKatie Hockman <katie@golang.org>2021-11-03 14:44:16 -0400
committerKatie Hockman <katie@golang.org>2021-11-04 20:01:10 +0000
commit9b2dd1f7714b38f1bfe25676357b62c1bb4cad64 (patch)
tree6237584bcb313b149da11c6a0528f9de7d9b7bf5 /src/runtime/mpallocbits.go
parent961aab26bffece299f1528b44d260ea0a921ac56 (diff)
downloadgo-9b2dd1f7714b38f1bfe25676357b62c1bb4cad64.tar.xz
internal/fuzz: fix internal error handling
This doesn't handle every possible scenario, but improves the one we can control. For example, if the worker panics for some reason, we have no way of knowing whether the panic occurred in an expected way (while executing the fuzz target) or due to an internal error in the worker. So any panic will still be treated as a crash. However, if it fails due to some internal bug that we know how to catch, then the error should be reported to the user without a new crasher being written to testdata. This is very difficult to test. The reasons an internal error would occur is because something went very wrong, and we have a bug in our code (which is why they were previously panics). So simulating a problem like this in a test is not really feasible. Fixes #48804 Change-Id: I334618f84eb4a994a8d17419551a510b1fdef071 Reviewed-on: https://go-review.googlesource.com/c/go/+/361115 Trust: Katie Hockman <katie@golang.org> Run-TryBot: Katie Hockman <katie@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
Diffstat (limited to 'src/runtime/mpallocbits.go')
0 files changed, 0 insertions, 0 deletions