GeezerVison

Description

Memory-safety and robustness bugs in how JS arguments are converted for Java calls. Each fix has a spec that crashed or failed on the test app before this change.

1. Typed arrays passed to object parameters leaked, then aborted the process. Passing an ArrayBuffer, SharedArrayBuffer, typed array or DataView to an object parameter (ByteBuffer, Object, channel.read(new ArrayBuffer(n)), …) wraps its memory in a direct Java buffer. The converter also took a JNI global reference to that buffer and never deleted it. As a result:

• the Java buffer could never be collected;
• its link kept the JS typed array, and so the V8 backing store, alive forever;
• once 51200 buffers had been passed, ART aborted with global reference table overflow (max=51200).

Core reaches this in file-system-access.android.ts (readBufferSync, writeBufferSync, writeBufferAsync).

The global ref was never needed for lifetime. The buffer is registered in the object table and linked to the JS object, which keeps the JS object, and with it the memory, alive for as long as Java holds the buffer. This is the same mechanism every other wrapper relies on. The conversion now:

• drops the global ref;
• deletes every local ref it creates (it used to leak ~5 per call);
• looks up the ByteBuffer/ByteOrder method ids and the native byte order once, instead of on every call;
• is shared by JsArgConverter and JsArgToArrayConverter instead of duplicated in both;
• throws a JS error for a buffer over 2 GiB, which NewDirectByteBuffer cannot represent and ART aborts on.

2. Typed arrays passed to array parameters were type confusion. When the call's signature is already resolved, the same code handed the direct buffer to an array parameter. Two examples:

• java.nio.ByteBuffer.wrap(u8), where wrap(byte[]) is the only one-argument overload;
• java.lang.String.format("%s", f32), whose varargs parameter is Object[].

Without CheckJNI (release builds) Java then uses a DirectByteBuffer as an array. Debug builds abort:

JNI ERROR (app bug): attempt to pass an instance of java.nio.DirectByteBuffer as argument 1 to java.nio.ByteBuffer java.nio.ByteBuffer.wrap(byte[])
JNI ERROR (app bug): attempt to pass an instance of java.nio.ByteBufferAsFloatBuffer as argument 2 to java.lang.String java.lang.String.format(java.lang.String, java.lang.Object[])

The value is now copied into a new Java array of the parameter's type, which is the same copy semantics plain JS arrays already have:

Any other typed array is converted element by element, exactly like a plain JS array holding the same numbers. For example:

• Float64Array → int[] truncates through ToInt32;
• Uint8Array → boolean[] maps non-zero values to true;
• Int32Array → Object[] boxes each element.

These combinations throw Cannot convert <Type> to <signature> at index N:

• a BigInt array for anything but long[];
• an ArrayBuffer/DataView for anything but byte[];
• any typed array for a nested array type such as int[][].

Overload resolution is unchanged. Whether a typed array should select a byte[] overload among several candidates is a separate decision. This PR only fixes the conversion once the signature is resolved.

3. Converting a large JS array to a primitive array overflowed the stack. ConvertJavaScriptArray built the Java array's contents in a stack array (VLA) sized by the JS array's length. A 4M-element array passed to int[] (16 MB) overflowed the main thread's stack, and worker threads have much smaller stacks. The contents are now built in a heap buffer.

4. A reused typed array could lose its Java buffer for good. This sequence broke the typed array for every later Java call:

1. JS drops a typed array, and its buffer becomes weakly held on the Java side.
2. Java hands the same buffer back to JS, which gets the original typed array.
3. Java lets go of the buffer and it is collected.
4. JS passes the typed array to Java again, and the call fails with Failed to get Java object by ID ... Attempt to use cleared object reference.

Now, when a typed array's link points at a collected buffer, the runtime asks Java to confirm that the buffer is gone (Runtime.releaseIfCollected). Only then does it drop the stale registrations on both sides (the Java object table entry and the native link state) and link a new buffer over the same memory. A link whose buffer Java still holds is never released, since that would leave the buffer pointing at memory nothing keeps alive.

5. Unconvertible JS array elements aborted the process. Converting a plain JS array to a Java array used ToChecked()/ToLocalChecked() on every element read. A BigInt or Symbol element, a throwing getter or a throwing valueOf therefore aborted with SIGTRAP. These now throw Cannot convert array to <signature> at index N: <reason>, for example ... [J at index 0: TypeError: Cannot convert a BigInt value to a number.

Arrays reject BigInt elements because scalar long parameters already reject BigInt. The scalar error message used to be empty because the message buffer was never filled; it now reads Cannot convert bigint to J at index N.

6. Over-long arrays aborted the process. A JS array or typed array longer than a Java array can be (more than 2^31 − 1 elements, for example a sparse [] with length = 2 ** 31) now fails with the usual conversion error instead of aborting.

Known hazards, not addressed here: the Java buffer points straight at the V8 backing store. If JS detaches that ArrayBuffer (transfer(), or a transfer through postMessage) or shrinks a resizable one while Java still holds the buffer, Java reads freed or stale memory. This is unchanged by this PR.

Does your commit message include the wording below to reference a specific issue in this repo?

No issue.

Related Pull Requests

None.

Does your pull request have unit tests?

Yes. testTypedArrayArgs.js has 18 specs, with a helper class com.tns.tests.TypedArrayArgs that has one single-overload method per array parameter type. The specs cover:

• copy semantics for ByteBuffer.wrap(Uint8Array);
• view offsets and lengths;
• every same-layout pairing;
• element-wise conversion matching plain arrays, including Object[] parameters;
• the rejected combinations;
• empty typed and plain arrays;
• 60,000 distinct typed arrays to an Object parameter, and as Object[] elements;
• the Java buffer being collectable after JS drops the typed array;
• a held buffer's memory staying valid after JS drops the typed array and GC runs;
• a 4M-element JS array to int[];
• relinking a reused typed array after Java collected its buffer;
• BigInt, Symbol, throwing-getter and throwing-valueOf elements, plus BigInt to a scalar long;
• an array longer than a Java array can be.

Verified on an API 36 arm64 emulator (debug build, CheckJNI on).

Full suite (./gradlew runtestsAndVerifyResults): 1545 specs, 0 failures. That is the 1527 existing specs plus the 18 new ones.

Summary by CodeRabbit

• New Features
  • JavaScript typed arrays and array buffers can now be passed to Java methods as compatible primitive arrays or buffers.
  • Typed-array views and buffers support conversion to Java arrays, including element-by-element conversion when types differ. Buffer views preserve their offsets, and oversized inputs are rejected.
• Tests
  • Added coverage for typed-array and buffer conversions, empty and large inputs, buffer references, and conversion errors.