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

Bug#93453: marked as done ([libapt-pkg] apt-get segfaults on corrupt /var/cache/apt/*.bin)

Your message dated Fri, 19 Aug 2011 12:05:22 +0200
with message-id <20110819115258.GA4040@debian.org>
and subject line Re: Bug#81829: "Segmentation faulty tree" (#270147) still present in Lenny, broken /var/cache/apt/*.bin available for download
has caused the Debian Bug report #81829,
regarding [libapt-pkg] apt-get segfaults on corrupt /var/cache/apt/*.bin
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
81829: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=81829
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: apt
Version: 0.5.3
Severity: normal

(note: recompiled for stable; same version works fine on other
computer)

snoopy:~# chroot  /nfsroot/potato/root/
snoopy:/# apt-get upgrade
Reading Package Lists...
Building Dependency Tree...
Segmentation fault
 
snoopy:/# gdb apt-get
GNU gdb 19990928
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(no debugging symbols found)...
(gdb) set args upgradwe
(gdb) set args upgrade 
(gdb) r
Starting program: /usr/bin/apt-get upgrade
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
Reading Package Lists...
Building Dependency Tree...
(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x400736af in pkgProblemResolver::MakeScores ()
   from /usr/lib/libapt-pkg-libc6.1-3-2.so.3.1
(gdb) bt
#0  0x400736af in pkgProblemResolver::MakeScores ()
   from /usr/lib/libapt-pkg-libc6.1-3-2.so.3.1
#1  0x400756ad in pkgProblemResolver::ResolveByKeep ()
   from /usr/lib/libapt-pkg-libc6.1-3-2.so.3.1
#2  0x40072fec in pkgAllUpgrade () from /usr/lib/libapt-pkg-libc6.1-3-2.so.3.1
#3  0x80572fb in strcpy ()
#4  0x40059d4a in CommandLine::DispatchArg ()
   from /usr/lib/libapt-pkg-libc6.1-3-2.so.3.1
#5  0x80619c0 in strcpy ()
#6  0x40163a52 in __libc_start_main () from /lib/libc.so.6


Steps to try and fix (with no sucess):

1. upgrade from 0.5.0 to 0.5.3

2. try same image on different computers (NFS-Root). I think
chroot should be most reliable. In any case I get the same error
everywhere.

3. tried combinations of -s, install, and -d, but always get the same error.

4. created an /etc/apt/preferences file. Same as what is used on
a working system:

Package: autoconf
Pin: release a=stable
Pin-Priority: 1001

Package: automake
Pin: release a=stable
Pin-Priority: 1001

Package: libtool
Pin: release a=stable
Pin-Priority: 1001

Package: *
Pin: release a=stable
Pin-Priority: 600

Package: *
Pin: release a=potato
Pin-Priority: 600

Package: *
Pin: release o=helix
Pin-Priority: 700

Possibly something is currupt on this root directory, but I don't
know what (everything looks OK to me), and even if that is the
case, apt-get should not segfault.

I think I saw something at one stage with apt-get from stable about the
status file being currupt. I looked at that file, and it looks fine.
Nor does dpkg have any problems accessing it. I can send it to you on
request. However, I think it might be just a false lead.

-- System Information
Debian Release: 2.2
Architecture: i386
Kernel: Linux snoopy 2.4.3 #1 Sat Mar 31 13:50:13 EST 2001 i686

Versions of packages apt depends on:
ii  libc6                        2.1.3-17    GNU C Library: Shared libraries an
ii  libstdc++2.10                1:2.95.2-13 The GNU stdc++ library

--- End Message ---
--- Begin Message --- 
Source: apt
Source-Version: 0.8.16~exp4

apt (0.8.16~exp4) experimental; urgency=low

   [ Julian Andres Klode ]
   * apt-pkg/pkgcache.h:
     - [ABI break] Add pkgCache::Header::CacheFileSize, storing the cache size
   * apt-pkg/pkgcachegen.cc:
     - Write the file size to the cache
   * apt-pkg/pkgcache.cc:
     - Check that cache is at least CacheFileSize bytes large (LP: #16467)

On Thu, Aug 18, 2011 at 04:16:05PM -0500, Jonathan Nieder wrote:
> tags 81829 - moreinfo
> quit
> 
> Axel Beckert wrote:
> 
> > I occasionally ran into this bug on Lenny, can't remember on which
> > platform, but never deterministically.
> >
> > But today I reproducibly ran into this bug with both, apt-get and
> > aptitude. Independent of what I did: aptitude; aptitude -u; aptitude
> > upgrade; apt-get upgrade, I always get the "Segmentation faulty
> > tree... 50%" ("Building dependency tree... 50%^MSegmentation fault").
> >
> > Moving /var/lib/apt/extended_states away didn't help.
> >
> > Couldn't even do an apt-get install gdb for generating a backtrace.
> >
> > Moving away pkgcache.bin and srcpkgcache.bin from /var/cache/apt/
> > finally did help (thanks to waldi for that hint), but copying them
> > back after upgrading two packages didn't reproduce the segfault --
> > they always got recreated.
> 
> Thanks!  No promises about being able to take a look soon, but I've
> downloaded them.
I closed the Launchpad bug in 0.8.16~exp4, but forgot to close that 
one. We still cannot detect invalid caches where data changes, but we
can now detect all truncated caches, and reject them.

I could have included a CRC checksum in the header of the remaining
cache, but our experience so far is that 

 (a) most (all?) of these bugs are the result of truncated cache files
 (b) checksumming the cache on opening is much slower than we want,
     especially on ARM systems (200 ms on abel.d.o, 500 ms on an N900,
     12 ms on my Intel Core i5)

That said, if future shows us cases where there are problems with
correctly-sized caches, we can still add a checksum when we break
ABI again, and enable it by default only on amd64 and other fast
architectures.

-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.

Attachment: pgpxzgKO35qoZ.pgp
Description: PGP signature


--- End Message ---
Reply to: