Hi,
Apologies to the experts who have been kind enough to help me on this issue.
I will try to come up with a small, complete reproducible test case for
this issue.
Thanks,
Nitish
On Sun, Jul 14, 2019 at 6:36 PM Nitish Saboo <nitish.sabo...@gmail.com>
wrote:
> HI Ian,
>
> func (obj SyslogParser) LoadPatternDB(opts Syslog, workerId int) {
> log.Info("Loading pattern db with path:", opts.Patterndb)
> > patterndbpath := C.CString(opts.Patterndb) . <<<<<<<<<<<<<<< . STEP 1
> > defer C.free(unsafe.Pointer(patterndbpath)) . <<<<<<<<<<<<<<<< STEP 2
> > InitStruct := (*C.Accumulatedparams)(C.calloc(1,
> C.sizeof_struct_Accumulatedparams))
> > InitStruct.callback = (C.key_value_cb)(C.callback)
> > InitStruct.data = C.int(workerId)
> > C.load_pattern_db(patterndbpath,
> (*C.Accumulatedparams)(unsafe.Pointer(InitStruct)), C.int(workerId))
> > }
> >
>
> In my code there is one calloc call producing a pointer but I am not
> freeing up calloc pointer.I am freeing up 'patterndbpath' pointer.
>
> Thanks,
> Nitish
>
> On Sat, Jul 13, 2019 at 8:34 PM Ian Lance Taylor <i...@golang.org> wrote:
>
>> On Sat, Jul 13, 2019, 1:20 AM Nitish Saboo <nitish.sabo...@gmail.com>
>> wrote:
>>
>>> Hi Ian,
>>>
>>> Apologies for not being very descriptive with the issue.I will try to be
>>> more clear from next time.
>>> Can you please clarify the following that you had mentioned in the
>>> previous conversation of this email:
>>>
>>> > 3)Is it possible that one Go routine has already freed up the address
>>> that the other Go routine is trying to free and that is causing this
>>> 'fatal error: bin/main': double free or corruption (fasttop)'
>>>
>>> Yes, that is possible. It won't happen with the code I see above but
>>> I have no idea what the rest of your code is doing.
>>>
>>> How can it not happen with this particular code mentioned ?I did not
>>> understand this point.
>>> Can you please clarify this point ?
>>>
>>
>>
>> In the code you showed us, there is one calloc call producing a pointer
>> and one free call releasing that pointer. So in that code there is no way
>> for one goroutine to free code allocated by another goroutine. I'm not
>> sure how else to say it. Perhaps you could clarify the code path you are
>> concerned about.
>>
>> Iam
>>
>>
>> On Fri, Jul 12, 2019 at 11:42 PM Ian Lance Taylor <i...@golang.org>
>>> wrote:
>>>
>>>> On Fri, Jul 12, 2019 at 10:53 AM Nitish Saboo <nitish.sabo...@gmail.com>
>>>> wrote:
>>>> >
>>>> > Thanks for pointing it out.I am a beginner with Go and CGO and have
>>>> never worked on corruption issues with C.
>>>> > I am familiar with python and Java.So just seeking help from the
>>>> experts to find the pain points that should be looked into.
>>>> > Hence, asking questions to Ian as in where all I should look for the
>>>> corruption issues.
>>>>
>>>> From my perspective, it's kind of like you have a broken clock, and
>>>> you are showing us a photo of the clock face, and asking how to fix
>>>> the clock. We don't know. The clock face looks OK. The problem is
>>>> most likely inside the clock, but we can't see that. Only you can see
>>>> that.
>>>>
>>>> Ian
>>>>
>>>
--
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/CALjMrq7rdTDWcR9%2B2ONvxnr992cOh54gh1Nmf0mxfGCgT4xkEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
