Running gdb inside gVisor hits segmentation faults

[xinyangge]

Description

When running the following command in gVisor, it consistently hits SEGV fault: for i in $(seq 1 100) ; do gdb -q --batch -ex "run" --args /bin/true 2>&1 | grep SEGV ; done. The issue doesn't repro with the same base image + command in a vanilla docker container.

Below is the environment information:

# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.5 LTS"

# gdb --version
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04.2) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Steps to reproduce

No response

runsc version

runsc version release-20250820.0-120-g6bf3c4885132-dirty
spec: 1.1.0-rc.1

docker version (if using docker)

uname

$ uname -r
6.6.72+

kubectl (if using Kubernetes)

repo state (if built from source)

No response

runsc debug logs (if available)

[nixprime]

I can't reproduce this using runsc built from either 6bf3c48 or head:

$ sudo docker run --runtime=runsc -it ubuntu:22.04
root@59be1d2ee50a:/# for i in $(seq 1 100) ; do gdb -q --batch -ex "run" --args /bin/true 2>&1 | grep SEGV ; done
root@59be1d2ee50a:/# for i in $(seq 1 1000) ; do gdb -q --batch -ex "run" --args /bin/true 2>&1 | grep SEGV ; done
root@59be1d2ee50a:/#

IIUC, the -dirty suffix in your runsc version indicates that you have local changes to your runsc binary.