Ubuntu

Upgrade tool crashed with " Cannot allocate memory"

Reported by Bradley T Hughes on 2007-04-17
804
This bug affects 5 people
Affects Status Importance Assigned to Milestone
update-manager (Baltix)
Undecided
Unassigned
update-manager (Ubuntu)
High
Unassigned
Nominated for Hardy by Marco Cimmino
Nominated for Jaunty by Nikolaus Rath

Bug Description

Ever since feisty, the release upgrade tool fails with "OSError: [Errno 12] Cannot allocate memor" on some systems. This has been reported for both the KDE, Gnome and console programs.

The problem is reproducible with the current Jaunty -> Karmic upgrade as well.

[ description cleaned up to summarize comments and current status ]

Bradley T Hughes (bhughes) wrote :
Bradley T Hughes (bhughes) wrote :
Michael Vogt (mvo) wrote :

Thanks for your bugreport.

It looks like the machine ran out of memory. How much memory/swap do you have ?

Thanks,
 Michael

Changed in update-manager:
status: Unconfirmed → Needs Info

1G of memory, 3G of swap. At the time of the upgrade, the only thing that was running was Konsole and the upgrader. The upgrade seems to have succeeded, and I don't know how to reproduce the problem, should I need to :/

Michael Vogt (mvo) wrote :

Uh, that should be plenty of resources. I do the upgrade tests on a 256 mb test machine. Was there anything else runing that could have used up a lot of memoty?

Bradley T Hughes (bhughes) wrote :

I don't believe so. There could have been a process running in the background that might have taken some memory (g++), but I've never had OOM situations on this laptop before while doing rebuilds of the Qt 4 library. We may just have to shrug this one off as a fluke. :/

Stephan (stephan-cs) wrote :

Exact same situation here.
- up-to-the-minute update within edgy
- use update-manager to upgrade to feisty
- no other processes
- 1G of RAM
-> "Cannot allocate memory"

NB.: I'm using Kubuntu.

(Then a window asks me to enter this as a bug to launchpad, which of course
doesn't work, because upgrade just shut down the internet connection ;-).

Should I upload my log files, too?

Also #107727 looks like the same problem?

Michael Vogt (mvo) on 2007-04-20
Changed in update-manager:
importance: Undecided → High
status: Needs Info → Confirmed

I was not able to reproduce this on a 256MB RAM/377MB SWAP machine (no other aps runing when the upgrade was runing, only adept). I also tried it with amarok, kmail and konqoror runing in the background and got no memeory expection.

Jonathan Riddell (jr) wrote :

What version of KDE did you have installed in Edgy? what stage was the installer at when it crashed?

Tirsel Martin (bruce-wardogs) wrote :

if it hleps, the upgrader crashed after i confirmed to remove some obsolote packages (i had php4, but i cant remember if it was in this remove box). It seems that the upgrade was succesfull (system is working ok) and the only problem was these packages, which i removed afterwards manually. Is there any way to checkif the upgrade was ok?

Hi,

> What version of KDE did you have installed in Edgy?
3.5.5 to the best of my knowledge (the latest in Kubuntu Edgy)
> what stage was the installer at when it crashed?

must have been close to finish.
After reboot the system seems to be properly setup.

The last interaction as far as I remember was about bcm43xx-fwcutter.
Last entry in main.log before the crash is
The following packages are remove candidates: libapr0 linux-headers-2.6.17-11-generic libdns21 libgpod0 ndiswrapper-utils libavahi-core4 acroread libdirectfb-0.9-24 linux-heade
rs-2.6.17-10 libopenobex-1.0-0 grepmap libicu34 ndiswrapper-utils-1.8 linux-headers-2.6.17-10-generic libsvn0 linux-headers-2.6.17-11 libsvnqt2 ndiswrapper-utils-1.1 libtunepimp3
There was a dialog asking for confirmation, I remember now, where I answered OK.

(attaching the file)

regards,
Stephan

Everyone bitten by this bug has a complete upgrade, its just that some old package have not be removed.

Michael Vogt (mvo) wrote :

This problem might be releated to a network failure during the download of the packages. Most logs seem to have one (but at least one does not have it). But it might be something to try to reproduce it.

Stephan (stephan-cs) wrote :

The only warnings I could find in my main.log are

WARNING no activity on terminal for 240 seconds (Configuring libssl0.9.8)
WARNING no activity on terminal for 240 seconds (Configuring bcm43xx-fwcutter)

In fact I was away from the machine for more than 3 minutes during upgrade.

How would a network problem show up?

Michael Vogt (mvo) wrote :

Could this be theme releated? What theme do you use?

Yann (yannlieb) wrote :

For me, problem occured after upgrade-manager got stuck with interaction for package lm-sensors. I had to kill this post-intall thread, update manager went on till the end of install phase and then crashed when arriving to clean-up phase.

Please note that I had previously applied the "kde-356-pre-feisty-upgrade" in order to run the upgrade

bertkenward (bert-kenward) wrote :

Just to add to this, I've had similar behaviour. Running KDE 3.5.5. An aptitude upgrade run after a reboot removed three packages, and it's fine.

Following up from Stephan's comment about being away from the machine for a while, I left this to work for a while, and there was generally a question from dpkg when I got back.

DavidWhyte (dave-whyte) wrote :

I had this crash in the clean up stage after I confirmed to remove some obsolete packages

Error trace nearly identical to the one above.

Hello Michael:

    <<Could this be theme releated? What theme do you use?>>

Unlikely. The chance that we are all using the same theme is
vanishingly small... unless we're all using the default KDE
theme.

I *was* using the default theme, though I tried several on when
exploring those options. I also made a few minor tweaks (that I
understood, being a noob) and posted the V.I.S.T.A. wall paper.
Other than that, it was pretty much default KDE.

According to another message I received this morning, there were
instructions to (manually?) install 2 upgrades before proceeding
with the install. I *believe* my failure to do this is the more
likely cause.

DJ Brown
   Austin, TX

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On
Behalf Of Michael Vogt
Sent: Saturday, April 21, 2007 2:16 AM
To: <email address hidden>
Subject: [Bug 107188] Re: [MASTER] [kde] Upgrade tool crashed
(edgy -> feisty)

[snipped]

I experienced a complete system crash after starting the upgrad edgy to feisty. Now I cannot boot anymore and (sniff) have to resort to windows to add to this bug list. I do not even know how to retrieve any log files or personal data which went down with my system.

Marko (argus) wrote :

I also got a crash during full upgrade.

Maybe a network error was the reason. I use Wifi for my computer (I hate all those cables in my house), and this has been a bit buggy from time to time...

Dermot (dd2) wrote :

Here's some additional info. which might provide some clues.

I was running Kubuntu 6.10 with all current updates installed on 19-Apr. I was using default KDE theme. I have a Broadcom Wireless card and was using ndiswrapper.

The upgrade proceeded correctly and all 600-800 packages were downloaded and installed. The Upgrade tool then entered the cleanup phase. I received a couple of dialog boxes about overwriting configuration files (one was about /etc/modprobe.d/blacklist). I then received a dialog asking permission to remove obsolete packages which I allowed. I believe (but am not 100% certain) that this went OK and I then got a second dialog asking permission to remove obsolete packages. So I either got one (definitely) or two (probably) dialogs re. obsolete packages and said OK.
I remember that one of the packages to be removed on the last dialog was ndiswrapper-utils. The Upgrade tool then crashed when it ran out of memory with 1.1GB physical memory and 2GB swap on my laptop. No other applications were running except Konsole. I use network-manager to manage my network connections.

After restarting I can see that I have ndiswrapper-utils1.8 amd ndiswrapper1.9 installed so it seems like the Upgrade tool crashed either before or during removing this.

I see that Stephen mentioned bcm43xx-fwcutter. I wonder how many people who have experienced this bug are running Broadcom WiFi cards with fwcutter or ndiswrapper?

Dermot.

Heiko Hänsel (hhaensel) wrote :

Hi,

in my case the Upgrade Tool crashed in the phase "clean up". The last interaction was that it asked me to confirm the removal of some unsupported packages.

Tzvetan Mikov (tmikov) wrote :

Encountered the same problem today - the stack trace is exactly the same. If necessary I can upload my log files.

Tzvetan Mikov (tmikov) wrote :

Forgot to add some details: I ran "aptitude dist-uprade" after the crash and everything is fine now - I am happily running Feisty.
I don't think is related to with wireless networking, but for the record my laptop is with Intel 3945ABG.

Calabacin (raulgarciag) wrote :

Hi

I just got this same problem. I do not have any wireless configured, I am connected to a LAN router. I did not lose connectivity after the crash, and I am in fact writing this from my Kubuntu system, that seems to work fine.

After confirming I wanted to uninstall those old packages it just stopped working. Before I got any crash report I tried to open a folder clicking on it on the desktop, but it wouldn't work. Just waited there until I got that out of memory error message and a moment afterwards Konkeror finally opened.

These are the packages that were to be uninstalled:
libgnucrypto-java
libgtkhtml3.8-15
libjaxp1.2-java
libkexif1
libpq4
libsasl2
libstlport4.6c2
python-elementtree
wlassistant
xkeyboard-config

--------------------------------------
This is the error message I got:
Traceback (most recent call last):
  File "/tmp/kde-root/adept_updaterQGzWCb.tmp-extract/dist-upgrade.py", line 56, in ?
    app.run()
  File "/tmp/kde-root/adept_updaterQGzWCb.tmp-extract/DistUpgradeControler.py", line 1025, in run
    self.fullUpgrade()
  File "/tmp/kde-root/adept_updaterQGzWCb.tmp-extract/DistUpgradeControler.py", line 1014, in fullUpgrade
    self.doPostUpgrade()
  File "/tmp/kde-root/adept_updaterQGzWCb.tmp-extract/DistUpgradeControler.py", line 740, in doPostUpgrade
    res = self.cache.commit(fprogress,iprogress)
  File "/usr/lib/python2.4/site-packages/apt/cache.py", line 204, in commit
    if res == pm.ResultCompleted:
  File "/usr/lib/python2.4/site-packages/apt/cache.py", line 179, in installArchives
    installProgress.finishUpdate()
  File "/usr/lib/python2.4/site-packages/apt/progress.py", line 206, in run
    select.select([self.statusfd],[],[], self.selectTimeout)
  File "/tmp/kde-root/adept_updaterQGzWCb.tmp-extract/DistUpgradeViewKDE.py", line 227, in fork
    self.child_pid = os.fork()
OSError: [Errno 12] Cannot allocate memory

And here are the log files:
http://calabacin.es/ubuntu/apt.log
http://calabacin.es/ubuntu/main.log

I have 22GB of free HD, 1GB RAM and 2.2Gb swap.

I cannot say if my system will reboot, but I'm about to find out!

Tarski (supereddy) wrote :

Same problem after 4 hours of downloading/upgrading. I started a new bug thread because the update manager instructed me to

https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/109074

obotor (bonnet-o) wrote :

I connect through Wireless LAN. After the crash everything seems ok. The computer has 1.5 GB RAM and about 900MB swap (which is rarely used indeed). It has not lost any connectivity - as can be noticed.

I remember that among the so-called obsolete packages were (* correspond to forgotten chars, (?) means that I am not 100% sure of the name):
acroread
acroread-esw***** (?)
acroread-pck**** (?)
...
libmysql14
libphp4
...
libssl**
...
xkeyboard-config

Here is the trace in the upgrade manager:

Traceback (most recent call last):
  File "/tmp/kde-root/adept_updatertujGJb.tmp-extract/dist-upgrade.py", line 56, in ?
    app.run()
  File "/tmp/kde-root/adept_updatertujGJb.tmp-extract/DistUpgradeControler.py", line 1025, in run
    self.fullUpgrade()
  File "/tmp/kde-root/adept_updatertujGJb.tmp-extract/DistUpgradeControler.py", line 1014, in fullUpgrade
    self.doPostUpgrade()
  File "/tmp/kde-root/adept_updatertujGJb.tmp-extract/DistUpgradeControler.py", line 740, in doPostUpgrade
    res = self.cache.commit(fprogress,iprogress)
  File "/usr/lib/python2.4/site-packages/apt/cache.py", line 204, in commit
    if res == pm.ResultCompleted:
  File "/usr/lib/python2.4/site-packages/apt/cache.py", line 179, in installArchives
    installProgress.finishUpdate()
  File "/usr/lib/python2.4/site-packages/apt/progress.py", line 206, in run
    select.select([self.statusfd],[],[], self.selectTimeout)
  File "/tmp/kde-root/adept_updatertujGJb.tmp-extract/DistUpgradeViewKDE.py", line 227, in fork
    self.child_pid = os.fork()
OSError: [Errno 12] Ne peut allouer de la mémoire ( --> meaning Cannot allocate memory)

obotor (bonnet-o) wrote :
obotor (bonnet-o) wrote :

After a restart everything seems to be alright including all server stuff and databases. No further step has been required so far.

Alan (alan-fitzgerald) wrote :

I was in a mess after this happened to me. KDE was only half installed, I have no idea what state everything else is in. I reinstalled KDE, but kdeinit was still missing a bunch of libs. After reloading each of these I have KDE up and runnning again...o and startkde was no longer being called.

This has been a nightmare. This Linux box has been my primary box in an all Windows shop for 2 years. I had no response to the question, "what would a normal user do if this happened to them?". I need to get this straightened out asap, I have already lost 2 days of work. I would hate this to force me to run Windows there again.

My original bug was:
https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/109328

madamos (madamos) wrote :

After a restart things appear to be functioning normally for me.

Agreed Madamos:

I don't exactly trust it yet but KDE seems to come up normally
and run just fine except for a few missing items - things that
ran fine in the previous install but are missing now. I'll have
to do a bit of an inventory but I can come up with a list.

Alas, there are a couple of problems that continue: one is the
Adept (?) program installer that dumps mysteriously when I check
the two boxes at the upper right looking for all the available
application downloads. It takes a few seconds but the window just
pops away with no warning or crash report.

Still, I'm in the enviable position of being able to leave the
machine in its original failed condition in case any of the
Ubuntu diagnostic staff want to pick it apart.

DJ Brown
   Austin, TX

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On
Behalf Of madamos
Sent: Wednesday, April 25, 2007 8:19 AM
To: <email address hidden>
Subject: [Bug 107188] Re: [MASTER] [kde] Upgrade tool crashed
(edgy -> feisty)

After a restart things appear to be functioning normally for me.

[Snipped] <belch!> Good stuff!

I've noticed since my upgrade from 6.10 til 7.04, that my package lists
i adept is screwed up: I see a package (e.g Compiz) but the description
listed is for something completely different (in this case the OFFIS
DICOM commandline toolkit) ... whats going on there?!?

--
Med venlig hilsen / Kind regards
Søren O'Neill

Kiropraktor, klinisk lektor
Søren O'Neill, DC, M.Rehab, Stud.PhD
Rygcenter Fyn, Lindevej 5
5750 Ringe

mail (arb./work) <email address hidden>
mail (hjem/home) <email address hidden>

tel. (arb./work) +45 6362 1906
tel. (hjem/home) +45 6599 4430
tel. (mobile) +45 208 12 369

I got the same "Upgrade Tool Crashed" too after I clicked to remove obsolete packages. Exactly same message. And I got this from a newly installed edgy that is immediately upgraded to feisty. (I botched my first attempt to upgrade.)

Hmm, that was the same thing for me. The remove obsolete packages -
thanks for reminding me.

I'm also having a problem on a clean system with adept not starting
but not really crashing either, just kdesu hanging out in memory and
then adept not starting until I reboot.

On 4/25/07, AllisterX <email address hidden> wrote:
> I got the same "Upgrade Tool Crashed" too after I clicked to remove
> obsolete packages. Exactly same message. And I got this from a newly
> installed edgy that is immediately upgraded to feisty. (I botched my
> first attempt to upgrade.)
>
> --
> [MASTER] [kde] Upgrade tool crashed (edgy -> feisty)
> https://bugs.launchpad.net/bugs/107188
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
Usually I try to take it one day at a time, but lately several have
attacked me at once...

Same as others above -- I had the memory allocation error in DistUpgradeViewKDE.py, shortly after the screen that asks about removing packages. However, when I tried to reboot, grub was hosed up.

In my case, the problem was that the grub device names had changed. Previously in grub menu.lst I had root (hd1,0), which would no longer boot. I changed it to root (hd0,0) and then it booted OK. I have an ide disk in place, and a scsi -- and I wanted to boot off the scsi. Now, (after booting), the IDE drive shows up as /dev/sda, and the first scsi disk has shifted to /dev/sdb... ? However, the order is still the same, so I'm not sure why the grub change was needed.

Just want to add...

I did an upgrade about four times from edgy to feisty and ran into the same problem each time. It was the same machine/config, I restored back each time with a clone tool. I have 512meg of ram and 2gig swap drive. I ran the last upgrade with the swap file monitor running. It was barley used during the whole upgrade (between 50-300k), and when it got to the step where it asked to do the cleanup and I clicked OK, the swap usage climbed over about 10 seconds to 1.4gig before the upgrade tool crashed. Pretty much identical logs to the above.

The last attempt I made I used an AptOnCD dvd to hold my apt sources, so the network was not/barely used. Same result.

Tzvetan Mikov (tmikov) wrote :

I have a couple Kubuntu machines in our office to waiting to be upgraded, but I am putting that on hold for now. I can't risk it - apparently here some people's machines were hosed after the crash (shouldn't there be something on the main site, to warn people temporarily against upgrading). It is an unpleasant situation.

Is there any information available on what causes this, or workarounds ?

For example, won't it be better to use the "old" way of upgrading with "aptitude dist-upgrade" - that has never failed me before. I would be very surprised if it crashed.

Marc Dekenah (m-marcspages) wrote :

mvsjes, you beat me to it. I was going to set up a log on another 6.10 machine that needs to be "feistied" and see when/what goes crazy at the point of crash. But this raises another small issue; It's all very well to say "you need to do a manual clean-up" (oh yes, I'm all for keeping disk clear of junk), but please give us "intermediates" (not noobie, but not Linux boff either) a little help as to where we need to wield the cyber-broom. Ta, ever so ta.

I'm going to upgrade this other machine but not remove obsolete packages and see what occurs.

M.

Michael Vogt (mvo) on 2007-05-22
description: updated
Changed in update-manager:
status: New → Invalid
32 comments hidden view all 112 comments

Hi!

It seems that I am one the clueless users that have been hit by this bug. I even filled a bug report (https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/154278), that was obviously marked as duplicate.

I wonder what is the best way of action for me. I can think the following actions:

a) Wait until the bug is solved. After reading this thread it doesn't seem that this is going to happen nearly
b) Install the Gnome part of Ubuntu and do the upgrade using the Gnome updater tool
c) Use a more or less cryptic workaround
d) Wait until Kubuntu 8.04
e) Other that I cannot think right now

The truth is that not upgrading the distro is not a big problem for me. In fact I will do it only to get the newest OpenOffice.org (I wish that Ubuntu prepared packets for older distributions to avoid upgrading the distro, but this is another story). What do you suggest me to do?

Thanks,

Javier

BigPick (wpickard) wrote :

Hello fellow frustrated users.

I also ran into this problem earlier. I have been working on a patch that resolves a major memory leak in the dist-upgrade scripts. Certain raised exceptions are causing infinite loops to occur. Currently, I have only been able to resolve one of these infinite loops, but the memory leak still remains. On the plus side, the upgrade is able to gracefully fail with the current patch and attempt recovery instead of just exiting. I would love to have some of you all test it out and post your resulting logs. It will greatly help diagnose the problem.

For full info see this other bug:
https://bugs.launchpad.net/ubuntu/+source/adept/+bug/154493

BigPick (wpickard) wrote :

I am pleased to report that using the above patch, my second sandbox tower was finally able to upgrade using the dist-upgrade.py script without error. I will run the test again on my other sandbox tower as soon as I revert it back to a Feisty install. Right now, I need to go to bed.

While this result bodes well, I still need you all to try out the patch and report your results back here. Doing so will greatly aid in the resolution of other errors that still may be lurking. If you need some help applying the patch I posted instructions in the other bug report linked above, just make sure you download the second patch revision instead of the one used in the example. Once you have run the patch, successful or not, please post the log files located in /var/log/dist-upgrade/.

I am not a developer, I am just a lowly peon user who had his install corrupted when the update-manager crashed. As such I need your assistance in getting this patch tested and, if successful, pushed to the higher-ups. Thank you for your help.

Marco Cimmino (cimmo) wrote :

so the problem is a memory leak, then developers have for sure more details now, well I hope.

Ferran Rius (frius64) wrote :

BigPick: I'll test your patch as soon I go back home to see if I can confirm your results.
However, I insist on what I (and others) have said. Until a definitive fix for this has been released, this should be considered a critical bug and, as it clearly affects many users, upgrading from Feisty should not be recommended.

Agreed. I should add that there are bugs in KDEsu (1), which hamper
the use of adept-updater etc.

Of 5 computers upgraded at home and at work, two were left in a
completely unusable state (one recovered so far), the third is
affected by this memory-bug (2). The fourth and fifth have been
running gutsy for a long time and only required some manual
downloading and installing of .deb files for udev & volumeid, because
this wasn't handled automatically. This was deemed "not a bug" because
I "should have use adept or the upgrade manager", which was obviously
not possble because of bugs (1) and (2).

All in all, I'm NOT impressed: 0 out of 5 upgrades successful. For
now, I recommend against upgrading.

Therefore, creating the patch is very important and I hope it works
out, but for now I'm too busy fixing my unbootable machine to try it.

On 10/25/07, FerranRius <email address hidden> wrote:
> BigPick: I'll test your patch as soon I go back home to see if I can confirm your results.
> However, I insist on what I (and others) have said. Until a definitive fix for this has been released, this should be considered a critical bug and, as it clearly affects many users, upgrading from Feisty should not be recommended.
>
> --
> [MASTER] [kde] Upgrade tool crashed with " Cannot allocate memory" (edgy -> feisty)
> https://bugs.launchpad.net/bugs/107188
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Many thanks for the help you guys.

I would also like to thank John and Christian Assig for their efforts so far.

FerranRius's comment is very prudent and correct however, this upgrade should not be attempted whatsoever by anyone who uses their machine for work, school, or other important operations. The patch I posted is simply the fix I came up with for my situation when I attempted to upgrade Feisty on the laptop I use around campus. I never thought I'd be thankful for dual-booting windows, and to be honest, I resent the need to rely on it. Luckily, I have two old towers I use as sandboxes for messing around with networking and various Unix installations. One is an Intel/nVidia, the other is AMD/ATI, both failed the upgrade and became unbootable (so I'm 0 for 3), making them perfect candidates for trying to fix this.

Currently there are two memory leaks occurring as far as I can tell, only one of which I have identified and addressed in the patch. The second appears to be coming from the fetching of backport archives, which occurs prior to the main upgrade. I am unable to replicate this leak on my machines, so I have relied on the work of Christian Assig to track this down. He deserves many thanks for bearing with my sophomoric efforts. Although this patch does not fix the second leak, Christian did report dist-upgrade faied gracefully instead of crashing by bringing up an error window and attempting to recover and reset the system.

I need to repeat that I am not an official developer. I am a user with just enough information to make me dangerous. Nonetheless, I greatly appreciate your efforts to assist me in solving this critical issue.

What happens if you use "aptitude --full-upgrade" instead of "apt-get
--dist-upgrade" in the script?

On 10/25/07, BigPick <email address hidden> wrote:
>
> Many thanks for the help you guys.
>
> I would also like to thank John and Christian Assig for their efforts so
> far.
>
> FerranRius's comment is very prudent and correct however, this upgrade
> should not be attempted whatsoever by anyone who uses their machine for
> work, school, or other important operations. The patch I posted is
> simply the fix I came up with for my situation when I attempted to
> upgrade Feisty on the laptop I use around campus. I never thought I'd be
> thankful for dual-booting windows, and to be honest, I resent the need
> to rely on it. Luckily, I have two old towers I use as sandboxes for
> messing around with networking and various Unix installations. One is an
> Intel/nVidia, the other is AMD/ATI, both failed the upgrade and became
> unbootable (so I'm 0 for 3), making them perfect candidates for trying
> to fix this.
>
> Currently there are two memory leaks occurring as far as I can tell,
> only one of which I have identified and addressed in the patch. The
> second appears to be coming from the fetching of backport archives,
> which occurs prior to the main upgrade. I am unable to replicate this
> leak on my machines, so I have relied on the work of Christian Assig to
> track this down. He deserves many thanks for bearing with my sophomoric
> efforts. Although this patch does not fix the second leak, Christian did
> report dist-upgrade faied gracefully instead of crashing by bringing up
> an error window and attempting to recover and reset the system.
>
> I need to repeat that I am not an official developer. I am a user with
> just enough information to make me dangerous. Nonetheless, I greatly
> appreciate your efforts to assist me in solving this critical issue.
>
> --
> [MASTER] [kde] Upgrade tool crashed with " Cannot allocate memory" (edgy
> -> feisty)
> https://bugs.launchpad.net/bugs/107188
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
Loye Young
Isaac & Young Computer Company
Laredo, Texas
(956) 857-1172
<email address hidden>

valten (valten) wrote :

i have managed to make the update after all with several apt-get
upgrade commands so i cannot provide this information anymore, sorry
...

On 10/25/07, Loye Young <email address hidden> wrote:
> What happens if you use "aptitude --full-upgrade" instead of "apt-get
> --dist-upgrade" in the script?
>
> On 10/25/07, BigPick <email address hidden> wrote:
> >
> > Many thanks for the help you guys.
> >
> > I would also like to thank John and Christian Assig for their efforts so
> > far.
> >
> > FerranRius's comment is very prudent and correct however, this upgrade
> > should not be attempted whatsoever by anyone who uses their machine for
> > work, school, or other important operations. The patch I posted is
> > simply the fix I came up with for my situation when I attempted to
> > upgrade Feisty on the laptop I use around campus. I never thought I'd be
> > thankful for dual-booting windows, and to be honest, I resent the need
> > to rely on it. Luckily, I have two old towers I use as sandboxes for
> > messing around with networking and various Unix installations. One is an
> > Intel/nVidia, the other is AMD/ATI, both failed the upgrade and became
> > unbootable (so I'm 0 for 3), making them perfect candidates for trying
> > to fix this.
> >
> > Currently there are two memory leaks occurring as far as I can tell,
> > only one of which I have identified and addressed in the patch. The
> > second appears to be coming from the fetching of backport archives,
> > which occurs prior to the main upgrade. I am unable to replicate this
> > leak on my machines, so I have relied on the work of Christian Assig to
> > track this down. He deserves many thanks for bearing with my sophomoric
> > efforts. Although this patch does not fix the second leak, Christian did
> > report dist-upgrade faied gracefully instead of crashing by bringing up
> > an error window and attempting to recover and reset the system.
> >
> > I need to repeat that I am not an official developer. I am a user with
> > just enough information to make me dangerous. Nonetheless, I greatly
> > appreciate your efforts to assist me in solving this critical issue.
> >
> > --
> > [MASTER] [kde] Upgrade tool crashed with " Cannot allocate memory" (edgy
> > -> feisty)
> > https://bugs.launchpad.net/bugs/107188
> > You received this bug notification because you are a direct subscriber
> > of a duplicate bug.
> >
>
>
> --
> Loye Young
> Isaac & Young Computer Company
> Laredo, Texas
> (956) 857-1172
> <email address hidden>
>
> --
> [MASTER] [kde] Upgrade tool crashed with " Cannot allocate memory" (edgy -> feisty)
> https://bugs.launchpad.net/bugs/107188
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
>

All right, I am completely frustrated. First at my inability to fix the second memory leak and second by the total lack of developer input on this issue.

My current working thoery is that commit() function in the Cache class of the python-apt library runs into an infinite loop if an archive install returns a result of "Incomplete". My inability to replicate this error, and lack of familiarity with the python-apt library have thwarted my attempts to fix the problem.

For now, I am just going to post the third revision of my patch, which is essentially a regression. The patch no longer alters the types of Exceptions caught by the programs try/catch statements as this was mainly an attempt at getting more information. This revision just has the single memory leak fix.

I am incredibly displeased and disgusted by this entire situation.

Marco Cimmino (cimmo) wrote :

yeah BigPick I also had your problem, trying to resolve a big problem and lack of devels.
Unfortunately they have a lot of works and sometimes this a good excuse sometimes not.

anyway try to write an email to the package maintainer <email address hidden> pointing your patches, I'm sure that he wants to resolve this bis issue with so many duplicates :)

BigPick,

You have been working incredibly hard on this, and I'm sure you are very tired
and frustrated. You have done a great service already. You have already fixed
the biggest issue and gotten the thing back to working much better. Many have
already reported that your patches have enabled them to get their system
upgraded.

Your frustration is evidence of your deep commitment to Ubuntu and to
excellence in everything you do. (And maybe a healthy dose of perfectionism
thrown in as well?) You have many comrades who understand exactly what it
feels like to bang your head against the wall, see the wall move farther than
anyone else has ever done before, and still be pissed off that you can't move
it the rest of the way.

This is open source: it's all volunteer. Don't lose your sanity over it. If
you are tired, take a break. Go do something else. One of three things will
happen: It will still be there when you get back and you will have fresh
perspectives, you will take a second look at it and decide you have better
things to do, or someone will have picked up where you left off. If the
problem is big enough, someone else will jump in to help, just like you did.

St Jude is the patron saint of difficult cases. Perhaps while you are taking
the weekend off, he can go have a talk with the One who programmed us
all. :-)

Happy Trails,

Loye Young

On Friday, October 26, 2007 5:01:06 pm BigPick wrote:
> All right, I am completely frustrated. First at my inability to fix the
> second memory leak and second by the total lack of developer input on
> this issue.
>
> My current working thoery is that commit() function in the Cache class
> of the python-apt library runs into an infinite loop if an archive
> install returns a result of "Incomplete". My inability to replicate this
> error, and lack of familiarity with the python-apt library have thwarted
> my attempts to fix the problem.
>
> For now, I am just going to post the third revision of my patch, which
> is essentially a regression. The patch no longer alters the types of
> Exceptions caught by the programs try/catch statements as this was
> mainly an attempt at getting more information. This revision just has
> the single memory leak fix.
>
> I am incredibly displeased and disgusted by this entire situation.
>
> ** Attachment added: "BigPick dist-upgrade patch rev 3"
>
> http://launchpadlibrarian.net/10180893/gutsy-dist-upgrade_bigpick_0.3.patch

Hi!

How are the things going? I'm not a developer and am unable to apply the simplest patch :-(

It's a little bit frustating to be in no men's land. Now my distro is in the middle of the update process so neither I don't get the updates of Kubuntu 7.04 nor I can upgrade :-(

Should I wait until the problem is solved or should I look for greener pastures?

Javier

Marco Cimmino (cimmo) wrote :

Javier there is a workaround, change the config file and start the update in text mode, this worked around for me.
I've copied into first post steps.

description: updated

My solution was simple, Javier:

I'm a Windows tech support geek and I'm making the switch for a lot of
reasons but I have to admit I don’t know Linux like I know Window$ - not
yet anyway. Like you, I don't have the time or the experience to chase down
the problem or do file surgery on an operating system that's new to me. So
I resorted to the nuclear fix - wipe the drive and reinstall.

I had the relevant data backed up but it's just as easy to boot with a
Knoppix CD against the broken machine and back up the data that way. Once
that was done, I reinstalled from the installation CD right over the
original partitions. The install works just fine, it's the upgrade that's
crashing on us. This was true for my upgrade to 7.04 and again to 7.10.

It worked, of course, but it costs time to reconfigure and restore the
backed up data. Next time, maybe, I'll be ready to chase down the answers
but this is an old bug - more than a year old - and it's affected at least
two upgrades to date, so, I figure the developers are either totally
stumped or up to their collective eyeballs in a sea of more important
issues.

Something else you wrote caught my attention, though,

    <<Should I wait until the problem is solved or should I
    look for greener pastures?>>

It's not like Linux folk to sit around on their collective butts. I've
looked around and, for a n00by like myself, Ubuntu is easier to maintain
and I figure it's a good place to learn as well.

Speaker2Software
___________________________________________________
Code & Data: Making Excel Dance since 1994.
   Software Support & Data Services (ETL)
   VBA, COBOL, Documentation & Training
 * P.O. Box 302287; Austin, Texas 78703-2287
___________________________________________________

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of
Javier Arántegui
Sent: Friday, November 02, 2007 7:12 AM
To: <email address hidden>
Subject: [Bug 107188] Re: [MASTER] [kde] Upgrade tool crashed with "
Cannotallocate memory"

Hi!

How are the things going? I'm not a developer and am unable to apply the
simplest patch :-(

It's a little bit frustating to be in no men's land. Now my distro is in
the middle of the update process so neither I don't get the updates of
Kubuntu 7.04 nor I can upgrade :-(

Should I wait until the problem is solved or should I look for greener
pastures?

Javier

--
[Snipped, thank you... Now, me want more cookie...]

Alright, time for an update on my meddling.

In my earlier investigation into this problem I avoided looking at the python-apt code utilized by the update-manager as this would broaden the scope of the fix to another package. This week, after exhausting all other possible explanations for the second memory leak as reported by Christian Assig and others, I dove in. I identified a possible memory leak in the "commit()" function in "cache.py", and wrote an experimental patch. I will submit this as a new bug against the python-apt package in a moment. Anyone interested in helping resolve this issue, or checking my work, should take a look.

On Nov 2, 2007 5:12 AM, Javier Arántegui wrote:
> Hi!
>
> How are the things going? I'm not a developer and am unable to apply the
> simplest patch :-(
>
> It's a little bit frustating to be in no men's land. Now my distro is in
> the middle of the update process so neither I don't get the updates of
> Kubuntu 7.04 nor I can upgrade :-(
>
> Should I wait until the problem is solved or should I look for greener
> pastures?

Good luck waiting for a fix ;-) This bug has been known since the
previous release. At that time I was convinced it was going to be
fixed any time now. I would never have imagined that such a serious
upgrade bug would persist for two releases ... To this day there
isn't even a mention of it in the Kubuntu upgrade instructions, let
alone a fix.

This tells me that Canonical simply isn't taking Kubuntu seriously.
They are not to blame - 6-months is way too short time for a robust
release of two different desktops (or even one, if you ask me).
Perhaps another distribution which is primarily KDE-based would be a
better choice (MEPIS ?). Personally, I am posting this from Debian.

Alternatively you could pay $250 for support.

regards,
Tzvetan

Here is the workaround which worked for me:

* Download the Kubuntu "Alternate Install CD", burn it and mount it in /cdrom
* From a shell execute:
cd $(mktemp -d)
tar xzf /cdrom/dists/gutsy/main/dist-upgrader/binary-all/gutsy.tar.gz
wget http://launchpadlibrarian.net/10255100/DistUpgradeViewText.patch
patch < DistUpgradeViewText.patch
sed -ie "s/View=.*/View=DistUpgradeViewText/" DistUpgrade.cfg
sudo ./gutsy --cdrom /cdrom

The upgrade proceeds in text mode and completes successfully. Ironically there is also a minor bug in the text mode upgrade process (see https://bugs.launchpad.net/ubuntu/+bug/154195) - that is why the patch is necessary.

This is the same workaround as described by cimmo, but hopefully a bit more detailed so a novice could apply it (yeah, right :-).

On Friday, November 2, 2007 7:12:17 am Javier Arántegui wrote:
> Hi!
>
> How are the things going? I'm not a developer and am unable to apply the
> simplest patch :-(
>
> It's a little bit frustating to be in no men's land. Now my distro is in
> the middle of the update process so neither I don't get the updates of
> Kubuntu 7.04 nor I can upgrade :-(
>
> Should I wait until the problem is solved or should I look for greener
> pastures?
>
> Javier

Help is on the way.

Thanks for the comments on this bugreport and sorry for the trouble this is causing.

@BigPick: Thanks a lot for taking the time to investigate the mater so closely. If you can reproduce the problem reliably I would love to get in touch with you directly so that we can debug it together. If you can reproduce it, could you please tell me what version of kdelibs and kdebase you have installed when the bug happens?

Anyone who can reproduce the issue (maybe inside a virtual machine) and wants to help testing, I would appreciate if you could test the attached patch and see if that makes things better.

Thanks,
 Michael

BigPick (wpickard) wrote :
Download full text (3.5 KiB)

OMG its Michael! Thank goodness your here!

Forgive my moronic meddling, I obviously have absolutely no clue what I am doing. I went over my patch again and realized that my changes to the commit retry loops:

- currentRetry = 0
         fprogress = self._view.getFetchProgress()
         iprogress = self._view.getInstallProgress(self.cache)
         # retry the fetching in case of errors
         maxRetries = self.config.getint("Network","MaxRetries")
- while currentRetry < maxRetries:
+ for currentRetry in range(maxRetries):

...
             except IOError, e:
                 # fetch failed, will be retried
                 logging.error("IOError in cache.commit(): '%s'. Retrying (currentTry: %s)" % (e,currentRetry))
- currentRetry += 1

do absolutely nothing. :-D I somehow convinced myself that if an error other than a IOError were thrown, it would be magically caught by the try/catch statement and ignored, resulting in an infinite loop. This is obviously not the case, as erroneous exceptions are immediately passed up to DistUpgradeViewKDE and handled by _handleException. So that wasn't doing anything. No infinite loop. That leaves:

- self[key].markUpgrade()
+ self[key].markInstall()

as the only line which could have made any difference. (And it did for me and a few others for some reason.) What's interesting is that method call is only made in the section of the commit function that checks the state of the main metapackages (kubuntu-desktop, ubuntu-desktop, edubuntu-desktop, etc.). After looking back through my own logs and the logs that others have posted, I noticed that one commonality between some of them was kubuntu-desktop indicated that is wan't installed. In my case, kubuntu-desktop was accidentally removed accidentally by adept a while back when I replaced the ubuntu OO.o packages with ones from a third party repository to fix a font display issue. But this doesn't totally explain everything because the code that reports kubuntu-desktop as not being installed:

 if not metaPkgInstalled():
            logging.debug("none of the '%s' meta-pkgs installed" % metapkgs)
            for key in metapkgs:
                deps_found = True
                for pkg in self.config.getlist(key,"KeyDependencies"):
                    deps_found &= self.has_key(pkg) and self[pkg].isInstalled
                if deps_found:
                    logging.debug("guessing '%s' as missing meta-pkg" % key)
                    try:
                        self[key].markInstall()

occurs after the line that the patch changes. What I do know is that the difference between my failure logs and my success logs is the kubuntu-desktop metapackage being reported as installed in my successful logs right where the error occurs in my failure logs.

So far my only way to reliably test this has been to load Feisty installs onto my two sandbox towers and run them through the update process until they throw the error. Its a crude method of testing though and takes forever. I'm going to reload Feisty again on one of my tower, as both got to Gutsy despite my inept patch attempt, and give your patc...

Read more...

Michael Vogt (mvo) wrote :

@BigPick: Thanks for your analysis of the patch, when I read it I was wondering what change in it might have caused that the problem got fixed. My current theory is that the bug occur more or less random (or with a pattern that is very hard to reproduce) so that even if the patch itself has little effect, a upgrade test may still be successful because the bug is not triggered within this run. I'm currently trying to reproduce the problem with the virtualbox package in ubuntu. My current idea of reproducing it is to install kubuntu-feisty and try various combinations of stock kubuntu feisty install, install with updates, with backport enabled etc. Each time a snapshot is taken before the upgrade.

I hope using this method we will be able to find a way to reliable trigger the bug. Everybody is welcome to help with the hunt :) (my main machine is currently not usable, so I'm a bit slower with those tests as I would otherwise). As for the debugging output, I think that strace is usually a good first step. If we could get a gziped strace log when the bug happend, that would be really cool. I suspect the actual problem lies somewhere under the python layer of the code (in the C/C++ bits), so pdb is probably not that helpful. gdb might, once we know a bit better what to look for.

Cheers,
 Michael

There are specialized memory debugging tools, for example "valgrind".
If any attempt to allocate memory would fail, I would suspect that
valgrind would be able to give a nice stack trace. (recompile python
without optimization & with debugging symbols!)

refer to http://www.linuxjournal.com/article/6556 for a more detailed
article on the subject.

On 11/6/07, Michael Vogt <email address hidden> wrote:
> @BigPick: Thanks for your analysis of the patch, when I read it I was
> wondering what change in it might have caused that the problem got
> fixed. My current theory is that the bug occur more or less random (or
> with a pattern that is very hard to reproduce) so that even if the patch
> itself has little effect, a upgrade test may still be successful because
> the bug is not triggered within this run. I'm currently trying to
> reproduce the problem with the virtualbox package in ubuntu. My current
> idea of reproducing it is to install kubuntu-feisty and try various
> combinations of stock kubuntu feisty install, install with updates, with
> backport enabled etc. Each time a snapshot is taken before the upgrade.
>
> I hope using this method we will be able to find a way to reliable
> trigger the bug. Everybody is welcome to help with the hunt :) (my main
> machine is currently not usable, so I'm a bit slower with those tests as
> I would otherwise). As for the debugging output, I think that strace is
> usually a good first step. If we could get a gziped strace log when the
> bug happend, that would be really cool. I suspect the actual problem
> lies somewhere under the python layer of the code (in the C/C++ bits),
> so pdb is probably not that helpful. gdb might, once we know a bit
> better what to look for.
>
> Cheers,
> Michael
>
> --
> [patch] Upgrade tool crashed with " Cannot allocate memory"
> https://bugs.launchpad.net/bugs/107188
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Try this:

 valgrind /usr/bin/update-manager

*OUCH*

That's more memory-errors than I can copy-paste!!
Somebody needs to debug python2.5. This is a horrible mess!!

wateenellende (fpbeekhof) wrote :

For those interested, I tried this:

apt-get install python2.5-dbg valgrind
then, edit your /usr/bin/update-manager, line 1:
#!/usr/bin/python2.5-dbg

Then:
valgrind --log-file=python-errors /usr/bin/update-manager

This produced the attachment, and then said:
Traceback (most recent call last):
  File "/usr/bin/update-manager", line 28, in <module>
    import gtk
  File "/var/lib/python-support/python2.5/gtk-2.0/gtk/__init__.py", line 38, in <module>
    import gobject as _gobject
  File "/var/lib/python-support/python2.5/gtk-2.0/gobject/__init__.py", line 30, in <module>
    from gobject.constants import *
  File "/var/lib/python-support/python2.5/gtk-2.0/gobject/constants.py", line 22, in <module>
    from _gobject import type_from_name
ImportError: /var/lib/python-support/python2.5/gtk-2.0/gobject/_gobject.so: undefined symbol: Py_InitModule4
Error in sys.excepthook:
Traceback (most recent call last):
  File "/var/lib/python-support/python2.5/apport_python_hook.py", line 38, in apport_excepthook
    from apport.fileutils import likely_packaged
  File "/var/lib/python-support/python2.5/apport/__init__.py", line 1, in <module>
    from apport.report import Report
  File "/var/lib/python-support/python2.5/apport/report.py", line 18, in <module>
    from xml.parsers.expat import ExpatError
  File "/usr/lib/python2.5/site-packages/_xmlplus/parsers/expat.py", line 4, in <module>
    from pyexpat import *
ImportError: /usr/lib/python2.5/site-packages/_xmlplus/parsers/pyexpat.so: undefined symbol: Py_InitModule4

Original exception was:
Traceback (most recent call last):
  File "/usr/bin/update-manager", line 28, in <module>
    import gtk
  File "/var/lib/python-support/python2.5/gtk-2.0/gtk/__init__.py", line 38, in <module>
    import gobject as _gobject
  File "/var/lib/python-support/python2.5/gtk-2.0/gobject/__init__.py", line 30, in <module>
    from gobject.constants import *
  File "/var/lib/python-support/python2.5/gtk-2.0/gobject/constants.py", line 22, in <module>
    from _gobject import type_from_name
ImportError: /var/lib/python-support/python2.5/gtk-2.0/gobject/_gobject.so: undefined symbol: Py_InitModule4

I'll see if I can patch things a bit...

wateenellende (fpbeekhof) wrote :

Sorry, this is a dead end road.

Using the correct suppression file and python-dbg, all errors disappeared (they are false positives) ,
until it crashed because it can't find some gtk lib.
On a second attempt, using the correct suppression file and python without debugging symbols, my system hung hard.
I'm giving up....

arrikitaun (jcrp1970) on 2007-11-12
Changed in update-manager:
status: Confirmed → Invalid

Why was this set to "invalid". The defect still occurs and has been confirmed. No fix for it has yet been released. It may not be against the original packages that we thought, having been traced to a dependency, but it is still an outstanding defect, and the status invalid is not at all appropriate. Provide a fixed updater, and the defect can be closed.

Setting back to confirmed until it has been addressed.

Changed in update-manager:
status: Invalid → Confirmed
Marco Cimmino (cimmo) wrote :

why set to invalid?????

James Westby (james-w) wrote :

Hi,

It's only set to invalid for Baltix, it is still confirmed in
Ubuntu.

Thanks,

James

Harag (zaries) wrote :

This is happening on a sudo do-release-upgrade from intrepid to jaunty in a virtual machine

Checking for a new ubuntu release
Done Upgrade tool signature
Done Upgrade tools
Done downloading
extracting 'jaunty.tar.gz'
authenticate 'jaunty.tar.gz' against 'jaunty.tar.gz.gpg'

Reading cache

Checking package manager
Reading package lists: Done
Reading state information: Done
Reading state information: Done
Reading state information: Done
Hit http://archive.ubuntu.com intrepid Release.gpg
Hit http://security.ubuntu.com intrepid-security Release.gpg
Hit http://archive.ubuntu.com intrepid Release
Hit http://security.ubuntu.com intrepid-security Release
Done http://archive.ubuntu.com intrepid Release
Done http://security.ubuntu.com intrepid-security Release
Hit http://archive.ubuntu.com intrepid/main Packages
Hit http://security.ubuntu.com intrepid-security/main Packages
Hit http://archive.ubuntu.com intrepid/universe Packages
Hit http://archive.ubuntu.com intrepid/universe Sources
Done downloading
Reading package lists: Done
Reading state information: Done
Reading state information: Done
Reading state information: Done

Updating repository information
Done http://archive.ubuntu.com jaunty Release.gpg
Done http://archive.ubuntu.com jaunty Release
Done http://archive.ubuntu.com jaunty Release
Failed http://security.ubuntu.com jaunty-security Release.gpg
Done http://archive.ubuntu.com jaunty/main Packages
Done http://archive.ubuntu.com jaunty/main Packages
Done http://archive.ubuntu.com jaunty/universe Packages
Done http://archive.ubuntu.com jaunty/universe Packages
Done http://archive.ubuntu.com jaunty/universe Sources
Done http://archive.ubuntu.com jaunty/universe Sources
Done downloading

Checking package manager
Reading package lists: Doneaunty/universe Packages: 98
Reading state information: Done
Reading state information: Done
Reading state information: Done

A fatal error occurred

Please report this as a bug and include the files
/var/log/dist-upgrade/main.log and /var/log/dist-upgrade/apt.log in
your report. The upgrade is now aborted.
Your original sources.list was saved in
/etc/apt/sources.list.distUpgrade.

Traceback (most recent call last):

File "/tmp/tmpoG9RTE/jaunty", line 6, in <module>
main()

File "/tmp/tmpoG9RTE/DistUpgradeMain.py", line 125, in main
app.run()

File "/tmp/tmpoG9RTE/DistUpgradeController.py", line 1575, in run
self.fullUpgrade()

File "/tmp/tmpoG9RTE/DistUpgradeController.py", line 1514, in
fullUpgrade
self.openCache()

File "/tmp/tmpoG9RTE/DistUpgradeController.py", line 164, in
openCache
lock)

File "/tmp/tmpoG9RTE/DistUpgradeCache.py", line 107, in __init__
self.uname =
Popen(["uname","-r"],stdout=PIPE).communicate()[0].strip()

File "/usr/lib/python2.5/subprocess.py", line 594, in __init__
errread, errwrite)

File "/usr/lib/python2.5/subprocess.py", line 1073, in _execute_child
self.pid = os.fork()

OSError: [Errno 12] Cannot allocate memory

Nikolaus Rath (nikratio) wrote :

The same happens when trying to upgrade from Jaunty to Karmic using do-release-upgrade on a server system without X11.

Nikolaus Rath (nikratio) on 2009-11-07
description: updated
Michael Vogt (mvo) wrote :

@Nikolaus Rath: What specs did your system have? How much mem/swap? This error is even earlier than most of the problems described in the report, it fails already when calling "uname -r".

I wonder if for the others:
=== modified file 'DistUpgrade/DistUpgradeController.py'
--- DistUpgrade/DistUpgradeController.py 2009-11-03 16:03:25 +0000
+++ DistUpgrade/DistUpgradeController.py 2009-11-13 13:01:00 +0000
@@ -1040,6 +1040,18 @@
                 logging.error("IOError in cache.commit(): '%s'. Retrying (currentTry: %s)" % (e,currentRetry))
                 currentRetry += 1
                 continue
+ except OSError, e:
+ logging.exception("cache.commit()")
+ # deal gracefully with:
+ # OSError: [Errno 12] Cannot allocate memory
+ if e.errno == 12:
+ self._enableAptCronJob()
+ msg = _("Error during commit")
+ msg += "\n'%s'\n" % str(e)
+ msg += _("Restoring original system state")
+ self._view.error(_("Could not install the upgrades"), msg)
+ # abort() exits cleanly
+ self.abort()
             # no exception, so all was fine, we are done
             self._enableAptCronJob()
             return True

would help mitigating the problem somewhat by at least restoring a clean system state if it happens.

Nikolaus Rath (nikratio) wrote :

It's a Strato virtual server:

nikratio@ebox:~$ uname -a
Linux ebox 2.6.18-028stab064.7 #1 SMP Wed Aug 26 13:11:07 MSD 2009 i686 GNU/Linux

nikratio@ebox:~$ free
             total used free shared buffers cached
Mem: 5122676 224096 4898580 0 0 0
-/+ buffers/cache: 224096 4898580
Swap: 0 0 0

Do you need anything else?

---
Linux dexter.vps 2.6.18-128.2.1.el5.028stab064.7 #1 SMP Wed Aug 26
15:47:17 MSD 2009 i686 GNU/Linux
---
             total used free shared buffers
cached
Mem: 1024000 629444 394556 0 0
0
-/+ buffers/cache: 629444 394556
Swap: 0 0 0

I had a lot more free memory when I tried it because I shut down all my
webservers etc. Currently I have lisp image running that is chewing up
the memory (nearly half).

On Fri, 2009-11-13 at 13:06 +0000, Michael Vogt wrote:
> @Nikolaus Rath: What specs did your system have? How much mem/swap? This
> error is even earlier than most of the problems described in the report,
> it fails already when calling "uname -r".
>
> I wonder if for the others:
> === modified file 'DistUpgrade/DistUpgradeController.py'
> --- DistUpgrade/DistUpgradeController.py 2009-11-03 16:03:25 +0000
> +++ DistUpgrade/DistUpgradeController.py 2009-11-13 13:01:00 +0000
> @@ -1040,6 +1040,18 @@
> logging.error("IOError in cache.commit(): '%s'. Retrying (currentTry: %s)" % (e,currentRetry))
> currentRetry += 1
> continue
> + except OSError, e:
> + logging.exception("cache.commit()")
> + # deal gracefully with:
> + # OSError: [Errno 12] Cannot allocate memory
> + if e.errno == 12:
> + self._enableAptCronJob()
> + msg = _("Error during commit")
> + msg += "\n'%s'\n" % str(e)
> + msg += _("Restoring original system state")
> + self._view.error(_("Could not install the upgrades"), msg)
> + # abort() exits cleanly
> + self.abort()
> # no exception, so all was fine, we are done
> self._enableAptCronJob()
> return True
>
> would help mitigating the problem somewhat by at least restoring a clean
> system state if it happens.
>

http://aromasofcoorg.com/default/index.php

--
Political tags - such as royalist, communist, democrat, populist,
fascist, liberal, conservative, and so forth - are never basic
criteria. The human race divides politically into those who want
people to be controlled and those who have no such desire.

is that still an issue in karmic or lucid? the bug didn't get new duplicates or comment for months now

Changed in update-manager (Ubuntu):
status: Confirmed → Incomplete
Tzvetan Mikov (tmikov) wrote :

Sebastien, I will be upgrading my laptop from Kubuntu 8.04 to 10.04 one of these days, so I will post back here. Frankly, I am scared to upgrade, but it will be a good test because it is double upgrade from 8.04 to 9.10 and then to 10.04 (Kubuntu doesn't support a direct upgrade).

David Stansby (dstansby) on 2010-07-08
tags: added: patch-forwarded-upstream
tags: added: patch
removed: patch-forwarded-upstream
summary: - [patch] Upgrade tool crashed with " Cannot allocate memory"
+ Upgrade tool crashed with " Cannot allocate memory"
Tzvetan Mikov (tmikov) wrote :

Hi,
I just upgraded from Kubuntu 8.04 to 9.10 and then to 10.04 and didn't experience the problem. I used to have this problem on previous upgrades on the exact same system, so it appears it has been fixed. I vote to close it.

Invalidating per last comment. Please re-open if you're still affected.

Changed in update-manager (Ubuntu):
status: Incomplete → Invalid
Displaying first 40 and last 40 comments. View all 112 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers