The test fails on some machines but does not fail on others, all 4.x
kernels. The possible problem may be when build host and run host are
different machines. This seems to be related to map0() implementation in
FileChannelImpl.c in case MAP_SYNC and MAP_SHARED_VALIDATE are not
defined (or defined).
I also recommend to print original ioe stacktrace in the test. Adding
such gives us useful information like this:
java.io.IOException: Invalid argument
at java.base/sun.nio.ch.FileChannelImpl.map0(Native Method)
at java.base/sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:1062)
at MapFail.main(MapFail.java:48)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:565)
at
com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
at java.base/java.lang.Thread.run(Thread.java:830)
java.lang.Exception: unexpected message for IOExceptionInvalid argument
at MapFail.main(MapFail.java:61)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:565)
at
com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
at java.base/java.lang.Thread.run(Thread.java:830)
Caused by: java.io.IOException: Invalid argument
at java.base/sun.nio.ch.FileChannelImpl.map0(Native Method)
at java.base/sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:1062)
at MapFail.main(MapFail.java:48)
... 6 more
-Dmitry
On 8/7/19 3:04 PM, Dmitry Chuyko wrote:
On 8/7/19 2:02 PM, Dmitry Chuyko wrote:
Andrew,
New code is buildable and new MapFail test passes on different
platforms except it fails on linux i386:
Ah, that even was x86_64 (sorry, mixed up results from automated
system). I'll try to reproduce it by hand to see if there are any
additional details.
-Dmitry
----------System.err:(12/712)----------
java.lang.Exception: unexpected message for IOExceptionInvalid argument
at MapFail.main(MapFail.java:60)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:565)
at
com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:246)
at java.base/java.lang.Thread.run(Thread.java:830)
First there is a problem with the test,
and a minor test issue is it would be good to add ": " before actual
unexpected message.
-Dmitry
On 8/7/19 12:31 PM, Dmitry Chuyko wrote:
On 8/6/19 6:58 PM, Andrew Dinn wrote:
......................
No this behaviour is not currently tested. However, the only client at
present will never exercise that path so it is not critical to test it
now. I'd be happy to address testing of this behaviour as part of a
follow-up JIRA issue if you would be so good as to raise it. I say
that
because I would very much like to get this functionality into a
release
to simplify more extensive testing by Red Hat's middleware teams.
It sounds reasonable, I'll create a tiny RFE after you push the JEP.
New MapFail test succeeds if proper IOException or any
UnsupportedOperationException was caught but it aren't those
situations
actually 2 different ones that require distinct checks? If you say
that
is the situation when results depend on Linux version, it makes
sense at
least to put a comment in the test because it's really not trivial.
The documentation of the API under test makes it clear that both
errors
can occur and under what circumstances. However, a note in the test
will
certainly do no harm. I will insert one before checking in the patch.
Can PmemTest check IOException with message "map with mode MAP_SYNC
unsupported" as a part of expected behavior, not just showing a test
failure?
I don't see any need for this now that MapFail has been provided. Wit
that alterative in place for checking map failures on non-DAX file
syetems PmemTest is now primarily intended to test behaviour with a
DAX
file system which it expects to have been set up in advance as
described
in the main comment. So, the scenario you describe is not really an
intended usage and I woudl argue that a failure is the right way to
signal that.
OK, finally got it, thank you.
-Dmitry
regards,
Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No.
03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
