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/CAOyqgcUetEYyacJvcDVkNd9L%2BbJ%2BaRSaO5HqcOAaDyLGdqS65A%40mail.gmail.com.
