2012/3/21 Daniel Hartwig <mand...@gmail.com>:
>> ---------- Forwarded message ----------
>> From: LimCore DebianBug <debian...@limcore.pl>
>> To: sub...@bugs.debian.org
>
>> aptitude crashes when doing anything (like install foo) while parsing data.
>> [...]
>> so the file
>> /var/lib/apt/lists/192.168.44.20:9999_debian_dists_stable_main_binary-i386_Packages
>> is perhaps corrupted
>>
>> ---------- Forwarded message ----------
>> From: "Manuel A. Fernandez Montecelo" <manuel.montez...@gmail.com>
>> To: 411338-d...@bugs.debian.org
>
>> This bug report provides very detailed information but unfortunately
>> was never handled. It's a report from 5 years ago but obviously its
>> effects are not present today ("aptitude crashes when doing anything
>> (like install foo) while parsing data").
>
> Hi Manual
>
> This bug has been on my list to investigate when I have a large enough
> block of time, so the results of your investigation are of interest to
> me :-)
>
> The original report concludes that this is due to a corrupted list
> file, that 'apt-get update' will clear the problem, but aptitude
> commands fail.
>
> When determining that the effects are "obviously" not present today,
> did you check this after updating using a list file corrupted in a
> similar way?
>
> It is difficult to determine precisely the corruption present,
> however, the user has provided the final chunk read from the file
> which may provide a clue.
>
>
> There is enough information in this report to identify a small area of
> the code (either in aptitude or apt) that can be examined to determine
> the problem which appears to be in one of the list or dependency
> parsers.
>
> When presented with corrupt data the software needs to be robust
> enough to handle the situation sanely, especially as a segfault like
> this can lead to further corruption/loss of data.
So more than 5 years ago, one user reports that "aptitude crashes when
doing anything (like install foo) while parsing data", followed by a
very detailed bug report, and concludes that a file "is perhaps
corrupted".
Had the user attached the file, the bug could probably be reproduced
easily. Had it been last week, the user maybe would have the file
lying around and could send it ("I have it's copy if anyone needs
it"). If he still has the file 5 years later, he can see the bug
report and send the file just in case. The only problem for the
latter being that:
$ whois limcore.pl
No information available about domain name
limcore.pl in the Registry NASK database.
There are several causes other than the file corruption that can explain this:
1) problem with libapt (by that time it would be easier than now to
see if there were reports about that) that was fixed since then
2) a misuse of libapt library by aptitude, subsequently fixed while
this bug was never addressed (which is not unheard of, in the
aptitude-development world)
3) one of the random segfaults plagging 0.4.* series, which apparently
were very common
4) a real corruption in the file
5) that the file was not corrupted but that some entry caused
problems, because of:
5.1) an added field
5.2) charset problems
5.3) oddities, like the recent "0ad" package when package names were
not supposed to be started by digits
6) a few other rarer cases come to mind, but I think that it's enough
Even being very conservative, I think that the chance that this bug is
present today is not that big, especially taking into account that
it's probably not the only case of file-corruption in history
affecting aptitude users, and in that case the bug can have been fixed
in another occasion or will be in the future in a future bug report
where data can be get easily.
Overall, I think that there are more frequent bugs/problem affecting
aptitude users than this one, so time will be well spent elsewhere.
But well, it's up to you if you want to keep the bug open to
investigate it, I'm not going to stop you.
Cheers.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
