RFR: 8371587: Final mapping lost in ProcSmapsParser::parse_next [v2]

[Francesco Andreuzzi]

On Mon, 24 Nov 2025 14:29:41 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> A simple fix for off-by-one error in parsing `smaps` -- the final mapping is never recorded as we exits the parsing loop too early.
>> 
>> The spec of `parse_next` is updated to reflects what its caller expects. The newly added gtest fails without this path.
>> 
>> 
>> Test: tier1
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - copyright-header
>  - review
>  - Merge branch 'master' into smap-parser
>  - smap-parser

When `fgets` fails due to an error, it returns `nullptr` so `read_line` (L119) will return `false`. If a mapping was parsed, `parse_next` returns `true`. The next call to `parse_next` will start with this check:
https://github.com/openjdk/jdk/blob/c179ccd5b4a06f94ebec44ed1d75e7339f40e383/src/hotspot/os/linux/procMapsParser.cpp#L110-L114

But according to the [docs](https://en.cppreference.com/w/c/io/fgets) for `fgets`, the content of the buffer will be indeterminate at this point (since the last call failed due to an error). If any rubbish happens to be there, we won't even call `read_line` and we'll just try to `scan_header_line`, which is probably not the correct behavior.

Am I missing something?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28225#issuecomment-3589025841