dotnet/runtime · error
Problem waiting for createdump: waitpid() FAILED result
Error message
Problem waiting for createdump: waitpid() FAILED result %d wstatus %08x errno %s (%d)\n
What it means
Printed by PROCCreateCrashDump after the parent calls waitpid(childpid,&wstatus,0) to reap the forked createdump child. If waitpid does not return childpid the dump result is considered unreliable and the function returns false, reporting result, wstatus and errno. The most common cause is ECHILD, meaning the child was already reaped (for example by a concurrent SIGCHLD handler), but EINTR/EINVAL are also possible. This guards the crash-dump lifecycle so a half-finished dump is not reported as success.
Solutions
- Avoid reaping unrelated children in custom signal handlers: have SIGCHLD handlers use waitpid(WNOHANG) only for pids they own, never a blanket wait().
- Temporarily block SIGCHLD (sigprocmask) around the crash-dump path, or ensure the runtime's crash handler is the only waiter for the createdump pid.
- Inspect wstatus/errno in the message: ECHILD points to a double-reap race, EINTR to a missing retry, EINVAL to pid corruption.
- If dumps are unreliable in this environment, capture them out-of-process (dotnet-dump collect on a live process) instead of relying on the in-crash fork.
Defensive patterns
Strategy: validation
Validate before calling
// Avoid double-reaping the createdump child from a custom signal handler.
// If you must handle SIGCHLD, only reap pids you own:
static void SafeSigchld(int sig) {
int saved = errno;
while (true) {
pid_t p = waitpid((pid_t)-1, NULL, WNOHANG);
if (p <= 0) break;
// ONLY treat p if it is one of YOUR known child pids; never blanket-reap.
}
errno = saved;
} Prevention
- Never call bare wait()/waitpid(-1) in SIGCHLD handlers; use WNOHANG and reap only known pids.
- Block SIGCHLD (sigprocmask) around crash-dump logic if you control the handler.
- Avoid launching your own children concurrently with crash-dump generation to remove reaping races.
- Collect dumps out-of-process (dotnet-dump) when in-process reaping races are unavoidable.
When it happens
Trigger: Reached whenever waitpid for the createdump child returns a value other than childpid: the child was already collected by another waitpid in a signal handler (ECHILD), the call was interrupted and the retry loop is absent, or childpid is invalid (EINVAL). It is strictly a parent-side diagnostic after the dump child has been launched.
Common situations: An application installs a SIGCHLD/SIGCLD handler that calls wait/waitpid and inadvertently reaps the createdump child first; nested signal handlers during a crash; pid-reuse races on very long-lived hosts; a second crash-dump triggering while the first child is still being collected.
Related errors
- Problem writing to createdump parent_write_pipe
- Fail
- BEGIN: coreclr_execute_assembly failed - Error: 0x%08x
- BEGIN: coreclr_initialize failed - Error: 0x%08x
- both count and length property found on
AI-assisted analysis of dotnet/runtime@60108ba66e (2026-08-10).
Data as JSON: /api/errors/3ef00e7b1c9a4163.
Report an issue: GitHub.
Appendix: source
Thrown at src/coreclr/pal/src/thread/process.cpp:1617
int count = 0;
while ((count = read(parent_read_pipe, errorMessageBuffer + bytesRead, cbErrorMessageBuffer - bytesRead)) > 0)
{
bytesRead += count;
}
errorMessageBuffer[bytesRead] = 0;
if (bytesRead > 0)
{
fputs(errorMessageBuffer, stderr);
}
}
close(parent_read_pipe);
// Parent waits until the child process is done
int wstatus = 0;
int result = waitpid(childpid, &wstatus, 0);
if (result != childpid)
{
fprintf(stderr, "Problem waiting for createdump: waitpid() FAILED result %d wstatus %08x errno %s (%d)\n",
result, wstatus, strerror(errno), errno);
return false;
}
else
{
#ifdef _DEBUG
fprintf(stderr, "waitpid() returned successfully (wstatus %08x) WEXITSTATUS %x WTERMSIG %x\n", wstatus, WEXITSTATUS(wstatus), WTERMSIG(wstatus));
#endif
return !WIFEXITED(wstatus) || WEXITSTATUS(wstatus) == 0;
}
}
return true;
#endif // !TARGET_IOS && !TARGET_TVOS && !TARGET_WASM
}
/*++
Function:
PROCCreateCrashDumpView on GitHub (pinned to 60108ba66e)