Hi,
What's the status of Project Brisbane? According to [1], the Project
was approved two month ago on April 4th, but until now I can't find it
listed on openjdk.org nor can I find a corresponding mailing list?
Best regards,
Volker
[1] https://mail.openjdk.org/pipermail/announce/2024-April/00035
I can't find a link to the bug that has been filed with Apple in the
issue https://bugs.openjdk.org/browse/JDK-8282954.
Can somebody please post the link to corresponding Apple issue here
and/or update JDK-8282954 with that information?
Thanks,
Volker
On Mon, Oct 17, 2022 at 10:49 AM Alan Batema
commented on that JBS issue with the Apple bug id - it's FB9997771.
>
> -Jaikiran
>
> On 17/10/22 2:24 pm, Volker Simonis wrote:
> > I can't find a link to the bug that has been filed with Apple in the
> > issue https://bugs.openjdk.org/browse/JDK-8282954.
> >
On Wed, 2 Nov 2022 20:42:42 GMT, Lance Andersen wrote:
>> Hi all,
>>
>> This PR will update the javadoc to clarify the existing behavior of
>> InflaterInputStream::fill as it currently omits the possibility that a
>> EOFException may be thrown and that the protected `len` field is also
>> upd
Prior to
[JDK-8239384](https://bugs.openjdk.org/browse/JDK-8239384)/[JDK-8238358](https://bugs.openjdk.org/browse/JDK-8238358)
LambdaMetaFactory has created VM-anonymous classes which could easily be
unloaded once they were not referenced any more. Starting with JDK 15 and the
new "hidden class
On Thu, 9 Feb 2023 15:45:35 GMT, Jorn Vernee wrote:
>> Prior to
>> [JDK-8239384](https://bugs.openjdk.org/browse/JDK-8239384)/[JDK-8238358](https://bugs.openjdk.org/browse/JDK-8238358)
>> LambdaMetaFactory has created VM-anonymous classes which could easily be
>> unloaded once they were not re
On Thu, 9 Feb 2023 15:47:31 GMT, Jorn Vernee wrote:
> Your analysis in the JBS issue seems reasonable, but I'll wait for Mandy to
> respond here.
>
> I looked at the original PR and don't see a discussion of `STRONG` there, but
> I very vaguely remember it being talked about as being needed to
nt potential OOMs and fix the regression compared
> the JDK 14 and earlier I propose to create these hidden classes without the
> `STRONG` option.
>
> I'll be happy to add the test case as JTreg test to this PR if you think that
> would be useful.
Volker Simonis has update
On Fri, 10 Feb 2023 17:29:37 GMT, Ioi Lam wrote:
>> Volker Simonis has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove assertions which insist on Lambda proxy classes being strongly
>> linked to th
On Thu, 9 Feb 2023 18:11:18 GMT, Volker Simonis wrote:
>> Prior to
>> [JDK-8239384](https://bugs.openjdk.org/browse/JDK-8239384)/[JDK-8238358](https://bugs.openjdk.org/browse/JDK-8238358)
>> LambdaMetaFactory has created VM-anonymous classes which could easily be
>>
On Fri, 17 Feb 2023 21:21:56 GMT, Jorn Vernee wrote:
> > (because they are all not referenced from the program any more).
>
> So, it sounds like this is testing a case where
> `LambdaMetafactory.metafactory` is being called directly?
>
> I'd like to point out that, while I buy that people are
On Sat, 18 Feb 2023 01:55:52 GMT, Mandy Chung wrote:
> > Finally, the PR fixes a regression compared to the JDK 11 behavior.
>
> This is an intended change that improves the C heap memory usage. In
> addition, the spec of `LambdaMetafactory` has no guarantee of the spinned
> classes be unloade
On Thu, 9 Feb 2023 18:11:18 GMT, Volker Simonis wrote:
>> Prior to
>> [JDK-8239384](https://bugs.openjdk.org/browse/JDK-8239384)/[JDK-8238358](https://bugs.openjdk.org/browse/JDK-8238358)
>> LambdaMetaFactory has created VM-anonymous classes which could easily be
>>
On Tue, 21 Feb 2023 19:49:24 GMT, Coleen Phillimore wrote:
> The reason that non-strongly linked classes have their own ClassLoaderData is
> because it implements the property that when the class loader is no longer
> loaded, metadata for it can be removed at once. Even though Metaspace has
>
On Tue, 21 Feb 2023 23:44:48 GMT, David Holmes wrote:
> I also have to disagree with the statement. The unit of unloading is the
> ClassLoader.
Hidden classes are not normal classes. They are not defined, created or loaded
by a class loader. The only reason why hidden classes maintain a link t
On Wed, 22 Feb 2023 13:38:57 GMT, Volker Simonis wrote:
>> I also have to disagree with the statement. The unit of unloading is the
>> ClassLoader.
>
>> I also have to disagree with the statement. The unit of unloading is the
>> ClassLoader.
>
> Hidden classes
On Wed, 19 Apr 2023 13:57:43 GMT, Aleksey Shipilev wrote:
> Someone^W I did commit a test in the OpenJDK repo that has Amazon copyright
> notice in the form that is not inline with the preferred one (intentionally
> without copyright year):
>
> "Copyright Amazon.com Inc. or its affiliates. All
On Wed, 19 Apr 2023 13:57:43 GMT, Aleksey Shipilev wrote:
> Someone^W I did commit a test in the OpenJDK repo that has Amazon copyright
> notice in the form that is not inline with the preferred one (intentionally
> without copyright year):
>
> "Copyright Amazon.com Inc. or its affiliates. All
This issue was reported by: Yakov Shafranovich
([yako...@amazon.com](mailto:yako...@amazon.com))
Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a
negative array length in the deserialization stream. Instead it calls
`j.l.r.Array::newInstance(..)` with the negative le
On Wed, 19 Apr 2023 17:04:07 GMT, Joe Darcy wrote:
>> This issue was reported by: Yakov Shafranovich
>> ([yako...@amazon.com](mailto:yako...@amazon.com))
>>
>> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a
>> negative array length in the deserialization stream. I
On Wed, 19 Apr 2023 19:05:49 GMT, Andrey Turbanov wrote:
>> This issue was reported by: Yakov Shafranovich
>> ([yako...@amazon.com](mailto:yako...@amazon.com))
>>
>> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a
>> negative array length in the deserialization str
On Thu, 20 Apr 2023 10:57:30 GMT, Aleksey Shipilev wrote:
>> This issue was reported by: Yakov Shafranovich
>> ([yako...@amazon.com](mailto:yako...@amazon.com))
>>
>> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a
>> negative array length in the deserialization st
On Thu, 20 Apr 2023 18:44:54 GMT, Roger Riggs wrote:
>> src/java.base/share/classes/java/io/ObjectInputStream.java line 2142:
>>
>>> 2140: int len = bin.readInt();
>>> 2141: if (len < 0) {
>>> 2142: throw new InvalidClassException(desc.getName(), "Array
>>> length <
On Thu, 20 Apr 2023 18:53:53 GMT, Roger Riggs wrote:
>> This issue was reported by: Yakov Shafranovich
>> ([yako...@amazon.com](mailto:yako...@amazon.com))
>>
>> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a
>> negative array length in the deserialization stream.
On Thu, 20 Apr 2023 11:41:24 GMT, Aleksey Shipilev wrote:
>> This issue was reported by: Yakov Shafranovich
>> ([yako...@amazon.com](mailto:yako...@amazon.com))
>>
>> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a
>> negative array length in the deserialization st
On Thu, 20 Apr 2023 11:42:51 GMT, Aleksey Shipilev wrote:
>> This issue was reported by: Yakov Shafranovich
>> ([yako...@amazon.com](mailto:yako...@amazon.com))
>>
>> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a
>> negative array length in the deserialization st
On Thu, 20 Apr 2023 11:58:50 GMT, Aleksey Shipilev wrote:
>> This issue was reported by: Yakov Shafranovich
>> ([yako...@amazon.com](mailto:yako...@amazon.com))
>>
>> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a
>> negative array length in the deserialization st
On Wed, 19 Apr 2023 16:47:33 GMT, Volker Simonis wrote:
> This issue was reported by: Yakov Shafranovich
> ([yako...@amazon.com](mailto:yako...@amazon.com))
>
> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a
> negative array length in the de
jectInputFilter.FilterInfo::arrayLength()` which is defined as:
>
> Returns:
> the non-negative number of array elements when deserializing an array of the
> class, otherwise -1
>
> but currently returns a negative value if the array length is negative.
Volker Simonis has u
jectInputFilter.FilterInfo::arrayLength()` which is defined as:
>
> Returns:
> the non-negative number of array elements when deserializing an array of the
> class, otherwise -1
>
> but currently returns a negative value if the array length is negative.
Volker Simonis has
On Tue, 25 Apr 2023 21:01:04 GMT, Roger Riggs wrote:
>> test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 88:
>>
>>> 86: } catch (ObjectStreamException ose) {
>>> 87: // OK, because a NegativeArraySizeException should be
>>> converted into a ObjectStreamExce
On Mon, 24 Apr 2023 15:58:49 GMT, Aleksey Shipilev wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Addresed review comments of @turbanoff, @shipilev and @RogerRiggs
>
> test
On Wed, 26 Apr 2023 12:47:47 GMT, Roger Riggs wrote:
>> Volker Simonis 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 contai
On Thu, 27 Apr 2023 17:05:24 GMT, Amit Kumar wrote:
>> DeInflate.java test fails on s390x platform because size for out1 array
>> which is responsible for storing the compressed data is insufficient. And
>> being unable to write whole compressed data on array, on s390 whole data
>> can't be re
On Fri, 28 Apr 2023 09:08:18 GMT, Amit Kumar wrote:
>> DeInflate.java test fails on s390x platform because size for out1 array
>> which is responsible for storing the compressed data is insufficient. And
>> being unable to write whole compressed data on array, on s390 whole data
>> can't be re
On Fri, 28 Apr 2023 09:23:59 GMT, Amit Kumar wrote:
>> DeInflate.java test fails on s390x platform because size for out1 array
>> which is responsible for storing the compressed data is insufficient. And
>> being unable to write whole compressed data on array, on s390 whole data
>> can't be re
On Fri, 28 Apr 2023 09:26:52 GMT, Volker Simonis wrote:
>> Amit Kumar has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> suggestion from @simonis
>
> test/jdk/java/util/zip/DeInflate.java line 16
On Fri, 28 Apr 2023 11:18:56 GMT, Amit Kumar wrote:
>> DeInflate.java test fails on s390x platform because size for out1 array
>> which is responsible for storing the compressed data is insufficient. And
>> being unable to write whole compressed data on array, on s390 whole data
>> can't be re
jectInputFilter.FilterInfo::arrayLength()` which is defined as:
>
> Returns:
> the non-negative number of array elements when deserializing an array of the
> class, otherwise -1
>
> but currently returns a negative value if the array length is negative.
Volker Simonis has u
On Thu, 27 Apr 2023 21:24:04 GMT, Roger Riggs wrote:
>> Volker Simonis 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 contai
On Tue, 2 May 2023 15:52:03 GMT, Roger Riggs wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Throw StreamCorruptedException instead of InvalidClassException and handle
>> negative
jectInputFilter.FilterInfo::arrayLength()` which is defined as:
>
> Returns:
> the non-negative number of array elements when deserializing an array of the
> class, otherwise -1
>
> but currently returns a negative value if the array length is negative.
Volker Simonis has u
On Tue, 2 May 2023 16:06:50 GMT, Aleksey Shipilev wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Throw StreamCorruptedException instead of InvalidClassException and handle
>> neg
jectInputFilter.FilterInfo::arrayLength()` which is defined as:
>
> Returns:
> the non-negative number of array elements when deserializing an array of the
> class, otherwise -1
>
> but currently returns a negative value if the array length is negative.
Volker Simonis has u
On Tue, 2 May 2023 16:59:00 GMT, Aleksey Shipilev wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Throw StreamCorruptedException instead of InvalidClassException and handle
>> neg
On Tue, 2 May 2023 18:02:41 GMT, Volker Simonis wrote:
>> This issue was reported by: Yakov Shafranovich
>> ([yako...@amazon.com](mailto:yako...@amazon.com))
>>
>> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a
>> negative
On Wed, 19 Apr 2023 16:47:33 GMT, Volker Simonis wrote:
> This issue was reported by: Yakov Shafranovich
> ([yako...@amazon.com](mailto:yako...@amazon.com))
>
> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a
> negative array length in the de
Since JDK13, executing commands in a sub-process defaults to the so called
`POSIX_SPAWN` launching mechanism (i.e.
`-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using
`posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper`
in a subprocess. In a
On Fri, 12 May 2023 21:37:36 GMT, Roger Riggs wrote:
> Looks ok.
>
> Is it practical to write a test for this situation? Can I assume you've
> validated the improvement as a remedy for the observed hangs?
I thought about a test but couldn't come up with a practical way to write it.
The JVM ha
On Sun, 14 May 2023 17:28:33 GMT, Thomas Stuefe wrote:
> Trying to understand this, and the scope of the problem:
>
> * Parent process opens "in" pipe.
>
> * Now owns read and write end of pipe.
>
> * Parent forks jspawnhelper.
>
> * jspawnhelper inherits handles. Now there ar
On Fri, 12 May 2023 12:47:28 GMT, Jaikiran Pai wrote:
> Can I please get a review of this test only change which addresses the issue
> noted in https://bugs.openjdk.org/browse/JDK-8307403?
>
> When we recently did a change in https://bugs.openjdk.org/browse/JDK-8299748,
> there was a oversight
On Fri, 12 May 2023 15:24:19 GMT, Volker Simonis wrote:
> Since JDK13, executing commands in a sub-process defaults to the so called
> `POSIX_SPAWN` launching mechanism (i.e.
> `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by
> using `posix_spawn(3)` to f
On Fri, 12 May 2023 15:24:19 GMT, Volker Simonis wrote:
> Since JDK13, executing commands in a sub-process defaults to the so called
> `POSIX_SPAWN` launching mechanism (i.e.
> `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by
> using `posix_spawn(3)` to f
On Mon, 15 May 2023 16:31:38 GMT, Thomas Stuefe wrote:
> The fact that this error is in there since JDK 13 is scary.
The error is there since ten years since the `posix_spawn` mechanism was
initially introduced with
[JDK-5049299](https://bugs.openjdk.org/browse/JDK-5049299) for JDK 8 and
down
t; Also did some cleanup:
> - in `jspawnhelper.c` correctly chek the result of `readFully()`
> - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to
> write the command data from the parent process to `jspawnhelper`
> - in `childproc.{c,h}` remove remaining trace
On Tue, 16 May 2023 12:32:44 GMT, Thomas Stuefe wrote:
> > > > I wonder if @Martin-Buchholz is able to look at this one?
> > > > My concern with changes like this is that they fix an issue but then
> > > > have unexpected side-effects themselves.
> > >
> > >
> > > Are there any specific concer
On Mon, 15 May 2023 18:45:24 GMT, Roger Riggs wrote:
>> Since JDK13, executing commands in a sub-process defaults to the so called
>> `POSIX_SPAWN` launching mechanism (i.e.
>> `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by
>> using `posix_spawn(3)` to firstly start
On Mon, 15 May 2023 20:00:28 GMT, Joe Darcy wrote:
> Should this issue have a CSR for any behavioral changes?
Well, you can certainly argue that every bug fix is a behavioral changes, right
:)
But seriously, I don't see how this PR could require a CSR. The only behavioral
change is really tha
On Mon, 15 May 2023 19:55:45 GMT, Bernd wrote:
> Independent of the actual fix, it was mentioned that it can block listening
> sockets, aren’t those close on exec? Also should a write and read timeout be
> used in addition? At least to call the close descriptor code before retrying?
While the
On Wed, 17 May 2023 14:55:00 GMT, Roger Riggs wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Added test case
>
> src/java.base/unix/native/libjava/childproc.c line 408:
>
t; Also did some cleanup:
> - in `jspawnhelper.c` correctly chek the result of `readFully()`
> - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to
> write the command data from the parent process to `jspawnhelper`
> - in `childproc.{c,h}` remove remaining trace
On Wed, 17 May 2023 13:46:29 GMT, Thomas Stuefe wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Added test case
>
> src/java.base/unix/native/jspawnhelper/jspawnhelper.c line 140:
On Wed, 17 May 2023 14:10:59 GMT, Thomas Stuefe wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Added test case
>
> src/java.base/unix/native/libjava/ProcessImpl_md.c line 490:
On Wed, 17 May 2023 14:42:45 GMT, Roger Riggs wrote:
> if parent process dies prematurely
@RogerRiggs , I've created a release note for the issue based on your
suggestions. Please feel free to proof-read and enhance it :)
-
PR Comment: https://git.openjdk.org/jdk/pull/13956#issuec
On Wed, 17 May 2023 17:08:34 GMT, Roger Riggs wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> REALLY adding the test :)
>
> test/jdk/java/lang/ProcessBuilder/JspawnhelperPro
On Wed, 17 May 2023 17:01:53 GMT, Roger Riggs wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> REALLY adding the test :)
>
> test/jdk/java/lang/ProcessBuilder/JspawnhelperP
On Wed, 17 May 2023 17:05:54 GMT, Roger Riggs wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> REALLY adding the test :)
>
> test/jdk/java/lang/ProcessBuilder/JspawnhelperP
On Wed, 17 May 2023 17:07:13 GMT, Roger Riggs wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> REALLY adding the test :)
>
> test/jdk/java/lang/ProcessBuilder/JspawnhelperPro
t; Also did some cleanup:
> - in `jspawnhelper.c` correctly chek the result of `readFully()`
> - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to
> write the command data from the parent process to `jspawnhelper`
> - in `childproc.{c,h}` remove remaining traces of
On Thu, 18 May 2023 05:58:26 GMT, Thomas Stuefe wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> REALLY adding the test :)
>
> src/java.base/unix/native/libjava/childproc.c line
On Wed, 17 May 2023 20:03:37 GMT, Joe Darcy wrote:
> > > Should this issue have a CSR for any behavioral changes?
> >
> >
> > Well, you can certainly argue that every bug fix is a behavioral changes,
> > right :)
> > But seriously, I don't see how this PR could require a CSR. The only
> > beh
On Mon, 22 May 2023 10:22:16 GMT, Volker Simonis wrote:
>> Since JDK13, executing commands in a sub-process defaults to the so called
>> `POSIX_SPAWN` launching mechanism (i.e.
>> `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by
>> using `po
On Fri, 19 May 2023 15:43:30 GMT, Roger Riggs 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 rea
On Tue, 23 May 2023 05:34:15 GMT, Thomas Stuefe wrote:
>> Volker Simonis has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains five commits:
>>
>> - Merge branch 'master' into JDK-8307990
>&
t; Also did some cleanup:
> - in `jspawnhelper.c` correctly chek the result of `readFully()`
> - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to
> write the command data from the parent process to `jspawnhelper`
> - in `childproc.{c,h}` remove remaining trace
t; Also did some cleanup:
> - in `jspawnhelper.c` correctly chek the result of `readFully()`
> - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to
> write the command data from the parent process to `jspawnhelper`
> - in `childproc.{c,h}` remove remaining trace
On Fri, 19 May 2023 15:43:30 GMT, Roger Riggs 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 rea
t; Also did some cleanup:
> - in `jspawnhelper.c` correctly chek the result of `readFully()`
> - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to
> write the command data from the parent process to `jspawnhelper`
> - in `childproc.{c,h}` remove remaining trace
On Thu, 25 May 2023 15:25:40 GMT, Volker Simonis wrote:
>> Since JDK13, executing commands in a sub-process defaults to the so called
>> `POSIX_SPAWN` launching mechanism (i.e.
>> `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by
>> using `po
On Mon, 9 May 2022 09:56:19 GMT, Volker Simonis wrote:
>> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)`
>> to highlight that it might write more bytes than the returned number of
>> inflated bytes into the buffer `b`.
>>
>> The s
On Tue, 28 Jun 2022 16:54:54 GMT, Roger Riggs wrote:
>> Changes the definition of `CollectorImpl` to be a record.
>
> Marked as reviewed by rriggs (Reviewer).
Hi @RogerRiggs,
Thanks for reviewing this PR. I have a more general question. Do we have any
recommendations about using new language f
point of view it is easy to artificially construct a program which violates
> `InflaterInputStream::read(..)`'s postcondition if using one of the
> alterantive zlib implementations. A recently integrated JTreg test
> (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unint
On Mon, 9 May 2022 09:56:19 GMT, Volker Simonis wrote:
>> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)`
>> to highlight that it might write more bytes than the returned number of
>> inflated bytes into the buffer `b`.
>>
>> The s
The problem is that after
[JDK-8281962](https://bugs.openjdk.org/browse/JDK-8292327) we call `fill()`
unconditionally (and before calling `Inflater::inflate()`) in
`InflaterInputStream::read()` if `Inflater::needsInput()` is true. This misses
the case where the native inflater has consumed all
On Mon, 15 Aug 2022 18:01:15 GMT, Alan Bateman wrote:
>> The problem is that after
>> [JDK-8281962](https://bugs.openjdk.org/browse/JDK-8292327) we call `fill()`
>> unconditionally (and before calling `Inflater::inflate()`) in
>> `InflaterInputStream::read()` if `Inflater::needsInput()` is tru
On Mon, 15 Aug 2022 18:34:17 GMT, Alan Bateman wrote:
>> The problem is that after
>> [JDK-8281962](https://bugs.openjdk.org/browse/JDK-8292327) we call `fill()`
>> unconditionally (and before calling `Inflater::inflate()`) in
>> `InflaterInputStream::read()` if `Inflater::needsInput()` is tru
On Mon, 15 Aug 2022 18:36:11 GMT, Alan Bateman wrote:
>> The problem is that after
>> [JDK-8281962](https://bugs.openjdk.org/browse/JDK-8292327) we call `fill()`
>> unconditionally (and before calling `Inflater::inflate()`) in
>> `InflaterInputStream::read()` if `Inflater::needsInput()` is tru
;
>> "If `inflate()` returns `Z_OK` and with zero `avail_out`, it must be called
>> again after making room in the output buffer because there might be more
>> output pending."
Volker Simonis has updated the pull request incrementally with one additional
commit since
On Tue, 16 Aug 2022 06:26:24 GMT, Alan Bateman wrote:
>> Not sure about this one? `fill()` is specified to throw an `IOException` and
>> `EOFException` is an `IOException`. It probably depends on how you interpret
>> the current "*if an I/O error has occurred*" description in the throws
>> sec
On Mon, 15 Aug 2022 20:23:16 GMT, Volker Simonis wrote:
>> The problem is that after
>> [JDK-8281962](https://bugs.openjdk.org/browse/JDK-8281962) we call `fill()`
>> unconditionally (and before calling `Inflater::inflate()`) in
>> `InflaterInputStream::read()` if `In
On Tue, 16 Aug 2022 09:41:07 GMT, Alan Bateman wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Minor changes regarding indentation, naming and spelling
>
> test/jdk/jav
;
>> "If `inflate()` returns `Z_OK` and with zero `avail_out`, it must be called
>> again after making room in the output buffer because there might be more
>> output pending."
Volker Simonis has updated the pull request incrementally with one additional
com
On Tue, 16 Aug 2022 11:25:03 GMT, Volker Simonis wrote:
>> test/jdk/java/util/zip/InflaterInputStream/UnexpectedEndOfZlibStream.java
>> line 48:
>>
>>> 46: };
>>> 47: String deflated = "@ObjectiveCName(\"DYNSApi\")\npacka
On Tue, 16 Aug 2022 09:53:54 GMT, Alan Bateman wrote:
>> I've updated the link in the description (sorry, copy-paste error) and
>> opened a [JBS issue for
>> `fill()`](https://bugs.openjdk.org/browse/JDK-8292427).
>>
>> What else is needed to push this to HEAD?
>>
>> And what do we want to do
On Tue, 16 Aug 2022 20:01:10 GMT, Lance Andersen wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Changed the payload to a more innocent version
>
> This looks OK Volker.
>
>
On Mon, 15 Aug 2022 17:43:27 GMT, Volker Simonis wrote:
> The problem is that after
> [JDK-8281962](https://bugs.openjdk.org/browse/JDK-8281962) we call `fill()`
> unconditionally (and before calling `Inflater::inflate()`) in
> `InflaterInputStream::read()` if `Inflater::needsInpu
point of view it is easy to artificially construct a program which violates
> `InflaterInputStream::read(..)`'s postcondition if using one of the
> alterantive zlib implementations. A recently integrated JTreg test
> (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unint
On Thu, 21 Jul 2022 17:45:39 GMT, Mark Reinhold wrote:
>> Volker Simonis has refreshed the contents of this pull request, and previous
>> commits have been removed. Incremental views are not available.
>
> First, I’ll observe that there is no specification conflict here. The
point of view it is easy to artificially construct a program which violates
> `InflaterInputStream::read(..)`'s postcondition if using one of the
> alterantive zlib implementations. A recently integrated JTreg test
> (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unint
On Wed, 31 Aug 2022 21:05:18 GMT, Joe Darcy wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Updated JavaDoc according to @mbreinhold's suggestions
>
> src/ja
1 - 100 of 160 matches
Mail list logo
