Re: RFR(XS): 8058647, 8058649, 8058651, 8058652: ProblemList additions
Reviewed -JB- On 09/18/2014 02:32 PM, Mikael Auno wrote: Hi, Could I please have a review for these small additions to ProblemList.txt in jdk9? They are separate changes (jcheck didn't agree with the guidelines[1] about multiple fixes in a single changeset) with separate bug numbers, but it seems easier to have one review for them all. bug: https://bugs.openjdk.java.net/browse/JDK-8058647 bug: https://bugs.openjdk.java.net/browse/JDK-8058649 bug: https://bugs.openjdk.java.net/browse/JDK-8058651 bug: https://bugs.openjdk.java.net/browse/JDK-8058652 webrev: http://cr.openjdk.java.net/~miauno/8058647_8058649_8058651_8058652/webrev.00/ Thanks, Mikael [1] http://openjdk.java.net/guide/producingChangeset.html#changesetComment
Re: URGENT: RE: RFR(XS): 8057564: JVM hangs at getAgentProperties after attaching to VM with lower IntegrityLevel
Hi, This is new version of the patch. I hope last one. http://cr.openjdk.java.net/~sgabdura/8057564/webrev.03/ I also spent time on Sunday with that issue. I tried to find another solution, but did not succeed. All my attempts of applying of modified Security Descriptor to existing Named Pipe failed with error Access denied BR, Sergey On 22.09.2014 0:30, Markus Grönlund wrote: Hi again Sergey, I have spent some time in an attempt to figure out how we could accomplish this - I must say it has been quite frustrating. I was hoping we could only update the pSacl info with the SYSTEM_MANDATORY_LABEL_ACE field set to Medium. This is not straightforward. I have also tried to accomplish this by Windows impersonation, and updating the impersonation token - this works, but it requires quite a lot of infrastructure. In addition, if the thread is already impersonating, we need to restore the original token - and by setting the IntegrityLevel to Medium for the impersonation token one looses the SeImpersonatePrivilege which means I cannot do SetThreadToken() again for the original impersonation...messy. I then thought about using SDDL just as you have done, but only updating the Sacl info using SetSecurityInfo on the already created named pipe. This works, but it seems this triggered another issue (manifests as still hanging) - even though the integrity level is now set to Medium, the client have problem connecting (looks like this also requires easing up on the actual Discretionary ACL (just as you have done). So I ended up circling back to what you have in your second patch - if we are going to solve this proper, we need to spend quite a lot of time on it. I initially thought we should also state the Mandatory Label information in the SDDL, mainly for readability and rational purposes like: TCHAR *szSD = TEXT(D:) // Discretionary ACL TEXT((A;OICI;GRGW;;;WD)) // Allow read/write/execute to everybody TEXT((A;OICI;GA;;;SY))// Allow full control to system TEXT((A;OICI;GA;;;BA))// Allow full control to administrators TEXT(S:) // System ACL TEXT((ML;;NW;;;ME)); // Mandatory Integrity Label, No-WriteUp Policy, Medium Mandatory Level However, after some thought I changed my mind on this: Only Vista and later support the Mandatory Integrity Label, and if we include it we need to check conditionally. Somehow, the default when creating a securable object with you own Security Descriptor (instead of inheriting either the primary process or impersonation token) is that you default to Medium Mandatory Level (I don’t know if this just luck, but it seems to be that way, even for High Level process tokens). So to avoid conditional checks I suggest not including this: (S:) // System ACL TEXT((ML;;NW;;;ME)); // Mandatory Integrity Label, No-WriteUp Policy, Medium Mandatory Level Which is also what you already have in your patch. Maybe you could include a comment about the assumption that we expect to get Medium Mandatory Level by creating our own Security Descriptor? That way we can keep track of the rationale, and if MSFT changes this. I then just have one additional comment/change request: 291: LocalFree((sa.lpSecurityDescriptor)); This should be: 291: LocalFree(sa.lpSecurityDescriptor); With that change and some comment to the Medium Mandatory Level I am ok with your suggestion. Thanks a lot for fixing this. Many thanks Markus -Original Message- From: Markus Grönlund Sent: den 19 september 2014 14:46 To: Sergey Gabdurakhmanov Cc: Alexey Utkin; serviceability-dev@openjdk.java.net Subject: RE: URGENT: RE: RFR(XS): 8057564: JVM hangs at getAgentProperties after attaching to VM with lower IntegrityLevel Hi Sergey, This is not exactly what I had in mind - we have updated the DACL to provide some explicit security (from a NULL DACL which allows everyone everything), so that’s good. But.. I was hoping we could just keep the default security for the DACL (no need to change this, pass a NULL to CreateNamedPipe() is fine (will inherit process token)). Then we should just focus on manipulating the SidStart field in the SYSTEM_MANDATORY_LABEL_ACE structure in the SACL (not the DACL). Maybe you tried this already? Cheers Markus -Original Message- From: Sergey Gabdurakhmanov Sent: den 19 september 2014 14:34 To: Mattis Castegren; serviceability-dev@openjdk.java.net; Markus Grönlund; Staffan Larsen; Christian Törnqvist; Markus Grönlund; Alexey Utkin; Dmitry Samersoff Subject: Re: URGENT: RE: RFR(XS): 8057564: JVM hangs at getAgentProperties after attaching to VM with lower IntegrityLevel Hi, New version of the fix for review: http://cr.openjdk.java.net/~sgabdura/8057564/webrev.02/ Now I add security descriptor with read/write permissions to everybody and
RE: URGENT: RE: RFR(XS): 8057564: JVM hangs at getAgentProperties after attaching to VM with lower IntegrityLevel
Looks good. Minor nit: 265: // That will allow to connect to VM with Medium Integrity Level from VM with High Integrity Level. It's actually the other way around - the server creates the NamedPipe (at High Integrity Level) and the clients running in Medium Integrity Level attempt to connect. Therefore the NamedPipe must be created at Medium Integrity Level (which is the default when passing an explicit SD to the CreateNamedPipe call). You could change this to: 265: // In order to allow Medium Integrity Level clients to open and use a NamedPipe created by an High Integrity Level process. Thanks for fixing. You will also need a (R)eviewer for this as well, copying Staffan here as well. Thanks Markus -Original Message- From: Sergey Gabdurakhmanov Sent: den 22 september 2014 10:31 To: Markus Grönlund; Alexey Utkin; serviceability-dev@openjdk.java.net; SAMERSOFF,DMITRIY Cc: Mattis Castegren; Christian Tornqvist Subject: Re: URGENT: RE: RFR(XS): 8057564: JVM hangs at getAgentProperties after attaching to VM with lower IntegrityLevel Hi, This is new version of the patch. I hope last one. http://cr.openjdk.java.net/~sgabdura/8057564/webrev.03/ I also spent time on Sunday with that issue. I tried to find another solution, but did not succeed. All my attempts of applying of modified Security Descriptor to existing Named Pipe failed with error Access denied BR, Sergey On 22.09.2014 0:30, Markus Grönlund wrote: Hi again Sergey, I have spent some time in an attempt to figure out how we could accomplish this - I must say it has been quite frustrating. I was hoping we could only update the pSacl info with the SYSTEM_MANDATORY_LABEL_ACE field set to Medium. This is not straightforward. I have also tried to accomplish this by Windows impersonation, and updating the impersonation token - this works, but it requires quite a lot of infrastructure. In addition, if the thread is already impersonating, we need to restore the original token - and by setting the IntegrityLevel to Medium for the impersonation token one looses the SeImpersonatePrivilege which means I cannot do SetThreadToken() again for the original impersonation...messy. I then thought about using SDDL just as you have done, but only updating the Sacl info using SetSecurityInfo on the already created named pipe. This works, but it seems this triggered another issue (manifests as still hanging) - even though the integrity level is now set to Medium, the client have problem connecting (looks like this also requires easing up on the actual Discretionary ACL (just as you have done). So I ended up circling back to what you have in your second patch - if we are going to solve this proper, we need to spend quite a lot of time on it. I initially thought we should also state the Mandatory Label information in the SDDL, mainly for readability and rational purposes like: TCHAR *szSD = TEXT(D:) // Discretionary ACL TEXT((A;OICI;GRGW;;;WD)) // Allow read/write/execute to everybody TEXT((A;OICI;GA;;;SY))// Allow full control to system TEXT((A;OICI;GA;;;BA))// Allow full control to administrators TEXT(S:) // System ACL TEXT((ML;;NW;;;ME)); // Mandatory Integrity Label, No-WriteUp Policy, Medium Mandatory Level However, after some thought I changed my mind on this: Only Vista and later support the Mandatory Integrity Label, and if we include it we need to check conditionally. Somehow, the default when creating a securable object with you own Security Descriptor (instead of inheriting either the primary process or impersonation token) is that you default to Medium Mandatory Level (I don’t know if this just luck, but it seems to be that way, even for High Level process tokens). So to avoid conditional checks I suggest not including this: (S:) // System ACL TEXT((ML;;NW;;;ME)); // Mandatory Integrity Label, No-WriteUp Policy, Medium Mandatory Level Which is also what you already have in your patch. Maybe you could include a comment about the assumption that we expect to get Medium Mandatory Level by creating our own Security Descriptor? That way we can keep track of the rationale, and if MSFT changes this. I then just have one additional comment/change request: 291: LocalFree((sa.lpSecurityDescriptor)); This should be: 291: LocalFree(sa.lpSecurityDescriptor); With that change and some comment to the Medium Mandatory Level I am ok with your suggestion. Thanks a lot for fixing this. Many thanks Markus -Original Message- From: Markus Grönlund Sent: den 19 september 2014 14:46 To: Sergey Gabdurakhmanov Cc: Alexey Utkin; serviceability-dev@openjdk.java.net Subject: RE: URGENT: RE: RFR(XS): 8057564: JVM hangs at getAgentProperties after
Re: URGENT: RE: RFR(XS): 8057564: JVM hangs at getAgentProperties after attaching to VM with lower IntegrityLevel
Hi, I changed comment at line 265 and reduce line length. http://cr.openjdk.java.net/~sgabdura/8057564/webrev.04/ BR, Sergey On 22.09.2014 12:43, Markus Grönlund wrote: Looks good. Minor nit: 265: // That will allow to connect to VM with Medium Integrity Level from VM with High Integrity Level. It's actually the other way around - the server creates the NamedPipe (at High Integrity Level) and the clients running in Medium Integrity Level attempt to connect. Therefore the NamedPipe must be created at Medium Integrity Level (which is the default when passing an explicit SD to the CreateNamedPipe call). You could change this to: 265: // In order to allow Medium Integrity Level clients to open and use a NamedPipe created by an High Integrity Level process. Thanks for fixing. You will also need a (R)eviewer for this as well, copying Staffan here as well. Thanks Markus -Original Message- From: Sergey Gabdurakhmanov Sent: den 22 september 2014 10:31 To: Markus Grönlund; Alexey Utkin; serviceability-dev@openjdk.java.net; SAMERSOFF,DMITRIY Cc: Mattis Castegren; Christian Tornqvist Subject: Re: URGENT: RE: RFR(XS): 8057564: JVM hangs at getAgentProperties after attaching to VM with lower IntegrityLevel Hi, This is new version of the patch. I hope last one. http://cr.openjdk.java.net/~sgabdura/8057564/webrev.03/ I also spent time on Sunday with that issue. I tried to find another solution, but did not succeed. All my attempts of applying of modified Security Descriptor to existing Named Pipe failed with error Access denied BR, Sergey On 22.09.2014 0:30, Markus Grönlund wrote: Hi again Sergey, I have spent some time in an attempt to figure out how we could accomplish this - I must say it has been quite frustrating. I was hoping we could only update the pSacl info with the SYSTEM_MANDATORY_LABEL_ACE field set to Medium. This is not straightforward. I have also tried to accomplish this by Windows impersonation, and updating the impersonation token - this works, but it requires quite a lot of infrastructure. In addition, if the thread is already impersonating, we need to restore the original token - and by setting the IntegrityLevel to Medium for the impersonation token one looses the SeImpersonatePrivilege which means I cannot do SetThreadToken() again for the original impersonation...messy. I then thought about using SDDL just as you have done, but only updating the Sacl info using SetSecurityInfo on the already created named pipe. This works, but it seems this triggered another issue (manifests as still hanging) - even though the integrity level is now set to Medium, the client have problem connecting (looks like this also requires easing up on the actual Discretionary ACL (just as you have done). So I ended up circling back to what you have in your second patch - if we are going to solve this proper, we need to spend quite a lot of time on it. I initially thought we should also state the Mandatory Label information in the SDDL, mainly for readability and rational purposes like: TCHAR *szSD = TEXT(D:) // Discretionary ACL TEXT((A;OICI;GRGW;;;WD)) // Allow read/write/execute to everybody TEXT((A;OICI;GA;;;SY))// Allow full control to system TEXT((A;OICI;GA;;;BA))// Allow full control to administrators TEXT(S:) // System ACL TEXT((ML;;NW;;;ME)); // Mandatory Integrity Label, No-WriteUp Policy, Medium Mandatory Level However, after some thought I changed my mind on this: Only Vista and later support the Mandatory Integrity Label, and if we include it we need to check conditionally. Somehow, the default when creating a securable object with you own Security Descriptor (instead of inheriting either the primary process or impersonation token) is that you default to Medium Mandatory Level (I don’t know if this just luck, but it seems to be that way, even for High Level process tokens). So to avoid conditional checks I suggest not including this: (S:) // System ACL TEXT((ML;;NW;;;ME)); // Mandatory Integrity Label, No-WriteUp Policy, Medium Mandatory Level Which is also what you already have in your patch. Maybe you could include a comment about the assumption that we expect to get Medium Mandatory Level by creating our own Security Descriptor? That way we can keep track of the rationale, and if MSFT changes this. I then just have one additional comment/change request: 291: LocalFree((sa.lpSecurityDescriptor)); This should be: 291: LocalFree(sa.lpSecurityDescriptor); With that change and some comment to the Medium Mandatory Level I am ok with your suggestion. Thanks a lot for fixing this. Many thanks Markus -Original Message- From: Markus Grönlund Sent: den 19 september 2014 14:46 To: Sergey Gabdurakhmanov Cc: Alexey Utkin;
Re: URGENT: RE: RFR(XS): 8057564: JVM hangs at getAgentProperties after attaching to VM with lower IntegrityLevel
Looks good! Thanks, /Staffan On 22 sep 2014, at 10:54, Sergey Gabdurakhmanov sergey.gabdurakhma...@oracle.com wrote: Hi, I changed comment at line 265 and reduce line length. http://cr.openjdk.java.net/~sgabdura/8057564/webrev.04/ BR, Sergey On 22.09.2014 12:43, Markus Grönlund wrote: Looks good. Minor nit: 265: // That will allow to connect to VM with Medium Integrity Level from VM with High Integrity Level. It's actually the other way around - the server creates the NamedPipe (at High Integrity Level) and the clients running in Medium Integrity Level attempt to connect. Therefore the NamedPipe must be created at Medium Integrity Level (which is the default when passing an explicit SD to the CreateNamedPipe call). You could change this to: 265: // In order to allow Medium Integrity Level clients to open and use a NamedPipe created by an High Integrity Level process. Thanks for fixing. You will also need a (R)eviewer for this as well, copying Staffan here as well. Thanks Markus -Original Message- From: Sergey Gabdurakhmanov Sent: den 22 september 2014 10:31 To: Markus Grönlund; Alexey Utkin; serviceability-dev@openjdk.java.net; SAMERSOFF,DMITRIY Cc: Mattis Castegren; Christian Tornqvist Subject: Re: URGENT: RE: RFR(XS): 8057564: JVM hangs at getAgentProperties after attaching to VM with lower IntegrityLevel Hi, This is new version of the patch. I hope last one. http://cr.openjdk.java.net/~sgabdura/8057564/webrev.03/ I also spent time on Sunday with that issue. I tried to find another solution, but did not succeed. All my attempts of applying of modified Security Descriptor to existing Named Pipe failed with error Access denied BR, Sergey On 22.09.2014 0:30, Markus Grönlund wrote: Hi again Sergey, I have spent some time in an attempt to figure out how we could accomplish this - I must say it has been quite frustrating. I was hoping we could only update the pSacl info with the SYSTEM_MANDATORY_LABEL_ACE field set to Medium. This is not straightforward. I have also tried to accomplish this by Windows impersonation, and updating the impersonation token - this works, but it requires quite a lot of infrastructure. In addition, if the thread is already impersonating, we need to restore the original token - and by setting the IntegrityLevel to Medium for the impersonation token one looses the SeImpersonatePrivilege which means I cannot do SetThreadToken() again for the original impersonation...messy. I then thought about using SDDL just as you have done, but only updating the Sacl info using SetSecurityInfo on the already created named pipe. This works, but it seems this triggered another issue (manifests as still hanging) - even though the integrity level is now set to Medium, the client have problem connecting (looks like this also requires easing up on the actual Discretionary ACL (just as you have done). So I ended up circling back to what you have in your second patch - if we are going to solve this proper, we need to spend quite a lot of time on it. I initially thought we should also state the Mandatory Label information in the SDDL, mainly for readability and rational purposes like: TCHAR *szSD = TEXT(D:) // Discretionary ACL TEXT((A;OICI;GRGW;;;WD)) // Allow read/write/execute to everybody TEXT((A;OICI;GA;;;SY))// Allow full control to system TEXT((A;OICI;GA;;;BA))// Allow full control to administrators TEXT(S:) // System ACL TEXT((ML;;NW;;;ME)); // Mandatory Integrity Label, No-WriteUp Policy, Medium Mandatory Level However, after some thought I changed my mind on this: Only Vista and later support the Mandatory Integrity Label, and if we include it we need to check conditionally. Somehow, the default when creating a securable object with you own Security Descriptor (instead of inheriting either the primary process or impersonation token) is that you default to Medium Mandatory Level (I don’t know if this just luck, but it seems to be that way, even for High Level process tokens). So to avoid conditional checks I suggest not including this: (S:) // System ACL TEXT((ML;;NW;;;ME)); // Mandatory Integrity Label, No-WriteUp Policy, Medium Mandatory Level Which is also what you already have in your patch. Maybe you could include a comment about the assumption that we expect to get Medium Mandatory Level by creating our own Security Descriptor? That way we can keep track of the rationale, and if MSFT changes this. I then just have one additional comment/change request: 291: LocalFree((sa.lpSecurityDescriptor)); This should be: 291: LocalFree(sa.lpSecurityDescriptor); With that change and some comment
Re: URGENT: RE: RFR(XS): 8057564: JVM hangs at getAgentProperties after attaching to VM with lower IntegrityLevel
Looks good for me. -Dmitry On 2014-09-22 12:54, Sergey Gabdurakhmanov wrote: Hi, I changed comment at line 265 and reduce line length. http://cr.openjdk.java.net/~sgabdura/8057564/webrev.04/ BR, Sergey On 22.09.2014 12:43, Markus Grönlund wrote: Looks good. Minor nit: 265: // That will allow to connect to VM with Medium Integrity Level from VM with High Integrity Level. It's actually the other way around - the server creates the NamedPipe (at High Integrity Level) and the clients running in Medium Integrity Level attempt to connect. Therefore the NamedPipe must be created at Medium Integrity Level (which is the default when passing an explicit SD to the CreateNamedPipe call). You could change this to: 265: // In order to allow Medium Integrity Level clients to open and use a NamedPipe created by an High Integrity Level process. Thanks for fixing. You will also need a (R)eviewer for this as well, copying Staffan here as well. Thanks Markus -Original Message- From: Sergey Gabdurakhmanov Sent: den 22 september 2014 10:31 To: Markus Grönlund; Alexey Utkin; serviceability-dev@openjdk.java.net; SAMERSOFF,DMITRIY Cc: Mattis Castegren; Christian Tornqvist Subject: Re: URGENT: RE: RFR(XS): 8057564: JVM hangs at getAgentProperties after attaching to VM with lower IntegrityLevel Hi, This is new version of the patch. I hope last one. http://cr.openjdk.java.net/~sgabdura/8057564/webrev.03/ I also spent time on Sunday with that issue. I tried to find another solution, but did not succeed. All my attempts of applying of modified Security Descriptor to existing Named Pipe failed with error Access denied BR, Sergey On 22.09.2014 0:30, Markus Grönlund wrote: Hi again Sergey, I have spent some time in an attempt to figure out how we could accomplish this - I must say it has been quite frustrating. I was hoping we could only update the pSacl info with the SYSTEM_MANDATORY_LABEL_ACE field set to Medium. This is not straightforward. I have also tried to accomplish this by Windows impersonation, and updating the impersonation token - this works, but it requires quite a lot of infrastructure. In addition, if the thread is already impersonating, we need to restore the original token - and by setting the IntegrityLevel to Medium for the impersonation token one looses the SeImpersonatePrivilege which means I cannot do SetThreadToken() again for the original impersonation...messy. I then thought about using SDDL just as you have done, but only updating the Sacl info using SetSecurityInfo on the already created named pipe. This works, but it seems this triggered another issue (manifests as still hanging) - even though the integrity level is now set to Medium, the client have problem connecting (looks like this also requires easing up on the actual Discretionary ACL (just as you have done). So I ended up circling back to what you have in your second patch - if we are going to solve this proper, we need to spend quite a lot of time on it. I initially thought we should also state the Mandatory Label information in the SDDL, mainly for readability and rational purposes like: TCHAR *szSD = TEXT(D:) // Discretionary ACL TEXT((A;OICI;GRGW;;;WD)) // Allow read/write/execute to everybody TEXT((A;OICI;GA;;;SY))// Allow full control to system TEXT((A;OICI;GA;;;BA))// Allow full control to administrators TEXT(S:) // System ACL TEXT((ML;;NW;;;ME)); // Mandatory Integrity Label, No-WriteUp Policy, Medium Mandatory Level However, after some thought I changed my mind on this: Only Vista and later support the Mandatory Integrity Label, and if we include it we need to check conditionally. Somehow, the default when creating a securable object with you own Security Descriptor (instead of inheriting either the primary process or impersonation token) is that you default to Medium Mandatory Level (I don’t know if this just luck, but it seems to be that way, even for High Level process tokens). So to avoid conditional checks I suggest not including this: (S:) // System ACL TEXT((ML;;NW;;;ME)); // Mandatory Integrity Label, No-WriteUp Policy, Medium Mandatory Level Which is also what you already have in your patch. Maybe you could include a comment about the assumption that we expect to get Medium Mandatory Level by creating our own Security Descriptor? That way we can keep track of the rationale, and if MSFT changes this. I then just have one additional comment/change request: 291: LocalFree((sa.lpSecurityDescriptor)); This should be: 291: LocalFree(sa.lpSecurityDescriptor); With that change and some comment to the Medium Mandatory Level I am ok with your suggestion. Thanks a lot for fixing this. Many
Re: RFR(XS): 8058647, 8058649, 8058651, 8058652: ProblemList additions
Thanks for the review Jaroslav. Could you also help me push this (exported changesets attached)? Thanks, Mikael On 2014-09-22 10:30, Jaroslav Bachorik wrote: Reviewed -JB- On 09/18/2014 02:32 PM, Mikael Auno wrote: Hi, Could I please have a review for these small additions to ProblemList.txt in jdk9? They are separate changes (jcheck didn't agree with the guidelines[1] about multiple fixes in a single changeset) with separate bug numbers, but it seems easier to have one review for them all. bug: https://bugs.openjdk.java.net/browse/JDK-8058647 bug: https://bugs.openjdk.java.net/browse/JDK-8058649 bug: https://bugs.openjdk.java.net/browse/JDK-8058651 bug: https://bugs.openjdk.java.net/browse/JDK-8058652 webrev: http://cr.openjdk.java.net/~miauno/8058647_8058649_8058651_8058652/webrev.00/ Thanks, Mikael [1] http://openjdk.java.net/guide/producingChangeset.html#changesetComment # HG changeset patch # User miauno # Date 1411032854 -7200 # Node ID 80c2675985834df64dc385eb914776f089261bf8 # Parent 71c9aa685da57a3a700a067163d9817a35143494 8058647: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java should be quarantined Reviewed-by: jbachorik diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -298,4 +298,7 @@ # 6456333 sun/tools/jps/TestJpsJarRelative.javageneric-all +# 8057732 +sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.javageneric-all + # HG changeset patch # User miauno # Date 1411032854 -7200 # Node ID 89b3cbfdf0e8684c6772fb1095b9b07fd1c1bd37 # Parent 80c2675985834df64dc385eb914776f089261bf8 8058649: java/lang/management/ThreadMXBean/FindDeadlocks.java should be quarantined Reviewed-by: jbachorik diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -130,6 +130,9 @@ # 8056143 java/lang/management/MemoryMXBean/LowMemoryTest.java generic-all +# 8058492 +java/lang/management/ThreadMXBean/FindDeadlocks.java generic-all + # jdk_jmx # HG changeset patch # User miauno # Date 1411032854 -7200 # Node ID 19d857cb4b9d0ce001c732f676e8c98e9e048625 # Parent 89b3cbfdf0e8684c6772fb1095b9b07fd1c1bd37 8058651: com/sun/jdi/RedefinePop.sh should be quarantined Reviewed-by: jbachorik diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -271,6 +271,9 @@ # 8044419 com/sun/jdi/JdbReadTwiceTest.sh generic-all +# 8058616 +com/sun/jdi/RedefinePop.sh generic-all + # jdk_util # HG changeset patch # User miauno # Date 1411032854 -7200 # Node ID 3f92ca54cd2c87617e345cc7fad26c6a8908e46c # Parent 19d857cb4b9d0ce001c732f676e8c98e9e048625 8058652: java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java should be quarantined Reviewed-by: jbachorik diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -133,6 +133,9 @@ # 8058492 java/lang/management/ThreadMXBean/FindDeadlocks.java generic-all +# 8058506 +java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java generic-all + # jdk_jmx
Re: RFR(XS): 8058647, 8058649, 8058651, 8058652: ProblemList additions
On 09/22/2014 04:20 PM, Mikael Auno wrote: Thanks for the review Jaroslav. Could you also help me push this (exported changesets attached)? Will do. -JB- Thanks, Mikael On 2014-09-22 10:30, Jaroslav Bachorik wrote: Reviewed -JB- On 09/18/2014 02:32 PM, Mikael Auno wrote: Hi, Could I please have a review for these small additions to ProblemList.txt in jdk9? They are separate changes (jcheck didn't agree with the guidelines[1] about multiple fixes in a single changeset) with separate bug numbers, but it seems easier to have one review for them all. bug: https://bugs.openjdk.java.net/browse/JDK-8058647 bug: https://bugs.openjdk.java.net/browse/JDK-8058649 bug: https://bugs.openjdk.java.net/browse/JDK-8058651 bug: https://bugs.openjdk.java.net/browse/JDK-8058652 webrev: http://cr.openjdk.java.net/~miauno/8058647_8058649_8058651_8058652/webrev.00/ Thanks, Mikael [1] http://openjdk.java.net/guide/producingChangeset.html#changesetComment
