On Thu, Jan 5, 2023 at 9:02 PM mariappan balraj <mariappan.bal...@gmail.com> wrote: > > Thanks for your reply. This point is clear. I am interested only in getting > the complete C call stack only. I could able to get the GO stack by using the > delve debugger. > > When I use the GDB, I am getting the following stack. In the stack I am > seeing the last C function called which test1(). But I am not seeing test2() > and test3() in the stack. In GO code, test3() is called. These details are > very important when we want to debug the issues from production. > > I am eagerly waiting for the solution. It really helps others also. Kindly > please help on this.
Please include plain text as plain text, not in colors with a background. Plain text is much easier to read in e-mail. Thanks. I expect that you are only seeing test1 because the C code is compiled with optimization and all the functions are inlined. Try building with `CGO_CFLAGS=-g` set in the environment. Ian > > (gdb) thread apply all bt > > Thread 3 (Thread 0x7f2d70694740 (LWP 182930)): > > #0 runtime.usleep () at /usr/local/go/src/runtime/sys_linux_amd64.s:140 > > #1 0x0000000000448fd8 in runtime.sighandler (sig=6, info=<optimized out>, > ctxt=<optimized out>, gp=0xc0000061a0) at > /usr/local/go/src/runtime/signal_unix.go:789 > > #2 0x00000000004484a5 in runtime.sigtrampgo (sig=6, info=0xc00000fbf0, > ctx=0xc00000fac0) at /usr/local/go/src/runtime/signal_unix.go:479 > > #3 0x000000000045fba6 in runtime.sigtramp () at > /usr/local/go/src/runtime/sys_linux_amd64.s:359 > > #4 <signal handler called> > > #5 0x00007f2d7072da7c in pthread_kill () from /lib/x86_64-linux-gnu/libc.so.6 > > #6 0x00007f2d706d9476 in raise () from /lib/x86_64-linux-gnu/libc.so.6 > > #7 0x00007f2d706bf7f3 in abort () from /lib/x86_64-linux-gnu/libc.so.6 > > #8 0x00007f2d706bf71b in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > > #9 0x00007f2d706d0e96 in __assert_fail () from > /lib/x86_64-linux-gnu/libc.so.6 > > #10 0x0000000000462be7 in test1 () at /home/ubuntu/mbalraj/GO/TEST/test.go:10 > > #11 0x000000000045dce4 in runtime.asmcgocall () at > /usr/local/go/src/runtime/asm_amd64.s:844 > > #12 0x00000000004dd620 in ?? () > > #13 0x0000000000000001 in ?? () > > #14 0x000000c000080a00 in ?? () > > #15 0x0a007ffebe0a3b28 in ?? () > > #16 0x0000000000000001 in ?? () > > #17 0x00000000000000f8 in ?? () > > #18 0x000000c0000061a0 in ?? () > > #19 0x000000c000058ae0 in ?? () > > #20 0x000000000045db29 in runtime.systemstack () at > /usr/local/go/src/runtime/asm_amd64.s:492 > > #21 0x00000000004604e5 in runtime.newproc (fn=0x1) at <autogenerated>:1 > > #22 0x00000000004c57c0 in runtime[scavenger] () > > #23 0x0000000000000001 in ?? () > > #24 0x000000000045da25 in runtime.mstart () at > /usr/local/go/src/runtime/asm_amd64.s:390 > > #25 0x000000000045d9af in runtime.rt0_go () at > /usr/local/go/src/runtime/asm_amd64.s:354 > > #26 0x0000000000000001 in ?? () > > #27 0x00007ffebe0a3ca8 in ?? () > > #28 0x0000000000000000 in ?? () > > > By using dlv, I am seeing the following GO stack. > > > (dlv) goroutine 1 bt > > 0 0x000000000045f85d in runtime.usleep > > at /usr/local/go/src/runtime/sys_linux_amd64.s:140 > > 1 0x000000000045dac0 in runtime.systemstack_switch > > at /usr/local/go/src/runtime/asm_amd64.s:459 > > 2 0x0000000000404c4a in runtime.cgocall > > at /usr/local/go/src/runtime/cgocall.go:168 > > 3 0x0000000000462b45 in main._Cfunc_test3 > > at _cgo_gotypes.go:41 > > 4 0x0000000000462b97 in main.main > > at ./test.go:24 > > 5 0x0000000000437458 in runtime.main > > at /usr/local/go/src/runtime/proc.go:250 > > 6 0x000000000045dfe1 in runtime.goexit > > at /usr/local/go/src/runtime/asm_amd64.s:1594 > > > My GDB version is > > gdb --version > > GNU gdb (GDB) 12.1 > > > go version go1.19.4 linux/amd64 > > > Best Regards > Mariappan > > On Fri, Jan 6, 2023 at 1:12 AM Ian Lance Taylor <i...@golang.org> wrote: >> >> On Thu, Dec 22, 2022 at 1:57 PM mariappan balraj >> <mariappan.bal...@gmail.com> wrote: >> > >> > I have following programming where making CGO from GO code. test3() is >> > called from Go code. Which calls test2() and which calls test1(). In >> > test1(), there is a NULL pointer assignment. I could able to generate the >> > core dump when running the program. But when I use gdb, I am not getting >> > the stack trace. Can someone please help? >> >> The call from Go to C switches stacks. The Go runtime doesn't provide >> enough information for gdb to be able to unwind past that stack >> switch. gdb can show the stack trace of the C function calls, but not >> the stack trace of the Go functions. >> >> 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/CAOyqgcW42w5w_XGEG%2BdhTNHWUjXJ2-SLWAvc5k17gcmYN9mv_A%40mail.gmail.com.
