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

Bug#678225: marked as done (libapt-pkg: Apt and related tools (apt-cache, aptitude, etc.) segfault on reading package lists)



Your message dated Fri, 14 Aug 2015 10:37:36 +0200
with message-id <20150814083736.GA14408@crossbow>
and subject line Re: [libapt-pkg4.12] aptitude crashes while updating packages list
has caused the Debian Bug report #674951,
regarding libapt-pkg: Apt and related tools (apt-cache, aptitude, etc.) segfault on reading package lists
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.)


-- 
674951: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674951
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: libapt-pkg4.12
Version: 0.9.6
Severity: important
File: libapt-pkg

Dear Maintainer,

It appears that any apt- activity that depends on reading the package
lists is failing. (aptitude --version doesn't fail, aptitude update,
apt-cache policy, apt-get update, and aptitude show all do fail.)

% gdb $(which aptitude) core                                                                                                                                              [1150.57]
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/aptitude...Reading symbols from /usr/lib/debug/.build-id/49/189d38eb992c3f04ed3a2d33415221f18298e9.debug...done.
done.
[New LWP 18185]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `aptitude update'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007ffb22aa4f30 in pkgCacheGenerator::ListParser::NewProvides(pkgCache::VerIterator&, std::string const&, std::string const&, std::string const&) ()
   from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
(gdb) bt
#0  0x00007ffb22aa4f30 in pkgCacheGenerator::ListParser::NewProvides(pkgCache::VerIterator&, std::string const&, std::string const&, std::string const&) ()
   from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
#1  0x00007ffb22adc561 in debListParser::NewProvidesAllArch(pkgCache::VerIterator&, std::string const&, std::string const&) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
#2  0x00007ffb22ade943 in debListParser::ParseProvides(pkgCache::VerIterator&) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
#3  0x00007ffb22adf57c in debListParser::NewVersion(pkgCache::VerIterator&) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
#4  0x00007ffb22aa3668 in pkgCacheGenerator::MergeListVersion(pkgCacheGenerator::ListParser&, pkgCache::PkgIterator&, std::string const&, pkgCache::VerIterator*&) ()
   from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
#5  0x00007ffb22aa48b3 in pkgCacheGenerator::MergeList(pkgCacheGenerator::ListParser&, pkgCache::VerIterator*) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
#6  0x00007ffb22af7cba in debPackagesIndex::Merge(pkgCacheGenerator&, OpProgress*) const () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
#7  0x00007ffb22a9d892 in ?? () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
#8  0x00007ffb22aa0669 in pkgCacheGenerator::MakeStatusCache(pkgSourceList&, OpProgress*, MMap**, bool) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
#9  0x00007ffb23160ff4 in aptitudeCacheFile::Open (this=0x7ffb255171f0, Progress=..., do_initselections=false, WithLock=true, status_fname=0x0) at ../../../../src/generic/apt/aptcache.cc:2178
#10 0x00007ffb2316fea7 in apt_load_cache (progress_bar=0x7fffa95c6910, do_initselections=false, status_fname=0x0) at ../../../../src/generic/apt/apt.cc:435
#11 0x00007ffb23116e32 in cmdline_do_download (m=0x7fffa95c6d70, verbose=0, term_input=..., term_locale=..., term_metrics=..., term_output=...) at ../../../src/cmdline/cmdline_util.cc:445
#12 0x00007ffb23113788 in cmdline_update (argc=<optimized out>, argv=<optimized out>, verbose=0) at ../../../src/cmdline/cmdline_update.cc:67
#13 0x00007ffb22fe769b in main (argc=2, argv=0x7fffa95c76f8) at ../../src/main.cc:1114


-- System Information:
Debian Release: wheezy/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libapt-pkg4.12:amd64 depends on:
ii  libbz2-1.0         1.0.6-3
ii  libc6              2.13-33
ii  libgcc1            1:4.7.0-8
ii  libstdc++6         4.7.0-8
ii  multiarch-support  2.13-33
ii  zlib1g             1:1.2.7.dfsg-11

libapt-pkg4.12:amd64 recommends no packages.

libapt-pkg4.12:amd64 suggests no packages.

-- no debconf information



--- End Message ---
--- Begin Message ---
On Thu, Sep 13, 2012 at 07:47:13AM +0200, Marc wrote:
> And after a few update/upgrade cycles using the
> "APT::Cache-Start=100000000", it is now working correctly again... I guess
> because of the 0.9.7.5 upgrade of libapt-pkg4.12

This kind of bug is highly dependent on the sources you have configured,
the exact content of the index from these sources and even the memory
area they are loaded into.

In layman terms: APT creates a cache of the data it parses. It doesn't
know how big the cache will be, but as it needs to start somewhere it
picks a "high" number (currently 25 MB) and hopes that it fits as it
can't ask for too much or we fail downright (or do you want to give 5 GB
of RAM to apt just in case it might need it?).

If it doesn't it has to pull various tricks to increase the size which
depends a bit on your hardware what it can do and how. That is an error
prune process as a lot of things have to be updated to look at the new
place rather than the previous one and we mere humans tend to
forget/overlook all the places it needs to be done.

In the last three years many places were found where the update was
missing and everytime we hope it is the last place. We have now managed
a few months without any new reports, so maybe this time we got it…

In the end, even if not, these kind of bugs are better handled in new
reports for each instance than to keep a "catch-all" open "just in
case". So closing in the hopes we really found the last instance last
time (well, I am more than hoping as I have read the code what seems
like a million times over by now with each instance so I am "sure").


Best regards

David Kalnischkies

Attachment: signature.asc
Description: Digital signature


--- End Message ---

Reply to: