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/50f21d79-beea-46b7-866a-479d7e860d00n%40googlegroups.com.
