Hi Ian,
When I call the same function from pure C code, I am able to get the
complete stack and it is not reporting that the stack is corrupted. I am
expecting the same C stack when I use CGO also. Please kindly help with
this.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000559e2af8813d in test1 () at test.c:6
6 *p = 30;
(gdb) bt
#0 0x0000559e2af8813d in test1 () at test.c:6
#1 0x0000559e2af88153 in test2 () at test.c:11
#2 0x0000559e2af88163 in test3 () at test.c:15
#3 0x0000559e2af88173 in main () at test.c:19
#include <stdio.h>
#include <assert.h>
void test1(void) {
int *p = (int*)NULL;
*p = 30;
//assert(1 == 2);
}
void test2(void) {
test1();
}
void test3(void) {
test2();
}
int main(void) {
test3();
}
Best Regards
Mariappan
On Fri, Jan 6, 2023 at 11:42 AM mariappan balraj <mariappan.bal...@gmail.com>
wrote:
> 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/CAKKWi6SqvemgBbSPpcmQPD1bYEZ0kh56SH0Rexs19mu5tPofFA%40mail.gmail.com.
