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
ruary 2018 at 16:15, Kane Kim >
> 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
You might also want to play with
> GODEBUG=gctrace=1.
>
> On 13 February 2018 at 18:55, Kane Kim >
> wrote:
>>
>> Both memory profile and heap debug show ~500MB memory is in use, idle
>> heap is pretty low, given all that and lack of cgo, where rest 10.5G cou
Main thing is that memory doesn't show up in heap profile, but still
occupies resident memory.
On Tuesday, February 13, 2018 at 12:18:36 PM UTC-8, Tamás Gulácsi wrote:
>
> TotalAlloc - TotalReleased = Inuse
> TotalAlloc is the total allocated bytes in the lifetime of the process.
> Every allocat
Process show up using 11GB of resident memory, it doesn't use cgo, built
with go 1.9.
Heap debug shows:
# runtime.MemStats
# Alloc = 535278016
# TotalAlloc = 113090364120
# Sys = 583994616
# Lookups = 221159
# Mallocs = 499797278
# Frees = 492733492
# HeapAlloc = 535278016
# HeapSys = 543293440
#
Nevermind, looks like it is undefined behavior here.
On Friday, September 2, 2016 at 1:43:49 AM UTC-7, kane@sendgrid.com
wrote:
>
> Hello,
>
> I was expecting it to segfault after deallocating CString. How does it
> work internally?
>
> func (m *Message) Test() string {
> s := C.CString("tes
