Bug 1029512 - Bug in netpbm introduced in 10.56 causing hangs during pnmtops conversion
Bug in netpbm introduced in 10.56 causing hangs during pnmtops conversion
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: netpbm (Show other bugs)
19
All Linux
unspecified Severity high
: ---
: ---
Assigned To: Jindrich Novy
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 1031514
  Show dependency treegraph
 
Reported: 2013-11-12 09:08 EST by Raman Gupta
Modified: 2014-01-03 03:43 EST (History)
2 users (show)

See Also:
Fixed In Version: netpbm-10.61.02-8.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1031514 1037756 (view as bug list)
Environment:
Last Closed: 2013-12-20 21:16:27 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Raman Gupta 2013-11-12 09:08:50 EST
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
Comment 1 Petr Hracek 2013-11-13 08:28:23 EST
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.
Comment 2 Raman Gupta 2013-11-14 01:04:04 EST
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.
Comment 3 Fedora Update System 2013-12-12 07:48:24 EST
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
Comment 5 Fedora Update System 2013-12-12 08:18:08 EST
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
Comment 6 Fedora Update System 2013-12-12 11:33:19 EST
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).
Comment 7 Raman Gupta 2013-12-13 13:08:44 EST
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>
Comment 8 Petr Hracek 2013-12-16 03:05:43 EST
The is prepared by I forgot to add them into SPEC file for F19.
It is awful fault from my side.
Comment 9 Fedora Update System 2013-12-16 03:55:50 EST
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
Comment 10 Fedora Update System 2013-12-16 18:04:31 EST
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).
Comment 11 Raman Gupta 2013-12-17 08:45:15 EST
Thanks, it works now!
Comment 12 Fedora Update System 2013-12-20 21:16:27 EST
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.
Comment 13 Fedora Update System 2014-01-03 03:43:03 EST
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.

Note You need to log in before you can comment on or make changes to this bug.