Bug 1029512

Summary:	Bug in netpbm introduced in 10.56 causing hangs during pnmtops conversion
Product:	[Fedora] Fedora	Reporter:	Raman Gupta <rocketraman>
Component:	netpbm	Assignee:	Jindrich Novy <novyjindrich>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	19	CC:	novyjindrich, phracek
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	netpbm-10.61.02-8.fc20	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1031514 1037756 (view as bug list)		Environment:
Last Closed:	2013-12-21 02:16:27 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Bug Depends On:
Bug Blocks:	1031514

Description Raman Gupta 2013-11-12 14:08:50 UTC

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 13:28:23 UTC

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 06:04:04 UTC

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 12:48:24 UTC

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 4 Petr Hracek 2013-12-12 12:52:48 UTC

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

Comment 5 Fedora Update System 2013-12-12 13:18:08 UTC

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 16:33:19 UTC

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 18:08:44 UTC

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 08:05:43 UTC

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 08:55:50 UTC

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 23:04:31 UTC

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 13:45:15 UTC

Thanks, it works now!

Comment 12 Fedora Update System 2013-12-21 02:16:27 UTC

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 08:43:03 UTC

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.