[PR #3642] [CLOSED] fix(flutter): recognize single-snapshot Dart AOT symbols in inspect_dart_aot #5863

Closed
opened 2026-10-31 01:10:00 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/3642
Author: @PabloDev24
Created: 10/14/2026
Status: ❌ Closed

Base: main ← Head: fix/3629-dart-aot-single-snapshot-symbols


📝 Commits (1)

  • d285296 fix(flutter): recognize single-snapshot Dart AOT symbols in inspect_dart_aot

📊 Changes

6 files changed (+169 additions, -18 deletions)

View changed files

📝 docs/flutter-analysis.md (+7 -4)
📝 src/domain/flutter/flutterBuildAnalysis.ts (+2 -0)
📝 src/flutter/FlutterBuildProvider.ts (+54 -14)
📝 tests/boundary/filesystem/flutterBuildProvider.test.ts (+104 -0)
📝 tests/boundary/mcp/dartAotSummaryMcp.test.ts (+1 -0)
📝 tests/boundary/mcp/flutterMcp.test.ts (+1 -0)

📄 Description

Summary

Fixes #3629. inspect_dart_aot refused libapp.so files built with current Dart toolchains because it only looked up the four legacy snapshot symbols. It now also recognizes the single-snapshot symbols and reports which layout it found.

Problem and expected behavior

Dart commit d36adbacaf ("[vm] Remove the VM isolate") renamed the snapshot symbols to _kDartSnapshotData and _kDartSnapshotText. Such a libapp.so was refused with unsupported_target ("No recognizable Dart snapshot symbols were found"), even though identify_flutter_build succeeds on the same APK.

Expected: the new symbols are recognized next to the legacy four, the layout found is reported, and when neither set is present the error stays unsupported_target and names both expected sets.

Change and scope

  • src/flutter/FlutterBuildProvider.ts: the legacy layout is tried first; the single-snapshot layout is used only when none of the legacy symbols are exported. Expected coverage (header count and hash sources) is derived from the selected layout instead of a fixed pair.
  • src/domain/flutter/flutterBuildAnalysis.ts: adds libapp.snapshot_layout (vm_isolate_pair | single_snapshot) to the inspect_dart_aot result schema.
  • docs/flutter-analysis.md documents both layouts.
  • Not included: _kDartSnapshotBuildId is not read (it is not a snapshot section), and the hash header kind/layout checks are unchanged.

Contract and boundary impact

  • Semantic owner and earliest changed stage: Flutter provider, ELF symbol selection in inspect_dart_aot.
  • Contribution scope fit and linked maintainer decision: not applicable (fix within an existing boundary).
  • CLI and MCP/tool-catalog contract: inspect_dart_aot output gains the required field libapp.snapshot_layout; no input change.
  • Provider, bridge, target-format, or platform compatibility: legacy-layout output is unchanged apart from the new field.
  • Evidence, artifact, provenance, or reconstruction contract: unsupported/partial outcomes stay visible; a missing symbol in the selected layout still reports partial coverage.
  • Generated metadata impact: unknown; I did not regenerate or check docs/public/product-catalog.json.

Expected effects:

  • Read existing files or captured data.
  • Launch or attach to a process.
  • Inject instrumentation or run scripts/code.
  • Change process memory, registers, files, or configuration.
  • Contact network services.
  • Recover protected code or work around protections.
  • Documentation or usability only; no target interaction.
  • Not sure yet; investigation or maintainer guidance needed.

Evidence and regression coverage

Executed evidence on synthetic ELF64 fixtures only.

  • Tests added or updated: tests/boundary/filesystem/flutterBuildProvider.test.ts adds a complete single-snapshot case, a single-snapshot case missing its text symbol (partial), and an error-message case naming both symbol sets; the legacy end-to-end case now asserts vm_isolate_pair. Two hand-written MCP result fixtures gain the new field.
  • Base reproduction or other evidence: with the provider change stashed, the new tests fail on the base revision.
  • Remaining proof gaps: not run against the public Saber 1.36.1 APK from the issue; other ABIs and the first Dart release containing the rename are unchecked.

Validation performed

  • npx vitest run tests/boundary/filesystem/flutterBuildProvider.test.ts tests/boundary/mcp/flutterMcp.test.ts tests/boundary/mcp/dartAotSummaryMcp.test.ts — 3 files, 103 tests passed
  • npx vitest run src/flutter — passed
  • npx tsc --noEmit — no errors
  • npm run verify:module-boundaries — passed
  • npx oxfmt on the changed files — applied
  • Full test suite, scripts/verify-flutter.mjs, and real-provider coverage — not run

Compatibility, safety, and release

  • Breaking changes or migration steps: none; the new output field is additive for callers.
  • Real Hopper/Ghidra, browser, or OS coverage: not applicable.
  • Package or release metadata impact: none expected.
  • Security, privacy, process, or containment review: read-only parsing through the existing bounds-checked ELF symbol reader.

Author readiness

Human owner:

  • I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
  • I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
  • I declare this PR ready for initial maintainer review.

Before merge

  • This PR addresses a concrete problem or an agreed enhancement.
  • Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff.
  • The PR has one focused outcome and the title follows type(scope): outcome.
  • Related issue is linked, or the reason for not linking one is stated above.
  • Tests cover changed observable behavior and meaningful failure paths.
  • Owning docs, contracts, and generated metadata are updated where needed.
  • User-visible CLI/MCP changes include representative output.
  • I checked the final diff for secrets, unrelated cleanup, and unsupported claims.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/3642 **Author:** [@PabloDev24](https://github.com/PabloDev24) **Created:** 10/14/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/3629-dart-aot-single-snapshot-symbols` --- ### 📝 Commits (1) - [`d285296`](https://github.com/morluto/rea/commit/d2852969312e465562efa9fb825deda594face73) fix(flutter): recognize single-snapshot Dart AOT symbols in inspect_dart_aot ### 📊 Changes **6 files changed** (+169 additions, -18 deletions) <details> <summary>View changed files</summary> 📝 `docs/flutter-analysis.md` (+7 -4) 📝 `src/domain/flutter/flutterBuildAnalysis.ts` (+2 -0) 📝 `src/flutter/FlutterBuildProvider.ts` (+54 -14) 📝 `tests/boundary/filesystem/flutterBuildProvider.test.ts` (+104 -0) 📝 `tests/boundary/mcp/dartAotSummaryMcp.test.ts` (+1 -0) 📝 `tests/boundary/mcp/flutterMcp.test.ts` (+1 -0) </details> ### 📄 Description ## Summary Fixes #3629. `inspect_dart_aot` refused `libapp.so` files built with current Dart toolchains because it only looked up the four legacy snapshot symbols. It now also recognizes the single-snapshot symbols and reports which layout it found. ## Problem and expected behavior Dart commit `d36adbacaf` ("[vm] Remove the VM isolate") renamed the snapshot symbols to `_kDartSnapshotData` and `_kDartSnapshotText`. Such a `libapp.so` was refused with `unsupported_target` ("No recognizable Dart snapshot symbols were found"), even though `identify_flutter_build` succeeds on the same APK. Expected: the new symbols are recognized next to the legacy four, the layout found is reported, and when neither set is present the error stays `unsupported_target` and names both expected sets. ## Change and scope - `src/flutter/FlutterBuildProvider.ts`: the legacy layout is tried first; the single-snapshot layout is used only when none of the legacy symbols are exported. Expected coverage (header count and hash sources) is derived from the selected layout instead of a fixed pair. - `src/domain/flutter/flutterBuildAnalysis.ts`: adds `libapp.snapshot_layout` (`vm_isolate_pair` | `single_snapshot`) to the `inspect_dart_aot` result schema. - `docs/flutter-analysis.md` documents both layouts. - Not included: `_kDartSnapshotBuildId` is not read (it is not a snapshot section), and the hash header kind/layout checks are unchanged. ## Contract and boundary impact - Semantic owner and earliest changed stage: Flutter provider, ELF symbol selection in `inspect_dart_aot`. - Contribution scope fit and linked maintainer decision: not applicable (fix within an existing boundary). - CLI and MCP/tool-catalog contract: `inspect_dart_aot` output gains the required field `libapp.snapshot_layout`; no input change. - Provider, bridge, target-format, or platform compatibility: legacy-layout output is unchanged apart from the new field. - Evidence, artifact, provenance, or reconstruction contract: unsupported/partial outcomes stay visible; a missing symbol in the selected layout still reports partial coverage. - Generated metadata impact: unknown; I did not regenerate or check `docs/public/product-catalog.json`. Expected effects: - [x] Read existing files or captured data. - [ ] Launch or attach to a process. - [ ] Inject instrumentation or run scripts/code. - [ ] Change process memory, registers, files, or configuration. - [ ] Contact network services. - [ ] Recover protected code or work around protections. - [ ] Documentation or usability only; no target interaction. - [ ] Not sure yet; investigation or maintainer guidance needed. ## Evidence and regression coverage Executed evidence on synthetic ELF64 fixtures only. - Tests added or updated: `tests/boundary/filesystem/flutterBuildProvider.test.ts` adds a complete single-snapshot case, a single-snapshot case missing its text symbol (partial), and an error-message case naming both symbol sets; the legacy end-to-end case now asserts `vm_isolate_pair`. Two hand-written MCP result fixtures gain the new field. - Base reproduction or other evidence: with the provider change stashed, the new tests fail on the base revision. - Remaining proof gaps: not run against the public Saber 1.36.1 APK from the issue; other ABIs and the first Dart release containing the rename are unchecked. ## Validation performed - `npx vitest run tests/boundary/filesystem/flutterBuildProvider.test.ts tests/boundary/mcp/flutterMcp.test.ts tests/boundary/mcp/dartAotSummaryMcp.test.ts` — 3 files, 103 tests passed - `npx vitest run src/flutter` — passed - `npx tsc --noEmit` — no errors - `npm run verify:module-boundaries` — passed - `npx oxfmt` on the changed files — applied - Full test suite, `scripts/verify-flutter.mjs`, and real-provider coverage — not run ## Compatibility, safety, and release - Breaking changes or migration steps: none; the new output field is additive for callers. - Real Hopper/Ghidra, browser, or OS coverage: not applicable. - Package or release metadata impact: none expected. - Security, privacy, process, or containment review: read-only parsing through the existing bounds-checked ELF symbol reader. ## Author readiness Human owner: <!-- @PabloDev24 --> - [x] I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work. - [x] I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps. - [x] I declare this PR ready for initial maintainer review. ## Before merge - [ ] This PR addresses a concrete problem or an agreed enhancement. - [ ] Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff. - [ ] The PR has one focused outcome and the title follows `type(scope): outcome`. - [ ] Related issue is linked, or the reason for not linking one is stated above. - [ ] Tests cover changed observable behavior and meaningful failure paths. - [ ] Owning docs, contracts, and generated metadata are updated where needed. - [ ] User-visible CLI/MCP changes include representative output. - [ ] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
bsakaguchi 2026-10-31 01:10:00 +00:00
Sign in to join this conversation.
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#5863
No description provided.