aptitude will use hundreds of megabytes of memory in the process of
resolving dependencies.

I noticed this problem recently when I pressed "u" to update my files,
then "U" to upgrade everything.  There were some broken packages,
which aptitude attempted to resolve.  I killed it when my system
started hitting swap and became very sluggish.

I marked this bug as important because aptitude (in its ncurses mode)
will automatically try to resolve conflicts, and, therefore,
automatically take up all available memory.

  Hi,

  Would it be possible for you to press '*' while aptitude is searching
for a resolution and send the resulting file to me (via private email
please, so we don't kill the BTS :-) )

    Thanks,
  Daniel

Hi Daniel,

I've managed to get Aptitude in to a memory-hogging state; but
only by misuse.  I'll leave my PC in the broken state for a
while, in case you need more logs.

The resolver does stop in the end, using >3GB and claiming that
there are "No more solutions" (it should be recommending to keep
fontconfig-config at the current version).


Replication steps:
In an interactive session, I'd updated.  There were several
upgrades available, including fontconfig-config 2.6.0-4 which
depends an unavailable version of libfontconfig1, I took the
resolver's suggestion to hold fontconfig-config at the current
version.  I then started the upgrade.

I suspended Aptitude with ^Z, and later quit the shell it was running
from by pressing ^D twice ("There are stopped jobs." -- oops,
I've already pressed it the second time).  IIRC it was suspended
either immediately after downloading or immediately after
installing packages, but while it was still doing something
before returning to the normal package list.


So far I haven't tried doing an update again; I'll do so once you
confirm that you've enough logs (or say that the replication
steps are obscure enough not to worry about).

Logs have been uploaded to http://www.s.cotton.clara.co.uk/temp/aptitude_memory_hog.tar.bz2
  resolver_debugging (result of pressing "*" while the resolver was still running)
  /var/log/aptitude
  /var/lib/apt/extended_states
  /var/lib/aptitude/pkgstates

The suspended and forceably quit session would be around
2009-06-13 09:26.  According to dpkg -l, perl 5.10.0-23 (one of
the packages to be upgraded in that run) has been installed.


Rough overview of package states:
iuA   fontconfig-config                                                           +170kB  2.6.0-3    2.6.0-4
iBA   libfontconfig1                                                                      2.6.0-3    2.6.0-3
iF    {lots of upgradeable texlive, games and -doc packages}
ih    {lots of upgradeable texlive and games packages}
iF    exmap {this is a local package with the same version number as the official one}    0.10-2.1   0.10-2.1

A few months ago I had local versions of apt and corresponding
rebuilts of aptitude installed.  AFAICS I'm completely back to
official packages.

Cheers,
Steve

Updating again fixed it for me, in my case it seems to be an
easily-recoverable situation.  Although the behaviour persisted
across reboots, I couldn't replicate the bug by copying all the
obvious files in to a chroot.

I guess the bug needs to stay open as it would be nasty for an
unattended upgrade.  The bug did affect the command-line mode as
well as the ncurses interface.

Steve

Hi, I see this with the latest aptitude (0.6.4-1). The resolving goes on
until segfault (after about 30 mins), probably because it is out of memory.
I have not been able to get rid of the problem by updating or dpkg cleaning.
Normal update/upgrade with apt-get works fine.
Tell me if you want logs or other data.

This happened to me as well. The problem started on aptitude 0.6.3,
and remained after upgrading to 0.6.4-1.2. apt-get (and hence, I
assume, dpkg) works fine. If any files would be useful for
diagnostics, please let me know which ones.

HEllo,

I have encountered this with 0.6.3-3.2+squeeze1.
Please tell me if/how I can look at the problem

Dear Maintainer,

I am running into this problem too. I have been trying to upgrade my Debian Testing
system for the past three weeks to no avail. The problem is that the libstdc++6 library
The problem is that the libstdc++6 library is creating a ton of conflicts so that typing
'e' to get to the conflict resolution dialog causes aptitude to use up all the memory
(over 10GB) until it gets killed. As a result I have been unable to upgrade my system
for the past three weeks, resulting in more and more packages being upgradable, which
gets aptitude in a worse spot each time.

This issue already happened over a year ago so this is nothing new.

Hello,

2015-09-27 15:41 Francois Gouget:

I am afraid that unstable and testing at the moment might still not be
ready to upgrade fully, specially if you have KDE packages installed and
you don't want to loose some of them.  I imagine that the situation can
be similar if you use other desktop environments or applications high in
the stack.

I don't know how are you upgrading and if you are aware of the
following, but just in case it helps...

It usually helps to get aptitude unstuck in these situations if you
start aptitude interactively, select by hand packages to upgrade (with
+), press 'e' to enter the resolution if there are conflicts and select
one if satisfactory, or not select any, quit the resolver and and press
Control-U to undo if the first few solutions are not satisfactory.


Cheers.

On Tue, 29 Sep 2015, Manuel A. Fernandez Montecelo wrote:
[...]
for upgrade but I finally got through it by using 'b' (find broken
packages) + ':' (hold temporarily) + recursing through the exact version
of the package being installed to hold its broken dependencies. Required
multiple passes. Took hours to get through it all though.

While I was at it I marked a bunch of packages as automatically
installed ('M').

But the point remains: the dependency resolution should not rnu out of
memory like that. My system was not in a broken state so it's also
surprising it's unable to find the obvious solution which is to not
upgrade anything.

Even if it's unable to find a solution it should be able to at least
show the conflicts.

For bonus points it should also present independant conflicts
separately. For instance currently I have a problem with a package that
depends on the mysql-client virtual package which is not provided by the
new mysql-client-5.6 package. Chances are this is totally independent
from the libstdc++6 conflicts. But the conflict resolution dialog
systematically shows all conflicts together, making figuring things out
much harder for the administrator, and also causes a combinatorial
explosion in the number of possible solutions.

This also leads me to wonder whether partitionning independent conflicts
could help find solutions using less CPU and memory (though here the
libstdc++6 issue alone seems to be enough to cause memory usage to
explode).

Please fix that issue, or at least make aptitude detect and quit by itself.

It's only a matter of luck whether I catch the cronjob in time, or whether
I have to wait for an hour for the server to come back (alternatively,
I can spend ~15 minutes on the serial line to get a chance to kill it by
hand).

      PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
    10649 root      20   0 18,881g 0,014t  18296 S   0,0 61,6  38:55.96 aptitude -y -s -v safe-upgrade

Dear Maintainer,

   * What led up to the situation?

Some unknown sequence of packages slowly being installed and perhaps
getting broken over time?  It only showed up when I started trying to
install libpcl-dev:i386, but now aptitude is stuck trying to resolve
dependencies.  Nothing I can do seems to be able to stop it; that is, if
I kill aptitude and start it again, it just starts over trying to
resolve dependencies.  If I try to use the "Cancel pending actions",
aptitude dies with a segfault (I will open a separate bug for this
specific behavior).

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

Nothing was effective.  Killing and restarting aptitude had no effect.
"Cancel pending actions" led to a SIGSEGV and also had no positive
effect.

Based on the advice of closed bug #665794, I have used
aptitude-create-state-bundle; the file is 168 MB.  Kindly suggest where
to upload it.

Many thanks.

I was out for a few days, and the large number of updates that's been happening in testing lately probably threw aptitude out of whack.

I'm running testing (Trixie/sid), and trying to update using aptitude causes it to crash after running out of memory (I currently have 45G of swap, and I stopped it at 22G, with no sign of it slowing down).

Taking note of Message #10 in this bug, I pressed '*' while aptitude was labouring away, and the resulting file is attached (uncrunched, it's around 35M in size).

Thanks,

.....Ron