[GH-ISSUE #2532] fix(ghidra): missing Java bitness is reported as a 0-bit runtime #848

New issue

Closed

opened 2026-10-15 18:28:58 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-15 18:28:58 +00:00

Owner

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

Summary

When a Java settings probe reports version, home, and VM name but omits bitness, Ghidra inspection describes the runtime as 0-bit and returns an unsupported-version failure. The probe did not establish that bitness. This is a diagnostic defect; refusing admission while bitness remains unknown is appropriate.

Runtime or environment

Repository revision 8b181716ac, Node v26.10.0, npm 11.19.1, and locked dependencies. A controlled shell program was executed through the real system Java probe. No real JDK omitting the property was identified, and Ghidra was not launched.

Steps to reproduce

Create a disposable absolute installation root with Ghidra/application.properties containing application.version=12.1.4 and application.java.min=21, each on its own line.
Create a disposable absolute JDK home with executable bin/javac that exits successfully. Make executable bin/java print settings lines java.version = 21.0.11, java.home = <absolute fixture JDK home>, and java.vm.name = OpenJDK 64-Bit Server VM, then exit zero. Omit sun.arch.data.model.
Call inspectGhidraInstallation with those absolute roots, an empty environment, and Linux x64 host coordinates, using the system host. Read its check named java. Doctor uses this same inspector for the configured installation and JDK.
Repeat with sun.arch.data.model = 32, then with sun.arch.data.model = 64. The local focused probe executed all three cases once. Compare the Java check rather than overall availability, since this fixture does not supply Ghidra native tools.

Expected behavior

The Java check should preserve the observed version, home, runtime kind, and VM name while describing bitness as unknown. It must refuse admission until the required 64-bit identity is established, without claiming that an unreported value is a measured incompatible bitness.

Actual behavior

The missing-property case returned a failed Java check with unsupported_version and a detail containing 21.0.11; 0-bit; JDK. The 32-bit control was refused as 32-bit, and the 64-bit control passed the Java check. The observations came from a controlled settings-output program, not a real Java implementation.

Evidence

Expected source: AGENTS.md, Architecture and Cleanup, requires unresolved identity to remain unknown and boundary parsing to preserve partial facts and meaningful failure reasons; docs/installation.md:544 describes Java bitness inspection.
Failure source: src/ghidra/GhidraInstallation.ts:767 substitutes zero for an absent bitness property, and src/ghidra/GhidraInstallation.ts:670 formats that as a determined bitness in the Java check. The focused probe reached both through real subprocess output parsing. src/ghidra/GhidraDoctor.ts:66 connects doctor to this inspector.
Evidence provenance: observed
Local verification: reproduced
Reproduction completeness: complete

Read-only issue searches found no matching report. The existing unresolved-version branch concerns the installation's declared Java range and does not establish the required error code for unknown bitness.

Restoration check

Repeat the incomplete-settings fixture. The Java check must remain refused but identify bitness as unknown without claiming a 0-bit runtime; preserve the established facts. The 32-bit control must remain refused as a known incompatible runtime, and the eligible 64-bit control must continue passing the Java check.

Triage assessment

Impact level: P3
Assessment status: supported
Impact basis: The established defect is false diagnostic wording and classification for an incomplete probe. The desired correction retains refusal, and no actual supported JDK affected by omission was established.
Workaround status: unverified
Workaround basis: Selecting a JDK that reports bitness avoids the fixture's symptom, but an available replacement for an actual affected installation was not established.

Originally created by @coygeek on GitHub (Oct 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2532 ## Summary When a Java settings probe reports version, home, and VM name but omits bitness, Ghidra inspection describes the runtime as 0-bit and returns an unsupported-version failure. The probe did not establish that bitness. This is a diagnostic defect; refusing admission while bitness remains unknown is appropriate. ## Runtime or environment Repository revision 8b181716aca2cb467be499cba226abfb5ae19141, Node v26.10.0, npm 11.19.1, and locked dependencies. A controlled shell program was executed through the real system Java probe. No real JDK omitting the property was identified, and Ghidra was not launched. ## Steps to reproduce 1. Create a disposable absolute installation root with `Ghidra/application.properties` containing `application.version=12.1.4` and `application.java.min=21`, each on its own line. 2. Create a disposable absolute JDK home with executable `bin/javac` that exits successfully. Make executable `bin/java` print settings lines `java.version = 21.0.11`, `java.home = <absolute fixture JDK home>`, and `java.vm.name = OpenJDK 64-Bit Server VM`, then exit zero. Omit `sun.arch.data.model`. 3. Call `inspectGhidraInstallation` with those absolute roots, an empty environment, and Linux x64 host coordinates, using the system host. Read its check named `java`. Doctor uses this same inspector for the configured installation and JDK. 4. Repeat with `sun.arch.data.model = 32`, then with `sun.arch.data.model = 64`. The local focused probe executed all three cases once. Compare the Java check rather than overall availability, since this fixture does not supply Ghidra native tools. ## Expected behavior The Java check should preserve the observed version, home, runtime kind, and VM name while describing bitness as unknown. It must refuse admission until the required 64-bit identity is established, without claiming that an unreported value is a measured incompatible bitness. ## Actual behavior The missing-property case returned a failed Java check with `unsupported_version` and a detail containing `21.0.11; 0-bit; JDK`. The 32-bit control was refused as 32-bit, and the 64-bit control passed the Java check. The observations came from a controlled settings-output program, not a real Java implementation. ## Evidence - Expected source: `AGENTS.md`, Architecture and Cleanup, requires unresolved identity to remain unknown and boundary parsing to preserve partial facts and meaningful failure reasons; `docs/installation.md:544` describes Java bitness inspection. - Failure source: `src/ghidra/GhidraInstallation.ts:767` substitutes zero for an absent bitness property, and `src/ghidra/GhidraInstallation.ts:670` formats that as a determined bitness in the Java check. The focused probe reached both through real subprocess output parsing. `src/ghidra/GhidraDoctor.ts:66` connects doctor to this inspector. - Evidence provenance: observed - Local verification: reproduced - Reproduction completeness: complete Read-only issue searches found no matching report. The existing unresolved-version branch concerns the installation's declared Java range and does not establish the required error code for unknown bitness. ## Restoration check Repeat the incomplete-settings fixture. The Java check must remain refused but identify bitness as unknown without claiming a 0-bit runtime; preserve the established facts. The 32-bit control must remain refused as a known incompatible runtime, and the eligible 64-bit control must continue passing the Java check. ## Triage assessment - Impact level: P3 - Assessment status: supported - Impact basis: The established defect is false diagnostic wording and classification for an incomplete probe. The desired correction retains refusal, and no actual supported JDK affected by omission was established. - Workaround status: unverified - Workaround basis: Selecting a JDK that reports bitness avoids the fixture's symptom, but an available replacement for an actual affected installation was not established.

bsakaguchi

2026-10-15 18:28:58 +00:00

closed this issue
added the
area: native

bug
labels

bsakaguchi commented

2026-10-15 18:28:59 +00:00

Author

Owner

@morluto commented on GitHub (Oct 14, 2026):

Verified the reported defect is addressed on main by 85f960ccc1.

Root cause and resolution: Missing or malformed Java bitness was coerced to numeric zero and reported as a known unsupported 0-bit runtime.

Validation: tests/boundary/filesystem/ghidraJavaProbe.test.ts — Omitted, empty, malformed and unsafe-integer bitness remain unresolved and never become 0-bit; a known 32-bit control remains explicitly unsupported.

Evidence: CI run 500e: owner unchanged and assertions passed.

Verification scope: Controlled Java probe output; no real JDK/Ghidra launch.

Current main CI has separate failures under repair; this closure does not claim the complete main workflow is green.

@morluto commented on GitHub (Oct 14, 2026): Verified the reported defect is addressed on main by 85f960ccc10ab8c3822aa3976643a0b55b2a12e4. Root cause and resolution: Missing or malformed Java bitness was coerced to numeric zero and reported as a known unsupported 0-bit runtime. Validation: `tests/boundary/filesystem/ghidraJavaProbe.test.ts` — Omitted, empty, malformed and unsafe-integer bitness remain unresolved and never become `0-bit`; a known 32-bit control remains explicitly unsupported. Evidence: CI run 500e: owner unchanged and assertions passed. Verification scope: Controlled Java probe output; no real JDK/Ghidra launch. Current main CI has separate failures under repair; this closure does not claim the complete main workflow is green.

bsakaguchi referenced this issue

2026-10-16 21:02:34 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi referenced this issue

2026-10-16 21:16:46 +00:00

[PR #848] [MERGED] feat(javascript): recover readable modules with Wakaru #2286

bsakaguchi referenced this issue

2026-10-17 21:12:14 +00:00

[PR #1540] [MERGED] fix(javascript): accept the Wakaru 1.x release line and verify 1.14.0 #2956