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.
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.