Hi Ian,
Thanks for your quick reply. I have now tried setting the CGO_CFLAGS to -g.
Now I am seeing the following BT. It is reporting "corrupt stack".
(gdb) bt
#0 runtime.raise () at /usr/local/go/src/runtime/sys_linux_amd64.s:159
#1 0x0000000000443345 in runtime.dieFromSignal (sig=6) at
/usr/local/go/src/runtime/signal_unix.go:870
#2 0x00000000004438de in runtime.sigfwdgo (sig=6, info=<optimized out>,
ctx=<optimized out>, ~r0=<optimized out>)
at /usr/local/go/src/runtime/signal_unix.go:1086
#3 0x0000000000442027 in runtime.sigtrampgo (sig=0, info=0x0, ctx=0x4583c1
<runtime.raise+33>) at /usr/local/go/src/runtime/signal_unix.go:432
#4 0x00000000004586a6 in runtime.sigtramp () at
/usr/local/go/src/runtime/sys_linux_amd64.s:359
#5 <signal handler called>
#6 runtime.raise () at /usr/local/go/src/runtime/sys_linux_amd64.s:159
#7 0x0000000000443345 in runtime.dieFromSignal (sig=6) at
/usr/local/go/src/runtime/signal_unix.go:870
#8 0x0000000000443558 in runtime.crash () at
/usr/local/go/src/runtime/signal_unix.go:962
#9 0x000000000042f891 in runtime.fatalthrow.func1 () at
/usr/local/go/src/runtime/panic.go:1129
#10 0x000000000042f80c in runtime.fatalthrow (t=<optimized out>) at
/usr/local/go/src/runtime/panic.go:1122
#11 0x000000000042f4bd in runtime.throw (s=...) at
/usr/local/go/src/runtime/panic.go:1047
#12 0x0000000000443289 in runtime.sigpanic () at
/usr/local/go/src/runtime/signal_unix.go:819
#13 0x000000000045abe6 in test1 () at /home/ubuntu/mbalraj/GO/TEST/test.go:9
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
root@nvme-tcp:/home/ubuntu/mbalraj/GO/TEST# go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/root/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/root/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct";
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.19.4"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/ubuntu/mbalraj/GO/TEST/go.mod"
GOWORK=""
CGO_CFLAGS="-g"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0
-fdebug-prefix-map=/tmp/go-build1125623398=/tmp/go-build
-gno-record-gcc-switches"
Best Regards
Mariappan
On Fri, Jan 6, 2023 at 11:29 AM Ian Lance Taylor <i...@golang.org> wrote:
> 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/CAKKWi6Sd5Bp2g5am6amGXFxYFo1c9K7Ga51ENqu%2B6dVzwVjB6g%40mail.gmail.com.
