-
Bug
-
Resolution: Unresolved
-
Undefined
-
None
-
rhel-9.7
-
None
-
Yes
-
None
-
rhel-pt-gdb
-
2
-
False
-
False
-
-
No
-
None
-
None
-
None
-
Unspecified Release Note Type - Unknown
-
Unspecified
-
Unspecified
-
Unspecified
-
None
What were you trying to do that didn't work?
Latest rhel-9.7 golang-1.24.4-2.el9 internal testsuite fails due to a failure on TestGdbInfCallstack when running with gdb-16.3-2.el9 on aarch64:
[root@ampere-mtsnow-altramax-04-vm-01 ~]# rpm -qa golang gdb golang-1.24.4-2.el9.aarch64 gdb-16.3-2.el9.aarch64 [root@ampere-mtsnow-altramax-04-vm-01 ~]# go test runtime -count=1 --- FAIL: TestGdbInfCallstack (2.19s) runtime-gdb_test.go:79: gdb version 16.3 runtime-gdb_test.go:849: gdb output: Loading Go Runtime support. Breakpoint 1 at 0x468870: file /usr/lib/golang/src/runtime/asm_arm64.s, line 1201. warning: Unable to determine the number of hardware watchpoints available. warning: Unable to determine the number of hardware breakpoints available. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0xffffb12ff100 (LWP 478424)] [Switching to Thread 0xffffb12ff100 (LWP 478424)] Thread 2 "a.exe" hit Breakpoint 1, setg_gcc () at /usr/lib/golang/src/runtime/asm_arm64.s:1201 1201 TEXT setg_gcc<>(SB),NOSPLIT,$8 terminate called after throwing an instance of 'std::logic_error' what(): basic_string::_M_construct null not valid Fatal signal: Aborted ----- Backtrace ----- 0xaaaad6b4e77b ??? 0xaaaad6c6e373 ??? 0xffffa01b67df ??? (...) 0xffff9f479617 ??? 0xaaaad6a65b2f ??? 0xffffffffffffffff ??? --------------------- A fatal error internal to GDB has been detected, further debugging is not possible. GDB will now terminate. This is a bug, please report it. For instructions, see: <https://www.gnu.org/software/gdb/bugs/>. runtime-gdb_test.go:851: gdb exited with error: signal: aborted (core dumped) FAIL FAIL runtime 78.477s FAIL
Looking into the testcase, the failure seems to be triggered when calling backtrace inside gdb:
[root@ampere-mtsnow-altramax-04-vm-01 ~]# cat > main.go <<EOF package main import "C" import "time" func loop() { for i := 0; i < 1000; i++ { time.Sleep(time.Millisecond*5) } } func main() { go loop() time.Sleep(time.Second * 1) } EOF [root@ampere-mtsnow-altramax-04-vm-01 ~]# go build -o a.exe main.go [root@ampere-mtsnow-altramax-04-vm-01 ~]# gdb -nx -batch \ -iex "add-auto-load-safe-path /usr/lib/golang/src/runtime" \ -ex "set startup-with-shell off" \ -ex "break setg_gcc" \ -ex "run" \ -ex "backtrace 3" \ $(pwd)/a.exe Loading Go Runtime support. Breakpoint 1 at 0x468870: file /usr/lib/golang/src/runtime/asm_arm64.s, line 1201. warning: Unable to determine the number of hardware watchpoints available. warning: Unable to determine the number of hardware breakpoints available. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0xffffb12ff100 (LWP 488499)] [New Thread 0xffffb0aef100 (LWP 488500)] [Switching to Thread 0xffffb12ff100 (LWP 488499)] Thread 2 "a.exe" hit Breakpoint 1, setg_gcc () at /usr/lib/golang/src/runtime/asm_arm64.s:1201 1201 TEXT setg_gcc<>(SB),NOSPLIT,$8 terminate called after throwing an instance of 'std::logic_error' what(): basic_string::_M_construct null not valid Fatal signal: Aborted ----- Backtrace ----- 0xaaaab10ce77b ??? 0xaaaab11ee373 ??? 0xffffadc807df ??? (...)
This issue is also reproducible on x86_64, although the go test is skipped for all arches other than aarch64.
This seems to be a regression, since it's not reproducible with previous gdb-14.2-4.1.el9_6, nor rhel-10.1 gdb-16.3-2.el10.
What is the impact of this issue to you?
It results on a go internal testsuite failure.
Please provide the package NVR for which the bug is seen:
gdb-16.3-2.el9
How reproducible is this bug?:
100%
Expected results
No failure
Actual results
gdb aborts