Go version

go version go1.22.6 linux/amd64 (cross compile to arm64 with CGO_ENABLED=0)

Output of go env in your module/workspace:

// cross compile

GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/opt/xxx/.cache/go-build'
GOENV='/opt/xxx/.config/go/env'
GOEXE=''
GOEXPERIMENT='arenas'
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/opt/xxx/gopath/pkg/mod'
GONOPROXY='xxx'
GONOSUMDB='xxx'
GOOS='linux'
GOPATH='/opt/xxx/gopath'
GOPRIVATE='xxx'
GOPROXY='xxx'
GOROOT='/opt/xxx/go'
GOSUMDB='sum.golang.google.cn'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/opt/xxx/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.22.6'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/opt/xxx/inception/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build200162598=/tmp/go-build -gno-record-gcc-switches'

What did you do?

I'm writing a Golang+CGO program, and testing a bad code in CGO to check if it could catch the right backtrace.

Here is my code:

test.c:

#include <stdio.h>
#include <stddef.h>
void test()
{
    int* ptr = NULL;
    *ptr = 1024;
}
void trigger_crash()
{
    printf("hello world\n");
    test();
}

test.h:

#ifndef FDDE6B57_4166_4D0B_9BED_C9BF03D209B8
#define FDDE6B57_4166_4D0B_9BED_C9BF03D209B8

void trigger_crash();

#endif /* FDDE6B57_4166_4D0B_9BED_C9BF03D209B8 */

main.go:

package main

/*
#include <test.h>
*/
import "C"
import (
    "fmt"
    "os"
    "os/signal"
    "runtime/debug"
    "syscall"
)

func enableCore() {
    debug.SetTraceback("crash")

    var lim syscall.Rlimit
    err := syscall.Getrlimit(syscall.RLIMIT_CORE, &lim)
    if err != nil {
        panic(fmt.Sprintf("error getting rlimit: %v", err))
    }
    lim.Cur = lim.Max
    fmt.Fprintf(os.Stderr, "Setting RLIMIT_CORE = %+#v\n", lim)
    err = syscall.Setrlimit(syscall.RLIMIT_CORE, &lim)
    if err != nil {
        panic(fmt.Sprintf("error setting rlimit: %v", err))
    }
    signal.Ignore(syscall.SIGABRT)
}

func main() {
    enableCore()
    C.trigger_crash()
}

What did you see happen?

I cannot get the C stack by gdb on arm64.

$ gdb -nx -batch -ex bt cgo-crash /var/core/cgo-crash.1724899484.2105538.core
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
Core was generated by `./cgo-crash'.
Program terminated with signal SIGABRT, Aborted.
#0  runtime.raise () at /opt/xxx/go/src/runtime/sys_linux_arm64.s:158
158     /opt/xxx/go/src/runtime/sys_linux_arm64.s: No such file or directory.
[Current thread is 1 (Thread 0x7f5b7fe1d0 (LWP 2105542))]
warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts
of file /home/admin/cgo-crash.
Use `info auto-load python-scripts [REGEXP]' to list them.
#0  runtime.raise () at /opt/xxx/go/src/runtime/sys_linux_arm64.s:158
#1  0x000000000044e884 in runtime.dieFromSignal (sig=6) at /opt/xxx/go/src/runtime/signal_unix.go:923
#2  0x000000000044ef30 in runtime.sigfwdgo (sig=6, info=<optimized out>, ctx=<optimized out>, ~r0=<optimized out>) at /opt/xxx/go/src/runtime/signal_unix.go:1128
#3  0x000000000044d53c in runtime.sigtrampgo (sig=0, info=0x2020c6, ctx=0x6) at /opt/xxx/go/src/runtime/signal_unix.go:432
#4  0x0000000000469a54 in runtime.sigtramp () at /opt/xxx/go/src/runtime/sys_linux_arm64.s:462

Before 1.20 (included), C stack could be typed correctly. After version 1.21, this problem appeared. Related issue: https://github.com/golang/go/issues/63277

https://github.com/golang/go/commit/de5b418bea70aaf27de1f47e9b5813940d1e15a4 fixes the problem on x64. Unfortunately, arm64 remains the problem.

@zzkcode gave more context in https://github.com/golang/go/issues/63277#issuecomment-2316767430

What did you expect to see?

Generating the correct backtrace on arm64 (details will be in the Details section).

Comment From: gabyhelp

Related Issues and Documentation

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

Comment From: timothy-king

CC @golang/compiler

Comment From: dmitshur

Moving this issue to Go1.24 milestone to track investigating and fixing it at tip. If a backport is needed, please follow the https://go.dev/wiki/MinorReleases process to create backport issue(s).