On Mon, 15 Jul 2019 10:55:19 +0530 Nitish Saboo <nitish.sabo...@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 -- 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/20190715100506.0326df8b%40zuzia. For more options, visit https://groups.google.com/d/optout.
