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

Bug#674951: marked as done ([libapt-pkg4.12] aptitude crashes while updating packages list)

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-pkg4.12] aptitude crashes while updating packages list
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.5.1
Severity: normal

--- Please enter the report below this line. ---

"aptitude update" causes segmentation fault in libapt-pkg.so.4.12:

Program terminated with signal 11, Segmentation fault.
#0  0xb72c8461 in
debListParser::LoadReleaseInfo(pkgCache::PkgFileIterator&, FileFd&,
std::string) ()
   from /usr/lib/i386-linux-gnu/libapt-pkg.so.4.12

Backtrace attached.

--- System information. ---
Architecture: i386
Kernel:       Linux 3.2.0-0.bpo.1-686-pae

Debian Release: wheezy/sid
  500 unstable        www.debian-multimedia.org
  500 unstable        ftp2.de.debian.org
  500 testing         www.debian-multimedia.org
  500 testing         security.debian.org
  500 testing         ftp2.de.debian.org
  500 stable-updates  ftp2.de.debian.org
  500 stable          ftp2.de.debian.org
    1 experimental    www.debian-multimedia.org
    1 experimental    ftp2.de.debian.org

--- Package information. ---
Depends             (Version) | Installed
=============================-+-===============
libbz2-1.0                    | 1.0.6-1
libc6                (>= 2.8) | 2.13-32
libgcc1          (>= 1:4.1.1) | 1:4.7.0-9
libstdc++6           (>= 4.6) | 4.7.0-9
zlib1g         (>= 1:1.2.3.3) | 1:1.2.7.dfsg-11


Package's Recommends field is empty.

Package's Suggests field is empty.

# aptitude update
.....
Fetched 10.2 kB in 4s (2,124 B/s)
[100%] Reading package listsSegmentation fault (core dumped)

# gdb aptitude
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 "i486-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/97/69b4c55215260a64d888e5305fe18d45a0df27.debug...done.
done.
(gdb) core-file core 
[New LWP 24619]
warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".
Core was generated by `aptitude update'.
Program terminated with signal 11, Segmentation fault.
#0  0xb72c8461 in debListParser::LoadReleaseInfo(pkgCache::PkgFileIterator&, FileFd&, std::string) ()
   from /usr/lib/i386-linux-gnu/libapt-pkg.so.4.12
(gdb) backtrace
#0  0xb72c8461 in debListParser::LoadReleaseInfo(pkgCache::PkgFileIterator&, FileFd&, std::string) ()
   from /usr/lib/i386-linux-gnu/libapt-pkg.so.4.12
#1  0xb72e470d in debPackagesIndex::Merge(pkgCacheGenerator&, OpProgress*) const ()
   from /usr/lib/i386-linux-gnu/libapt-pkg.so.4.12
#2  0xb7284879 in ?? () from /usr/lib/i386-linux-gnu/libapt-pkg.so.4.12
#3  0xb7287801 in pkgCacheGenerator::MakeStatusCache(pkgSourceList&, OpProgress*, MMap**, bool) ()
   from /usr/lib/i386-linux-gnu/libapt-pkg.so.4.12
#4  0xb727ddb2 in pkgCacheFile::BuildCaches(OpProgress*, bool) () from /usr/lib/i386-linux-gnu/libapt-pkg.so.4.12
#5  0xb756a896 in download_update_manager::finish (this=0xbfb67d1c, res=pkgAcquire::Continue, progress=0xb7e61944, 
    k=...) at ../../../../src/generic/apt/download_update_manager.cc:175
#6  0xb74e861a in cmdline_do_download (m=0xbfb67d1c, verbose=0, term_input=..., term_locale=..., term_metrics=..., 
    term_output=...) at ../../../src/cmdline/cmdline_util.cc:471
#7  0xb74e49ab in cmdline_update (argc=1, argv=0xbfb681f8, verbose=30408703)
    at ../../../src/cmdline/cmdline_update.cc:67
#8  0xb73ab34f in main (argc=<error reading variable: Cannot access memory at address 0xb4956898>, 
    argv=<error reading variable: Cannot access memory at address 0xb495689c>) at ../../src/main.cc:1114
(gdb) quit

--- 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: