Tools or debug options for debugging 'Error in `bin/main': double free or corruption (fasttop)' in cgo

[Nitish Saboo]

Hi,

Can some please share the details of tools or Debug options to debug the following error in cgo:

Error in `bin/main': double free or corruption (fasttop)

Thanks,

Ntish

[Jan Mercl]

On Sun, Jul 14, 2019 at 5:03 PM Nitish Saboo <nitish....@gmail.com> wrote:

> Can some please share the details of tools or Debug options to debug the following error in cgo:

Log allocations, log frees. From the log you'll know at which line of
code the error was triggered.

'Log' can be as simple as printing to stdout/stderr.

After you'll detect the error triggering location, log a stack trace
at that point. The pre-mortem (last logged) stack trace should be
helpful, hopefully.

[Nitish Saboo]

Hi Jan,

I am a beginner with GO and cgo, and have never dealt with C corruption issues.

Do you have commands or a blog post or something else where I can read about it and follow the steps.

Being a beginner, I have to read and understand the stuff before applying it.

Thanks,

Nitish

[Kurtis Rader]

As I wrote in a reply on a different thread that has the same purpose as this one...

When debugging memory management problems in C/C++ code there are many tools to assist in understanding the problem.

The first, and usually easiest to use is to enable your platform "debug" version of the malloc subsystem. Type "man malloc" to find out which env vars, if any, your platform provides to enable these features.

Second is "valgrind".

Third, and by far the most useful (i.e., helpful) tool, is ASAN: the address sanitizer. I haven't needed to use this tool with cgo code so I can't explain how to use it with cgo. My google search results yielded some results (e.g., https://grokbase.com/p/gg/golang-dev/133rert6kv/using-addresssanitizer-with-go) that imply it is at least theoretically possible to use ASAN with go.

At the end of the day you are asking us to debug your code for free. Most of use are happy to help if the problem is described in a way that allows us to reproduce the problem. Or, is so simple (once you know the answer) that composing an answer doesn't take much more time than reading the original question. Your situation does not match either of those possibilities.

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/70001fbc-9302-4e76-a270-d18b95664423%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Kurtis Rader

Caretaker of the exceptional canines Junior and Hank

[Nitish Saboo]

Thanks Kurtis.Will try these options.

Yes, now I remember you had given the same options on a different thread.

It just skipped my mind because of the mail conversation.

Thanks,

Nitish

[Wojciech S. Czarnecki]

On Mon, 15 Jul 2019 10:55:19 +0530
Nitish Saboo <nitish....@gmail.com> wrote:

> Hi Jan,
>
> I am a beginner with GO and cgo, and have never dealt with C corruption
> issues.
> Do you have commands or a blog post or something else where I can read
> about it and

Internet is full of C and C debugging tutorials. Problem is, that those assume
readers do know C and are able to imagine intrinsic of how does its product
work on the target hardware. This is something you cannot be simply "told",
this is something you will gain with the experience writing C code from the
scratch. Simple linear first, then -- after a year or two -- concurrent one. Then
you will be debugging knowing and comparing "what you thought how should
it work" with "how does it behave/work" under debugger.

> follow the steps.

Unlike with C&P "writing" you can not simply "follow the steps" in debugging,
you need to be able to **both** imagine and reason about the code. Here,
iirc, you do not even have access to the half of the code.

> Being a beginner, I have to read and understand the stuff before applying it.

If you are a beginner with both Go and C you should not aim at Cgo solution
at all. You are kindly asking for help, and on this list are people willing to help
but there is too thick wall in the communication. They **can not** help you
because you **do not know** what you should tell them so they might help you.
Hence you shrugged off their repeating requests for the full code example.

Try to understand Ian's metaphor.

On the list full of watchmaker gurus'
you are asking them
to give you instructions
how to fix
broken mechanical clock
showing them the photo of the clock
with the hands of it standing at one-fifteen.


Other one.

On the list of neurosurgeons
you are asking them to give you instructions
how to do a surgery
on the brain of unknown to them patient
that has "something like a tremors" under his left eye.

You were given a most straight instruction written in most simple words
I could imagine (kudos Jan Mercl)

> > Log allocations, log frees. From the log you'll know at which line of
> > code the error was triggered.
> >
> > 'Log' can be as simple as printing to stdout/stderr.
> >
> > After you'll detect the error triggering location, log a stack trace
> > at that point. The pre-mortem (last logged) stack trace should be
> > helpful, hopefully.

Bot nothing yet hints you followed this.


> Thanks,
> Nitish

Your welcome,

PS. rethink whether you ere experienced enough to bear with whatever work
you said you will do. Note that this bug is only the first one of likely some
dozens ahead (iirc this is a concurrent C you are trying to link with and it
certainly was not written with Go interop on mind).

I personally would not take this without access to full C source.
Thats said after 30+ years at keyboard doing mostly C for 20 and
Go for 5.

--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE

[jake...@gmail.com]

I am a beginner with GO and cgo, and have never dealt with C corruption issues.

First, I would try really hard to find a pure go solution to your problem, or next best, a solution that uses a 3rd party go package that handles the cgo for you. I understand that this may not be possible.

Using cgo is diving right into what is the (arguably) most difficult, confusing, error prone, advanced part of the language. Go is a really great language, and one of its features is its simplicity. I find that beginners in go write better, more reliable, and more readable code with less of a learning curve than most languages. However, this does not apply to using cgo. I'm suspect that some people come to go and get put off because they start with cgo, or one of the other "danger areas".

I always suggest that those new to go focus on writing idiomatic code in pure go. Completely avoid cgo, the "unsafe" package, and reflection.

Which ever way you go, I wish you the best of luck.