On Tue, 12 Nov 2024 23:34:48 GMT, Shaojin Wen wrote:
>> In the JDK code, there are some places that may cause Unsafe offset
>> overflow. The probability of occurrence is low, but if it occurs, it will
>> cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additi
On Tue, 12 Nov 2024 23:34:48 GMT, Shaojin Wen wrote:
>> In the JDK code, there are some places that may cause Unsafe offset
>> overflow. The probability of occurrence is low, but if it occurs, it will
>> cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additi
On Tue, 12 Nov 2024 23:52:35 GMT, Laurence Cable wrote:
> t is not feasible to introspect on the target process to determine if
it is a JVM or not, this is the best case not to send SIGQUIT to a
process that is neither catching nor blocking it, where the default is
to terminate it!
Even if the t
I should also note that on other *nix'es (where there is no /proc to
introspect) the default behavior is simply to send the QUIT regardless.
In the case of Linux, this addition obviates the chance of an attach
killing the target should it not be catching QUIT!
On 11/12/24 3:45 PM, Laurence C
On 11/12/24 3:33 PM, Serguei Spitsyn wrote:
On Thu, 7 Nov 2024 04:48:28 GMT, Serguei Spitsyn wrote:
Larry Cable has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8342449: fixed missing param in throws msg and renamed local var
src/jdk.
> In the JDK code, there are some places that may cause Unsafe offset overflow.
> The probability of occurrence is low, but if it occurs, it will cause JVM
> crash.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
Update src/java.base
On Thu, 7 Nov 2024 04:48:28 GMT, Serguei Spitsyn wrote:
>> Larry Cable has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> JDK-8342449: fixed missing param in throws msg and renamed local var
>
> src/jdk.attach/linux/classes/sun/tools/attach
On Tue, 12 Nov 2024 20:39:55 GMT, Larry Cable wrote:
>> the implementation I originally provided does not in fact solve the issue!
>>
>> the attach protocol initiation "handshake" requires that the "attacher" (the
>> caller of this code) and the "attachee"(the target JVM to be "attached" to)
>
On Tue, 12 Nov 2024 19:41:50 GMT, Severin Gehwolf wrote:
>> Sergey Chernyshev 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
>>
On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and locals that trigger the
>> u
> the implementation I originally provided does not in fact solve the issue!
>
> the attach protocol initiation "handshake" requires that the "attacher" (the
> caller of this code) and the "attachee"(the target JVM to be "attached" to)
> *must* share a "/tmp" (or access to the attachee's `cwd`)
On Tue, 5 Nov 2024 00:42:23 GMT, Alex Menkov wrote:
> The fix adds correct handling of "could not open pipe" errors in attach
> listener instead of assert which causes target VM crash.
>
> testing: tier1,tier2,hs-tier5-svc
This pull request has now been integrated.
Changeset: a4e2c208
Author:
On Tue, 12 Nov 2024 14:59:41 GMT, Sergey Chernyshev
wrote:
> > The JBS issue doesn't mention `NullPointerException`. It would be good to
> > list the observed NPE issue.
>
> Example for NPE:
>
> ```
> public class Test {
> public static void main(String[] args) {
> java.lang.manag
On Fri, 8 Nov 2024 19:07:34 GMT, Archie Cobbs wrote:
>> Please review this patch which removes unnecessary `@SuppressWarnings`
>> annotations.
>
> Archie Cobbs has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the unrelated changes
> Cgroup V1 subsustem fails to initialize mounted controllers properly in
> certain cases, that may lead to controllers left undetected/inactive. We
> observed the behavior in CloudFoundry deployments, it affects also host
> systems.
>
> The relevant /proc/self/mountinfo line is
>
>
> 2207 21
On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> system
On Tue, 12 Nov 2024 19:09:54 GMT, Sergey Chernyshev
wrote:
> > Edit: Yet, cg v2 will get into trouble since there, for example on rootless
> > podman on cg v2 you'd end up with this instead:
> > ```
> > [0.008s][trace][os,container] OSContainer::init: Initializing Container
> > Support
> > [0.
On Mon, 11 Nov 2024 10:23:02 GMT, Severin Gehwolf wrote:
> The JBS issue doesn't mention `NullPointerException`. It would be good to
> list the observed NPE issue.
Example for NPE:
public class Test {
public static void main(String[] args) {
java.lang.management.ManagementFactory.
On Fri, 8 Nov 2024 15:20:00 GMT, Nizar Benalla wrote:
> Can I please get a review for this PR that add tests to verify the value of
> `@since` tags to the Serviceability area modules. The test is described in
> this
> [email](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html)
On Tue, 12 Nov 2024 16:30:12 GMT, Shaojin Wen wrote:
>> In the JDK code, there are some places that may cause Unsafe offset
>> overflow. The probability of occurrence is low, but if it occurs, it will
>> cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additi
On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> system
On Tue, 12 Nov 2024 18:54:30 GMT, Chris Plummer wrote:
>> Archie Cobbs 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 five additional
>> commit
On Fri, 8 Nov 2024 19:07:34 GMT, Archie Cobbs wrote:
>> Please review this patch which removes unnecessary `@SuppressWarnings`
>> annotations.
>
> Archie Cobbs has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the unrelated changes
On Fri, 8 Nov 2024 15:20:00 GMT, Nizar Benalla wrote:
> Can I please get a review for this PR that add tests to verify the value of
> `@since` tags to the Serviceability area modules. The test is described in
> this
> [email](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html)
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote:
> This is the implementation of JEP 486: Permanently Disable the Security
> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
> main change
On Tue, 12 Nov 2024 16:30:12 GMT, Shaojin Wen wrote:
>> In the JDK code, there are some places that may cause Unsafe offset
>> overflow. The probability of occurrence is low, but if it occurs, it will
>> cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additi
On Tue, 12 Nov 2024 16:37:28 GMT, Shaojin Wen wrote:
> @liach provided a new idea, which is to change the type of
> jdk.internal.misc.Unsafe.ARRAY_XXX_OFFSET from int to long. I think @liach's
> idea is better, that is the way to completely solve this problem.
I discussed this briefly with him
On Tue, 12 Nov 2024 16:30:12 GMT, Shaojin Wen wrote:
>> In the JDK code, there are some places that may cause Unsafe offset
>> overflow. The probability of occurrence is low, but if it occurs, it will
>> cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additi
On Tue, 12 Nov 2024 14:44:55 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
> In the JDK code, there are some places that may cause Unsafe offset overflow.
> The probability of occurrence is low, but if it occurs, it will cause JVM
> crash.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
fix copyright
-
On Tue, 12 Nov 2024 15:54:00 GMT, Shaojin Wen wrote:
>> In the JDK code, there are some places that may cause Unsafe offset
>> overflow. The probability of occurrence is low, but if it occurs, it will
>> cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additi
On Tue, 12 Nov 2024 12:10:07 GMT, Alan Bateman wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> rename address to offset, from @AlanBateman
>
> Marked as reviewed by alanb (Reviewer).
> @AlanBateman @minborg Sorry,
On Tue, 12 Nov 2024 14:44:55 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Tue, 12 Nov 2024 14:44:55 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Tue, 12 Nov 2024 14:44:55 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Tue, 12 Nov 2024 12:10:07 GMT, Alan Bateman wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> rename address to offset, from @AlanBateman
>
> Marked as reviewed by alanb (Reviewer).
@AlanBateman @minborg
Sorry, a
> In the JDK code, there are some places that may cause Unsafe offset overflow.
> The probability of occurrence is low, but if it occurs, it will cause JVM
> crash.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
more fix unsafe addr
On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo
wrote:
> This is the implementation of JEP 491: Synchronize Virtual Threads without
> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
> further details.
>
> In order to make the code review easier the changes hav
On Tue, 12 Nov 2024 15:02:12 GMT, Sean Mullan wrote:
>> I can add it back if it is more convenient and readable to have the `@see`
>> tag.
>
> This can be taken care of later after integration.
Agreed!
-
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1838282
On Tue, 12 Nov 2024 02:59:59 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the change
On Fri, 1 Nov 2024 19:40:03 GMT, Alexey Ivanov wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 200 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>> - Modify three RMI t
On Thu, 24 Oct 2024 17:03:25 GMT, Alexey Ivanov wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 150 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>> - Merge
>> - Updat
On Fri, 8 Nov 2024 18:31:13 GMT, Harshitha Onkar wrote:
>> It has a value… when it's mentioned with `@see`, the link is present in the
>> *See Also* section, as you can see in the the specification of
>> [`MouseInfo.getPointerInfo()`](https://docs.oracle.com/en/java/javase/21/docs/api/java.desk
On Tue, 12 Nov 2024 14:44:55 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Tue, 12 Nov 2024 14:44:55 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
> This is the implementation of JEP 486: Permanently Disable the Security
> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
> main changes in the JEP and also includes an apidiff of the specif
On Tue, 12 Nov 2024 13:01:33 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Tue, 12 Nov 2024 12:18:03 GMT, Per Minborg wrote:
> I want to add such a test case, but I am worried that it will consume too
> many resources during the build process.
>
> ```java
> /**
> * @test
> * @bug 8343984
> * @summary Test that the append capacity is close to Integer.MaxValue
>
On Tue, 12 Nov 2024 13:01:33 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Tue, 12 Nov 2024 11:24:24 GMT, Shaojin Wen wrote:
>> In the JDK code, there are some places that may cause Unsafe offset
>> overflow. The probability of occurrence is low, but if it occurs, it will
>> cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additi
> This is the implementation of JEP 486: Permanently Disable the Security
> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
> main changes in the JEP and also includes an apidiff of the specif
On Tue, 12 Nov 2024 11:24:24 GMT, Shaojin Wen wrote:
>> In the JDK code, there are some places that may cause Unsafe offset
>> overflow. The probability of occurrence is low, but if it occurs, it will
>> cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additi
On Tue, 12 Nov 2024 11:24:24 GMT, Shaojin Wen wrote:
>> In the JDK code, there are some places that may cause Unsafe offset
>> overflow. The probability of occurrence is low, but if it occurs, it will
>> cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additi
On Tue, 12 Nov 2024 11:24:24 GMT, Shaojin Wen wrote:
>> In the JDK code, there are some places that may cause Unsafe offset
>> overflow. The probability of occurrence is low, but if it occurs, it will
>> cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additi
On Tue, 12 Nov 2024 11:24:24 GMT, Shaojin Wen wrote:
>> In the JDK code, there are some places that may cause Unsafe offset
>> overflow. The probability of occurrence is low, but if it occurs, it will
>> cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additi
> In the JDK code, there are some places that may cause Unsafe offset overflow.
> The probability of occurrence is low, but if it occurs, it will cause JVM
> crash.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
rename address to of
On Mon, 11 Nov 2024 11:06:17 GMT, Kevin Walls wrote:
> Test timeout change to cope with -Xcomp runs.
> Long-standing problemlisted test.
>
> With -Xcomp locally I could see a failure on the second attempt.
> After this change, ran more runs locally and 40 runs per platform in CI are
> OK.
This
On Tue, 12 Nov 2024 02:59:59 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the change
> In the JDK code, there are some places that may cause Unsafe offset overflow.
> The probability of occurrence is low, but if it occurs, it will cause JVM
> crash.
Shaojin Wen has updated the pull request incrementally with two additional
commits since the last revision:
- re gen-src
- rena
> In the JDK code, there are some places that may cause Unsafe offset overflow.
> The probability of occurrence is low, but if it occurs, it will cause JVM
> crash.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
from @minborg
-
On Mon, 11 Nov 2024 18:28:11 GMT, Sergey Chernyshev
wrote:
> > So on cg v1 you start out and end with a `subsystem_path() == null` and on
> > cg v2 you start out and end with a `subsystem_path() ==
> > /../../../../../../test`. In both cases the memory limit of 400m won't be
> > detected.
>
On Tue, 12 Nov 2024 08:59:30 GMT, Shaojin Wen wrote:
>> In the JDK code, there are some places that may cause Unsafe offset
>> overflow. The probability of occurrence is low, but if it occurs, it will
>> cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additi
On Tue, 12 Nov 2024 08:59:30 GMT, Shaojin Wen wrote:
>> In the JDK code, there are some places that may cause Unsafe offset
>> overflow. The probability of occurrence is low, but if it occurs, it will
>> cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additi
On Tue, 12 Nov 2024 08:26:44 GMT, Shaojin Wen wrote:
>> In the JDK code, there are some places that may cause Unsafe offset
>> overflow. The probability of occurrence is low, but if it occurs, it will
>> cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additi
On Tue, 12 Nov 2024 08:15:33 GMT, Per Minborg wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> revert, from @minborg
>
> src/java.base/share/classes/sun/nio/cs/StringUTF16.java line 35:
>
>> 33: public static ch
> In the JDK code, there are some places that may cause Unsafe offset overflow.
> The probability of occurrence is low, but if it occurs, it will cause JVM
> crash.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
revert, from @minbor
On Tue, 12 Nov 2024 07:30:41 GMT, Shaojin Wen wrote:
> In the JDK code, there are some places that may cause Unsafe offset overflow.
> The probability of occurrence is low, but if it occurs, it will cause JVM
> crash.
src/java.base/share/classes/sun/nio/cs/StringUTF16.java line 35:
> 33:
67 matches
Mail list logo
