[GH-ISSUE #108] Hopper analysis continues after timeout and close_binary, retaining 4 GB RSS #68

New issue

Closed

opened 2026-10-15 18:20:46 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:20:46 +00:00

Owner

Originally created by @morluto on GitHub (Jul 13, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/108

Summary

Opening a large stripped Rust Mach-O through REA causes Hopper analysis to exceed the 120-second REA timeout. After the timeout, Hopper continues analyzing in the background. close_binary returns OK but does not cancel the analysis or release the document; RSS continued growing until Hopper was manually terminated.

Environment

REA: 1.2.0
Hopper: 6.1.0-demo (build 42.6295552)
macOS host reported by rea doctor: 26.3
Architecture: Apple arm64
Subject: Grok CLI 0.2.99, Mach-O arm64
Subject SHA-256: 01bcacec12e7c2a164d23975f1595400ff7f3cbd74f50b1858f6a5a14eb9ff81
Subject size: 129,124,976 bytes
Mach-O shape: 93,239,936-byte __text, 20,135,184-byte __TEXT.__const, 6,803,476-byte __eh_frame, only 474 symbols

Reproduction

npx -y rea-agents doctor reports healthy.
Open the binary with open_binary.
Call binary_overview with detailed output.
REA returns HopperTimeoutError: Hopper did not respond within 120000ms.
Observe Hopper RSS after the timeout.
Call close_binary; it returns OK.
Observe Hopper still running and growing.

The equivalent CLI rea analyze <path> --detail detailed also timed out after 120 seconds.

Observed memory

Hopper RSS after timeout: approximately 3,683,936 KiB
Hopper RSS after close_binary returned OK: approximately 4,079,648 KiB
No Grok process was running.
Memory was released only after manually terminating Hopper.

Expected behavior

A provider timeout should cancel or otherwise terminate the outstanding Hopper analysis request.
close_binary should wait for cancellation and release the opened document/provider resources, or return an explicit failure if it cannot.
At minimum, REA should not report OK while the provider remains busy with the closed target.

Likely contributing workload

This is a monolithic, mostly stripped, statically linked Rust binary. Hopper has to recover structure across roughly 93 MB of code with little symbol guidance. That explains why analysis is expensive, but not why timeout and close fail to stop it. A bounded analysis mode or provider-process memory guard may also be useful for this class of artifact.

Originally created by @morluto on GitHub (Jul 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/108 ## Summary Opening a large stripped Rust Mach-O through REA causes Hopper analysis to exceed the 120-second REA timeout. After the timeout, Hopper continues analyzing in the background. `close_binary` returns `OK` but does not cancel the analysis or release the document; RSS continued growing until Hopper was manually terminated. ## Environment - REA: 1.2.0 - Hopper: 6.1.0-demo (build 42.6295552) - macOS host reported by `rea doctor`: 26.3 - Architecture: Apple arm64 - Subject: Grok CLI 0.2.99, Mach-O arm64 - Subject SHA-256: `01bcacec12e7c2a164d23975f1595400ff7f3cbd74f50b1858f6a5a14eb9ff81` - Subject size: 129,124,976 bytes - Mach-O shape: 93,239,936-byte `__text`, 20,135,184-byte `__TEXT.__const`, 6,803,476-byte `__eh_frame`, only 474 symbols ## Reproduction 1. `npx -y rea-agents doctor` reports healthy. 2. Open the binary with `open_binary`. 3. Call `binary_overview` with detailed output. 4. REA returns `HopperTimeoutError: Hopper did not respond within 120000ms`. 5. Observe Hopper RSS after the timeout. 6. Call `close_binary`; it returns `OK`. 7. Observe Hopper still running and growing. The equivalent CLI `rea analyze <path> --detail detailed` also timed out after 120 seconds. ## Observed memory - Hopper RSS after timeout: approximately 3,683,936 KiB - Hopper RSS after `close_binary` returned `OK`: approximately 4,079,648 KiB - No Grok process was running. - Memory was released only after manually terminating Hopper. ## Expected behavior - A provider timeout should cancel or otherwise terminate the outstanding Hopper analysis request. - `close_binary` should wait for cancellation and release the opened document/provider resources, or return an explicit failure if it cannot. - At minimum, REA should not report `OK` while the provider remains busy with the closed target. ## Likely contributing workload This is a monolithic, mostly stripped, statically linked Rust binary. Hopper has to recover structure across roughly 93 MB of code with little symbol guidance. That explains why analysis is expensive, but not why timeout and close fail to stop it. A bounded analysis mode or provider-process memory guard may also be useful for this class of artifact.

bsakaguchi

2026-10-15 18:20:46 +00:00