Bug 514206 - Assertion '!sr_isError(sr)' failed - mmap fd points to an open descriptor to a PCI device
Summary: Assertion '!sr_isError(sr)' failed - mmap fd points to an open descriptor to ...
Status: REPORTED
Alias: None
Product: valgrind
Classification: Developer tools
Component: memcheck (other bugs)
Version First Reported In: 3.24.0
Platform: RedHat Enterprise Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Paul Floyd
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2026-01-05 23:01 UTC by Brayton Hackbarth
Modified: 2026-01-12 07:44 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brayton Hackbarth 2026-01-05 23:01:32 UTC
Our binary mmap()'s a PCI device (/sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/resource0), but Rocky9 returns errno 5 if one tries to pread() that descriptor. This causes the sr_isError(sr) assertion when we run Valgrindm since it can't peek the descriptor. I verified fd flags such as O_DIRECT don't matter here.

 I'm not sure if this is due to more strict kernel policies, but our team currently only observes this behavior on Rocky9. I was hoping to open a bug to see if there was a future way to tweak the ELF / DWARF checks, as there's no way for me to make this work without compiling a patch to skip the ELF check logic.
Comment 1 Paul Floyd 2026-01-06 06:14:28 UTC
Do you get the same error with Valgrind 3.26?

Any ideas how we could reproduce this issue without your software and hardware?
Comment 2 Brayton Hackbarth 2026-01-06 20:57:31 UTC
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.
Comment 3 Brayton Hackbarth 2026-01-09 20:01:55 UTC
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.
Comment 4 Paul Floyd 2026-01-12 07:44:03 UTC
I'll take a look at the code. Maybe we can use fstat to tell that the fd is not a regular file.