From sspitsyn at openjdk.org  Wed Feb  1 00:00:59 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 1 Feb 2023 00:00:59 GMT
Subject: jmx-dev [jdk20] RFR: 8299891: JMX ObjectInputFilter additional
 classes needed [v3]
In-Reply-To: <PFSKFfXoQq5HBrGAcoZWHtQ5iM915Opp-pQoWkTNoeA=.85a93461-9cc8-46c7-bcd4-0119b16a91bc@github.com>
References: <h4CeVFsM2p0D4FwjcVnNKQfbVZEIYs_Asq8vwMW5frY=.f14d64ce-253c-4908-a8d5-5040cdcf3459@github.com>
 <PFSKFfXoQq5HBrGAcoZWHtQ5iM915Opp-pQoWkTNoeA=.85a93461-9cc8-46c7-bcd4-0119b16a91bc@github.com>
Message-ID: <-J-a_66vQS4h2q-xWRfdBiPyUO95jOkPdg1HVNR-2LQ=.fe3e2707-9132-4f75-a3f9-2e2d9b7f9466@github.com>

On Tue, 31 Jan 2023 14:29:38 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The default setting for the ObjectInputFilter for JMX, introduced in jdk20, is too restrictive.
>> javax.management.Attribute and AttributeList classes are also needed, and Query related classes.
>> 
>> There are a number of Query-related classes, so adding javax.management.* is appropriate otherwise the list becomes hard to manage.  This is a * and not a ** which would mean all subpackages, so the openmean subpackage stays in the list.
>
> Kevin Walls has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Test additional print, and comment edit
>  - properties comment and formatting
>  - Print in getNotificationInfo

Thank you for the update, Kevin!
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/97

From kevinw at openjdk.org  Wed Feb  1 09:05:02 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 1 Feb 2023 09:05:02 GMT
Subject: jmx-dev [jdk20] RFR: 8299891: JMX ObjectInputFilter additional
 classes needed [v3]
In-Reply-To: <PFSKFfXoQq5HBrGAcoZWHtQ5iM915Opp-pQoWkTNoeA=.85a93461-9cc8-46c7-bcd4-0119b16a91bc@github.com>
References: <h4CeVFsM2p0D4FwjcVnNKQfbVZEIYs_Asq8vwMW5frY=.f14d64ce-253c-4908-a8d5-5040cdcf3459@github.com>
 <PFSKFfXoQq5HBrGAcoZWHtQ5iM915Opp-pQoWkTNoeA=.85a93461-9cc8-46c7-bcd4-0119b16a91bc@github.com>
Message-ID: <6nfH7bI5HvpnWpmw_vd1tq__S__pOhSpDF1tH5Of4ug=.d5e303af-a616-4337-8784-6f40fd0d3a1a@github.com>

On Tue, 31 Jan 2023 14:29:38 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The default setting for the ObjectInputFilter for JMX, introduced in jdk20, is too restrictive.
>> javax.management.Attribute and AttributeList classes are also needed, and Query related classes.
>> 
>> There are a number of Query-related classes, so adding javax.management.* is appropriate otherwise the list becomes hard to manage.  This is a * and not a ** which would mean all subpackages, so the openmean subpackage stays in the list.
>
> Kevin Walls has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Test additional print, and comment edit
>  - properties comment and formatting
>  - Print in getNotificationInfo

Thanks for the suggestions and reviews, will integrate.

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

PR: https://git.openjdk.org/jdk20/pull/97

From kevinw at openjdk.org  Wed Feb  1 09:18:04 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 1 Feb 2023 09:18:04 GMT
Subject: jmx-dev [jdk20] Integrated: 8299891: JMX ObjectInputFilter
 additional classes needed
In-Reply-To: <h4CeVFsM2p0D4FwjcVnNKQfbVZEIYs_Asq8vwMW5frY=.f14d64ce-253c-4908-a8d5-5040cdcf3459@github.com>
References: <h4CeVFsM2p0D4FwjcVnNKQfbVZEIYs_Asq8vwMW5frY=.f14d64ce-253c-4908-a8d5-5040cdcf3459@github.com>
Message-ID: <5zBtoPQqwjbHQqYHfI2jUGOYZ9jbMrk2Z9u9d53GQnM=.f9c16acb-04de-48c2-95e5-d7507d7a444c@github.com>

On Wed, 11 Jan 2023 09:40:11 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> The default setting for the ObjectInputFilter for JMX, introduced in jdk20, is too restrictive.
> javax.management.Attribute and AttributeList classes are also needed, and Query related classes.
> 
> There are a number of Query-related classes, so adding javax.management.* is appropriate otherwise the list becomes hard to manage.  This is a * and not a ** which would mean all subpackages, so the openmean subpackage stays in the list.

This pull request has now been integrated.

Changeset: 225f8053
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/225f80532cbeb1597c7f5d660e67d4fa4248c83f
Stats:     158 lines in 2 files changed: 145 ins; 0 del; 13 mod

8299891: JMX ObjectInputFilter additional classes needed

Reviewed-by: dfuchs, sspitsyn, cjplummer

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

PR: https://git.openjdk.org/jdk20/pull/97

From jwilhelm at openjdk.org  Wed Feb  1 20:10:46 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 1 Feb 2023 20:10:46 GMT
Subject: jmx-dev RFR: Merge jdk20
Message-ID: <uECVXFD4DaiFB8oJ8sMqMnncDYZTXZSlJ0qpvN_nVao=.0ca72a0b-5528-46f8-9876-690dda3313c3@github.com>

Forwardport JDK 20 -> JDK 21

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

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8298377: JfrVframeStream causes deadlocks in ZGC
 - 8299891: JMX ObjectInputFilter additional classes needed

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk/pull/12374/files
  Stats: 158 lines in 2 files changed: 145 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/12374.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12374/head:pull/12374

PR: https://git.openjdk.org/jdk/pull/12374

From jwilhelm at openjdk.org  Wed Feb  1 22:39:33 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 1 Feb 2023 22:39:33 GMT
Subject: jmx-dev Integrated: Merge jdk20
In-Reply-To: <uECVXFD4DaiFB8oJ8sMqMnncDYZTXZSlJ0qpvN_nVao=.0ca72a0b-5528-46f8-9876-690dda3313c3@github.com>
References: <uECVXFD4DaiFB8oJ8sMqMnncDYZTXZSlJ0qpvN_nVao=.0ca72a0b-5528-46f8-9876-690dda3313c3@github.com>
Message-ID: <m1huL7ABF-nuCXMUMXLb430DmlrwcReSTLks1lVGkno=.ee42b0b4-ac46-4039-82ae-eb409e58bf58@github.com>

On Wed, 1 Feb 2023 19:43:51 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: d6832121
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d6832121b718d40df263da6e2f9261dee2c4c508
Stats:     158 lines in 2 files changed: 145 ins; 0 del; 13 mod

Merge

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

PR: https://git.openjdk.org/jdk/pull/12374

From kevinw at openjdk.org  Mon Feb  6 17:34:52 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 6 Feb 2023 17:34:52 GMT
Subject: jmx-dev RFR: 8299739: HashedPasswordFileTest.java and
 ExceptionTest.java can fail with java.lang.NullPointerException
In-Reply-To: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
References: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
Message-ID: <KR_EOBTk8MwuALMQWC36f2gMZ8SE2APczad9Tx_Z_LU=.e30ae867-5e40-4770-ab50-650b2f430225@github.com>

On Fri, 6 Jan 2023 13:11:41 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Exceptions during setup of these tests could leave e.g. JMXConnector cs as null.
> But, we call cs.close() during a finally block and fail with an NPE, obscuring the real failure.
> We must only call close if this is not null.

Thanks Chris -
Actually yes the ExceptionTest failure is a little odd...

HashedPasswordFileTest more clearly doesn't show an Exception on the way to its finally clause that hits the NPE.

The CI failures where there's an NPE at ExceptionTest.java:126, do not include an earlier exception.  I see it would/should have been shown by the printThrowable at line 121.

Even looking at the full log, there is no earlier exception, so that is odd.   If cs is null, I don't see how there isn't an Exception at that point.  The newConnectorServer and JMXConnectorFactory.connect methods might give an IOException... but that should have been logged, so it's not clear how we get to that state.  (There are ExceptionTest failures in jdk11 and jdk19/panama, but they are the same test.)

There are other things that ExceptionTest should have printed if it had got a connection and made progress through the test, and we don't see them, so seems that we failed early on, probably at JMXConnectorFactory.connect(addr);

I checked and saw the printThrowable IS called if I make something get thrown in the test, and printThrowable IS being used to print the NPE in the failures, so those things do all work.

Having the NPE when we don't have a connection to close is still misleading, so I think we should check them for null.  If the connection failed with no Exception, it would hit a real NPE soon after which would be a useful message.  But I think more likely the connect does throw an Exception, but in those builds/runs it didn't get captured in the log for some unclear reason.  We should still fail correctly - if we are handling an Exception, even if our print was lost, we are throwing a RuntimeException, and with the finally block not throwing a new NPE, we should see that RuntimeException and have the test fail. 8-)

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

PR: https://git.openjdk.org/jdk/pull/11881

From amenkov at openjdk.org  Tue Feb  7 01:49:43 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 7 Feb 2023 01:49:43 GMT
Subject: jmx-dev RFR: 8299739: HashedPasswordFileTest.java and
 ExceptionTest.java can fail with java.lang.NullPointerException
In-Reply-To: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
References: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
Message-ID: <0pnKAw5nBEU23sx6LNQ9vqDpvHBZE8GX6tWFl0Lb0Io=.51a2b197-3050-441b-b0c2-a45b42a2bbeb@github.com>

On Fri, 6 Jan 2023 13:11:41 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Exceptions during setup of these tests could leave e.g. JMXConnector cs as null.
> But, we call cs.close() during a finally block and fail with an NPE, obscuring the real failure.
> We must only call close if this is not null.

ExceptionTest failure looks strange, but anyway we need the checks to avoid NPE on failures

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

Marked as reviewed by amenkov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11881

From amenkov at openjdk.org  Tue Feb  7 02:00:43 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 7 Feb 2023 02:00:43 GMT
Subject: jmx-dev RFR: 8299739: HashedPasswordFileTest.java and
 ExceptionTest.java can fail with java.lang.NullPointerException
In-Reply-To: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
References: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
Message-ID: <jpFfcft321u195bhJmtEFsX0tfkUvjUwl-P-OS5HoH8=.a7823f7c-9742-4ecd-a2d1-c98fac09313b@github.com>

On Fri, 6 Jan 2023 13:11:41 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Exceptions during setup of these tests could leave e.g. JMXConnector cs as null.
> But, we call cs.close() during a finally block and fail with an NPE, obscuring the real failure.
> We must only call close if this is not null.

My only guess is ExceptionTest failed with some Error, so catch (Exception) didn't catch it

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

PR: https://git.openjdk.org/jdk/pull/11881

From cjplummer at openjdk.org  Tue Feb  7 19:47:26 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 7 Feb 2023 19:47:26 GMT
Subject: jmx-dev RFR: 8299739: HashedPasswordFileTest.java and
 ExceptionTest.java can fail with java.lang.NullPointerException
In-Reply-To: <jpFfcft321u195bhJmtEFsX0tfkUvjUwl-P-OS5HoH8=.a7823f7c-9742-4ecd-a2d1-c98fac09313b@github.com>
References: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
 <jpFfcft321u195bhJmtEFsX0tfkUvjUwl-P-OS5HoH8=.a7823f7c-9742-4ecd-a2d1-c98fac09313b@github.com>
Message-ID: <WXFVUbPaEP8vVEzCvgJQkzCk5fDH4T27vHiK_w2ZtSM=.001c92c7-b7b0-408d-bb3e-f1a4c6e4c333@github.com>

On Tue, 7 Feb 2023 01:58:15 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> My only guess is ExceptionTest failed with some Error, so catch (Exception) didn't catch it

Yes, that makes sense. Kevin, can you try changing this to catch Throwable and see if you can get the initial exception printed?

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

PR: https://git.openjdk.org/jdk/pull/11881

From kevinw at openjdk.org  Wed Feb  8 12:28:31 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 8 Feb 2023 12:28:31 GMT
Subject: jmx-dev RFR: 8302069:
 javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java
 update
Message-ID: <cUHkFe8QZAUzzoMFF9AXNwCnnnYgarzYp2n98CclU_U=.29382486-f376-4429-8891-1d774714a461@github.com>

NotifReconnectDeadlockTest.java has been problemlisted for a long time (although 8042215 is the wrong bug id).

The originally reported problem ("No reconnection happened") cannot be reproduced, although there are occasional failures when the test is run.

Those failures are more like the connection failures fixed in similar tests (e.g. JDK-8227337), where:
java.rmi.NoSuchObjectException: no such object in table
..is reported, a startup issue, before the notification work, a failure to connect:
at java.management/javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
at NotifReconnectDeadlockTest.main(NotifReconnectDeadlockTest.java:88)

We should do something similar here, but not such that it affects the deadlock timing.  Increase serverTimeout, it needs a longer timeout to permit the initial connect to work reliably (fails occasionally, particularly but not exclusively on Windows debug builds).  Not using the test library timeout scaling here as the timeout has to be kept fairly short, to let the test intentionally block the notification handler and try to cause the original issue.

Additional prints to make the test logs hopefully easier to follow, and tried to clarify a few comments that made no sense to me.

Passing on many runs on all platforms.

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

Commit messages:
 - 8042596: javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java No reconnection happened

Changes: https://git.openjdk.org/jdk/pull/12472/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12472&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302069
  Stats: 16 lines in 2 files changed: 6 ins; 2 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/12472.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12472/head:pull/12472

PR: https://git.openjdk.org/jdk/pull/12472

From kevinw at openjdk.org  Wed Feb  8 13:07:42 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 8 Feb 2023 13:07:42 GMT
Subject: jmx-dev RFR: 8299739: HashedPasswordFileTest.java and
 ExceptionTest.java can fail with java.lang.NullPointerException
In-Reply-To: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
References: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
Message-ID: <AiPFYMsaqZh4WydM9A1iGIKeiItyU1yDEPXANXjE6xc=.080facc6-4346-4bf4-ab27-8d79f5863cfd@github.com>

On Fri, 6 Jan 2023 13:11:41 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Exceptions during setup of these tests could leave e.g. JMXConnector cs as null.
> But, we call cs.close() during a finally block and fail with an NPE, obscuring the real failure.
> We must only call close if this is not null.

Yes, that's exactly what's happening...
The NPEs on the connection stop us seeing an earlier Error from e.g. the connection attempt, and an NPE is reported as the reason for the test failure.

If I add a "throw new OutOfMemoryError" before it makes the connection, then that is not seen with the original version, just the misleading NPE on the cleanup attempt in the finally block.

With the new null checks, that OutOfMemoryError is reported by the test harness as the reason for the test failure (JavaTest Message: Test threw exception: java.lang.OutOfMemoryError).  This seems like the kind of Error the test harness should be reporting for us (I don't think the test should necessarily catch Throwable/Error, but it should be well-behaved in its finally).

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

PR: https://git.openjdk.org/jdk/pull/11881

From cjplummer at openjdk.org  Wed Feb  8 20:25:44 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 8 Feb 2023 20:25:44 GMT
Subject: jmx-dev RFR: 8299739: HashedPasswordFileTest.java and
 ExceptionTest.java can fail with java.lang.NullPointerException
In-Reply-To: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
References: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
Message-ID: <HMtu4_XECp9l6qpiecEquY09AqNo6DbMTNL9aqgSivI=.3c4159e9-e793-424e-83dc-a04e96720fb1@github.com>

On Fri, 6 Jan 2023 13:11:41 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Exceptions during setup of these tests could leave e.g. JMXConnector cs as null.
> But, we call cs.close() during a finally block and fail with an NPE, obscuring the real failure.
> We must only call close if this is not null.

Marked as reviewed by cjplummer (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11881

From cjplummer at openjdk.org  Wed Feb  8 21:40:43 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 8 Feb 2023 21:40:43 GMT
Subject: jmx-dev RFR: 8302069:
 javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java
 update
In-Reply-To: <cUHkFe8QZAUzzoMFF9AXNwCnnnYgarzYp2n98CclU_U=.29382486-f376-4429-8891-1d774714a461@github.com>
References: <cUHkFe8QZAUzzoMFF9AXNwCnnnYgarzYp2n98CclU_U=.29382486-f376-4429-8891-1d774714a461@github.com>
Message-ID: <iVsUgWjYS6wgYdQHml8YlajJsZLq9eanO25M-q6KaQY=.0ec88b7d-59f4-4758-9533-cd6be7a59bd0@github.com>

On Wed, 8 Feb 2023 11:57:21 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> NotifReconnectDeadlockTest.java has been problemlisted for a long time (although 8042215 is the wrong bug id).
> 
> The originally reported problem ("No reconnection happened") cannot be reproduced, although there are occasional failures when the test is run.
> 
> Those failures are more like the connection failures fixed in similar tests (e.g. JDK-8227337), where:
> java.rmi.NoSuchObjectException: no such object in table
> ..is reported, a startup issue, before the notification work, a failure to connect:
> at java.management/javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
> at NotifReconnectDeadlockTest.main(NotifReconnectDeadlockTest.java:88)
> 
> We should do something similar here, but not such that it affects the deadlock timing.  Increase serverTimeout, it needs a longer timeout to permit the initial connect to work reliably (fails occasionally, particularly but not exclusively on Windows debug builds).  Not using the test library timeout scaling here as the timeout has to be kept fairly short, to let the test intentionally block the notification handler and try to cause the original issue.
> 
> Additional prints to make the test logs hopefully easier to follow, and tried to clarify a few comments that made no sense to me.
> 
> Passing on many runs on all platforms.

Marked as reviewed by cjplummer (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12472

From kevinw at openjdk.org  Thu Feb  9 09:30:44 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 9 Feb 2023 09:30:44 GMT
Subject: jmx-dev RFR: 8299739: HashedPasswordFileTest.java and
 ExceptionTest.java can fail with java.lang.NullPointerException
In-Reply-To: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
References: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
Message-ID: <HafzDWTbQddQOVpeJJJW1brnnAHpfXNmHfX3i5xmUGs=.2ced21d7-1e9e-496a-a747-2533b4764977@github.com>

On Fri, 6 Jan 2023 13:11:41 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Exceptions during setup of these tests could leave e.g. JMXConnector cs as null.
> But, we call cs.close() during a finally block and fail with an NPE, obscuring the real failure.
> We must only call close if this is not null.

Thanks for all the comments/reviews.

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

PR: https://git.openjdk.org/jdk/pull/11881

From kevinw at openjdk.org  Thu Feb  9 09:33:54 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 9 Feb 2023 09:33:54 GMT
Subject: jmx-dev Integrated: 8299739: HashedPasswordFileTest.java and
 ExceptionTest.java can fail with java.lang.NullPointerException
In-Reply-To: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
References: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
Message-ID: <mJ96BPcmVNrs8-xLecJKKEJuHEzgNH_Pk1bzV6ZJXp4=.b6b6b010-32b4-4133-b44b-9aad2f5ca403@github.com>

On Fri, 6 Jan 2023 13:11:41 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Exceptions during setup of these tests could leave e.g. JMXConnector cs as null.
> But, we call cs.close() during a finally block and fail with an NPE, obscuring the real failure.
> We must only call close if this is not null.

This pull request has now been integrated.

Changeset: 04f30185
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/04f30185e914c10c918d0eff1fb63fd96e1139fb
Stats:     18 lines in 2 files changed: 9 ins; 0 del; 9 mod

8299739: HashedPasswordFileTest.java and ExceptionTest.java can fail with java.lang.NullPointerException

Reviewed-by: sspitsyn, amenkov, cjplummer

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

PR: https://git.openjdk.org/jdk/pull/11881

From amenkov at openjdk.org  Thu Feb  9 21:42:43 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 9 Feb 2023 21:42:43 GMT
Subject: jmx-dev RFR: 8302069:
 javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java
 update
In-Reply-To: <cUHkFe8QZAUzzoMFF9AXNwCnnnYgarzYp2n98CclU_U=.29382486-f376-4429-8891-1d774714a461@github.com>
References: <cUHkFe8QZAUzzoMFF9AXNwCnnnYgarzYp2n98CclU_U=.29382486-f376-4429-8891-1d774714a461@github.com>
Message-ID: <W-7bnW8CcNqOiCyezQervI0szTNoY-wWgi8pn4dh16w=.1b60967d-1b71-4d95-abb6-d80d3f8ba804@github.com>

On Wed, 8 Feb 2023 11:57:21 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> NotifReconnectDeadlockTest.java has been problemlisted for a long time (although 8042215 is the wrong bug id).
> 
> The originally reported problem ("No reconnection happened") cannot be reproduced, although there are occasional failures when the test is run.
> 
> Those failures are more like the connection failures fixed in similar tests (e.g. JDK-8227337), where:
> java.rmi.NoSuchObjectException: no such object in table
> ..is reported, a startup issue, before the notification work, a failure to connect:
> at java.management/javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
> at NotifReconnectDeadlockTest.main(NotifReconnectDeadlockTest.java:88)
> 
> We should do something similar here, but not such that it affects the deadlock timing.  Increase serverTimeout, it needs a longer timeout to permit the initial connect to work reliably (fails occasionally, particularly but not exclusively on Windows debug builds).  Not using the test library timeout scaling here as the timeout has to be kept fairly short, to let the test intentionally block the notification handler and try to cause the original issue.
> 
> Additional prints to make the test logs hopefully easier to follow, and tried to clarify a few comments that made no sense to me.
> 
> Passing on many runs on all platforms.

Marked as reviewed by amenkov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12472

From kevinw at openjdk.org  Fri Feb 10 08:35:02 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 10 Feb 2023 08:35:02 GMT
Subject: jmx-dev RFR: 8302069:
 javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java
 update
In-Reply-To: <cUHkFe8QZAUzzoMFF9AXNwCnnnYgarzYp2n98CclU_U=.29382486-f376-4429-8891-1d774714a461@github.com>
References: <cUHkFe8QZAUzzoMFF9AXNwCnnnYgarzYp2n98CclU_U=.29382486-f376-4429-8891-1d774714a461@github.com>
Message-ID: <y6lontvhcfdcRvSHdeFJanVuMxJFnETR01MSavX7JpE=.48c4d8d6-ac6e-465b-9b00-f60d7417e4a6@github.com>

On Wed, 8 Feb 2023 11:57:21 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> NotifReconnectDeadlockTest.java has been problemlisted for a long time (although 8042215 is the wrong bug id).
> 
> The originally reported problem ("No reconnection happened") cannot be reproduced, although there are occasional failures when the test is run.
> 
> Those failures are more like the connection failures fixed in similar tests (e.g. JDK-8227337), where:
> java.rmi.NoSuchObjectException: no such object in table
> ..is reported, a startup issue, before the notification work, a failure to connect:
> at java.management/javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
> at NotifReconnectDeadlockTest.main(NotifReconnectDeadlockTest.java:88)
> 
> We should do something similar here, but not such that it affects the deadlock timing.  Increase serverTimeout, it needs a longer timeout to permit the initial connect to work reliably (fails occasionally, particularly but not exclusively on Windows debug builds).  Not using the test library timeout scaling here as the timeout has to be kept fairly short, to let the test intentionally block the notification handler and try to cause the original issue.
> 
> Additional prints to make the test logs hopefully easier to follow, and tried to clarify a few comments that made no sense to me.
> 
> Passing on many runs on all platforms.

Thanks!

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

PR: https://git.openjdk.org/jdk/pull/12472

From kevinw at openjdk.org  Fri Feb 10 08:35:04 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 10 Feb 2023 08:35:04 GMT
Subject: jmx-dev Integrated: 8302069:
 javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java
 update
In-Reply-To: <cUHkFe8QZAUzzoMFF9AXNwCnnnYgarzYp2n98CclU_U=.29382486-f376-4429-8891-1d774714a461@github.com>
References: <cUHkFe8QZAUzzoMFF9AXNwCnnnYgarzYp2n98CclU_U=.29382486-f376-4429-8891-1d774714a461@github.com>
Message-ID: <grKehVE5IxiuLuCTbOMmuCpZJjvWgLIdhH-Mw-ybHKk=.c24cbdc1-ddae-418c-b915-218bb3f1c046@github.com>

On Wed, 8 Feb 2023 11:57:21 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> NotifReconnectDeadlockTest.java has been problemlisted for a long time (although 8042215 is the wrong bug id).
> 
> The originally reported problem ("No reconnection happened") cannot be reproduced, although there are occasional failures when the test is run.
> 
> Those failures are more like the connection failures fixed in similar tests (e.g. JDK-8227337), where:
> java.rmi.NoSuchObjectException: no such object in table
> ..is reported, a startup issue, before the notification work, a failure to connect:
> at java.management/javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
> at NotifReconnectDeadlockTest.main(NotifReconnectDeadlockTest.java:88)
> 
> We should do something similar here, but not such that it affects the deadlock timing.  Increase serverTimeout, it needs a longer timeout to permit the initial connect to work reliably (fails occasionally, particularly but not exclusively on Windows debug builds).  Not using the test library timeout scaling here as the timeout has to be kept fairly short, to let the test intentionally block the notification handler and try to cause the original issue.
> 
> Additional prints to make the test logs hopefully easier to follow, and tried to clarify a few comments that made no sense to me.
> 
> Passing on many runs on all platforms.

This pull request has now been integrated.

Changeset: 1c7b09bc
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1c7b09bc23ac37f83b9043de35b71bea7e814da5
Stats:     16 lines in 2 files changed: 6 ins; 2 del; 8 mod

8302069: javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java update

Reviewed-by: cjplummer, amenkov

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

PR: https://git.openjdk.org/jdk/pull/12472

From xuelei at openjdk.org  Mon Feb 13 20:01:31 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 13 Feb 2023 20:01:31 GMT
Subject: jmx-dev RFR: 8301279: update for deprecated sprintf for
 management components
In-Reply-To: <GWoNgierf17aTWNajU0zV15VGoRNbh7rYHHG603jr2E=.6c03bfc9-2456-4981-8aaf-318e7b71466f@github.com>
References: <GWoNgierf17aTWNajU0zV15VGoRNbh7rYHHG603jr2E=.6c03bfc9-2456-4981-8aaf-318e7b71466f@github.com>
Message-ID: <A3fAEnJuDfZYg3jYzdKW5SMOGoz-dYx6BHLAzRiN_jg=.2db066fb-b95f-49be-ac88-e55e66859733@github.com>

On Fri, 27 Jan 2023 20:32:35 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in management components.

Ping .... an Reviewer reviewing is required.  Thanks!

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

PR: https://git.openjdk.org/jdk/pull/12266

From dholmes at openjdk.org  Tue Feb 14 02:55:47 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 14 Feb 2023 02:55:47 GMT
Subject: jmx-dev RFR: 8301279: update for deprecated sprintf for
 management components
In-Reply-To: <GWoNgierf17aTWNajU0zV15VGoRNbh7rYHHG603jr2E=.6c03bfc9-2456-4981-8aaf-318e7b71466f@github.com>
References: <GWoNgierf17aTWNajU0zV15VGoRNbh7rYHHG603jr2E=.6c03bfc9-2456-4981-8aaf-318e7b71466f@github.com>
Message-ID: <7JZfDcmDk4DxBzFugvlhPR5jUWSTpC6Wqo0jiPBlQFw=.bd5e3b72-6ead-4a27-9d98-f86295755075@github.com>

On Fri, 27 Jan 2023 20:32:35 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in management components.

Looks good. Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12266

From xuelei at openjdk.org  Tue Feb 14 15:39:35 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 14 Feb 2023 15:39:35 GMT
Subject: jmx-dev Integrated: 8301279: update for deprecated sprintf for
 management components
In-Reply-To: <GWoNgierf17aTWNajU0zV15VGoRNbh7rYHHG603jr2E=.6c03bfc9-2456-4981-8aaf-318e7b71466f@github.com>
References: <GWoNgierf17aTWNajU0zV15VGoRNbh7rYHHG603jr2E=.6c03bfc9-2456-4981-8aaf-318e7b71466f@github.com>
Message-ID: <Y3H9LwPuGQd9iMpV8O3CJxEShHetboCGb4EFvFliknY=.a6eb7235-a404-448b-8cec-2d0c7871b3f3@github.com>

On Fri, 27 Jan 2023 20:32:35 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in management components.

This pull request has now been integrated.

Changeset: ec901f28
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ec901f28c3fde1aa7cef0ea41fe8bc3896ad962e
Stats:     3 lines in 3 files changed: 0 ins; 0 del; 3 mod

8301279: update for deprecated sprintf for management components

Reviewed-by: kevinw, dholmes

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

PR: https://git.openjdk.org/jdk/pull/12266

From serb at openjdk.org  Thu Feb 23 10:18:50 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 23 Feb 2023 10:18:50 GMT
Subject: jmx-dev RFR: 8303102: jcmd: ManagementAgent.status truncates the
 text longer than O_BUFLEN
Message-ID: <n_Lo2CQw1S68JUjBypLTP5Ia5uJlf0KKfOU6ptMvrt8=.271ae232-9cf8-4d78-af9f-b4dd3bd16ea6@github.com>

Implementation of the "ManagementAgent.status" indirectly depends on the size of "O_BUFLEN".

The root cause is usage of [print_cr()](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/ostream.cpp#L153) which may [truncate](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/ostream.cpp#L101) the output.

The solution is similar to the [JDK-8263640](https://bugs.openjdk.org/browse/JDK-8263640). see discussion about that approach https://github.com/openjdk/jdk/pull/4616

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

Commit messages:
 - 8303102: jcmd: ManagementAgent.status truncates the text longer than O_BUFLEN

Changes: https://git.openjdk.org/jdk/pull/12724/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12724&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303102
  Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12724.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12724/head:pull/12724

PR: https://git.openjdk.org/jdk/pull/12724

From serb at openjdk.org  Thu Feb 23 10:18:52 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 23 Feb 2023 10:18:52 GMT
Subject: jmx-dev RFR: 8303102: jcmd: ManagementAgent.status truncates
 the text longer than O_BUFLEN
In-Reply-To: <n_Lo2CQw1S68JUjBypLTP5Ia5uJlf0KKfOU6ptMvrt8=.271ae232-9cf8-4d78-af9f-b4dd3bd16ea6@github.com>
References: <n_Lo2CQw1S68JUjBypLTP5Ia5uJlf0KKfOU6ptMvrt8=.271ae232-9cf8-4d78-af9f-b4dd3bd16ea6@github.com>
Message-ID: <oKWKdteAJI5Nbed-2O74cgYVHH_eZffBXu_oGlJKGbU=.dd5ebf5b-dc62-4e9a-8bac-a9c296803f22@github.com>

On Thu, 23 Feb 2023 05:16:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Implementation of the "ManagementAgent.status" indirectly depends on the size of "O_BUFLEN".
> 
> The root cause is usage of [print_cr()](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/ostream.cpp#L153) which may [truncate](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/ostream.cpp#L101) the output.
> 
> The solution is similar to the [JDK-8263640](https://bugs.openjdk.org/browse/JDK-8263640). see discussion about that approach https://github.com/openjdk/jdk/pull/4616

One tier1 test failure is unrelated to this patch, it is filed https://bugs.openjdk.org/browse/JDK-8303105

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

PR: https://git.openjdk.org/jdk/pull/12724

From dholmes at openjdk.org  Thu Feb 23 11:37:07 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 23 Feb 2023 11:37:07 GMT
Subject: jmx-dev RFR: 8303102: jcmd: ManagementAgent.status truncates
 the text longer than O_BUFLEN
In-Reply-To: <n_Lo2CQw1S68JUjBypLTP5Ia5uJlf0KKfOU6ptMvrt8=.271ae232-9cf8-4d78-af9f-b4dd3bd16ea6@github.com>
References: <n_Lo2CQw1S68JUjBypLTP5Ia5uJlf0KKfOU6ptMvrt8=.271ae232-9cf8-4d78-af9f-b4dd3bd16ea6@github.com>
Message-ID: <LIegOV5E5t1y2i_JbULrUJ2C_mIW22SK5wVQJmFycaI=.45ef21dc-4030-42d2-b90e-c8aa45625942@github.com>

On Thu, 23 Feb 2023 05:16:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Implementation of the "ManagementAgent.status" indirectly depends on the size of "O_BUFLEN".
> 
> The root cause is usage of [print_cr()](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/ostream.cpp#L153) which may [truncate](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/ostream.cpp#L101) the output.
> 
> The solution is similar to the [JDK-8263640](https://bugs.openjdk.org/browse/JDK-8263640). see discussion about that approach https://github.com/openjdk/jdk/pull/4616

Change seems reasonable. Can we get an actual regression test to verify this?

test/jdk/sun/management/jmxremote/startstop/JMXStatusTest.java line 36:

> 34: /**
> 35:  * @test
> 36:  * @bug 8023093 8138748 8142398 8303102

As this test doesn't explicitly test/check the issue in 8303102 I don't think it needs to belisted on the @bug line. (And if it does then the copyright year needs t be updated too).

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

PR: https://git.openjdk.org/jdk/pull/12724

From serb at openjdk.org  Thu Feb 23 17:06:59 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 23 Feb 2023 17:06:59 GMT
Subject: jmx-dev RFR: 8303102: jcmd: ManagementAgent.status truncates
 the text longer than O_BUFLEN [v2]
In-Reply-To: <n_Lo2CQw1S68JUjBypLTP5Ia5uJlf0KKfOU6ptMvrt8=.271ae232-9cf8-4d78-af9f-b4dd3bd16ea6@github.com>
References: <n_Lo2CQw1S68JUjBypLTP5Ia5uJlf0KKfOU6ptMvrt8=.271ae232-9cf8-4d78-af9f-b4dd3bd16ea6@github.com>
Message-ID: <dgdAK_yce5DgEamcWoiiDKJXn2pDRZ9jpTgmDfKaDxA=.c476d3c5-b782-44b8-8913-9940b86cf407@github.com>

> Implementation of the "ManagementAgent.status" indirectly depends on the size of "O_BUFLEN".
> 
> The root cause is usage of [print_cr()](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/ostream.cpp#L153) which may [truncate](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/ostream.cpp#L101) the output.
> 
> The solution is similar to the [JDK-8263640](https://bugs.openjdk.org/browse/JDK-8263640). see discussion about that approach https://github.com/openjdk/jdk/pull/4616

Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:

  Update JMXStatusTest.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12724/files
  - new: https://git.openjdk.org/jdk/pull/12724/files/23422bc0..99aef33c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12724&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12724&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12724.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12724/head:pull/12724

PR: https://git.openjdk.org/jdk/pull/12724

From serb at openjdk.org  Thu Feb 23 17:07:02 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 23 Feb 2023 17:07:02 GMT
Subject: jmx-dev RFR: 8303102: jcmd: ManagementAgent.status truncates
 the text longer than O_BUFLEN [v2]
In-Reply-To: <LIegOV5E5t1y2i_JbULrUJ2C_mIW22SK5wVQJmFycaI=.45ef21dc-4030-42d2-b90e-c8aa45625942@github.com>
References: <n_Lo2CQw1S68JUjBypLTP5Ia5uJlf0KKfOU6ptMvrt8=.271ae232-9cf8-4d78-af9f-b4dd3bd16ea6@github.com>
 <LIegOV5E5t1y2i_JbULrUJ2C_mIW22SK5wVQJmFycaI=.45ef21dc-4030-42d2-b90e-c8aa45625942@github.com>
Message-ID: <TdzOEtbVMkYst-mV0IpCy1rGwA3vVND9clKw6_MUbAc=.029251af-536b-4191-8620-f7efcb868ab1@github.com>

On Thu, 23 Feb 2023 11:34:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update JMXStatusTest.java
>
> test/jdk/sun/management/jmxremote/startstop/JMXStatusTest.java line 36:
> 
>> 34: /**
>> 35:  * @test
>> 36:  * @bug 8023093 8138748 8142398 8303102
> 
> As this test doesn't explicitly test/check the issue in 8303102 I don't think it needs to belisted on the @bug line. (And if it does then the copyright year needs t be updated too).

I have found this issue by using this test on a host with long hostname, it does validate the output of the command and fails if it truncated.

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

PR: https://git.openjdk.org/jdk/pull/12724

From dholmes at openjdk.org  Sat Feb 25 03:11:10 2023
From: dholmes at openjdk.org (David Holmes)
Date: Sat, 25 Feb 2023 03:11:10 GMT
Subject: jmx-dev RFR: 8303102: jcmd: ManagementAgent.status truncates
 the text longer than O_BUFLEN [v2]
In-Reply-To: <dgdAK_yce5DgEamcWoiiDKJXn2pDRZ9jpTgmDfKaDxA=.c476d3c5-b782-44b8-8913-9940b86cf407@github.com>
References: <n_Lo2CQw1S68JUjBypLTP5Ia5uJlf0KKfOU6ptMvrt8=.271ae232-9cf8-4d78-af9f-b4dd3bd16ea6@github.com>
 <dgdAK_yce5DgEamcWoiiDKJXn2pDRZ9jpTgmDfKaDxA=.c476d3c5-b782-44b8-8913-9940b86cf407@github.com>
Message-ID: <SCVFc34vu-CJMM3SjYW5OXcbmeppgO4wJGzDAQ0N4do=.edc778ae-9f99-49e5-af80-7d68ad07c6fe@github.com>

On Thu, 23 Feb 2023 17:06:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Implementation of the "ManagementAgent.status" indirectly depends on the size of "O_BUFLEN".
>> 
>> The root cause is usage of [print_cr()](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/ostream.cpp#L153) which may [truncate](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/ostream.cpp#L101) the output.
>> 
>> The solution is similar to the [JDK-8263640](https://bugs.openjdk.org/browse/JDK-8263640). see discussion about that approach https://github.com/openjdk/jdk/pull/4616
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update JMXStatusTest.java

Marked as reviewed by dholmes (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12724

From serb at openjdk.org  Sun Feb 26 23:40:11 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 26 Feb 2023 23:40:11 GMT
Subject: jmx-dev Integrated: 8303102: jcmd: ManagementAgent.status truncates
 the text longer than O_BUFLEN
In-Reply-To: <n_Lo2CQw1S68JUjBypLTP5Ia5uJlf0KKfOU6ptMvrt8=.271ae232-9cf8-4d78-af9f-b4dd3bd16ea6@github.com>
References: <n_Lo2CQw1S68JUjBypLTP5Ia5uJlf0KKfOU6ptMvrt8=.271ae232-9cf8-4d78-af9f-b4dd3bd16ea6@github.com>
Message-ID: <SEUQjc_XVWtbv2xDmQolMPlAw_Ad40DN5rkO1S_QJSU=.63ded5a6-b5fd-43e8-a21e-a5dbbdb34a92@github.com>

On Thu, 23 Feb 2023 05:16:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Implementation of the "ManagementAgent.status" indirectly depends on the size of "O_BUFLEN".
> 
> The root cause is usage of [print_cr()](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/ostream.cpp#L153) which may [truncate](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/ostream.cpp#L101) the output.
> 
> The solution is similar to the [JDK-8263640](https://bugs.openjdk.org/browse/JDK-8263640). see discussion about that approach https://github.com/openjdk/jdk/pull/4616

This pull request has now been integrated.

Changeset: a43931b7
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a43931b79cb25d218e8f9b4d4f3a106f59cb2d37
Stats:     4 lines in 2 files changed: 1 ins; 0 del; 3 mod

8303102: jcmd: ManagementAgent.status truncates the text longer than O_BUFLEN

Reviewed-by: dholmes

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

PR: https://git.openjdk.org/jdk/pull/12724