[collegeming]

What this fixes

Two descriptor-lifetime defects in the daemon. Both are reachable in normal operation and both close descriptors the code no longer owns.

1. SerialPipe closes adopted pipe ends twice. The constructor hands both local ends to FDPipeConsoleStream, which adopts them into ParcelFileDescriptor; the stream is the sole owner from then on. close() closed the stream first (releasing those numbers) and then closed the saved integers again. If the kernel hands a released number to another FileInputStream in between, the second close takes that one down. closeRemoteFd() also tested pipe_out while reading pipe_in.

2. NativeDisplayInputBridge.release() is not atomic. Two concurrent releases can read the same slot map and close the same listening descriptors twice, and the accept loop had no way to stop without another thread closing descriptors it was still using.

Why it matters

On a 0.0.6.r242.g3348830 build, one VM shutdown left the daemon dead:

fdsan: attempted to close file descriptor 114, expected to be unowned, actually owned by FileInputStream
Fatal signal 6 (SIGABRT) in tid 19033 (DefaultRouterWa), pid 18608 (droidvmd)
  #03 libopenjdk.so (UNIXProcess_forkAndExec)
  #06 java.lang.ProcessImpl.start
  #09 java.lang.Runtime.exec
  #14 cn.classfun.droidvm.daemon.network.backend.Netbox.query
  #15 cn.classfun.droidvm.daemon.network.backend.DefaultRouterWatcher.reconcileRules

That abort is a raw close of a number owned by a Java stream while Runtime.exec was building its process pipes: the pipe bookkeeping held a descriptor that someone else had already closed and the kernel had reused. Both defects produce exactly this shape (close of an adopted end after the stream already released it, with a reuse window). I am not claiming it is the only possible source of that abort; what is certain is that both paths close descriptors they do not own, and the serial one runs on every VM stop.

Changes

• SerialPipe now delegates its descriptor bookkeeping to a small SerialPipeFds owner. It records which ends were transferred to the stream, detaches before invoking any closer, and never raw-closes a transferred end. close() and closeRemoteFd() are serialized. Constructor failure closes only ends that were not adopted.
• NativeDisplayInputBridge gives each generation a NativeInputSocketOwner. startListening/release are serialized and detach the map atomically; release closes only the wake-pipe writer, whose HUP wakes poll, while the accept worker closes the listener and read end after its last syscall. The listener is non-blocking so a readiness that disappeared cannot leave accept parked. Duplicate slots are rejected before binding, and an old worker never unlinks a path a newer generation owns.

Tests

SerialPipeFdsTest and NativeInputSocketOwnerTest are plain JUnit tests, no Android or JNI:

• descriptor number reused immediately after a close (the failure this patch prevents),
• close after closeRemoteFd, reentrant closer, concurrent full/remote close,
• partial transfer failure in the constructor,
• stop before the worker starts, concurrent stop, and an old generation after its numbers were reused.

Local static checks (check_ascii, check_string_concat, check_arity, check_translations, check_vector_icons) pass on this branch.

I could not run this on a device: installing a modified APK requires the project signing key, and updating with a different key would wipe app data. If you build a signed dev APK with this applied, I can run the VM start/stop and input-session lifecycle on a Xiaomi tablet (Android 17, arm64, gfxstream and PanVK routes) and report the result here.

Not changed

• If the constructor fails after adoptFd, that end stays with the caller's stream (the caller keeps the stream and closes it on normal VM teardown). Reclaiming it immediately would need a targeted release API on FDPipeConsoleStream; that is left out of this change.
• No JNI change, no fdsan suppression, no signature or install changes.

[BigfootACA]

Please rebase your commits and fix conflicts