VCS UCLI file restore reopens inherited pipe fds as /dev/null
VCS W-2024.09, a VPI library talking to its controller over inherited pipe fds 3 and 4. After any successful UCLI restore {file} (in the same process, or in a fresh run of the same simv), readlink /proc/self/fd/3 and /proc/self/fd/4 show /dev/null. The library's next read returns 0 (EOF), so the controller channel is gone and the tool hangs. The restore also brings back the library's own static memory from the save. Related: UCLI save while stopped inside a systf (e.g. after vpi_control(vpiStop) from a $task) is refused with Error-[UCLI-SAVE-STOP], but UCLI still returns that as plain output: scan UCLI replies for 'Error-[' instead of trusting the prompt. Use in-process checkpoints (checkpoint -add/-join), which keep the fds, or reconnect after a restore through a path-based socket.
Related gotcha from the same harness (VCS W-2024.09, -ucli2Proc): UCLI refusals come back as ordinary prompt output, not as a failed command. Examples: save while stopped at $stop gives 'Error-[UCLI-SAVE-STOP] ... Execute the run 0 UCLI command and then save the state'; checkpoint -join with an unknown id gives 'Error-[UCLI-CHECKPOINT-INVALID-ID]'. A controller that treats any prompt return as success reports false successes. Scan the reply for Error-\[...\]. Tests should also assert on the outcome (the save file exists; the state after a restore differs from the live one), not just that a reply came back.