i.java:174)
> at java.naming/com.sun.jndi.ldap.LdapURL.(LdapURL.java:105)
>
> I would like to add the host and port info to the exception (in the example
> it is host:port of URI:null:-1] ) so that it is directly visible that the
> input caused the construction of a URI
> with &quo
On Tue, 14 Jun 2022 10:43:54 GMT, Matthias Baesken wrote:
>> When trying to construct an LdapURL object with a bad input string (in this
>> example the _ in ad_jbs is causing issues), and not using
>> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing=&
i.java:174)
> at java.naming/com.sun.jndi.ldap.LdapURL.(LdapURL.java:105)
>
> I would like to add the host and port info to the exception (in the example
> it is host:port of URI:null:-1] ) so that it is directly visible that the
> input caused the construction of a URI
> with &quo
On Thu, 9 Jun 2022 11:37:21 GMT, Matthias Baesken wrote:
> We still handle at a number of places ancient historic _MSC_VER versions of
> Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don'
On Fri, 10 Jun 2022 12:16:17 GMT, Matthias Baesken wrote:
> When trying to construct an LdapURL object with a bad input string (in this
> example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="
i.java:174)
> at java.naming/com.sun.jndi.ldap.LdapURL.(LdapURL.java:105)
>
> I would like to add the host and port info to the exception (in the example
> it is host:port of URI:null:-1] ) so that it is directly visible that the
> input caused the construction of a URI
> with &quo
On Mon, 13 Jun 2022 11:46:52 GMT, Matthias Baesken wrote:
>> We still handle at a number of places ancient historic _MSC_VER versions of
>> Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
>> This should be cleaned up, as long as it is not 3rd party code that
On Mon, 13 Jun 2022 14:29:44 GMT, Jaikiran Pai wrote:
> > Hi Daniel, should we maybe better print something like "check for not
> > allowed characters" in the exception ? Do you have an easy and cheap way in
> > mind to the get the unsupported character (in this case "_") to add it to
> > the
quot;valid") VS version are 2017+, see
> https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4
> .
> VALID_VS_VERSIONS="2019 2017 2022"
> Even with adjusted toolchain m4 files, something older than VS2013 (also
> probably older than VS20
On Mon, 13 Jun 2022 10:33:24 GMT, Andrey Turbanov wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> use round directly
>
> src/hotspot/share/adlc/main.cpp line 491:
>
>>
On Fri, 10 Jun 2022 14:19:27 GMT, Daniel Fuchs wrote:
> I might question whether the added "null:-1" information is really helpful,
> or just as confusing however.
Hi Daniel, should we maybe better print something like "check for not allowed
characters" in the exception ? Do you have an easy
On Fri, 10 Jun 2022 21:04:04 GMT, Phil Race wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> use round directly
>
> src/java.desktop/windows/native/libawt/windows/ThemeReader.cp
quot;valid") VS version are 2017+, see
> https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4
> .
> VALID_VS_VERSIONS="2019 2017 2022"
> Even with adjusted toolchain m4 files, something older than VS2013 (also
> probably older than VS20
On Fri, 10 Jun 2022 13:15:11 GMT, Alan Bateman wrote:
> We have to be cautious about leaking security sensitive configuration in
> exception messages. Can you look at the security property
> jdk.includeInException (conf/security/java.security) and usages in the JDK
> for ideas on how this
When trying to construct an LdapURL object with a bad input string (in this
example the _ in ad_jbs is causing issues), and not using
the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run
into the exception below :
import com.sun.jndi.ldap.LdapURL;
String url =
On Fri, 10 Jun 2022 10:49:25 GMT, Martin Doerr wrote:
> LGTM and sounds feasible.
Hi Martin, thanks for the review.
-
PR: https://git.openjdk.org/jdk/pull/9105
We still handle at a number of places ancient historic _MSC_VER versions of
Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
This should be cleaned up, as long as it is not 3rd party code that we don't
want to adjust.
Currently still supported ("valid") VS version are 2017+,
On Wed, 11 May 2022 16:00:32 GMT, Maxim Kartashev
wrote:
> This change seem to have made this group of declarations obsolete:
> `src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h:157` (follow
> the
>
On Thu, 5 May 2022 15:21:23 GMT, Matthias Baesken wrote:
> The isMusl method had to be handled in
> test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java .
> Additionally, the vm.musl predicate seem not to be available in the langtools
> tests.
This pull request
> The isMusl method had to be handled in
> test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java .
> Additionally, the vm.musl predicate seem not to be available in the langtools
> tests.
Matthias Baesken has updated the pull request with a new target base due
On Wed, 27 Apr 2022 14:57:41 GMT, Matthias Baesken wrote:
> Currently we set _WIN32_WINNT at various places in the codebase; this is used
> to target a minimum Windows version we want to support. See also for more
> detailled information :
> https://docs.microsoft.com/en-us/w
On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote:
>> Currently we set _WIN32_WINNT at various places in the codebase; this is
>> used to target a minimum Windows version we want to support. See also for
>> more detailled information :
>> https://docs.microsoft
On Wed, 4 May 2022 09:08:28 GMT, Matthias Baesken wrote:
> Does this mean that not setting _WIN32_WINNT means :any API is allowed" ?
Hi David , I did one more try with my current setup (VS2017 on a Win10
notebook). I did not set _WIN32_WINNT.
My little test program
#include
#inclu
On Thu, 5 May 2022 16:14:32 GMT, Daniel D. Daugherty wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> restore year in ExternalEditorTest, remove test exclusion
>
On Thu, 5 May 2022 16:33:53 GMT, Daniel D. Daugherty wrote:
> ... update the PR's synopsis.
Done .
-
PR: https://git.openjdk.java.net/jdk/pull/8556
> The isMusl method had to be handled in
> test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java .
> Additionally, the vm.musl predicate seem not to be available in the langtools
> tests.
Matthias Baesken has updated the pull request incrementally with one additi
> The isMusl method had to be handled in
> test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java .
> Additionally, the vm.musl predicate seem not to be available in the langtools
> tests.
Matthias Baesken has updated the pull request with a new target base due
The isMusl method had to be handled in
test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java .
Additionally, the vm.musl predicate seem not to be available in the langtools
tests.
-
Commit messages:
- remove from ProblemList
- Merge remote-tracking branch
On Thu, 5 May 2022 15:24:25 GMT, Martin Doerr wrote:
> Strange. The pre-submit tests are all green.
Yes sorry those seem not to cover these 2 findings. And I think I locally run
by mistake only the jdk test instead of the jdk + langtools tests with my
script , this will of course not show
On Thu, 5 May 2022 13:43:30 GMT, Alan Bateman wrote:
>> A couple a tests like java/lang/ProcessBuilder/Basic.java#id0.Basic_id0 and
>> jdk/jshell/ExternalEditorTest.java.ExternalEditorTest try to start small
>> shell scripts without #! at the first line of the script. This fails with
>>
On Wed, 4 May 2022 12:04:47 GMT, Matthias Baesken wrote:
> A couple a tests like java/lang/ProcessBuilder/Basic.java#id0.Basic_id0 and
> jdk/jshell/ExternalEditorTest.java.ExternalEditorTest try to start small
> shell scripts without #! at the first line of the script. This fails with
On Wed, 4 May 2022 12:04:47 GMT, Matthias Baesken wrote:
> A couple a tests like java/lang/ProcessBuilder/Basic.java#id0.Basic_id0 and
> jdk/jshell/ExternalEditorTest.java.ExternalEditorTest try to start small
> shell scripts without #! at the first line of the script. This fails with
On Wed, 4 May 2022 11:37:09 GMT, Matthias Baesken wrote:
> There is one TestLibrary.bomb call in
> sun/rmi/runtime/Log/checkLogging/CheckLogging.java that is not passing the
> exception to bomb, that should be improved.
This pull request has now been integrated.
Changeset: 7424f4
On Wed, 4 May 2022 11:37:09 GMT, Matthias Baesken wrote:
> There is one TestLibrary.bomb call in
> sun/rmi/runtime/Log/checkLogging/CheckLogging.java that is not passing the
> exception to bomb, that should be improved.
Hi Roger and Martin, thanks for the reviews !
-
A couple a tests like java/lang/ProcessBuilder/Basic.java#id0.Basic_id0 and
jdk/jshell/ExternalEditorTest.java.ExternalEditorTest try to start small shell
scripts without #! at the first line of the script. This fails with error=8,
Exec format error when running on Alpine 3.15 .
Looks like this
There is one TestLibrary.bomb call in
sun/rmi/runtime/Log/checkLogging/CheckLogging.java that is not passing the
exception to bomb, that should be improved.
-
Commit messages:
- JDK-8286114
Changes: https://git.openjdk.java.net/jdk/pull/8533/files
Webrev:
On Wed, 4 May 2022 08:34:43 GMT, David Holmes wrote:
> I'm confused.
> `src\jdk.crypto.mscapi\windows\native\libsunmscapi\security.cpp` doesn't set
> _WIN32_WINNT so how is that later API being enabled? Does this mean that not
> setting _WIN32_WINNT means :any API is allowed" ?
I found this
ops_md.c
> (so targeting older Windows versions at other places is most likely not
> useful).
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
adjust API level to Windows 8 for security.cpp and do some cleanup
--
On Tue, 3 May 2022 13:27:41 GMT, David Holmes wrote:
> I agree with Erik - the source locations need to be modified to not define
> it. If we want to keep a record perhaps add an assertion that the value is
> what was expected?
>
> I still feel we have a disconnect between this and an actual
On Tue, 3 May 2022 07:10:58 GMT, Matthias Baesken wrote:
>> Currently we set _WIN32_WINNT at various places in the codebase; this is
>> used to target a minimum Windows version we want to support. See also for
>> more detailled information :
>> https://docs.microsoft
On Tue, 3 May 2022 08:23:52 GMT, Alan Bateman wrote:
>> Hi Alan, I agree (thats why I did not change the define in harfbuzz, but I
>> missed that wepoll.c is 3rd party code as well).
>
> I assume you can revert the update to the copyright header in the latest
> version as there aren't any
ops_md.c
> (so targeting older Windows versions at other places is most likely not
> useful).
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
Adjust Copyright year in wepoll.c
-
Changes:
- all: https://
ops_md.c
> (so targeting older Windows versions at other places is most likely not
> useful).
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
set _WIN32_WINNT=0x0601 centrally in flags-cflags.m4
-
Changes:
On Fri, 29 Apr 2022 05:09:35 GMT, David Holmes wrote:
> That only seems to be half of the issue though. If we are defining
> _WIN32_WINNT=0x0601 because the minimum required OS API support level is
> Windows 7, then don't we need a check that the build platform is also at
> least Windows 7?
On Wed, 27 Apr 2022 14:57:41 GMT, Matthias Baesken wrote:
> Currently we set _WIN32_WINNT at various places in the codebase; this is used
> to target a minimum Windows version we want to support. See also for more
> detailled information :
> https://docs.microsoft.com/en-us/w
On Wed, 27 Apr 2022 15:10:51 GMT, Alan Bateman wrote:
>> Currently we set _WIN32_WINNT at various places in the codebase; this is
>> used to target a minimum Windows version we want to support. See also for
>> more detailled information :
>>
Currently we set _WIN32_WINNT at various places in the codebase; this is used
to target a minimum Windows version we want to support. See also for more
detailled information :
On Thu, 20 Jan 2022 10:55:59 GMT, Matthias Baesken wrote:
> After 8270492
> https://github.com/openjdk/jdk/commit/78b2c8419bc69436873e6fc9c542480949d140c5
> has been pushed, we should adjust
> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SystemIDR
70492 to
> src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/SystemIDResolver.java
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
Add LastModified
-
Changes:
- all: https://git.openjdk.java.net/j
On Thu, 20 Jan 2022 23:32:33 GMT, Joe Wang wrote:
> Thanks Alan for the reminder. The change looks good. Please add a copyright
> header and the LastModified tag as the other class did.
Hi, I added the header and LastModified.
Best regards, Matthias
-
PR:
70492 to
> src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/SystemIDResolver.java
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
Add header
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/
After 8270492
https://github.com/openjdk/jdk/commit/78b2c8419bc69436873e6fc9c542480949d140c5
has been pushed, we should adjust
src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SystemIDResolver.java
getAbsoluteURI to what has been done in 8270492 to
On Wed, 19 Jan 2022 09:19:00 GMT, Matthias Baesken wrote:
> Very small change fixing wrong strings "Falied" in a couple of tests.
This pull request has now been integrated.
Changeset: 8931c122
Author:Matthias Baesken
URL:
https://git.openjdk.java.n
Very small change fixing wrong strings "Falied" in a couple of tests.
-
Commit messages:
- JDK-8280157
Changes: https://git.openjdk.java.net/jdk/pull/7142/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7142=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8280157
On Thu, 7 Oct 2021 11:20:57 GMT, Matthias Baesken wrote:
> The OS detection code of the JDK/JVM should recognize the new Windows 11. For
> details see :
>
> https://docs.microsoft.com/en-us/windows/release-health/windows11-release-information
> OS build number is : 22000.194 for
On Thu, 7 Oct 2021 11:20:57 GMT, Matthias Baesken wrote:
> The OS detection code of the JDK/JVM should recognize the new Windows 11. For
> details see :
>
> https://docs.microsoft.com/en-us/windows/release-health/windows11-release-information
> OS build number is : 22000.194 for
The OS detection code of the JDK/JVM should recognize the new Windows 11. For
details see :
https://docs.microsoft.com/en-us/windows/release-health/windows11-release-information
OS build number is : 22000.194 for 21H2 (original release)
Please review the following small patch !
(patch comes
On Wed, 29 Sep 2021 12:51:00 GMT, Severin Gehwolf wrote:
> Please review this test fix to work around a podman issue[1]. `podman`
> expects for the "unlimited" option of `--pids-limit` to be `0` whereas
> `docker` wants `-1`. See the JBS bug for details. Thoughts?
>
> Testing: hotspot/jdk
On Thu, 9 Sep 2021 09:21:59 GMT, Matthias Baesken wrote:
> https://bugs.openjdk.java.net/browse/JDK-8266490
> extended the OSContainer API in order to also support the pids controller of
> cgroups. However only pids.max output was added with 8266490.
> There is a second parameter
On Wed, 15 Sep 2021 07:09:54 GMT, Matthias Baesken wrote:
>>> Maybe it should be "any_integer"?
>>
>> +1
>
>> Is "no_value_expected" generated by Docker? I searched the entire HotSpot
>> source code and couldn't find it. I also could
On Fri, 10 Sep 2021 12:36:35 GMT, Severin Gehwolf wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Some simplifications and test adjustment suggested by Severin
>
> test/h
est/admin-guide/cgroup-v2.html#pid
> that would be helpful too and can be added to the OSContainer API .
> pids.current :
> A read-only single value file which exists on all cgroups.
> The number of processes currently in the cgroup and its descendants.
>
> Best regards, Matth
On Tue, 14 Sep 2021 18:23:49 GMT, Severin Gehwolf wrote:
>> Oh, I misunderstood the test. "no_value_expected" was passed in from
>> `testPids()` in this file, but that's confusing because you are expecting an
>> integer value. Maybe it should be "any_integer"?
>
>> Maybe it should be
On Fri, 10 Sep 2021 11:07:52 GMT, Matthias Baesken wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8266490
>> extended the OSContainer API in order to also support the pids controller of
>> cgroups. However only pids.max output was added with 8266490.
>> The
est/admin-guide/cgroup-v2.html#pid
> that would be helpful too and can be added to the OSContainer API .
> pids.current :
> A read-only single value file which exists on all cgroups.
> The number of processes currently in the cgroup and its descendants.
>
> Best regards, Matth
est/admin-guide/cgroup-v2.html#pid
> that would be helpful too and can be added to the OSContainer API .
> pids.current :
> A read-only single value file which exists on all cgroups.
> The number of processes currently in the cgroup and its descendants.
>
> Best regards, Matth
On Thu, 9 Sep 2021 09:21:59 GMT, Matthias Baesken wrote:
> https://bugs.openjdk.java.net/browse/JDK-8266490
> extended the OSContainer API in order to also support the pids controller of
> cgroups. However only pids.max output was added with 8266490.
> There is a second parameter
https://bugs.openjdk.java.net/browse/JDK-8266490
extended the OSContainer API in order to also support the pids controller of
cgroups. However only pids.max output was added with 8266490.
There is a second parameter pids.current , see
On Thu, 2 Sep 2021 06:43:16 GMT, Matthias Baesken wrote:
> Hello, please review this small change.
> The OS detection code of the JDK/JVM should recognize the new Windows server
> 2022 :
>
> https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2022
> https://doc
On Thu, 2 Sep 2021 07:49:55 GMT, David Holmes wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Adjust comments
>
> src/hotspot/os/windows/os_windows.cpp line 1871:
>
>
erver-release-info
>
> The build number of Windows server 2022 according to the documentation in the
> second link is 20348 .
> Thanks, Matthias
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
Adjust comments
Hello, please review this small change.
The OS detection code of the JDK/JVM should recognize the new Windows server
2022 :
https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2022
https://docs.microsoft.com/en-us/windows-server/get-started/windows-server-release-info
The build
On Thu, 17 Jun 2021 12:27:25 GMT, Matthias Baesken wrote:
> Hello, please review this PR; it extend the OSContainer API in order to also
> support the pids controller of cgroups.
>
> I noticed that unlike the other controllers "cpu", "cpuset", "cpuac
tros (SLES 12.1, RHEL 7.1) the pids
> controller might not be there (or not fully supported) so it was added as
> optional , see the coding
>
>
> if (!cg_infos[PIDS_IDX]._data_complete) {
> log_debug(os, container)("Optional cgroup v1 pids subsystem not found");
&g
On Fri, 6 Aug 2021 08:29:50 GMT, Severin Gehwolf wrote:
> This looks good to me now and passes tests on my cgroup v1 and cgroup v2
> setups.
Thanks for the review and approval .
Best regards, Matthias
-
PR: https://git.openjdk.java.net/jdk/pull/4518
tros (SLES 12.1, RHEL 7.1) the pids
> controller might not be there (or not fully supported) so it was added as
> optional , see the coding
>
>
> if (!cg_infos[PIDS_IDX]._data_complete) {
> log_debug(os, container)("Optional cgroup v1 pids subsystem not found");
&g
On Mon, 2 Aug 2021 11:42:33 GMT, Severin Gehwolf wrote:
> > What do you think about accepting, when setting -1/unlimited, a high limit
> > number like 20.000+ as well (and and a comment that on some setups
> > unlimited means just "high number" but not unlimited?
>
> This seems most
tros (SLES 12.1, RHEL 7.1) the pids
> controller might not be there (or not fully supported) so it was added as
> optional , see the coding
>
>
> if (!cg_infos[PIDS_IDX]._data_complete) {
> log_debug(os, container)("Optional cgroup v1 pids subsystem not found");
&g
On Fri, 23 Jul 2021 12:32:04 GMT, Severin Gehwolf wrote:
> > Could this be some setting configured on your box that is picked up as an
> > additional limit ?
>
> Possibly. Not sure where to look, though.
I ask some local experts about that issue.
What do you think about accepting, when
On Fri, 23 Jul 2021 08:39:37 GMT, Severin Gehwolf wrote:
>
> No, I don't know what to do about it. All I can see it comes back with a pids
> limit of `38019` when set to `-1`. It does seem like a bug or an intentional
> setting so as to avoid fork bombs.
Very strange indeed, I have docker
On Thu, 22 Jul 2021 12:18:20 GMT, Matthias Baesken wrote:
>> Hello, please review this PR; it extend the OSContainer API in order to also
>> support the pids controller of cgroups.
>>
>> I noticed that unlike the other controllers "cpu", "cpuset",
tros (SLES 12.1, RHEL 7.1) the pids
> controller might not be there (or not fully supported) so it was added as
> optional , see the coding
>
>
> if (!cg_infos[PIDS_IDX]._data_complete) {
> log_debug(os, container)("Optional cgroup v1 pids subsystem not found");
&g
On Fri, 16 Jul 2021 06:14:07 GMT, Matthias Baesken wrote:
>> Hello, please review this PR; it extend the OSContainer API in order to also
>> support the pids controller of cgroups.
>>
>> I noticed that unlike the other controllers "cpu", "cpuset",
tros (SLES 12.1, RHEL 7.1) the pids
> controller might not be there (or not fully supported) so it was added as
> optional , see the coding
>
>
> if (!cg_infos[PIDS_IDX]._data_complete) {
> log_debug(os, container)("Optional cgroup v1 pids subsystem not found");
&g
On Fri, 9 Jul 2021 13:53:27 GMT, Matthias Baesken wrote:
> > OK. Please also add a test on the hotspot side. You may want to add
> > relevant parts to `TestMisc.java`.
>
> Thanks for the suggestion, I will look into TestMisc.java .
I added some HS testing code in the la
tros (SLES 12.1, RHEL 7.1) the pids
> controller might not be there (or not fully supported) so it was added as
> optional , see the coding
>
>
> if (!cg_infos[PIDS_IDX]._data_complete) {
> log_debug(os, container)("Optional cgroup v1 pids subsystem not found");
&g
On Fri, 9 Jul 2021 13:42:15 GMT, Severin Gehwolf wrote:
> OK. Please also add a test on the hotspot side. You may want to add relevant
> parts to `TestMisc.java`.
Thanks for the suggestion, I will look into TestMisc.java .
-
PR: https://git.openjdk.java.net/jdk/pull/4518
On Tue, 29 Jun 2021 08:21:51 GMT, Severin Gehwolf wrote:
> This looks pretty good now. Looking forward to seeing container tests for
> this new code.
Hi Severin , I did some adjustments following your suggestions.
I added docker based test coding for testing pids-limit (with limits and also
tros (SLES 12.1, RHEL 7.1) the pids
> controller might not be there (or not fully supported) so it was added as
> optional , see the coding
>
>
> if (!cg_infos[PIDS_IDX]._data_complete) {
> log_debug(os, container)("Optional cgroup v1 pids subsystem not found");
&g
On Wed, 23 Jun 2021 14:48:22 GMT, Severin Gehwolf wrote:
> > But I think that the testing needs to be enhanced (e.g. with some added
> > docker tests?). Do you have some good suggestions
> > where I could look at existing (docker?) tests and adjust those for the new
> > pids.max ?
>
> Have a
On Wed, 23 Jun 2021 13:37:59 GMT, Matthias Baesken wrote:
>> Hello, please review this PR; it extend the OSContainer API in order to also
>> support the pids controller of cgroups.
>>
>> I noticed that unlike the other controllers "cpu", "cpuset",
tros (SLES 12.1, RHEL 7.1) the pids
> controller might not be there (or not fully supported) so it was added as
> optional , see the coding
>
>
> if (!cg_infos[PIDS_IDX]._data_complete) {
> log_debug(os, container)("Optional cgroup v1 pids subsystem not found");
&g
Hello, please review this PR; it extend the OSContainer API in order to also
support the pids controller of cgroups.
I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct",
"memory" on some older Linux distros (SLES 12.1, RHEL 7.1) the pids controller
might not be there (or
On Tue, 11 May 2021 14:49:42 GMT, Matthias Baesken wrote:
> Hello, please review this small Sonar finding.
> Sonar reports a potential NULL pointer dereference here :
> https://sonarcloud.io/project/issues?id=shipilev_jdk=c=AXck8CPLBBG2CXpcnh_z=false=MAJOR=BUG
> "Access to fie
> from variable 'new')"
> It would be better to add a check .
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
Replace check by assertion
-
Changes:
- all: https://git.openjdk.java.net/jdk/pu
Hello, please review this small Sonar finding.
Sonar reports a potential NULL pointer dereference here :
https://sonarcloud.io/project/issues?id=shipilev_jdk=c=AXck8CPLBBG2CXpcnh_z=false=MAJOR=BUG
"Access to field 'item' results in a dereference of a null pointer (loaded from
variable 'new')"
It
On Tue, 23 Feb 2021 13:58:03 GMT, Matthias Baesken wrote:
> Sonar reports a finding in args.c, where a file check is done .
> Stat performs a check on file, and later fopen is called on the file .
>
> The coding could be slightly rewritten so that the potential issue is removed
>
On Thu, 25 Feb 2021 17:46:42 GMT, Christoph Langer wrote:
>> I think that did not work because it does not fit the param types of
>> reportAndExit but I can simplify it otherwise.
>
> Ah, I see.
> Maybe it's a bit bike-sheddy but as you're using reportAndExit only twice
> now, wouldn't it be
> Sonar reports a finding in args.c, where a file check is done .
> Stat performs a check on file, and later fopen is called on the file .
>
> The coding could be slightly rewritten so that the potential issue is removed
> (however I do not think that it is such a big issue).
M
On Thu, 25 Feb 2021 16:07:36 GMT, Christoph Langer wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove fclose before exit
>
> src/java.base/share/native/lib
1 - 100 of 115 matches
Mail list logo
