go-delve/delve · error

could not get event message: %s

Error message

could not get event message: %s

What it means

This error is returned by the Linux native backend's wait loop (trapWaitInternal) when PTRACE_GETEVENTMSG fails for a stopped thread that has hit a PTRACE_EVENT_CLONE or PTRACE_EVENT_VFORK stop. Delve needs the event message to learn the pid/tid of the newly cloned thread so it can attach to it; if the ptrace call fails with anything other than ESRCH (thread already gone, which is tolerated), the wait is aborted with this wrapped error. It almost always indicates the tracee died or the ptrace relationship was lost mid-event.

Source

Thrown at pkg/proc/native/proc_linux.go:518

			}
			// does this ever happen?
			delete(dbp.threads, wpid)
			continue
		}
		if status.StopSignal() == sys.SIGTRAP && (status.TrapCause() == sys.PTRACE_EVENT_CLONE || status.TrapCause() == sys.PTRACE_EVENT_VFORK) {
			// A traced thread has cloned a new thread, grab the pid and
			// add it to our list of traced threads.
			// If TrapCause() is sys.PTRACE_EVENT_VFORK this is actually a new
			// process, but treat it as a normal thread until exec happens, so that
			// we can initialize the new process normally.
			var cloned uint
			dbp.execPtraceFunc(func() { cloned, err = sys.PtraceGetEventMsg(wpid) })
			if err != nil {
				if err == sys.ESRCH {
					// thread died while we were adding it
					continue
				}
				return nil, fmt.Errorf("could not get event message: %s", err)
			}
			th, err = dbp.addThread(int(cloned), false)
			if err != nil {
				if err == sys.ESRCH {
					// thread died while we were adding it
					delete(dbp.threads, int(cloned))
					continue
				}
				return nil, err
			}
			if halt {
				th.os.running = false
				dbp.threads[int(wpid)].os.running = false
				return nil, nil
			}
			if err = th.resume(); err != nil {
				if err == sys.ESRCH {
					// thread died while we were adding it

View on GitHub (pinned to a23773e6c3)

Solutions

1. Check no other tracer (strace, another dlv, IDE debugger) is attached to the target; only one PTRACE_ATTACH is permitted.
2. Verify ptrace permissions: ensure /proc/sys/kernel/yama/ptrace_scope allows the attach and the container has CAP_SYS_PTRACE (docker run --cap-add=SYS_PTRACE).
3. Make sure the target process is still alive; if threads are being killed rapidly, reduce thread churn or attach to a quiescent process.
4. Retry the debug session; if reproducible, file an issue with the wrapped errno string since it indicates an unexpected ptrace failure.

// before debugging, verify single-tracer and ptrace access
ps -o tracer= -p $PID 2>/dev/null && echo 'already traced'
test -r /proc/$PID/mem || echo 'no ptrace permission'
cat /proc/sys/kernel/yama/ptrace_scope

err := runDebugSession()
if err != nil && strings.Contains(err.Error(), "could not get event message") {
    // target likely died mid-clone; verify liveness and retry once
    if processAlive(pid) { retrySession(pid) }
}

When it happens

Trigger: A debugged thread hits a clone/vfork stop and Delve calls sys.PtraceGetEventMsg(wpid), but the call fails with an errno other than ESRCH — e.g. the tracee was killed between the stop and the call, the process was re-parented, or another debugger/tool interfered with the ptrace attachment.

Common situations: Debugging a multithreaded program under heavy thread churn where threads are killed while the debugger processes stops; running inside containers or sandboxes (seccomp/apparmor) that restrict ptrace; attaching to a process that another tracer simultaneously owns (only one tracer allowed, causing EPERM-style failures).

Related errors

• could not continue new thread %d %s
• could not continue existing thread %d %s
• process must be stopped in order to kill it
• waiting for target execve failed: %s
• could not attach to new thread %d %s

AI-assisted analysis of go-delve/delve@a23773e6c3 (2026-08-31). Data as JSON: /api/errors/b586eb58ec507c3d. Report an issue: GitHub.