RFR: 8307990: jspawnhelper must close its writing side of a pipe before reading from it

Volker Simonis simonis at openjdk.org
Thu Jun 1 11:00:22 UTC 2023


On Fri, 19 May 2023 15:43:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>>> Sorry, but I don't understand this argument. If we do a short read we will work with corrupted ChildStuff and SpawnInfo 
>>> structures. This can in the extreme case execute arbitrary code (e.g. if ChildStuff.argv is not fully read from the parent). You are 
>>> basically saying it is better to work on corrupted data rather than reporting an error.
>> 
>> No I am simply pointing out that this has changed more than just the issue with close. And maybe a short-read does indicate data "corruption" and maybe it should be a fatal error. But I don't know exactly how this might manifest so perhaps there are benign short-reads that actually do happen. Regardless it might be better to split this part out and focus on the close issue here.
>
>> > Sorry, but I don't understand this argument. If we do a short read we will work with corrupted ChildStuff and SpawnInfo
>> > structures. This can in the extreme case execute arbitrary code (e.g. if ChildStuff.argv is not fully read from the parent). You are
>> > basically saying it is better to work on corrupted data rather than reporting an error.
>> 
>> No I am simply pointing out that this has changed more than just the issue with close. And maybe a short-read does indicate data "corruption" and maybe it should be a fatal error. But I don't know exactly how this might manifest so perhaps there are benign short-reads that actually do happen. Regardless it might be better to split this part out and focus on the close issue here.
> 
> Given the purpose and implementation of the `readFully` function, I don't see how it can return anything other than an error or the full requested read length.

Thanks @RogerRiggs and @tstuefe for your help and patience with this PR. I've now updated the [Release Note](https://bugs.openjdk.org/browse/JDK-8308297) for this change to also include the error scenario described by @mlichtblau .

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

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1571822491


More information about the core-libs-dev mailing list