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

  1. Avoid reaping unrelated children in custom signal handlers: have SIGCHLD handlers use waitpid(WNOHANG) only for pids they own, never a blanket wait().
  2. Temporarily block SIGCHLD (sigprocmask) around the crash-dump path, or ensure the runtime's crash handler is the only waiter for the createdump pid.
  3. Inspect wstatus/errno in the message: ECHILD points to a double-reap race, EINTR to a missing retry, EINVAL to pid corruption.
  4. 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

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


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:
  PROCCreateCrashDump

View on GitHub (pinned to 60108ba66e)