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 <ia...@golang.org> >> wrote: >> >>> On Sun, Jan 8, 2023, 9:33 PM mariappan balraj <mariappa...@gmail.com> >>> 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 <ia...@golang.org> >>>> wrote: >>>> >>>>> On Fri, Jan 6, 2023 at 9:01 PM mariappan balraj >>>>> <mariappa...@gmail.com> 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, 0xc000058f70) >>>>> > /usr/local/go/src/runtime/cgocall.go:158 +0x5c fp=0xc000058f48 >>>>> sp=0xc000058f10 pc=0x40579c >>>>> > main._Cfunc_test3() >>>>> > _cgo_gotypes.go:41 +0x45 fp=0xc000058f70 sp=0xc000058f48 pc=0x463885 >>>>> > main.main() >>>>> > /home/ubuntu/mbalraj/GO/TEST/test.go:26 +0x17 fp=0xc000058f80 >>>>> sp=0xc000058f70 pc=0x4638b7 >>>>> > runtime.main() >>>>> > /usr/local/go/src/runtime/proc.go:250 +0x212 fp=0xc000058fe0 >>>>> sp=0xc000058f80 pc=0x434c92 >>>>> > runtime.goexit() >>>>> > /usr/local/go/src/runtime/asm_amd64.s:1594 +0x1 fp=0xc000058fe8 >>>>> sp=0xc000058fe0 pc=0x45c761 >>>>> > >>>>> > Best Regards >>>>> > Mariappan >>>>> > >>>>> > On Sat, Jan 7, 2023 at 9:45 AM Ian Lance Taylor <ia...@golang.org> >>>>> wrote: >>>>> >> >>>>> >> On Fri, Jan 6, 2023, 5:57 PM mariappan balraj < >>>>> mariappa...@gmail.com> wrote: >>>>> >>> >>>>> >>> Hi Ian, >>>>> >>> Thanks for your active help. When I run the program by using gdb, >>>>> I am getting the complete stack. No issue. The issue is there when we >>>>> debug >>>>> core dump. Could you kindly please check whether you are seeing the same >>>>> behavior with core dump? >>>>> >> >>>>> >> >>>>> >> >>>>> >> Oh, right, sorry, I forgot about the core dump part. I don't know >>>>> if there is a way to make that better, given the three different stacks >>>>> involved. I'm surprised that it works as well as it does. A pure C >>>>> program that doesn't use sigaltstack only has a single stack, so it's a >>>>> much simpler case. >>>>> >> >>>>> >> Ian >>>>> >> >>>>> >> >>>>> >> >>>>> >>> On Sat, 7 Jan, 2023, 7:03 am Ian Lance Taylor, <ia...@golang.org> >>>>> wrote: >>>>> >>>> >>>>> >>>> On Fri, Jan 6, 2023 at 5:28 PM mariappan balraj >>>>> >>>> <mariappa...@gmail.com> wrote: >>>>> >>>> > >>>>> >>>> > I am not expecting GO stack. I am interested only in getting C >>>>> stack. If I want go stack, I can use delve debugger to get it. From GO, >>>>> using CGO, test3() is called which is calling test2() which is calling >>>>> test1(). I am expecting only C stack which contains test3(), test2(), >>>>> test1(). In this particular case assigning value by using pointer >>>>> variable >>>>> which contains NULL(segmentation fault). I am seeing only test1(). After >>>>> that it is not stack and saying stack corruption. I strongly believe that >>>>> you can help on this. Please help. >>>>> >>>> >>>>> >>>> I put your program in foo.go. Then I did: >>>>> >>>> >>>>> >>>> > CGO_CFLAGS=-g go build foo.go >>>>> >>>> > gdb ./foo >>>>> >>>> GNU gdb (Debian 12.1-3) 12.1 >>>>> >>>> Copyright (C) 2022 Free Software Foundation, Inc. >>>>> >>>> License GPLv3+: GNU GPL version 3 or later < >>>>> http://gnu.org/licenses/gpl.html> >>>>> >>>> This is free software: you are free to change and redistribute it. >>>>> >>>> There is NO WARRANTY, to the extent permitted by law. >>>>> >>>> Type "show copying" and "show warranty" for details. >>>>> >>>> This GDB was configured as "x86_64-linux-gnu". >>>>> >>>> Type "show configuration" for configuration details. >>>>> >>>> For bug reporting instructions, please see: >>>>> >>>> <https://www.gnu.org/software/gdb/bugs/>. >>>>> >>>> Find the GDB manual and other documentation resources online at: >>>>> >>>> <http://www.gnu.org/software/gdb/documentation/>. >>>>> >>>> >>>>> >>>> For help, type "help". >>>>> >>>> Type "apropos word" to search for commands related to "word"... >>>>> >>>> Reading symbols from ./foo... >>>>> >>>> warning: File "/home/iant/go/src/runtime/runtime-gdb.py" >>>>> auto-loading >>>>> >>>> has been declined by your `auto-load safe-path' set to >>>>> >>>> "$debugdir:$datadir/auto-load". >>>>> >>>> To enable execution of this file add >>>>> >>>> add-auto-load-safe-path /home/iant/go/src/runtime/runtime-gdb.py >>>>> >>>> line to your configuration file "/home/iant/.config/gdb/gdbinit". >>>>> >>>> To completely disable this security protection add >>>>> >>>> set auto-load safe-path / >>>>> >>>> line to your configuration file "/home/iant/.config/gdb/gdbinit". >>>>> >>>> For more information about this security protection see the >>>>> >>>> --Type <RET> for more, q to quit, c to continue without paging-- >>>>> >>>> "Auto-loading safe path" section in the GDB manual. E.g., run >>>>> from the shell: >>>>> >>>> info "(gdb)Auto-loading safe path" >>>>> >>>> (gdb) r >>>>> >>>> Starting program: /tmp/x/foo >>>>> >>>> [Thread debugging using libthread_db enabled] >>>>> >>>> Using host libthread_db library >>>>> "/lib/x86_64-linux-gnu/libthread_db.so.1". >>>>> >>>> [New Thread 0x7fffd09ea640 (LWP 650585)] >>>>> >>>> [New Thread 0x7fffcbfff640 (LWP 650586)] >>>>> >>>> [New Thread 0x7fffcb7fe640 (LWP 650587)] >>>>> >>>> [New Thread 0x7fffcaffd640 (LWP 650588)] >>>>> >>>> [New Thread 0x7fffca7fc640 (LWP 650589)] >>>>> >>>> >>>>> >>>> Thread 1 "foo" received signal SIGSEGV, Segmentation fault. >>>>> >>>> 0x000000000045b01a in test1 () at /home/iant/foo.go:6 >>>>> >>>> 6 *p = 30; >>>>> >>>> (gdb) where >>>>> >>>> #0 0x000000000045b01a in test1 () at /home/iant/foo.go:6 >>>>> >>>> #1 0x000000000045b02c in test2 () at /home/iant/foo.go:10 >>>>> >>>> #2 0x000000000045b038 in test3 () at /home/iant/foo.go:14 >>>>> >>>> #3 0x000000000045b054 in _cgo_3060c004c901_Cfunc_test3 >>>>> (v=0xc000064f70) >>>>> >>>> at /tmp/go-build/cgo-gcc-prolog:49 >>>>> >>>> #4 0x0000000000456c64 in runtime.asmcgocall () >>>>> >>>> at /home/iant/go/src/runtime/asm_amd64.s:848 >>>>> >>>> #5 0x00000000004e3460 in ?? () >>>>> >>>> #6 0x0000000000000001 in ?? () >>>>> >>>> #7 0x000000c000080500 in ?? () >>>>> >>>> #8 0x00007fffffffe458 in ?? () >>>>> >>>> #9 0x0000000000439225 in runtime.malg.func1 () >>>>> >>>> at /home/iant/go/src/runtime/proc.go:4227 >>>>> >>>> #10 0x0000000000456aa9 in runtime.systemstack () >>>>> >>>> at /home/iant/go/src/runtime/asm_amd64.s:496 >>>>> >>>> #11 0x00000000004596a5 in runtime.newproc (fn=0x1) at >>>>> <autogenerated>:1 >>>>> >>>> #12 0x00000000004cc720 in runtime[scavenger] () >>>>> >>>> #13 0x0000000000000001 in ?? () >>>>> >>>> #14 0x00000000004569a5 in runtime.mstart () >>>>> >>>> at /home/iant/go/src/runtime/asm_amd64.s:394 >>>>> >>>> #15 0x000000000045692f in runtime.rt0_go () >>>>> >>>> at /home/iant/go/src/runtime/asm_amd64.s:358 >>>>> >>>> #16 0x0000000000000001 in ?? () >>>>> >>>> --Type <RET> for more, q to quit, c to continue without paging--q >>>>> >>>> Quit >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> So when I try it, I do see the full C stack at the point where the >>>>> >>>> signal occurs. >>>>> >>>> >>>>> >>>> In your backtrace earlier you are trying to see the stack after >>>>> the >>>>> >>>> signal is already being handled by the Go signal handler. I don't >>>>> >>>> know why that would work. >>>>> >>>> >>>>> >>>> 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/60ef3181-f1e4-48d0-9fc9-f5b7bc6f4272n%40googlegroups.com.
