Continue to check the failed tests

Some tests fails for other reason than the previous: specifically under windows and with JDK 17. Looking at the available dumps, sometime there is an access violation during preparation of the KNetSerialization class. However, trying to reproduce the issue locally, the exception is not raised; between GitHub and local test the differences are:

OS: Windows Server for GitHub, Windows Desktop in local

JDK: locally tested only with a Temurin JDK 17

.NET 6/8: both at latest version

It is possible to highlight that KNetReplicator never raises such exception and the exception is not raised from the same test even if the order of execution is always the same.

Originally posted by @masesdevelopers in https://github.com/masesgroup/KEFCore/issues/243#issuecomment-2204084859

After some runs using both last published version and last build version of JNet/KNet it is possible to highlight that:

Test fails always on Windows, i.e. windows-latest GitHub image
Few time fails the tests with KNetReplicator: an example is at https://github.com/masesgroup/KEFCore/actions/runs/9778745372/job/26996474265

Other failures happen when a JDK 17 is in use: most one with Zulu, but other one are reported too; the failures in general reports the following callstack (here the source job):


The last pc belongs to native nmethod (printed below).
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 2983  java.lang.Class.getDeclaredMethods0(Z)[Ljava/lang/reflect/Method; java.base@17.0.10 (0 bytes) @ 0x00000292d69090e3 [0x00000292d69090a0+0x0000000000000043]
J 1419 c1 java.lang.Class.privateGetDeclaredMethods(Z)[Ljava/lang/reflect/Method; java.base@17.0.10 (64 bytes) @ 0x00000292ceff01dc [0x00000292ceff0040+0x000000000000019c]
j  java.lang.Class.getDeclaredMethods()[Ljava/lang/reflect/Method;+20 java.base@17.0.10
v  ~StubRoutines::call_stub

siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0xffffffffffffffff

which ends in the native call `getDeclaredMethods0` which accepts only a `boolean` parameter. So the expectation is that something is wrong at the hearth of the JVM itself.
The same

The last pc belongs to native nmethod (printed below). Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) J 2971 java.lang.Class.getDeclaredMethods0(Z)[Ljava/lang/reflect/Method; java.base@17.0.11 (0 bytes) @ 0x0000022db91a5063 [0x0000022db91a5020+0x0000000000000043] J 1388 c1 java.lang.Class.privateGetDeclaredMethods(Z)[Ljava/lang/reflect/Method; java.base@17.0.11 (64 bytes) @ 0x0000022db188255c [0x0000022db18823c0+0x000000000000019c] j java.lang.Class.getDeclaredMethods()[Ljava/lang/reflect/Method;+20 java.base@17.0.11 v ~StubRoutines::call_stub

siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0xffffffffffffffff


within a Corretto 17

masesgroup / KEFCore

Continue to check the failed tests #261