Hey Mariappan,
>From my experience, there are several possible options:
I believe you can use GOTRACEBACK=crash env variable (or its equivalent in
the runtime/debug package in the std) to get a coredump on the crash. See
this old post from JBD [1], that explored this.
If you clearly observe, t
You can certainly have memory leaks in Go - due to undesired references
retaining the object. What the op is asking for is a memory dump at OOM crash.
If the dump shows 1M object X and the author believes there should only be 1 -
you have a leak
> On Jan 12, 2023, at 4:01 AM, mariappan balr
Hi Brian,
A Go program can crash because of Out of Memory. Yes it can be because of
goroutine leak. Or it can have some reference to global variables, but it
should be freed? How to debug this?
When the leak is happening while using CGO, is there any tool to debug this?
Best Regards
Mariappan
On
I think you're not being clear on your problem you're trying to solve.
There are no "memory leaks" in Go in the traditional sense (omitting to
free an allocation) because of the garbage collector. Therefore, if memory
is not being freed in a pure Go program, it's because you are keeping a
refer
Hello Go experts,
Can someone please help with this?
Best Regards
Mariappan
On Tue, Jan 10, 2023 at 1:24 PM mariappan balraj
wrote:
> Hello Go experts,
>
> I could able to find the solution to debug memory leaks of GO process,
> when it is running by using PPROF. Is it possible to collect the
