Gdebi-kde uses massive amounts of memory!

[Mikael Gerdin]

When I tried gdebi-kde today to install an updated kdelibs-deb (to fix the kopete issue) I suddenly noticed that my system was getting less and less responsive, with increasing disk activity.
It seemed that gdebi allocated massive amounts of memory, when I checked with "top" it said that gdebi-kde was using 56% of my available memory (1024MB). I am quite sure that this wasn't the case when I used gdebi-kde before, although I usually stick to using "dpkg" in a terminal.
The massive disk activity was apparently because of all the swapping the kernel needed to do to get more memory.
I don't have any crash log or anything, but I'll be happy to provide the devs with whatever gdb/valgrind/somethingelse-output they might need.

[Filip Milivojevic (zekica)]

I have the same problem with gdebi-kde after update to final. I haven't had this problem with Gutsy RC version.

The problem is that after launching gdebi-kde as root, it starts to allocate memory until there is no more available, and then crashes.

[romassi (romassi1977)]

I experience the same problem from tribe version of Kubuntu gutsy to the actual stable release.
Nothing changed during all upgrades.
No crash log for me too...the installation process with gdebi is VERY slow and resource-expensive but ends correctly.
I suggest using kpackage instead of gdebi-kde until this bug is solved: there are no problems neither in cpu usage nor in massive memory allocation.

[birdflesh (birdflesh)]

Same situation here. Actually I never managed to install anything with gdebi-kde since tribe 4 that I first tried it. When attempting an installation it starts using all the available system memory and eventually crashes. Starting it from konsole (gdebi-kde ********.deb) I got this output during the crash: OSError: [Errno 12] Cannot allocate memory

[Mikael Gerdin (mgerdin)]

I've just tried running gdebi-kde on the exact same computer, but instead of i386 (which I usually run) I tried running the amd64-flavour from a USB-stick. When doing this I noticed no strange memory behavior at all, so I might be that this bug only affects i386, which sounds very strange since gdebi-kde is written in python.

It would be nice if anyone else could test this on amd64 (or any other platform for that matter) to confirm if this only affects i386.

[Matt Sicker (jvz)]

Several people can confirm this bug exists, and having just suffered from it a few minutes ago again, I think we can safely say there's a problem here.

[Joris Grouwels (jorisgrouwels)]

I can also confirm this bug.

[Mikael Gerdin (mgerdin)]

Joris: It would be helpful if you could say which architecture (i386, amd64, etc.) you're running so that we can determine if this affects i386 only or other archs as well.

[Joris Grouwels (jorisgrouwels)]

Hi Mikael

I'm on an Intel Pentium IV, 512MB RAM, Kubuntu Gutsy.
If you need something more, just let me know.

Thanks for your efforts!

Joris

Mikael Gerdin schreef:
> Joris: It would be helpful if you could say which architecture (i386,
> amd64, etc.) you're running so that we can determine if this affects
> i386 only or other archs as well.
>
>

[Mikael Gerdin (mgerdin)]

What we need to know is if you're running a 64-bit och 32-bit version of
Kubuntu, since there are 64-bit versions of Pentium 4. Just so that we can be
sure please post the output of running "dpkg --print-architecture" in a
terminal.

On Saturday 27 October 2007 15:45:02 Joris Grouwels wrote:
> Hi Mikael
>
> I'm on an Intel Pentium IV, 512MB RAM, Kubuntu Gutsy.
> If you need something more, just let me know.
>
> Thanks for your efforts!
>
> Joris
>
> Mikael Gerdin schreef:
> > Joris: It would be helpful if you could say which architecture (i386,
> > amd64, etc.) you're running so that we can determine if this affects
> > i386 only or other archs as well.

[birdflesh (birdflesh)]

Still happening after a clean install of gutsy (i386 arch)

[Hani (hani17)]

I've got this bug on a Pentium 4, 32-bit Gutsy. "dpkg --print-architecture" output is: i386.
Gdebi-KDE takes all my memory and eats up all the swap. The system becomes very sluggish due to continuous access to the hard drive.
Gdebi tool from the Konsole works by the way.

[jeroenl (jeroenl)]

I can also confirm this and it even crashes just before it wants to install the actual package, so after the dependencies check. I will add the file generated in /var/crash, hopefully this can fix this critical bug asap. FYI: The CLI-version of gdebi works fine.

[Marvin Hankley (marvin-hankley)]

I can confirm this on Kubuntu Hardy on x86 with an Athlon XP 2600+ and 512 Mb of RAM. I've just installed a few packages using gdebi-kde and the process took 52-56% of memory, accessed the hard disk a whole lot and generally slowed down the whole computer.

[Warren Dumortier (locowarr)]

Please fix this bug, it make Kubuntu hard to use when you tend to install any package! Please fix it for Hardy!

[Warren Dumortier (locowarr)]

What is the status of this bug, someone knows hy it doesn't work!

I have 2 installations of Kubuntu Hardy on 2 different pcs, one of them (fully up-to-date) gives the same error as "jeroenvrp", the allocation error; the other pc which is not totally up-to-date, in fact only some packages like python and gdebi* are up-to-date, this pc gives me this errror: "Failed to fork".

Please fix it! Kind regards...

[Swistak (swistakers)]

I have this bug on Kubuntu Hardy with all updates. Here's some output:

[swistak 17:56 ~]$ gdebi-kde billreminder_0.3.1-1_all.deb
/usr/lib/python2.5/site-packages/apt/__init__.py:18: FutureWarning: apt API not stable yet
  warnings.warn("apt API not stable yet", FutureWarning)
/usr/lib/python2.5/site-packages/apt/__init__.py:18: FutureWarning: apt API not stable yet
  warnings.warn("apt API not stable yet", FutureWarning)

kbuildsycoca running...

DCOP Cleaning up dead connections.

kdecore (KProcess): WARNING: setPty()

kdecore (KProcess): WARNING: _attachPty() 33

Traceback (most recent call last):
  File "/usr/bin/gdebi-kde", line 83, in <module>
    gdebi.installButtonClicked()

  File "/usr/lib/python2.5/site-packages/GDebi/GDebiKDE.py", line 265, in installButtonClicked

    dprogress.commit()
  File "/usr/lib/python2.5/site-packages/GDebi/KDEAptDialogs.py", line 85, in commit

    self.child_pid = os.fork()
OSError: [Errno 12] Cannot allocate memory

[luisromangz (luisromangz)]

I confirm this in Kubuntu Hardy in a Compaq Presario M2000 with 1Gib of RAM.

[jeroenl (jeroenl)]

This bug still exists in Hardy. Why is this bug not resolved? What's the use of reporting (confirmed) bugs, when they are not even fixed?

[tolaware (tola-ware)]

I can confirm this bug it's still present on Hardy.

Sempron Mobile 3500 1GB Ram, Kubuntu Hardy i386

[tolaware (tola-ware)]

Sorry I have forget the uname -a result:

Linux tolaware-laptop 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 i686 GNU/Linux

[Matevž Jekovec (matevz-jekovec)]

The bug is still present in Kubuntu Hardy. My gdebi-kde process needs about 710MB of RAM to install a deb packet (doesn't depend which one).

[Martin Böhm (martin.bohm)]

Please download this script: http://launchpadlibrarian.net/8558791/gd-test.py and run it in your console (python gd-test.py) and tell me if it crashed for you. Thank you.

[tolaware (tola-ware)]

I'm wonderign why this bug it's not even assigned to anyone.

[Mikael Gerdin (mgerdin)]

Martin Böhm:
I've ran that python script for about 5 minutes on both i386 and amd64 and I couldn't see any strange memory usage or crash.

[Kuovsk Anekask (kuovsk-anekask)]

Martin Böhm:
Ran your script on i386, it sat there saying "installing..." at 0% for about 5 mins.
Hope this helps.

[Michele Corazza (ashmikuz)]

Same for me on i386... The script runs and remains at 0%

[Martin Böhm (martin.bohm)]

Thank you for your comments. I wanted to check if this bug is related to the one which this test was designed for. Unfortunately (or fortunately?), it is not.

[Juan Carlos I (juancarlos1)]

I can confirm this bug with kubuntu hardy, this is the output from a console:
In the meanwhile, I use gdebi-gtk for the same purpose, wich runs ok

$ gdebi-kde pydza_v108.deb
/usr/lib/python2.5/site-packages/apt/__init__.py:18: FutureWarning: apt API not stable yet
  warnings.warn("apt API not stable yet", FutureWarning)
passprompt

/usr/lib/python2.5/site-packages/apt/__init__.py:18: FutureWarning: apt API not stable yet
  warnings.warn("apt API not stable yet", FutureWarning)

kbuildsycoca running...

Reusing existing ksycoca

kdecore (KProcess): WARNING: setPty()
kdecore (KProcess): WARNING: _attachPty() 51

Traceback (most recent call last):

  File "/usr/bin/gdebi-kde", line 83, in <module>
    gdebi.installButtonClicked()
  File "/usr/lib/python2.5/site-packages/GDebi/GDebiKDE.py", line 265, in installButtonClicked

dprogress.commit()

  File "/usr/lib/python2.5/site-packages/GDebi/KDEAptDialogs.py", line 85, in commit

    self.child_pid = os.fork()
OSError
: [Errno 12] No se puede asignar memoria
#this is: Can not assign memory

[Mehul J. Rajput (mehulrajput)]

I am using gdebi in gnome and in that too, gdebi is using huge amount of memory when it is trying to install a even small software.

[Mehul J. Rajput (mehulrajput)]

i upgraded to intrepid... seems this is fixed in that.

[Jonathan Thomas (echidnaman)]

Yes, this does not seem to be an issue any more with gdebi-kde 0.3.13 in Intrepid. If still this happens with 0.3.13 or greater, please reopen this bug.

[Anshul (anshul-alum)]

How do I fix this by upgrading to Intrepid? I still have my repositories pointed to Hardy. Will pointing my sources.list to Intrepid fix this issue and/or break other KDE3 packages?

-Anshul

[Lesergi (lesergi)]

Hi!

Confirmed, with Intrepid version the problem is fixed.

In order to install Intrepid version:

Download:
http://fr.archive.ubuntu.com/ubuntu/pool/main/g/gdebi/gdebi-kde_0.3.13_all.deb
http://fr.archive.ubuntu.com/ubuntu/pool/main/g/gdebi/gdebi-core_0.3.13_all.deb

And, in download directory, install with:
sudo dpkg -i *.deb
sudo apt-get -f install

This try to install DEB packages, and if there is any dependence not-installed, it will install it.

Bye!