[crac] RFR: Print better diagnostics for spawning CRIU [v2]
Jan Kratochvil
jkratochvil at openjdk.org
Wed Aug 9 23:11:28 UTC 2023
On Wed, 9 Aug 2023 19:41:33 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:
>> Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>>
>> - print error messages in C++
>> - Merge branch 'crac' into crac-error
>> - Print better diagnostics for spawning CRIU.
>
> src/java.base/unix/native/criuengine/criuengine.cpp line 199:
>
>> 197: if (WEXITSTATUS(status) != SUPPRESS_ERROR_IN_PARENT) {
>> 198: std::cerr << "Spawned CRIU \"" << join_args(args) << "\" has not properly exited:"
>> 199: " exit code " << WEXITSTATUS(status) << " - check " << path_abs(imagedir, log_local) << std::endl;
>
> we are not required to abs(imagedir), as unprocessed that is in the same way as it was provided in the args
The problem is users do not execute `criuengine` themselves. From my experience:
$ $JTREG_HOME/bin/jtreg -jdk:$ZULU_HOME -v:all -timeout:10 $TEST_HOME/test/jdk/jdk/crac/BigCheckpointTest.java
Spawned CRIU "/home/azul/azul/crac-git/build/linux-x86_64-server-fastdebug/images/jdk/lib/criu dump -t 648896 -D cr --shell-job -v4 -o dump4.log" has not properly exited: exit code 1 - check dump4.log
$ ls -l dump4.log
ls: cannot access 'dump4.log': No such file or directory
How to find out `dump4.log` is hiding in the `JTwork/scratch_1/cr` subdirectory?
$ ls -l ./JTwork/scratch_1/cr/dump4.log
-rw------- 1 azul azul 3547 Aug 10 06:58 ./JTwork/scratch_1/cr/dump4.log
-------------
PR Review Comment: https://git.openjdk.org/crac/pull/97#discussion_r1289340035
More information about the crac-dev
mailing list