Bug #73074 for Pod-Perldoc: ToMan output blocks on perlfunc

Wed Dec 07 12:19:55 2011 ppisar [...] redhat.com - Ticket created

Subject:

ToMan output blocks on perlfunc

3.15_10 (and 3.15.11) cannot process perlfunc.pod from perl-5.14.2. perlpod stops sending any output to roff: $ perldoc -D -F /usr/share/perl5/pod/perlfunc.pod Ending switch processing. Args are [/usr/share/perl5/pod/perlfunc.pod] with 0 errors. /usr/bin/perldoc => Pod::Perldoc v3.15_10 Formatter class Pod::Perldoc::ToMan version 3.15_10 successfully loaded! Will format with the class Pod::Perldoc::ToMan Searching for /usr/share/perl5/pod/perlfunc.pod Version 3.15_04 from perl-5.14.2 bundle can handle this POD file. I found the problem occurs when processing line 2591: 2582 print hex '0xAf'; # prints '175' 2583 print hex 'aF'; # same 2584 2585 Hex strings may only represent integers. Strings that would cause 2586 integer overflow trigger a warning. Leading whitespace is not stripped, 2587 unlike oct(). To present something as hex, look into L</printf>, 2588 L</sprintf>, and L</unpack>. 2589 2590 =item import LIST 2591 X<import> If I truncate the POD before the line, this new perlpod works. Output to different formats (unformated or text) works always.

Thu Dec 08 11:13:26 2011 ppisar [...] redhat.com - Correspondence added

Subject:	Re: [rt.cpan.org #73074] AutoReply: ToMan output blocks on perlfunc
Date:	Thu, 8 Dec 2011 17:13:13 +0100
To:	Bugs in Pod-Perldoc via RT <bug-Pod-Perldoc [...] rt.cpan.org>
From:	Petr Pisar <ppisar [...] redhat.com>

The problem appears first with commit bd0cf70fb668af400923efc7fce921b2625ba68e merged from podman branch. These times podman blocks on different line. But the whole perlfunc page still works as effective testcase. -- Petr

Fri Dec 09 04:44:20 2011 bdfoy [...] cpan.org - Correspondence added

It looks like this is related to the length of the input file, not anything in the file itself. I have a pipe to groff that looks like it needs to write in chunks instead of sending the entire file at once.

Fri Dec 09 04:44:21 2011 The RT System itself - Status changed from 'new' to 'open'

Fri Dec 09 08:04:48 2011 bdfoy [...] cpan.org - Correspondence added

I think I've fixed this in 3.15_012. Give it a try. By reading from the bi-directional pipe as I write to it, I let groff keep doing it's work. I think it fills up its output buffer otherwise and then refuses to read more. The patch is a bit rough, but it's there.

Fri Dec 09 08:04:49 2011 bdfoy [...] cpan.org - Status changed from 'open' to 'patched'

Fri Dec 09 08:47:31 2011 ppisar [...] redhat.com - Correspondence added

Subject:	Re: [rt.cpan.org #73074] ToMan output blocks on perlfunc
Date:	Fri, 9 Dec 2011 14:47:17 +0100
To:	brian d foy via RT <bug-Pod-Perldoc [...] rt.cpan.org>
From:	Petr Pisar <ppisar [...] redhat.com>

On Fri, Dec 09, 2011 at 08:04:49AM -0500, brian d foy via RT wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=73074 > > > I think I've fixed this in 3.15_012. Give it a try. >

The HEAD of master branch as well as 6ce4cbd97873fe234d7c35538b62f2c4516ce57c (RT #73074 Read from the groff) work on perlfunc for me very well. Thank you. Show quoted text

> By reading from the bi-directional pipe as I write to it, I let groff keep > doing it's work. I think it fills up its output buffer otherwise and then > refuses to read more. The patch is a bit rough, but it's there.

I don't think this an issue of groff. If I use perldoc `-n' argument to call fake processor (cat in shell script), I get the same results. So this is generic issue of pipe buffers in kernel (that thay are not infinite). `getconf -a | grep PIPE' returns 4096 on my system. -- Petr

Fri Dec 09 08:47:32 2011 The RT System itself - Status changed from 'patched' to 'open'

Sat Dec 10 01:18:26 2011 bdfoy [...] cpan.org - Status changed from 'open' to 'patched'

Sat Dec 10 01:18:26 2011 bdfoy [...] cpan.org - Severity Critical added

Fri Mar 16 23:42:34 2012 mrallen1 [...] yahoo.com - Status changed from 'patched' to 'resolved'