On Sat, Nov 11, 2006 at 12:00:42AM +0100, Frank Lichtenheld wrote:
I spent some time on this bug and so far I can tell that the infinit
loop is located at Mail/Mbox/MessageParser/Grep.pm, line 373. This is
code from the libmail-mbox-messageparser-perl package so this bug
might actually belong there.
Yes, there is a bug there; however, AFAICS that's only the symptom and not
the cause. I'm Cc-ing the libmail-mbox-messageparser-perl maintainer, as the
bug seems to be in that package (or at least it's buggy anyhow).
my $length_to_read =
$CACHE-{$self-{'file_name'}}{'emails'}[$self-{'CURRENT_EMAIL_INDEX'}]{'length'};
$length_to_read is actually undef here.
The reason is the following set of lines in read_next_email():
$self-{'email_line_number'} =
$CACHE-{$self-{'file_name'}}{'emails'}[$self-{'email_number'}]{'line_number'};
$self-{'email_offset'} =
$CACHE-{$self-{'file_name'}}{'emails'}[$self-{'email_number'}]{'offset'};
In this particular case, $self-{'email_number'} is larger than the last
index, which creates a new empty element on-the-fly (autovivification), which
is of course bogus. Part of the reason seems to be that _adjust_cache_data()
somehow merges or deletes messages without adjusting email_number; I'm not
really sure what it is supposed to do.
There is also a $self-{'CURRENT_EMAIL_INDEX'} which I think somehow might be
more relevant, but it's not actually documented anywhere, and the relation
between the two variables are somehow odd. (email_number is something that
comes from the base class, though.)
If I had to guess, I'd assume $self-{'email_number'} was somehow a _logical_
message number, and thus unfit for any sort of indexing. That's a guess,
though.
my $total_amount_read = 0;
do {
$total_amount_read += read($self-{'file_handle'},
$self-{'READ_BUFFER'},
$length_to_read-$total_amount_read, length($self-{'READ_BUFFER'}));
} while ($total_amount_read != $length_to_read);
I've tried adjusting this to handle EOF (0) and error (-1) correctly, but of
course, as long as $length_to_read = undef, the test will fail anyhow (and
you get warnings on stderr).
On a related note, I'm a bit unsure how this test can have passed before. The
code likes to call GNU grep; on a wild guess, perhaps some change there
triggered this?
/* Steinar */
--
Homepage: http://www.sesse.net/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
