Hi Ian, 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. 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/CAKKWi6Q9%2BMvOAM9mOUJ7ouHNVKm4yF7Ev4s1SbtSrVozYKeYoA%40mail.gmail.com.
