| Summary: | Assertion '!sr_isError(sr)' failed - mmap fd points to an open descriptor to a PCI device | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Brayton Hackbarth <bhackbarth> |
| Component: | memcheck | Assignee: | Paul Floyd <pjfloyd> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | bhackbarth, pjfloyd |
| Priority: | NOR | ||
| Version First Reported In: | 3.24.0 | ||
| Target Milestone: | --- | ||
| Platform: | RedHat Enterprise Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Brayton Hackbarth
2026-01-05 23:01:32 UTC
Do you get the same error with Valgrind 3.26? Any ideas how we could reproduce this issue without your software and hardware? Hello Paul, thanks for responding so quickly. Yes, I observed identical behavior on 3.26. Reproducing this elsewhere might pose a challenge because I'm not sure if this is hardware-specific (but I can say that even with identical hardware, I don't get the assert on Centos 6 or 7). Rocky9 is happy to let me read the file "resource" via in the PCI device directory, but not resource0, 1, etc. It will always throw a "Input/output error" or errno 5, almost as if there is a policy preventing standard I/O. However, it is quite happy to allow opening a file descriptor to the file. The hardware is a PTP hardware clock that is being disciplined based on a PPS input, so it's not exactly cheap and plentiful to obtain for testing. I was hoping that perhaps there could be a flag set in Valgrind to differentiate between mmap() ing physical devices versus shared libs since kernel permissions seem to come into play with physical devices. After checking an older Centos7 run I realized I'm running Valgrind 3.15 there, and things were fine because this was just a warning in that version: --6427-- WARNING: Serious error when reading debug info --6427-- When reading debug info from /sys/devices/pci0000:80/0000:80:03.0/0000:85:00.0/resource0: --6427-- can't read file to inspect ELF header But once we started testing Rocky9, we also upgraded Valgrind and that is no longer a warning in current code, so I created a patch that basically just makes that a warning again. I'll take a look at the code. Maybe we can use fstat to tell that the fd is not a regular file. |