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]