Potential NULL pointer dereference

Both Unix and Windows implementations have a potential NULL pointer dereference when checking the executable path.

Unix implementation (src/process/sentry_process_unix.c:151):

    if (\!executable || \!executable->path || strcmp(executable->path, "") == 0) {
        return false;
    }

Windows implementation (src/process/sentry_process_windows.c:12):

    if (\!executable || \!executable->path || wcscmp(executable->path, L"") == 0) {
        return false;
    }

Issue: The code checks \!executable but then directly accesses executable->path without verifying it's not NULL. Since sentry_path_t contains a sentry_pathchar_t *path field, this could be NULL even when the struct itself is valid, leading to a crash.

Logic Error: False Success in Double-Fork Pattern

The Unix implementation has a fundamental design flaw in the double-fork pattern where sentry__process_spawn() returns true even when the target executable fails to launch.

Logic Analysis:

1. Parent process calls fork() → creates first child (pid1)
2. First child calls setsid() and fork() again → creates second child (pid2, the grandchild)
3. Second child (grandchild) calls execv() - this is where the target process actually runs
4. First child immediately calls _exit(0) after creating the grandchild
5. Parent process waits for the first child to exit with waitpid(pid1, &status, 0)

The Problem:

// In spawn_process():
if (pid2 == 0) {
    // second child (grandchild): actual execv() happens here
    execv(argv[0], argv);
    SENTRY_ERRORF("execv failed: %s", strerror(errno));
    _exit(1);  // ← This failure is never seen by parent
} else {
    // first child exits immediately after fork
    _exit(0);  // ← Parent only sees this exit code
}

Issue Flow:

1. Parent waits for first child with waitpid(pid1, &status, 0)
2. First child exits with code 0 after successful second fork
3. If execv() fails in grandchild, it exits with code 1
4. But parent already received exit code 0 from first child → returns true

Impact: Function returns true for non-existent executables, making the boolean return value misleading.

Note: This is inherent to fully detached processes - you can't reliably detect launch success without IPC. Consider either:

• Documenting that true only means "detachment succeeded"
• Changing return type to void
• Adding optional launch verification mechanism

This affects the Unix implementation only (lines 84-146).

—
Comment by Claude Code

LGTM

LGTM, although it might make sense to document how this API should only ever be called internally (and not with any arguments coming from user input), as otherwise passing the constructed cli value to the CreateProcessW on Windows could potentially be open to injection attacks.

Alternatively we could sanitize the arguments, but I'm not sure that is strictly necessary.