RFR: 8303942: FileMapInfo::write_bytes aborts on a short os::write
David Holmes
dholmes at openjdk.org
Mon Apr 3 09:18:56 UTC 2023
On Mon, 3 Apr 2023 08:05:34 GMT, Afshin Zafari <duke at openjdk.org> wrote:
>> src/hotspot/share/cds/filemap.cpp line 1767:
>>
>>> 1765: void FileMapInfo::write_bytes(const void* buffer, size_t nbytes) {
>>> 1766: assert(_file_open, "must be");
>>> 1767: ssize_t size = (ssize_t)nbytes;
>>
>> I'm very confused as to how the underlying OS `write` can take in an unsigned count of bytes to write, yet the actual count of what was written is signed and so cannot reflect the true count for large values! Can we at least assert here that size is > 0 ?
>
> Can this be the rationale for it?
> The return value can be `-1` so the type is `ssize_t`. And it is also large enough to hold the maximum bytes transfer of `write()`:
> From the [write() man page](https://man7.org/linux/man-pages/man2/write.2.html#:~:text=of%20bytes%20written.-,On%20Linux%2C,-write()%20(and%20similar))
>
> On Linux, write() (and similar system calls) will transfer at
> most 0x7ffff000 (2,147,479,552) bytes, returning the number of
> bytes actually transferred. (This is true on both 32-bit and
> 64-bit systems.)
Ah! That is not in the version of the manpage on my system. But the one you link also has:
> According to POSIX.1, if count is greater than SSIZE_MAX, the result is implementation-defined; see NOTES for the upper limit on Linux.
which explains things. Thanks.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/13188#discussion_r1155684008
More information about the hotspot-runtime-dev
mailing list