Builders and GDB permissions

[Daniel Morsing]

Hi there,

Working on https://go-review.googlesource.com/c/go/+/704615, I discovered that some builders allow attaching to a running test with GDB, while others got a permission error. Because of the nature of the change, it's very hard to verify that it is functioning properly without an external core dump, so I'm wondering if it's possible to guarantee that GDB attaching can happen on the builders during tests.

So far, I've found the linux-amd64_avx512 and linux-amd64_debiansid builder failing on ptrace. I'm not sure what the common factor between them is

Cheers,

Daniel

[Michael Pratt]

Hi Daniel,

Most of our builders appear to have /proc/sys/kernel/yama/ptrace_scope set to 1. I don't believe we've configured this explicitly, it is just the default.

Per man 2 ptrace, Yama ptrace scope 1 requires that the tracer has "a predefined relationship with the target process.  By default, the predefined relationship is that the target process must be a descendant of the caller."

Your CL execs `gcore` as a subprocess to trace its parent, so the relationship is backwards and I would expect failure.

In fact, https://go-review.git.corp.google.com/c/go/+/704615?checksPatchset=10&tab=checks shows that every builder failed except for gotip-linux-amd64, which surprises me because gotip-linux-amd64 also has ptrace_scope 1 and should be identical to other builders like gotip-linux-amd64-newinliner except for a GOEXPERIMENT environment variable. So I don't understand why that builder is passing (it is passing, not skipped).

I think we could theoretically adjust ptrace settings on builders to be more permissive, but I'm not sure that is necessary. I think this could be made to work with the yama requirements. For example, a test subprocess could be launched under GDB with commands to generate a core at the right moment (https://sourceware.org/gdb/current/onlinedocs/gdb.html/Core-File-Generation.html).

All that said, I would also recommend seeing if there is any way you can do your testing without gdb or gcore (gcore is part of gdb). gdb is notoriously difficult to use reliably in tests across different configurations, versions, or even just slightly different execution paths in a single version. Take a look through the laughable number of skip cases in https://cs.opensource.google/go/go/+/master:src/runtime/runtime-gdb_test.go if you haven't already.

If you are attempting to scan memory for a secret, before going to gdb I'd be tempted to add something to runtime/export_test.go that stops the world and manually searches the heap and all stacks. Though admittedly that could miss some niche parts of memory that a complete core dump would not.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-dev/afc8f9f5-5540-4e1d-a068-ecf957b0be13n%40googlegroups.com.

[Michael Pratt]

On Thu, Oct 9, 2025 at 3:42 PM Michael Pratt <mpr...@google.com> wrote:

Hi Daniel,

Most of our builders appear to have /proc/sys/kernel/yama/ptrace_scope set to 1. I don't believe we've configured this explicitly, it is just the default.

Per man 2 ptrace, Yama ptrace scope 1 requires that the tracer has "a predefined relationship with the target process.  By default, the predefined relationship is that the target process must be a descendant of the caller."

Your CL execs `gcore` as a subprocess to trace its parent, so the relationship is backwards and I would expect failure.

In fact, https://go-review.git.corp.google.com/c/go/+/704615?checksPatchset=10&tab=checks shows that every builder failed except for gotip-linux-amd64, which surprises me because gotip-linux-amd64 also has ptrace_scope 1 and should be identical to other builders like gotip-linux-amd64-newinliner except for a GOEXPERIMENT environment variable. So I don't understand why that builder is passing (it is passing, not skipped).

Oops, I put the Googler link here. That should be https://go-review.googlesource.com/c/go/+/704615?checksPatchset=10&tab=checks.