On Thu, 7 Mar 2024 19:44:11 GMT, Roger Riggs wrote:
>> Elif Aslan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add args[0] back
>
> test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java line 56:
>
>> 54: public static void
On Tue, 5 Mar 2024 17:56:21 GMT, Roger Riggs wrote:
>> This change is intended to address the segmentation fault issue that occurs
>> when jspawnhelper is called without arguments,.
>> There is a new test added to verify the behavior in such cases.
>>
>> `[ec2-user@ip-172-16-0-10 jdk]$ make
On Thu, 7 Mar 2024 17:13:12 GMT, Elif Aslan wrote:
>> This change is intended to address the segmentation fault issue that occurs
>> when jspawnhelper is called without arguments,.
>> There is a new test added to verify the behavior in such cases.
>>
>> `[ec2-user@ip-172-16-0-10 jdk]$ make
On Wed, 6 Mar 2024 09:26:08 GMT, Aleksey Shipilev wrote:
> ```
> Process p = ProcessTools.startProcess(...);
> OutputAnalyzer oa = new OutputAnalyzer(p);
> oa.shouldNotHaveExitValue(0);
> oa.shouldContain("This command is not for general use");
> ```
Thank you! This shortens things quite
On Tue, 5 Mar 2024 10:39:31 GMT, Aleksey Shipilev wrote:
> The change in jspawnhelper looks good.
>
> I think it would be simpler to have a separate
> `jdk/java/lang/ProcessBuilder/JspawnhelperMisuse.java` test that simply
> invokes the `jspawnhelper` and verifies the proper message is
On Tue, 5 Mar 2024 17:56:21 GMT, Roger Riggs wrote:
> I'm curious why this test is requires `vm.debug`? That means it generally
> won't get run on release builds.
This is due to the tests of the crash scenarios that are guarded with #ifdef
DEBUG in jspawnhelper.
Moving the test in the
On Mon, 4 Mar 2024 23:23:04 GMT, Roger Riggs wrote:
>> This change is intended to address the segmentation fault issue that occurs
>> when jspawnhelper is called without arguments, and it includes an updated
>> test to verify the behavior in such cases.
>>
>> Existing tests passes since it
On Fri, 1 Mar 2024 07:37:22 GMT, Alan Bateman wrote:
> Would it be possible to expand a bit on what is going on here? Are you saying
> that in the course of upgrading a JDK that you somehow get into a state where
> jspawnhelper has been replaced with a version from a newer JDK? Is the real
>
On Fri, 1 Mar 2024 01:50:46 GMT, Vladimir Petko wrote:
> This MR fixes segsegv in jspawnhelper when it is called without args.
> This scenario happens when a long running Java process is not restarted
> during upgrade.
>
> It updates test/jdk/java/lang
This MR fixes segsegv in jspawnhelper when it is called without args.
This scenario happens when a long running Java process is not restarted during
upgrade.
It updates test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java to check
that jspawnhelper exits with code 1:
After test
On Fri, 1 Mar 2024 01:50:46 GMT, Vladimir Petko wrote:
> This MR fixes segsegv in jspawnhelper when it is called without args.
> This scenario happens when a long running Java process is not restarted
> during upgrade.
>
> It updates test/jdk/java/lang
On Fri, 18 Aug 2023 10:06:19 GMT, Vladimir Petko wrote:
> 8314491: Linux: jexec launched via PATH fails to find java
This pull request has now been integrated.
Changeset: dab1c213
Author: Vladimir Petko
Committer: David Holmes
URL:
https://git.openjdk.org/jdk/com
On Mon, 4 Sep 2023 08:01:16 GMT, Julian Waters wrote:
> Is this all clear for sponsorship?
Yes, I have checked with @dholmes-ora
-
PR Comment: https://git.openjdk.org/jdk/pull/15343#issuecomment-1704827486
> 8314491: Linux: jexec launched via PATH fails to find java
Vladimir Petko has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/rebase. The pull request contains ten additional
comm
On Fri, 25 Aug 2023 07:04:50 GMT, Vladimir Petko wrote:
>> 8314491: Linux: jexec launched via PATH fails to find java
>
> Vladimir Petko has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the unrelated cha
> 8314491: Linux: jexec launched via PATH fails to find java
Vladimir Petko has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/rebase. The pull request contains eight additional
comm
On Mon, 21 Aug 2023 21:36:13 GMT, David Holmes wrote:
>>> Nit: no need to pre-declare this, just use `int error = getJavaPath(...)`
>>
>> This one was intentional to keep the style consistent =)
>
> The others are more widely used and there is a desire to document their
> meaning. That isn't
> 8314491: Linux: jexec launched via PATH fails to find java
Vladimir Petko has updated the pull request incrementally with one additional
commit since the last revision:
declare error in-place
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15343/files
- new: ht
> 8314491: Linux: jexec launched via PATH fails to find java
Vladimir Petko has updated the pull request incrementally with one additional
commit since the last revision:
remove unused imports
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15343/files
- new: ht
On Mon, 21 Aug 2023 07:59:35 GMT, David Holmes wrote:
> Nit: no need to pre-declare this, just use `int error = getJavaPath(...)`
This one was intentional to keep the style consistent =)
-
PR Review Comment: https://git.openjdk.org/jdk/pull/15343#discussion_r1300614894
> 8314491: Linux: jexec launched via PATH fails to find java
Vladimir Petko has updated the pull request incrementally with one additional
commit since the last revision:
Review comment: use /proc/self/exe as the backup option
-
Changes:
- all: https://git.openjdk.org/jdk/p
On Mon, 21 Aug 2023 06:33:50 GMT, David Holmes wrote:
> To minimise the impact on existing users can this be implemented as a
> fallback if the initial attempt to locate `java` fails?
Updated and re-run the affected test:
==
Test summary
On Mon, 21 Aug 2023 04:38:56 GMT, David Holmes wrote:
> I get the sense from the comment in jexec.c that it is only intended to be
> launched via a full path, so having it in the $PATH seems like a usage error
> to me.
Unfortunately this executable is linked in /usr/bin and is assumed to work
> 8314491: Linux: jexec launched via PATH fails to find java
Vladimir Petko has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/rebase. The pull request contains four additional
comm
On Fri, 18 Aug 2023 10:06:19 GMT, Vladimir Petko wrote:
> 8314491: Linux: jexec launched via PATH fails to find java
When jexec is found in the PATH, e.g. we run ``$jexec myjar.jar``, the
`argv[0]` contains `jexec` and Java can not be found.
Running updated test without fix in jexe
8314491: Linux: jexec launched via PATH fails to find java
-
Commit messages:
- Use /proc/self/exec to identify path to the executable.
- Create failing test for jexec in PATH issue
Changes: https://git.openjdk.org/jdk/pull/15343/files
Webrev:
On Fri, 21 Jul 2023 10:55:13 GMT, Vladimir Petko wrote:
> Use the same approach as Logger::defaultLogger() to ensure that the appender
> is not destroyed before shared object destructor function is executed.
>
> The alternative is to delete dcon() function, but we might run into a
On Fri, 21 Jul 2023 20:52:32 GMT, Alexander Matveev
wrote:
>> Vladimir Petko has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> copyright typo
>
> src/jdk.jpackage/share/native/common/app.cpp line 2:
>
215 215 0 0
>
> ======
> TEST SUCCESS
Vladimir Petko has updated the pull request incrementally with one additional
commit since the last revision:
copyright typo
-
Changes:
- all: https://git.openjdk.org/jdk/pull/14971/files
- new: https://git.ope
Use the same approach as Logger::defaultLogger() to ensure that the appender
is not destroyed before shared object destructor function is executed.
The alternative is to delete dcon() function, but we might run into a similiar
tear-down issue later (e.g. logging from some object's destructor).
On Thu, 15 Jun 2023 17:44:01 GMT, Roger Riggs wrote:
>> Add mipsel and mips64el to the Architecture enum.
>> (Later to be backported to JDK 21)
>
> Roger Riggs has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Correct mps64el test case
=mips64el=21%7E26ea-2=1686605119=0
[2]
https://buildd.debian.org/status/fetch.php?pkg=openjdk-21=mipsel=21%7E26ea-2=1686722920=0
commit cca1cc7cf5d89de3dcf5fa4ba42f521ba3ceee89
Author: Vladimir Petko
Date: Wed Jun 14 21:05:06 2023 +1200
add mipsel architecture
diff --git a/src/java.base/share
[[I4](struct)]
-cut-
as JAVA_INT is represented as 'I4' for big endian.
Would it be possible to consider the attached patch to resolve the issue?
Best Regards,
Vladimir.
commit 99fe5b698cd75f0e0574ec94d43688aeff7a29da
Author: Vladimir Petko
Date: Fri Jun 9 20:51:43 2023 +1200
33 matches
Mail list logo
