morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 07:47:29 +00:00

[GH-ISSUE #8499] Windows x64: JADX bridge JVM stalls opening `engine.jar`, MCP connect times out (6.8.0) #6625

New issue

Open

opened 2026-11-01 21:12:46 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-01 21:12:46 +00:00

Owner

Originally created by @korsmotion on GitHub (Nov 1, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8499

Summary

On Windows x64, every Android JADX operation fails after about 30 seconds with Request timed out, before any JADX tool call. It fails the same way through CLI and MCP. rea doctor --provider jadx passes and binary_session reports the Android tools as available.

A thread dump taken during the failure shows the bridge JVM's main thread inside java.io.RandomAccessFile.open0 while opening a JAR from its class path. The only class-path entry is REA's workspace snapshot engine.jar. The JVM makes no further progress until REA ends it, so it never reads the initialize request.

The same bridge source, JAR and MCP client connect in under 2 seconds when the JAR is used from its original path outside REA's launcher.

Environment

rea-agents 6.8.0 (via npx), @modelcontextprotocol/client 2.3.1
Windows 11 Home 10.0.26300, x64, local NTFS
Node.js 26.13.0
jadx-headless-mcp 0.7.1 -all.jar, SHA-256 6e5eacf500b64292bfb73c49797c1958f6ee44646e43e868039ae7feb573ff75
Bridge rea-jadx-bridge 7, SHA-256 e5044a8312dd0731f53af3f095508b3e5cff54df6b971c95d4305e2f39b4fa30
Tested JDKs: Temurin 25.0.5+8, Android Studio JBR 21.0.10
Target: Appium ApiDemos-debug.apk v6.0.18, SHA-256 a9eecf37b26cd084855c530db81c2bb1b91f4c1b095a04f47aa7c20e2791f686
JAVA_TOOL_OPTIONS, _JAVA_OPTIONS, JDK_JAVA_OPTIONS and REA_JADX_HEAP_MIB unset; Defender real-time protection off; 63.7 GB RAM

Steps to reproduce

$env:JAVA_HOME = '<absolute path to JDK>'
$env:REA_JADX_MCP_JAR = '<absolute path to jadx-headless-mcp-0.7.1-all.jar>'
npx -y rea-agents@6.8.0 doctor --provider jadx --json
npx -y rea-agents@6.8.0 inspect-android-package '<absolute path to ApiDemos-debug.apk>' --json

The MCP path reproduces with REA_JADX_MCP_JAR in the server registration, after a client restart, by calling inspect_android_package.

Expected

Package metadata is returned.

Actual

code: capability_unavailable
category: unsupported_provider
Java could not start REA's Android bridge using <JDK>\bin\java.exe: Request timed out.
No launcher stderr was observed.

captured_output has empty stdout and stderr with exit_code: 1. partial_observation has calls: [], server_name: null, server_version: null, engine_version: null. The JAR and bridge hashes are reported correctly.

Run	JDK	Result
MCP `inspect_android_package`, server restarted with the JAR configured	25.0.5	Timeout
CLI, three runs	25.0.5	Timeout
CLI, one run	JBR 21.0.10	Timeout

Failure-time observations

Bridge process command line under REA:

java.exe --class-path <TEMP>\rea-android-<id>\engine.jar <TEMP>\rea-android-<id>\ReaJadxBridge.java

Sampling one run every 4 seconds, from t=4 s to t=29 s: process CPU stayed at 0.156 s, working set at 47-48 MB, and threads at 19-22. At t=33 s the process was shutting down.

jcmd <pid> Thread.print at about 6.5 s of JVM uptime, in a separate run:

"main" #3 prio=5 os_prio=0 cpu=78.12ms elapsed=6.55s nid=27896 runnable
   java.lang.Thread.State: RUNNABLE
	at java.io.RandomAccessFile.open0(java.base@25.0.5/Native Method)
	at java.io.RandomAccessFile.open(java.base@25.0.5/RandomAccessFile.java:338)
	at java.io.RandomAccessFile.<init>(java.base@25.0.5/RandomAccessFile.java:257)
	at java.io.RandomAccessFile.<init>(java.base@25.0.5/RandomAccessFile.java:211)
	at java.util.zip.ZipFile$Source.<init>(java.base@25.0.5/ZipFile.java:1539)
	at java.util.zip.ZipFile$Source.get(java.base@25.0.5/ZipFile.java:1506)
	at java.util.zip.ZipFile$CleanableResource.<init>(java.base@25.0.5/ZipFile.java:704)
	at java.util.zip.ZipFile.<init>(java.base@25.0.5/ZipFile.java:204)
	at java.util.zip.ZipFile.<init>(java.base@25.0.5/ZipFile.java:150)
	at java.util.jar.JarFile.<init>(java.base@25.0.5/JarFile.java:333)
	at jdk.internal.loader.URLClassPath$JarLoader.getJarFile(java.base@25.0.5/URLClassPath.java:682)
	...

The JVM reported java_class_path (initial): <TEMP>\rea-android-<id>\engine.jar, and java_command was SourceLauncher <TEMP>\rea-android-<id>\ReaJadxBridge.java.

At the same moment, Windows reported one thread in Wait, Executive. Whether that thread is main was not established.

The dump is a single sample, but it agrees with the flat CPU over the whole failure window.

Passing checks outside REA's launcher

Same machine, same JAR at its original path, JDK 25, and a copy of bridge/android/ReaJadxBridge.java in an ordinary directory:

Check	Result
`javac -proc:none -cp <jar>` on the bridge	Passes in about 1 s
`java --class-path <jar> ReaJadxBridge.java` with empty stdin	Starts and registers tools, about 1 s
Python piped stdio, one `initialize` for `2025-06-18`	Reply in 1.2 s
Python piped stdio, one `initialize` for `2026-07-28`	Reply in 1.2 s, server falls back to `2025-11-25`
Node `child_process` pipes with `Client` from `@modelcontextprotocol/client` 2.3.1	Connected in 1707 ms, server `rea-jadx-bridge` 7

Analysis

Observed: the JVM's main thread is in a native file open on the class-path JAR, and the process then uses no further CPU. This fits the MCP connect timeout, since the bridge's stdio server never starts. The 30-second limit appears to be dist/android/JadxSession.js:49; REA_JADX_OPERATION_TIMEOUT_MS does not apply to it.

Inferred, not proven: something specific to the REA workspace blocks that open. Differences from the passing runs are the snapshot copy of the JAR, the guardian-owned private-DACL workspace root, and the Windows owned-process launcher with a Job Object.

Unknown: the blocking mechanism. No handle, ACL or kernel trace of engine.jar was captured, so a lingering REA handle, a sharing or DACL interaction, and any filesystem filter all remain open. The MCP-path run was not thread-dumped; only its error matches.

This does not look like a Java version issue or a stdin/stdout framing issue. The JVM stalls before the bridge's main code runs.

#3111 is a different failure, but on the same Windows build and with the same JAR and APK digests. A retest there reported inspect-android-package succeeding on 6.5.0. That report used Node 22 and JDK 17, so this may be a regression or specific to the newer Node runtime; neither was tested here.

Not tested

Other Windows hosts.
Snapshot engine.jar used from a plain directory, or the same private workspace with an ordinary java launch.

Request

Please check what can block a reader of engine.jar between snapshot creation and JVM start on Windows, including any handle still open on the snapshot and the private DACL applied to the workspace. Reporting the JVM's state, or a thread dump, when connect times out would also make this failure easier to classify than "could not start".

Originally created by @korsmotion on GitHub (Nov 1, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8499 ## Summary On Windows x64, every Android JADX operation fails after about 30 seconds with `Request timed out`, before any JADX tool call. It fails the same way through CLI and MCP. `rea doctor --provider jadx` passes and `binary_session` reports the Android tools as available. A thread dump taken during the failure shows the bridge JVM's main thread inside `java.io.RandomAccessFile.open0` while opening a JAR from its class path. The only class-path entry is REA's workspace snapshot `engine.jar`. The JVM makes no further progress until REA ends it, so it never reads the `initialize` request. The same bridge source, JAR and MCP client connect in under 2 seconds when the JAR is used from its original path outside REA's launcher. ## Environment - rea-agents 6.8.0 (via `npx`), `@modelcontextprotocol/client` 2.3.1 - Windows 11 Home 10.0.26300, x64, local NTFS - Node.js 26.13.0 - jadx-headless-mcp 0.7.1 `-all.jar`, SHA-256 `6e5eacf500b64292bfb73c49797c1958f6ee44646e43e868039ae7feb573ff75` - Bridge `rea-jadx-bridge` 7, SHA-256 `e5044a8312dd0731f53af3f095508b3e5cff54df6b971c95d4305e2f39b4fa30` - Tested JDKs: Temurin 25.0.5+8, Android Studio JBR 21.0.10 - Target: Appium ApiDemos-debug.apk v6.0.18, SHA-256 `a9eecf37b26cd084855c530db81c2bb1b91f4c1b095a04f47aa7c20e2791f686` - `JAVA_TOOL_OPTIONS`, `_JAVA_OPTIONS`, `JDK_JAVA_OPTIONS` and `REA_JADX_HEAP_MIB` unset; Defender real-time protection off; 63.7 GB RAM ## Steps to reproduce ```powershell $env:JAVA_HOME = '<absolute path to JDK>' $env:REA_JADX_MCP_JAR = '<absolute path to jadx-headless-mcp-0.7.1-all.jar>' npx -y rea-agents@6.8.0 doctor --provider jadx --json npx -y rea-agents@6.8.0 inspect-android-package '<absolute path to ApiDemos-debug.apk>' --json ``` The MCP path reproduces with `REA_JADX_MCP_JAR` in the server registration, after a client restart, by calling `inspect_android_package`. ## Expected Package metadata is returned. ## Actual ```text code: capability_unavailable category: unsupported_provider Java could not start REA's Android bridge using <JDK>\bin\java.exe: Request timed out. No launcher stderr was observed. ``` `captured_output` has empty stdout and stderr with `exit_code: 1`. `partial_observation` has `calls: []`, `server_name: null`, `server_version: null`, `engine_version: null`. The JAR and bridge hashes are reported correctly. | Run | JDK | Result | | --- | --- | --- | | MCP `inspect_android_package`, server restarted with the JAR configured | 25.0.5 | Timeout | | CLI, three runs | 25.0.5 | Timeout | | CLI, one run | JBR 21.0.10 | Timeout | ## Failure-time observations Bridge process command line under REA: ```text java.exe --class-path <TEMP>\rea-android-<id>\engine.jar <TEMP>\rea-android-<id>\ReaJadxBridge.java ``` Sampling one run every 4 seconds, from t=4 s to t=29 s: process CPU stayed at 0.156 s, working set at 47-48 MB, and threads at 19-22. At t=33 s the process was shutting down. `jcmd <pid> Thread.print` at about 6.5 s of JVM uptime, in a separate run: ```text "main" #3 prio=5 os_prio=0 cpu=78.12ms elapsed=6.55s nid=27896 runnable java.lang.Thread.State: RUNNABLE at java.io.RandomAccessFile.open0(java.base@25.0.5/Native Method) at java.io.RandomAccessFile.open(java.base@25.0.5/RandomAccessFile.java:338) at java.io.RandomAccessFile.<init>(java.base@25.0.5/RandomAccessFile.java:257) at java.io.RandomAccessFile.<init>(java.base@25.0.5/RandomAccessFile.java:211) at java.util.zip.ZipFile$Source.<init>(java.base@25.0.5/ZipFile.java:1539) at java.util.zip.ZipFile$Source.get(java.base@25.0.5/ZipFile.java:1506) at java.util.zip.ZipFile$CleanableResource.<init>(java.base@25.0.5/ZipFile.java:704) at java.util.zip.ZipFile.<init>(java.base@25.0.5/ZipFile.java:204) at java.util.zip.ZipFile.<init>(java.base@25.0.5/ZipFile.java:150) at java.util.jar.JarFile.<init>(java.base@25.0.5/JarFile.java:333) at jdk.internal.loader.URLClassPath$JarLoader.getJarFile(java.base@25.0.5/URLClassPath.java:682) ... ``` The JVM reported `java_class_path (initial): <TEMP>\rea-android-<id>\engine.jar`, and `java_command` was `SourceLauncher <TEMP>\rea-android-<id>\ReaJadxBridge.java`. At the same moment, Windows reported one thread in `Wait, Executive`. Whether that thread is `main` was not established. The dump is a single sample, but it agrees with the flat CPU over the whole failure window. ## Passing checks outside REA's launcher Same machine, same JAR at its original path, JDK 25, and a copy of `bridge/android/ReaJadxBridge.java` in an ordinary directory: | Check | Result | | --- | --- | | `javac -proc:none -cp <jar>` on the bridge | Passes in about 1 s | | `java --class-path <jar> ReaJadxBridge.java` with empty stdin | Starts and registers tools, about 1 s | | Python piped stdio, one `initialize` for `2025-06-18` | Reply in 1.2 s | | Python piped stdio, one `initialize` for `2026-07-28` | Reply in 1.2 s, server falls back to `2025-11-25` | | Node `child_process` pipes with `Client` from `@modelcontextprotocol/client` 2.3.1 | Connected in 1707 ms, server `rea-jadx-bridge` 7 | ## Analysis Observed: the JVM's main thread is in a native file open on the class-path JAR, and the process then uses no further CPU. This fits the MCP connect timeout, since the bridge's stdio server never starts. The 30-second limit appears to be `dist/android/JadxSession.js:49`; `REA_JADX_OPERATION_TIMEOUT_MS` does not apply to it. Inferred, not proven: something specific to the REA workspace blocks that open. Differences from the passing runs are the snapshot copy of the JAR, the guardian-owned private-DACL workspace root, and the Windows owned-process launcher with a Job Object. Unknown: the blocking mechanism. No handle, ACL or kernel trace of `engine.jar` was captured, so a lingering REA handle, a sharing or DACL interaction, and any filesystem filter all remain open. The MCP-path run was not thread-dumped; only its error matches. This does not look like a Java version issue or a stdin/stdout framing issue. The JVM stalls before the bridge's main code runs. ## Related - #3111 is a different failure, but on the same Windows build and with the same JAR and APK digests. A retest there reported `inspect-android-package` succeeding on 6.5.0. That report used Node 22 and JDK 17, so this may be a regression or specific to the newer Node runtime; neither was tested here. ## Not tested - Other Windows hosts. - Snapshot `engine.jar` used from a plain directory, or the same private workspace with an ordinary `java` launch. ## Request Please check what can block a reader of `engine.jar` between snapshot creation and JVM start on Windows, including any handle still open on the snapshot and the private DACL applied to the workspace. Reporting the JVM's state, or a thread dump, when connect times out would also make this failure easier to classify than "could not start".

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#6625

No description provided.

Rows
Columns

[GH-ISSUE #8499] Windows x64: JADX bridge JVM stalls opening engine.jar, MCP connect times out (6.8.0) #6625