[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#612986: apt: E: Method rred has died unexpectedly! E: Sub-process rred received a segmentation fault. [sparc, powerpc]



On Sat, Feb 12, 2011 at 16:33, Jörg Sommer <joerg@alea.gnuu.de> wrote:
> Axel Beckert hat am Sat 12. Feb, 04:34 (+0100) geschrieben:
>> In Sid on the sparc and powerpc architectures I can no more update the
>> package lists as apt-get update (as well as aptitude update and aptitude
>> -u) fail with the following error messages.

(aptitude uses the same code as APT does as they share it in libapt-pkg)


> Me (powerpc) has the same problem. The problem is that in rred.cc:258 an
> incomplete object dyn is created, due to _error->PendingError() in
> contrib/mmap.cc:223 returns true. The object has the attribute Base=0
> which is feed to mmap in contrib/mmap.cc:270 on object destruction. This
> call causes the segfault.
>
> I don't know if Base == 0 is a valid state for a DynamicMMap object and
> the destructor has to check this value or if there's something else
> rotten and Base == 0 signals a deeper broken state.

It is a bad state as mmap creation shouldn't fail (as the error shows), but
we have a fallback for systems without mmap so failing with a segfault is
absolutely bad as we could use this fallback. (Fixed.)


> Hence, you have to do some edianess adoption
>
> 45454 == 0x0000b18e != 0x8eb10000 == 2393964544

I have changed in 0.8.11 rred handling by avoiding the uncompress of the patch
to a real file (which is deleted shortly after again) and instead use the new
inbuilt gzip support so that the patch is opened by rred and uncompressed
on the fly.

gzip support was added in 0.7.26~exp10 to be able to handle transparently
gzip-compressed indexfiles - and the faulty code reading the size of the
uncompressed file in 0.8.7, so squeeze is effected by this endian mess-up
just that it only effects a small feature (Acquire::GzipIndexes) and not rred
which is used by default.


It would be cool if someone with a big-endian machine could test the attached
diff which should fix this and related problems.
A tester wouldn't even need to install the self-built apt - building the tree
and running ./test/integration/test-pdiff-usage is enough to test it
(but you need to install weborf).


Best regards

David Kalnischkies

Attachment: apt-612986-big-endian-size
Description: Binary data


Reply to: