Fuzzing is about passing random data to functions in an attempt to find vulnerabilities or crash-causing inputs.
Imagine the following scenario where we have to implement a custom function to test whether a string starts with a prefix:
Sometimes, it can be quite cumbersome trying to think by ourselves about all the different cases to be tested. Fuzzing is here to help us with that:
We wrote a custom fuzz test with a given seed corpus (basically, a guide for the fuzz engine). Then, we can run the test:
$ go test -fuzz FuzzHasPrefix
--- FAIL: FuzzHasPrefix (0.04s)
testing.go:1349: panic: runtime error: slice bounds out of range [:2] with length 1
The engine has found a vulnerability that led the function to panic. It has created a unique file in /testdata containing the inputs that lead to a failure:
The pacer is the algorithm used to determine when to start a new GC cycle. It has been redesigned to include not only heap data but also other sources such as the stack.
As a result, it may, in some cases, help the GC to be more predictable.
When using Go 1.18, let's keep an eye on the GC behavior of our application and make sure everything is still running smoothly. As always, tweaking GOGC remains the only available option to tune the GC.
In the strings and bytes packages, a new Cut function is now available.
Given a string (or a []byte) and a prefix, it returns:
- The text before the separator
- The text after the separator
- Whether the separator was found
4. Try lock
sync.Mutex and sync.RWMutex are given new methods for trying to acquire a lock and report whether it succeeded:
- sync.Mutex => TryLock()
- sync.RWMutex => TryLock() and TryRLock()
Compared to Lock() and RLock(), these functions are not blocking
5. Workspace mode
In an attempt to provide better support for monorepos, Go 1.18 introduces a workspace mode.
Projects that rely on the workspace mode will have a new go.work file referencing the modules of the project: