Hi Tamas,
Using RPC will not scale and it needs lot of effort. So our only choice is
CGO.
Best Regards
Mariappan
On Monday, January 9, 2023 at 5:04:19 PM UTC+5:30 Tamás Gulácsi wrote:
> I'd create a separate C program, that can be communicated with RPC style -
> (https://github.com/protobuf-c/protobuf-c-rpc may solve it easily),
> and have the Go program start it like
> https://github.com/hashicorp/go-plugin .
>
> That way the stack traces and core dumps are separate, each program is
> easier to debug,
> the C error does not take down the Go program, which can restart the
> plugin ...
>
> mariappa...@gmail.com a következőt írta (2023. január 9., hétfő, 10:20:28
> UTC+1):
>
>> Hi Ian,
>>
>> Thanks. I will try this. When a process is crashed because of a
>> SEGMENTATION fault, it can be debugged by identifying the stack trace from
>> the core dump. Is there any other technique to debug this issue? Can you
>> please help if any other technique is there?
>>
>> Best Regards
>> Mariappan
>>
>> On Mon, Jan 9, 2023 at 12:07 PM Ian Lance Taylor
>> wrote:
>>
>>> On Sun, Jan 8, 2023, 9:33 PM mariappan balraj
>>> wrote:
>>>
Hi Ian,
Thanks for all your replies. It really shows that you have tried to
give your best all the time. I need some direction to get a permanent
solution for this. Is it possible to get help from the core google GO
team?
How to escalate this issue and get the fix? Please give me directions. So
that I can try best from my side.
>>>
>>> I'm on the core Google Go team myself.
>>>
>>> The next step is to file a bug report at https://go.dev/issue, with
>>> exact details for how to reproduce the problem. But I don't want to
>>> mislead you: it's unlikely that anybody on the core Go team is going to fix
>>> this. That said, Go is an open source project, and filing a bug report is
>>> the right step to encourage someone to fix the problem.
>>>
>>> It's also worth taking a step back and describing the real problem.
>>> Using gdb to get a stack trace from a core dump is a technique, it's not a
>>> solution. Perhaps there are other techniques.
>>>
>>> Ian
>>>
>>>
>>>
On Sat, Jan 7, 2023 at 10:29 PM Ian Lance Taylor
wrote:
> On Fri, Jan 6, 2023 at 9:01 PM mariappan balraj
> wrote:
> >
> > Thanks for your continuous support. GOLANG supports CGO to invoke C
> functions. When it is supported, the important thing is, it should
> provide
> better debugging support when there is any issue. In customer sites, it
> is
> not possible to run applications with GDB. Customers only provide core
> dump
> and logs. With the provided information, we should be able to debug the
> issue. It may not be possible to reproduce all the issues in the
> development environment to debug the issue.
> >
> > When we run the application with GDB, we are getting stack trace.
> Then the same thing should be possible with core dump also.
> >
> > I have tried with CGO symbolizer from
> https://github.com/ianlancetaylor/cgosymbolizer. I am getting the
> following output. This is useful. But I want to dump the C variables
> (local
> and global) to debug the issue. This is very critical when we want to
> debug
> some issues.
> >
> > What should I do now? How to proceed further? If possible, please
> provide your help with this.
>
> I'm sorry, I don't have any useful suggestions. It's possible in
> principle to unwind the stack yourself by looking carefully at the
> instructions that will be executed and the PC and SP registers, and
> then to look at the instructions to figure out where variables are
> stored, but it's hard and it's easy to make a mistake.
>
> Ian
>
>
> > fatal error: unexpected signal during runtime execution
> > [signal SIGSEGV: segmentation violation code=0x1 addr=0x0
> pc=0x463926]
> >
> > runtime stack:
> > runtime.throw({0x49046b?, 0x0?})
> > /usr/local/go/src/runtime/panic.go:1047 +0x5d fp=0x7ffca8644230
> sp=0x7ffca8644200 pc=0x43243d
> > runtime.sigpanic()
> > /usr/local/go/src/runtime/signal_unix.go:819 +0x369
> fp=0x7ffca8644280 sp=0x7ffca8644230 pc=0x446569
> >
> > goroutine 1 [syscall]:
> > test1
> > /home/ubuntu/mbalraj/GO/TEST/test.go:9 pc=0x463926
> > test2
> > /home/ubuntu/mbalraj/GO/TEST/test.go:14 pc=0x46393b
> > test3
> > /home/ubuntu/mbalraj/GO/TEST/test.go:18 pc=0x46394b
> > _cgo_64d258852278_Cfunc_test3
> > /tmp/go-build/cgo-gcc-prolog:49 pc=0x46396b
> > runtime.asmcgocall
> > /usr/local/go/src/runtime/asm_amd64.s:844 pc=0x45c443
> > runtime.cgocall(0x46394f, 0xc58f70)
> > /usr/local/go/src/runtime/cgocall.go:158 +0x5c fp=0xc58f48
> sp=0xc58f10 pc=0x40579c
> > main._Cfunc_test3()
> > _cgo_gotypes.go:41 +0x45 fp=0xc58f70
