In an out-of-tree build where the source code is in a read-only location
several gtests such as LogFileOutput.invalid_file_test_vm will fail
because they write files to the current working directory.
[ RUN ] LogFileOutput.invalid_file_test_vm
# To suppress the following error report, specify t
> On Sep 25, 2020, at 1:49 AM, Kim Barrett wrote:
>
> On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote:
>
>> Please review this small patch to enable the OSX build using Xcode 12.0.
>>
>> Thanks,
>> Paul
>
> […]
>
> I think changing the declaration for locs_buf to any of the following g
On Fri, 25 Sep 2020 05:46:08 GMT, Kim Barrett wrote:
>> Please review this small patch to enable the OSX build using Xcode 12.0.
>>
>> Thanks,
>> Paul
>
> No, don't do this. In the original, double is used to obtain the desired
> alignmnent. Changing the element type to short reduces the align
Hi.
I am trying to figure out if cve-2014-3566 cve-2014-6593 nad if yes -
starting from which build.
Alan Bateman pointed me to
https://openjdk.java.net/groups/vulnerability/advisories/. But it contains
only a list of fixed vulnerabilities, that were reported at 2019-2020 years.
I have found at htt
> On Sep 25, 2020, at 6:22 AM, Lutz Schmidt wrote:
>
> On Fri, 25 Sep 2020 05:46:08 GMT, Kim Barrett wrote:
>
> Another note, actually, it's more like a question:
> Has anyone had an eye on what happens in initialize_shared_locs(relocInfo*
> buf, int length)? To my understanding,
> "buf", whic
Hi Moshe,
On 25/09/2020 8:23 pm, Moshe Zuisman wrote:
Hi.
I am trying to figure out if cve-2014-3566 cve-2014-6593 nad if yes -
starting from which build.
This is not something that build-dev can help you with.
The best people to contact for this would be the Vulnerability group
that Alan re
Hi David. Do this Vulnerability group have some their own forum, mail list
or other place - they can be contacted?
пт, 25 сент. 2020 г. в 13:58, David Holmes :
> Hi Moshe,
>
> On 25/09/2020 8:23 pm, Moshe Zuisman wrote:
> > Hi.
> > I am trying to figure out if cve-2014-3566 cve-2014-6593 nad if
On Thu, 24 Sep 2020 15:15:45 GMT, Monica Beckwith wrote:
>> This is a continuation of
>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>>
>> Changes since then:
>> * We've improved the write barrier as suggested by Andrew [1]
>> * The define-guards around R18
> A few days ago I posted an initial version of the necessary configuration
> required to run pre-submit build and tests
> for JDK main-line contributions using GitHub Actions [2] and the free tier
> [3] available to everyone working with open
> source repositories. I've incorporated the feedback
On Wed, 23 Sep 2020 17:55:23 GMT, Robin Westberg wrote:
>> The version-numbers file (which is also a shared properties style file) is
>> not using quotes for values, which is fine
>> as long as there are no spaces. I believe if you read it as a properties
>> file, you need to strip the quotes i
On Fri, 25 Sep 2020 07:45:34 GMT, Nick Gasson wrote:
> In an out-of-tree build where the source code is in a read-only location
> several gtests such as LogFileOutput.invalid_file_test_vm will fail
> because they write files to the current working directory.
>
> [ RUN ] LogFileOutput.invalid_f
On Fri, 25 Sep 2020 13:10:01 GMT, Robin Westberg wrote:
>> A few days ago I posted an initial version of the necessary configuration
>> required to run pre-submit build and tests
>> for JDK main-line contributions using GitHub Actions [2] and the free tier
>> [3] available to everyone working w
On Fri, 25 Sep 2020 13:10:01 GMT, Robin Westberg wrote:
>> A few days ago I posted an initial version of the necessary configuration
>> required to run pre-submit build and tests
>> for JDK main-line contributions using GitHub Actions [2] and the free tier
>> [3] available to everyone working w
On 25/09/2020 10:28 pm, Moshe Zuisman wrote:
Hi David. Do this Vulnerability group have some their own forum, mail
list or other place - they can be contacted?
I assumed they did have but it seems not :(
https://openjdk.java.net/groups/vulnerability/
The only mailing list they have that you c
In AotCompiler.java, if artifact resolution fails, we have no way of diagnosing
the error. This patch improves the
default toString() of ArtifactResolverException to automatically include the
toString() method of the root cause. It
also adds stack trace printing specifically in AotCompiler.java.
> This patch is reorganized after 8252725, which is separated from this patch
> to refactor jlink glugin code. The previous
> webrev with hg can be found at:
> http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725
> integrated, the
> regeneration of holder classes is simply to c
> This patch is reorganized after 8252725, which is separated from this patch
> to refactor jlink glugin code. The previous
> webrev with hg can be found at:
> http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725
> integrated, the
> regeneration of holder classes is simply to c
> This patch is reorganized after 8252725, which is separated from this patch
> to refactor jlink glugin code. The previous
> webrev with hg can be found at:
> http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725
> integrated, the
> regeneration of holder classes is simply to c
On Fri, 25 Sep 2020 21:19:39 GMT, Yumin Qi wrote:
>> This patch is reorganized after 8252725, which is separated from this patch
>> to refactor jlink glugin code. The previous
>> webrev with hg can be found at:
>> http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725
>> integr
> This patch is reorganized after 8252725, which is separated from this patch
> to refactor jlink glugin code. The previous
> webrev with hg can be found at:
> http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725
> integrated, the
> regeneration of holder classes is simply to c
20 matches
Mail list logo
