Have you figure the root cause? We experience the same issue On Thursday, February 15, 2018 at 7:21:12 AM UTC-8, Kane Kim wrote: > > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1267ea72-6f03-46d4-b465-d8092ec233cc%40googlegroups.com.
