Skip to content

File handles leak when the owning shell job is killed (File is already open for writing) #649

Open
#667
Open
File handles leak when the owning shell job is killed (File is already open for writing)#649
#667
Labels
agent/needs-infoThe agent has posted clarifying questions; waiting for the reporter.area/fsfs/ — filesystem drivers (FAT, ext2, HFS+, NTFS, ISO9660, ExFAT).kind/bugConfirmed bug report with a repro or stack trace.

Description

@LSantha
LSantha
opened on Sep 17, 2026

Summary

When a shell job holding a file open for writing is killed via job control (Ctrl-C), its file handle is never released. Any later attempt to open the same path for writing fails with File is already open for writing until the VM is rebooted.

Environment

  • JNode 0.2.9-dev (x86 32-bit), VirtualBox 7.2.6, serial console
  • Observed 2026-09-17

Reproduction

  1. Start any long-running job that holds a FileOutputStream, e.g.: 
    java MauveDriver force /devices/hdb1/l2w/d5.txt /devices/hdb1/l2w/s5.txt
  2. Kill it with Ctrl-C (serial --interrupt, delivered as guest job-control ETX). The shell prints a stack trace showing the job died inside MauveDriver.main.
  3. Re-run the identical command: 
    java MauveDriver force /devices/hdb1/l2w/d5.txt /devices/hdb1/l2w/s5.txt
    dies during startup with: 
    Caused by: java.io.IOException: File is already open for writing
    at org.jnode.fs.service.def.FileHandleManager$FileData.open(FileHandleManager.java:...)
    at org.jnode.fs.service.def.FileHandleManager.open(FileHandleManager.java:...)
    at org.jnode.fs.service.def.FileSystemAPIImpl.open(FileSystemAPIImpl.java:...)
    at gnu.java.nio.channels.FileChannelImpl.open(FileChannelImpl.java:...)
    ...
  4. Only a reboot clears the condition; every fresh output filename works exactly once.

Expected behavior

Thread death (including kill-by-job-control) releases that thread's file handles — or at minimum, close() from another thread / a subsequent open is able to reclaim them. A single Ctrl-C should not permanently burn a pathname for the rest of the uptime.

Suspected component

org.jnode.fs.service.def.FileHandleManager — handle table keyed without cleanup on VmThread termination. (Normal close() path works; only the killed-thread path leaks.)

Impact

Breaks the standard run-kill-retry loop for long guest-side jobs: every killed run forces the operator to mint a fresh output filename (or reboot), which complicates automated test harnesses.

Triage Addendum (auto, 2026-09-24)

  • Area / Kind: area/fs (Sub: generic VFS file-handle manager; filesystem type not identified) / kind/bug
  • Blast radius: L1 class (FileHandleManager/FileHandleImpl in org.jnode.fs.service.def); cleanup behavior may touch the file-write path, but the implementation entry points are not yet confirmed
  • Expected scope: Inspect and update fs/src/fs/org/jnode/fs/service/def/FileHandleManager.java and its handle implementation, with a focused lifecycle regression test; do not change ASM, public APIs, or unrelated shell behavior
  • Test path: sh build.sh -f fs/build-tests.xml all-junit, plus a 32-bit QEMU/VirtualBox run reproducing the kill-and-reopen sequence
  • Merge signal: human-review (filesystem write-path behavior; requires VM-level verification)
  • Gaps: exact build target, filesystem/device identification, and complete boot/run reproduction are missing; these are blocking for DEV
  • Full report: ## Triage comment below.

✅ Ticket Runner Status

Field Value
Phase DONE
Turn 0/3
Retries 2/3
PR -
Started 2026-09-25T03:14:13.215Z

Activity

  1. LSantha
    added
    kind/bugConfirmed bug report with a repro or stack trace.
    area/fsfs/ — filesystem drivers (FAT, ext2, HFS+, NTFS, ISO9660, ExFAT).
    on Sep 17, 2026
  2. LSantha
    added
    no-autoSkip all automation; human drives via /oc and /run only.
    on Sep 24, 2026

  3. LSantha commented on Sep 24, 2026

    @LSantha
    LSantha
    on Sep 24, 2026
    OwnerAuthor

    /oc triage

  4. LSantha commented on Sep 24, 2026

    @LSantha
    LSantha
    on Sep 24, 2026
    OwnerAuthor

    Triage

    • Area: area/fs (Sub: generic VFS file-handle manager; filesystem type not identified)
    • Kind: kind/bug
    • Repro: needs more info from reporter
    • Blast radius: L1 class (FileHandleManager/FileHandleImpl in org.jnode.fs.service.def); cleanup behavior may touch the file-write path, but the implementation entry points are not yet confirmed
    • Expected scope: Inspect and update fs/src/fs/org/jnode/fs/service/def/FileHandleManager.java and its handle implementation, with a focused lifecycle regression test; do not change ASM, public APIs, or unrelated shell behavior
    • Test path: sh build.sh -f fs/build-tests.xml all-junit, plus a 32-bit QEMU/VirtualBox run reproducing the kill-and-reopen sequence
    • Merge signal: human-review (filesystem write-path behavior; requires VM-level verification)
    • Gaps: exact build target, filesystem/device identification, and complete boot/run reproduction are missing; these are blocking for DEV
    • Suggested next: needs-info
    • Split proposal: none - likely focused if the missing runtime details keep the fix within the file-handle package
    • Labels applied: kind/bug, area/fs, no-auto (audit confirmed; no removals)

    Auto-run: skipped (no-auto)

    Needs the following before work can start:

    1. Which exact build command and target produced the tested ISO (sh build.sh <target>)?
    2. What filesystem is mounted at /devices/hdb1, and what device/mount setup command created it?
    3. What exact VirtualBox/QEMU command and serial --interrupt sequence was used, including the 20–60 line log around the first killed job and retry?

  5. LSantha commented on Sep 24, 2026

    @LSantha
    LSantha
    on Sep 24, 2026
    OwnerAuthor

    (empty)

    New%20session%20-%202026-09-24T22%3A02%3A25.115Z
    opencode session  |  github run

  6. LSantha
    added
    agent/needs-infoThe agent has posted clarifying questions; waiting for the reporter.
    and removed
    no-autoSkip all automation; human drives via /oc and /run only.
    on Sep 24, 2026

  7. LSantha commented on Sep 25, 2026

    @LSantha
    LSantha
    on Sep 25, 2026
    OwnerAuthor

    /run

  8. LSantha commented on Sep 25, 2026

    @LSantha
    LSantha
    on Sep 25, 2026
    OwnerAuthor

    /oc Please proceed with this task.

  9. LSantha commented on Sep 25, 2026

    @LSantha
    LSantha
    on Sep 25, 2026
    OwnerAuthor

    🤖 Working on this. Run: automatic
    Plan: inspect FileHandleManager and VmThread lifecycle; implement the smallest thread-safe cleanup fix; add focused regression coverage; run filesystem tests and validation.

  10. LSantha
    added
    agent/in-progressThe OpenCode agent is currently working on this issue.
    and removed
    agent/in-progressThe OpenCode agent is currently working on this issue.
    on Sep 25, 2026

  11. LSantha commented on Sep 25, 2026

    @LSantha
    LSantha
    on Sep 25, 2026
    OwnerAuthor

    /oc Please proceed with this task.

  12. LSantha commented on Sep 25, 2026

    @LSantha
    LSantha
    on Sep 25, 2026
    OwnerAuthor

    /oc Please proceed with this task.

  13. LSantha commented on Sep 25, 2026

    @LSantha
    LSantha
    on Sep 25, 2026
    OwnerAuthor

    Created PR #667

    New%20session%20-%202026-09-25T04%3A48%3A18.895Z
    opencode session  |  github run

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    agent/needs-infoThe agent has posted clarifying questions; waiting for the reporter.area/fsfs/ — filesystem drivers (FAT, ext2, HFS+, NTFS, ISO9660, ExFAT).kind/bugConfirmed bug report with a repro or stack trace.

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions