Race Condition in IKVM JNI Layer Causes NegativeArraySizeException During Concurrent Startup

[gmohd2786]

We are encountering a critical race condition in the IKVM JNI layer (JNIEnv.NewObjectArray()) when running Java applications on IIS/.NET. This results in NegativeArraySizeException during concurrent application startup, especially after IIS resets.

Details:

Exception: NegativeArraySizeException in JNIEnv.NewObjectArray()
Environment: Windows Server 2022, .NET Runtime, IIS, Spring Framework
Reproducibility: Intermittent, only under concurrent load at startup (IIS reset)
Impact: Production downtime, data loss (empty site/page mappings), silent failures
Why Application-Level Workarounds Are Not Acceptable:

Retry logic can result in empty arrays, causing missing sites/pages and broken analytics
Fail-fast leads to downtime and restart loops
Synchronization cannot cover all JNI code paths and impacts performance
Request:

Please investigate thread-safety and initialization order in the JNI layer
Ensure JNIEnv.NewObjectArray() and related methods are fully protected from concurrent access before initialization
Add concurrent access tests to the IKVM test suite
We have a detailed bug report and root cause analysis available, including suggested fixes and test cases. Please advise how best to share this information and collaborate on a solution.

[wasabii]

I mean if you're loading multiple copies of the IKVM assembly in the same address space, this is going to happen. AppDomains are something we do not claim to support any more.

Is that what you're talking about?

Otherwise, initializing is done through statics called through module initializers.

[subramanya-n]

Hi Wasabii,
We are not loading multiple IKVM assemblies within the same address space. Each site runs in its own isolated w3wp.exe process under separate IIS Application Pools. Given this setup, we expect that IKVM assemblies are isolated per site and not shared across processes.

Therefore, we would like to understand how multiple IKVM assemblies could still be loaded within the same address space under this configuration.

-Subramanya N

[wasabii]

Well, then you're going to have to let me know what the issue actually is. You've said it is a "race condition" hinted that it involves concurrent startup, but have never stated otherwise what the race condition actually is.

[gmohd2786]

The race condition is specifically this: during cold start in a single w3wp.exe, multiple threads concurrently enter Java native startup paths before IKVM JNI state is fully published/thread-safe; in that window, JNIEnv.NewObjectArray(length, ...) intermittently receives an invalid negative length, which throws NegativeArraySizeException.

Evidence
Not multi-assembly/AppDomain related (single process, single address space).
Two independent Java paths fail in the same startup window and converge at the same JNI failure point:
File.listFiles() → WinNTFileSystem.list() → JNIEnv.NewObjectArray(...)
InetAddress.getLocalHost() → Inet6AddressImpl.lookupAllHostAddr() → JNIEnv.NewObjectArray(...)
Failure is timing/concurrency dependent: appears after recycle under concurrent startup load, and is not reproducible in single-threaded startup behavior.
This pattern isolates the fault to shared IKVM JNI startup/state handling, not to Java business logic in one caller.

Why this is not a Java-side fix:
The failing entry points include JDK internals (File., InetAddress.), not one controllable app method.
App-level retries/locks only mask the defect and introduce unacceptable risks (silent partial init/data loss, restart loops, startup latency/perf regression, incomplete coverage of JNI call surface).

Requested IKVM action:
Fix JNI initialization/thread-safety so no JNI call can observe partial state.
Add concurrency regression coverage (startup stress with many parallel threads invoking file and DNS paths) and verify NewObjectArray never sees negative length from valid callers.

[wasabii]

Am I talking to AI?

None of this explains why there are two threads.

[gmohd2786]

Nope 😄 this is me, not a bot template.

Also, agreed: it’s not exactly two threads — it’s concurrent startup, and we happened to capture two in that window.

What we actually mean is concurrent startup, not a fixed thread count. In the failing window after recycle, we captured two overlapping startup paths in the same w3wp process: one from bean/file initialization and one from runtime/DNS initialization. Both independently hit JNIEnv.NewObjectArray, which is why we suspect a JNI init/thread-safety race.

So the point isn’t “exactly two threads exist,” it’s “multiple startup threads can overlap, and in this capture two of them converged at the same JNI failure point.”

Key point:
Not “exactly two threads by design.”
Any concurrent startup threads entering JNI during PARTIALLY PUBLISHED window can fail.

[wasabii]

I have no idea what "concurrent startup" means if not threads.

And if that, it shouldn't be possible, since it happens as a module initializer.

I need to know what you mean by "concurrent startup". And what the stack traces are. Ideally with information about AppDomains, because I still suspect its that. Heh.

"multiple threads concurrently enter Java native startup paths" What are these paths? Which threads? Again, "Java native startup paths" happen during module init.