Hide Forgot
Description of problem: I was having a problem with netpbm. The forked child process pnmtops creates was never exiting, causing pnm to ps transformations to fail. Based on an email conversation with the maintainer, Bryan Henderson, he was able to fix the bug in 10.64.02. Here is the email from him: I found and fixed a bug that causes this symptom. It was introduced in Netpbm 10.56 (September 2011), so it doesn't explain the claim in the Macports bug report that the problem doesn't happen with Netpbm 10.62, but maybe that was just a mistake. 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. -- Bryan Henderson San Jose, California
In F19 we currently has netpbm-10.61.02. Do you have any test scenario? If I will find the patch then it will be in F19 immediatelly. But as I mentioned above some scenario would be good.
My particular scenario was here: http://unix.stackexchange.com/questions/93384/pnmtops-subprocess-hang-when-called-from-a-scanadf-script However, this is very easy to replicate by calling pnmtops from the following wrapper script: -------------------------------- #!/bin/bash # This opens several file descriptor's in order to lock up pnmtops < 10.64.02 exec 3<> $(mktemp -t tmp.descriptor.XXXXXX) exec 4<> $(mktemp -t tmp.descriptor.XXXXXX) exec 5<> $(mktemp -t tmp.descriptor.XXXXXX) exec 6<> $(mktemp -t tmp.descriptor.XXXXXX) exec 7<> $(mktemp -t tmp.descriptor.XXXXXX) exec 8<> $(mktemp -t tmp.descriptor.XXXXXX) exec 9<> $(mktemp -t tmp.descriptor.XXXXXX) exec pnmtops $@ -------------------------------- After commenting out the creation of the additional file descriptors above, everything works fine.
netpbm-10.61.02-8.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/netpbm-10.61.02-8.fc20
scm-commit (https://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-20131209/1157442.html) -> switched to MODIFIED. Test scenario description is above or http://unix.stackexchange.com/questions/93384/pnmtops-subprocess-hang-when-called-from-a-scanadf-script
netpbm-10.61.02-6.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/netpbm-10.61.02-6.fc19
Package netpbm-10.61.02-8.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing netpbm-10.61.02-8.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-23278/netpbm-10.61.02-8.fc20 then log in and leave karma (feedback).
The updated package does not work. When using pnmtops via the replication script given above in comment #2, it still hangs: ./pnmtops_bad -version pnmtops: Using libnetpbm from Netpbm Version: Netpbm 10.61.2 pnmtops: Compiled Thu Dec 12 12:53:21 UTC 2013 by user "mockbuild" pnmtops: BSD defined pnmtops: RGB_ENV='RGBDEF' pnmtops: RGBENV= 'RGBDEF' (env vbl is unset) $ ./pnmtops_repro_1029512 -verbose < circle.pnm > circle.ps pnmtops: Input maxval is 1. Postscript raster will have 1 bits per sample, so maxval = 1 pnmtops: Image will be 192.00 points wide by 192.00 points high, left edge 210.00 points from left edge of page, bottom edge 300.00 points from bottom of page; NOT turned to landscape orientation pnmtops: output filter spawned: pid 25785 pnmtops: Waiting for PID 25785 to exit <hang>
The is prepared by I forgot to add them into SPEC file for F19. It is awful fault from my side.
netpbm-10.61.02-7.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/netpbm-10.61.02-7.fc19
Package netpbm-10.61.02-7.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing netpbm-10.61.02-7.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-23474/netpbm-10.61.02-7.fc19 then log in and leave karma (feedback).
Thanks, it works now!
netpbm-10.61.02-7.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
netpbm-10.61.02-8.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.