De Bryan Henderson, mantenedor do netpbm:
I found and fixed a bug that causes this symptom. [...] The fix is in Netpbm 10.64.02.
The difference in environment that causes Pnmtops sometimes to hang and sometimes not is the number of open files. If there are more than 10 open files when Pnmtops gets invoked, the hang happens.
In case you care what the pathology is: The child exits when the pipe feeding it signals EOF. That happens when every copy of the file descriptor for the sending end of the pipe closes. The only copy that's supposed to exist is the one the parent process is writing data to. But the child necessarily inherits copies of the file descriptors for both ends of the pipe. If the child doesn't close its copy of the sending end of the pipe, the child will never see EOF on the receiving end, so will wait forever.
That means the child must close its copy of the sending end of the pipe that is feeding it. To do this, and fix some other similar problems, the child attempts at startup to close every file descriptor besides the two it actually uses. But POSIX doesn't provide a way to know the list of open file descriptors, so the child just blindly closes 0-9 (excluding the two it needs), knowing that Pnmtops would not use more files than that. The mistake was that the program didn't account for file descriptors the process was born with. The fix is for Pnmtops to close file descriptors 0-9 when it starts up, so that any pipes it creates will have file descriptor numbers in the range 0-9 and thus get closed by the blind 0-9 close.