Possible Infinite Loop in "commit()" Method

[BigPick]

Binary package hint: python-apt

This bug is related to:
https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/107188

In researching possible causes of the memory leak exceptions reported by some users attempting to upgrade using the "upgrade-manager" tool, a possible infinite loop resulting in memory leakage was identified in the "commit()" method of the "Cache" class in "apt/cache.py".

The method in question fetched and installed the required archives within a while loop, breaking from this loop only in the event of installArchives "ResultCompleted" or "ResultFailed". The intended function of this loop was assumed to be to attempt repeating the installation if installArchives returned a value of "ResultIncomplete". However, in some cases "ResultIncomplete" is returned due to an unmet condition of the installation, resulting in an infinite loop. A possible source of unmet conditions is a failure in fetching the archives to be installed; a situation not tested for within the loop.

I am also submitting an experimental patch I used to resolve this issue on my machine. In the patch a check is added on the return value of _fetchArchives() before calling installArchives(), in an effort to stop the installation going forward without all pre-conditions being met. The fetching and installing of archives is removed from the loop, and a return value of "ResultIncomplete" causes a new type of system error to be raised. This was done because I believe it would be better to have the calling program make the decision to re-attempt installation rather than doing so automatically. The final change is just a response to the FIXME in the "markUpgrade()" function of "apt/package.py". As described in the above update-manager bug report, the failure of markUpgrade() to raise an exception caused unexpected behavior in the update-manager code.

The patch was written for the python-apt-0.7.3.1ubuntu4 source version.

[Michael Vogt (mvo)]

Thanks for your bugreport and your patch.

Are you able to reproduce the crash that is reported in #107188 in one of your test machines? If so, I would love to debug it further with you, I was never able to reproduce it myself. The python-apt code in question is used by gdebi and update-manager in gtk too and I have never seen a issue like the one in #107188 here. If the python-apt code is the problem, then it must be something within the KDE upgrade view that triggers the problem. You can reach me on irc as "mvo" on irc.freenode.net and as <email address hidden> on jabber.

[Guillaume Martres (smarter)]

Any news on this? With Hardy, GDebi still use 100% of my CPU when I install something

[Christiansen (happylinux)]

Same issue with GDebi here on one laptop with a fresh Kubuntu Hardy Beta install. Before the fresh install the box was opgraded from Alpa2 -> Alpha3 -> ... -> Alpha 6 and then Beta, and the issue was identical after the last 2 or 3 upgrades. Other testboxes with Hardy do NOT show this hyper CPU usage, even installing the same packages from a USB stick.

BTW. No CPU issue installing packages from repository in Adept.

[Jonathan Thomas (echidnaman)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!