Given a core dump of a Go service, is there any command on Delve that can inspect memory region? We are trying to find out what is occupying the heap.
Asked
Active
Viewed 1,040 times
4
-
why dont you do a memory profile? it is buildin in go – Pizza lord - on strike May 28 '19 at 15:01
-
1@Pizzalord Unfortunately we didn't expose pprof endpoint on production, so we only can depend on core dump for post-mortem analysis.. – Dian Bakti May 28 '19 at 15:16
1 Answers
1
Last time I came across the similar problem, I found this little package https://github.com/golang/debug. It allows to get a histogram of a heap & inspect how many object of a specific type you had right before the crash.
Unfortunately, it doesn't work out of the box and you have to apply a couple of fixes which you find on the Pull Requests page
Aleksandr Karasev
- 437
- 1
- 4
- 12
-
Very cool tool! but do you know why I get a bunch of "unk" objects when running "histogram"? for example: "unk1152", "unk704", "unk288", etc. Please advise if there is some way to interpret these objects. update: seems like these refer to "unknown", wondering if there is any way to increase the "readability" of these objects – Dian Bakti Jun 30 '20 at 10:31
-
Yes, "unk1152" means unknown type & 1152 means size of the instance. Unfortunately, I don't know how one can improve "type detection" in this particular case( – Aleksandr Karasev Jun 30 '20 at 11:17
-
1I figured out some workaround for this, I use `objects` command to list all live objects, get the address of one of the "unk" type, and then do `reachable `. It is able to print some file location. Might need to run this several times on different addresses to confirm the finding, time consuming, but it works ) – Dian Bakti Jun 30 '20 at 12:08
-
nice, would be keep this mind the next time. Thanks for sharing! – Aleksandr Karasev Jun 30 '20 at 12:28