Fix process memory provider on Linux #1933
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem description
The process memory provider currently doesn't function correctly on Linux due to incorrect handling of the special procfs file
/proc/<pid>/maps
. I don't know if some of this behavior could vary by distro and/or kernel version, but I've observed the following issues in my Ubuntu 24.04 environment.file.readString()
which attempts to determine the size of the file by seeking to the end. However, procfs files don't have a defined size, so this fails with a return of -1. libwolv interprets this as the file size and attempts to allocate an enormous buffer, which results in an exception, so ultimately the process memory provider is unusable on the current code.readString
with a fixed maximum size of0xF'FFFF
. This avoids the seek issue, but when working with special files, a singleread
call isn't guaranteed to read the requested number of bytes even if that many bytes are available. In practice, on my machine, this call only ever reads the first few dozen lines of the file. So the feature works in this version, but it's unable to see the vast majority of the process' address space.maps
file that have a filename, the filenames are visually aligned by padding spaces between the inode column and filename column. ImHex includes these spaces as part of the filename, resulting in most of the path being pushed out of the visible area of the window.Implementation description
maps
file is read, I've changed the code to read from the file in a loop until we stop getting data. I've also set a fixed limit on the maximum number of bytes to read in one go to avoid issues with trying to determine the file size.trim
call to remove any padding around the filename.Screenshots
Exception in
file.readString()
in current code (for some reason this also causes the window to become transparent):Abridged memory region list in 1.35.4:
Complete memory region list after this PR:
Additional things
I was focused on fixing this ImHex feature here, but I wonder if some of this should be addressed in libwolv. Maybe
readBuffer
in file_unix.cpp should read in a loop until it has the requested number of bytes or encounters EOF/error?