-
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