Bug 68663 - IO::Handle::getline returning bogus output in perl-5.8.0
IO::Handle::getline returning bogus output in perl-5.8.0
Status: CLOSED RAWHIDE
Product: Red Hat Public Beta
Classification: Retired
Component: perl (Show other bugs)
limbo
i386 Linux
high Severity high
: ---
: ---
Assigned To: Chip Turner
David Lawrence
:
Depends On:
Blocks: 67218
  Show dependency treegraph
 
Reported: 2002-07-12 02:10 EDT by Jonathan Kamens
Modified: 2005-10-31 17:00 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-07-17 17:35:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
perl script illustrating a bug in the Perl internals (397 bytes, text/plain)
2002-07-12 02:11 EDT, Jonathan Kamens
no flags Details

  None (edit)
Description Jonathan Kamens 2002-07-12 02:10:28 EDT
I reproduced the following problem both with the version of perl-5.8.0 in Limbo
and the current Rawhide version (5.8.0-31).

Install MIME-tools-5.411, MailTools-1.44, and IO-stringy-2.108 from CPAN.  Then
run the attached script while cd'd into /tmp.  It will hang:

jik:/tmp!177> perl /tmp/test.pl
MIME-tools: debug:    process_header
MIME-tools: debug:    field param <boundary> = <foobar>
MIME-tools: debug:    type = multipart, subtype = alternative
MIME-tools: debug:    process_multipart...
MIME-tools: debug:    field param <boundary> = <foobar>
MIME-tools: debug:    field param <boundary> = <foobar>
MIME-tools: debug:    parsing part 1...
MIME-tools: debug:       process_header
MIME-tools: debug:    field param <charset> = <us-ascii>
MIME-tools: debug:       type = text, subtype = plain
MIME-tools: debug:       process_singlepart...
MIME-tools: debug:       using temp file
MIME-tools: debug:       t bound:  0 wallclock secs ( 0.00 usr +  0.00 sys = 
0.00 CPU)
MIME-tools: debug:       extract uuencode? 0
MIME-tools: debug:       encoding?         quoted-printable
MIME-tools: debug:    field param <charset> = <us-ascii>
MIME-tools: debug:       effective type?   text/plain
MIME-tools: debug:    field param <charset> = <us-ascii>
MIME-tools: debug:       no filename recommended: synthesizing our own
MIME-tools: debug:    field param <charset> = <us-ascii>
MIME-tools: debug:    field param <charset> = <us-ascii>
MIME-tools: debug:       planning to use 'msg-12850-1.txt'
MIME-tools: debug:       outputting body to disk file: ./msg-12850-1.txt
MIME-tools: debug:    field param <charset> = <us-ascii>

If you look in /tmp, you will see that the most recently modified file,
msg-<whatever>-1.txt, is growing larger and larger -- the script is appending
blank lines to it repeatedly.  This will continue forever until you kill the script.

I managed to track the problem down to this function in
/usr/lib/perl5/5.8.0/i386-linux-thread-multi/IO/Handle.pm:

sub getline {
    @_ == 1 or croak 'usage: $io->getline()';
    my $this = shift;
    return scalar <$this>;
} 

For some reason, this function is returning the last line of the input file over
and over again.  This is so even though <$this> evaluates to undef and eof $this
is true.  I made the problem go away by modifying the function above as follows:

sub getline {
    @_ == 1 or croak 'usage: $io->getline()';
    my $this = shift;
    my $val = <$this>;
    return $val;
}

These changes should not have been necessary.  There is clearly some sort of
internal Perl bug here.
Comment 1 Jonathan Kamens 2002-07-12 02:11:06 EDT
Created attachment 65084 [details]
perl script illustrating a bug in the Perl internals
Comment 2 Chip Turner 2002-07-15 08:20:32 EDT
Can you come up with a smaller testcase to reproduce this issue?  The smaller
the test case (preferably not requiring so many external modules) the easier it
is to determine the real problem and get it fixed.
Comment 3 Jonathan Kamens 2002-07-15 08:23:07 EDT
I tried to reduce the test case but failed.  I really don't think that
installing three CPAN modules is a particularly onerous task.  I don't have any
more time to spend on tracking down this bug; I already spent quite a bit of
time on it.
Comment 4 Jonathan Kamens 2002-07-15 12:54:17 EDT
Confirmed bug still present in perl-5.8.0-33.
Comment 5 Jonathan Kamens 2002-07-17 06:50:01 EDT
Confirm bug still present in perl-5.8.0-35.
Comment 6 Chip Turner 2002-07-17 17:35:23 EDT
This seems to now work:

[root@maxrod root]# rpm -q perl
perl-5.8.0-38
[root@maxrod root]# perl test-mime.pl 
MIME::Parser: 5.406 
MIME::Tools: 5.411 
Mail::Util: 1.47
IO::Scalar 2.104 
MIME-tools: debug:    process_header
MIME-tools: debug:    field param <boundary> = <foobar>
MIME-tools: debug:    type = multipart, subtype = alternative
MIME-tools: debug:    process_multipart...
MIME-tools: debug:    field param <boundary> = <foobar>
MIME-tools: debug:    field param <boundary> = <foobar>
MIME-tools: debug:    parsing part 1...
MIME-tools: debug:       process_header
MIME-tools: debug:    field param <charset> = <us-ascii>
MIME-tools: debug:       type = text, subtype = plain
MIME-tools: debug:       process_singlepart...
MIME-tools: debug:       using temp file
MIME-tools: debug:       t bound:  0 wallclock secs ( 0.00 usr +  0.00 sys = 
0.00 CPU)
MIME-tools: debug:       extract uuencode? 0
MIME-tools: debug:       encoding?         quoted-printable
MIME-tools: debug:    field param <charset> = <us-ascii>
MIME-tools: debug:       effective type?   text/plain
MIME-tools: debug:    field param <charset> = <us-ascii>
MIME-tools: debug:       no filename recommended: synthesizing our own
MIME-tools: debug:    field param <charset> = <us-ascii>
MIME-tools: debug:    field param <charset> = <us-ascii>
MIME-tools: debug:       planning to use 'msg-7173-1.txt'
MIME-tools: debug:       outputting body to disk file: ./msg-7173-1.txt
MIME-tools: debug:    field param <charset> = <us-ascii>
MIME-tools: debug:       t decode:  0 wallclock secs ( 0.00 usr +  0.00 sys = 
0.00 CPU)
MIME-tools: debug:    process_epilogue
MIME-tools: debug: t parse:  0 wallclock secs ( 0.02 usr +  0.00 sys =  0.02 CPU)

The file created seems correct, and there is no looping.  Note I am running
slightly more recent versions of the same modules, so this may be a factor. 
Please test and let me know if you still have issues.
Comment 7 Jonathan Kamens 2002-07-19 15:39:33 EDT
You're right, it appears to be fixed.  Woohoo!

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