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 <i...@golang.org> wrote: > On Sun, Jan 8, 2023, 9:33 PM mariappan balraj <mariappan.bal...@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 <i...@golang.org> wrote: >> >>> On Fri, Jan 6, 2023 at 9:01 PM mariappan balraj >>> <mariappan.bal...@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 <i...@golang.org> >>> wrote: >>> >> >>> >> On Fri, Jan 6, 2023, 5:57 PM mariappan balraj < >>> mariappan.bal...@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, <i...@golang.org> >>> wrote: >>> >>>> >>> >>>> On Fri, Jan 6, 2023 at 5:28 PM mariappan balraj >>> >>>> <mariappan.bal...@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/CAKKWi6RYWnOrwNwndNjyWVsqgG1rDT8%2BbDLSZJt33cX6j6PnGg%40mail.gmail.com.
