Description

When running inside a container with a restrictive seccomp profile (e.g. a Kubernetes pod), sentry_get_modules_list() always returns an empty list, causing debug_meta.images in manually-captured events to be empty. Sentry's symbolicator then marks every frame as unknown_image, making stack traces unsymbolicated even when debug files are correctly uploaded.

Possible issue

The root cause might be in read_safely(): it calls process_vm_readv() to read ELF magic bytes from each /proc/self/maps entry. There is already a fallback to memcpy for EPERM and EINVAL, but when seccomp blocks the syscall it returns ENOSYS, which is not handled — so read_safely() returns false, is_valid_elf_header() returns false for every entry, and the module list stays empty.

Note: crash events captured by crashpad are not affected — crashpad's handler process enumerates modules independently of sentry_get_modules_list().

Suggested fix

Add ENOSYS to the existing fallback in read_safely():

if (!rv && (errno == EPERM || errno == EINVAL || errno == ENOSYS)) {
    memcpy(dst, src, size);
    rv = true;
}

When does the problem happen

• During build
• During run-time
• When capturing a hard crash

Environment

• OS: Ubuntu 24.04.4 LTS (Flatcar Linux kernel 6.12.66), running inside a Kubernetes pod with default seccomp profile
• Compiler: Clang 20
• CMake version and config: SENTRY_BACKEND=crashpad
• sentry-native version: 0.13.2

Steps To Reproduce

1. Run the application with sentry-native (crashpad backend) inside a container where process_vm_readv is restricted by seccomp.
2. Enable debug logging: sentry_options_set_debug(options, 1).
3. Capture any non-crash event: sentry_capture_event(...).
4. Observe "read 0 modules from /proc/self/maps" in the log output.
5. In Sentry, all frames in the event have symbolicator_status: "unknown_image" despite debug files being uploaded.

Log output

[sentry] DEBUG trying to read modules from /proc/self/maps
[sentry] DEBUG read 0 modules from /proc/self/maps