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/CAOyqgcXHUT2OKFzweE%2BAXee_Jj887M7eGqc5qknu0EO%2BnzbGRw%40mail.gmail.com.
