sweep increased allocation count with v1.3.4 #214
Description
After updating our project to the latest version of bbolt which includes #201, we've started running into this runtime error in our tests:
runtime: nelems=21 nalloc=3 previous allocCount=2 nfreed=65535
fatal error: sweep increased allocation count
runtime stack:
runtime.throw(0xc2ecf1, 0x20)
/home/travis/.gimme/versions/go1.13.linux.amd64/src/runtime/panic.go:774 +0x72
runtime.(*mspan).sweep(0x7f399ffced10, 0x7f399ffced00, 0x455700)
/home/travis/.gimme/versions/go1.13.linux.amd64/src/runtime/mgcsweep.go:328 +0x8e1
runtime.(*mcentral).uncacheSpan(0x11e9d60, 0x7f399ffced10)
/home/travis/.gimme/versions/go1.13.linux.amd64/src/runtime/mcentral.go:197 +0x79
runtime.(*mcache).releaseAll(0x7f39a00cd008)
/home/travis/.gimme/versions/go1.13.linux.amd64/src/runtime/mcache.go:158 +0x6b
runtime.(*mcache).prepareForSweep(0x7f39a00cd008)
/home/travis/.gimme/versions/go1.13.linux.amd64/src/runtime/mcache.go:185 +0x46
runtime.acquirep(0xc000042000)
/home/travis/.gimme/versions/go1.13.linux.amd64/src/runtime/proc.go:4114 +0x3d
runtime.stopm()
/home/travis/.gimme/versions/go1.13.linux.amd64/src/runtime/proc.go:1930 +0xe8
runtime.gcstopm()
/home/travis/.gimme/versions/go1.13.linux.amd64/src/runtime/proc.go:2125 +0xb4
runtime.schedule()
/home/travis/.gimme/versions/go1.13.linux.amd64/src/runtime/proc.go:2481 +0x473
runtime.exitsyscall0(0xc000001680)
/home/travis/.gimme/versions/go1.13.linux.amd64/src/runtime/proc.go:3141 +0x116
runtime.mcall(0x800000)
/home/travis/.gimme/versions/go1.13.linux.amd64/src/runtime/asm_amd64.s:318 +0x5b
So far, it only seems to happen about every 1 in 5 test runs. At first we were running the tests with Go 1.14, then tried to go back to version 1.13, but the issue would still pop up. Only after downgrading to bbolt v1.3.3 does the issue seem to disappear. Given that the issue seems to persist using the last two major versions of Go, it may be the case that #201 uncovered another underlying issue, or the changes in the PR are actually triggering this new error.
We're working on creating a reproducible program to trigger this warning.
The full trace of this error in our tests can be found here: https://paste.ubuntu.com/p/XNgrZ49dbw/