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 ---
- To: submit@bugs.debian.org
- Subject: apt: apt-cache search segfaults
- From: Kestutis Kupciunas <kesha@soften.ktu.lt>
- Date: Mon, 20 Jan 2003 19:20:09 +0200
- Message-id: <200301201720.h0KHK9Uh010771@kaunas.alna.lt>
Package: apt Version: 0.5.4 Severity: normal i have occasionally tried searching: apt-cache search unit++ ant it has segfaulted. thought its something wrong with ++, but could find any other string which would segfault apt-cache... maybe there is something wrong with Packages file? I am ready to provide any additional info -- System Information Debian Release: testing/unstable Kernel Version: Linux kibiras 2.2.20 #1 Mon May 13 14:56:34 EET 2002 i686 unknown unknown GNU/Linux Versions of the packages apt depends on: ii libc6 2.3.1-3 GNU C Library: Shared libraries and Timezone ii libstdc++2.10- 2.95.4-12 The GNU stdc++ library
--- End Message ---
--- Begin Message ---
- To: Jonathan Nieder <jrnieder@gmail.com>, 81829-done@bugs.debian.org
- Subject: Re: Bug#81829: "Segmentation faulty tree" (#270147) still present in Lenny, broken /var/cache/apt/*.bin available for download
- From: Julian Andres Klode <jak@debian.org>
- Date: Fri, 19 Aug 2011 12:05:22 +0200
- Message-id: <20110819115258.GA4040@debian.org>
- In-reply-to: <[🔎] 20110818211605.GA12840@elie.gateway.2wire.net>
- References: <20090217200846.GW5399@sym.noone.org> <[🔎] 20110818211605.GA12840@elie.gateway.2wire.net>
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: pgpXuGtwIWOT1.pgp
Description: PGP signature
--- End Message ---