I was surprised to see that overhead is so significant, is there any way to peek into that and see what is taking up space in race detector? I've tried --inuse_objects in a heap dump, but didn't see anything suspicious there.
On Thursday, February 15, 2018 at 7:16:42 AM UTC-8, Kane Kim wrote: > > I think I've got a clue. I've discovered that the process under question > was built with -race flag. Apparently race detector structures (tsan) are > not visible to runtime and are not reported. > > On Thursday, February 15, 2018 at 2:14:55 AM UTC-8, Peter Waller wrote: >> >> On 14 February 2018 at 16:15, Kane Kim <kane....@gmail.com> wrote: >> >>> If we don't use CGO all memory should be reported somewhere? >>> >> >> Well, assuming no part of your software calls mmap, or there isn't >> something else funny going on. >> >> Can you capture when this large region is mapped with strace? At what >> point in the process lifecycle does this happen? Perhaps you can use a >> debugger (dlv) to catch the culprit in the act. Perhaps you could come up >> with a mechanism to unmap the region and get a segfault and stacktrace when >> the culprit tries to use it. >> >> If you find out what's going on please share if you can, it sounds like >> an interesting issue. >> > -- 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.
