Based on https://opensource.apple.com/source/clang/clang-700.1.81/src/projects/compiler-rt/lib/tsan/rtl/tsan_dense_alloc.h.auto.html it's an internal thing to thread sanitizer. It seems to be running out of memory when trying to instrument the code. It uses a cache of fixed size of kL1Size entries and when it runs out of the cache, it dies.
Per https://sourcegraph.com/github.com/golang/go@master/-/blob/src/runtime/race/README Go is based on https://sourcegraph.com/github.com/llvm-mirror/compiler-rt/-/blob/lib/tsan/rtl/tsan_dense_alloc.h I'm too lazy to figure out what kL1Size, how it's calculated and how bit it is. One theory: it's based on amount of memory. If your mac has more memory than your Linux, that would explain it. A way to verify: run your tests on a Linux machine with more memory. On Wednesday, April 11, 2018 at 10:47:00 PM UTC-7, cou...@uber.com wrote: > > Can someone please provide some guidance in finding the root-cause of this > little chestnut, please? > > I've a codebase within which all tests pass when run locally on Mac OS X, > but when verified on Linux, we see: > > ThreadSanitizer: DenseSlabAllocator overflow. Dying. > > > Both cases see the same code, and I use (in effect) go test -race, and no > race is reported. I can provide no further context, because none is > forthcoming! > > Ideas? > > Kevin. > > -- > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
