Bug#682162: mysql-workbench: Massive Memory Leak

July 19th, 2012 - 05:10 pm ET by Daniel Fussell | Report spam
Package: mysql-workbench
Version: 5.2.40+dfsg-1+b1
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,

* What led up to the situation?
Entering and running 3 queries in the workbench SQL editor, with a maximum of
3 records in any of those queries (so not a result of a boundless
cartesian product). Total time in the session is only about 3 minutes
when the memory leak starts.

* What was the outcome of this action?
Process when from 92m resident to 1.5g resident memory usage over
the course of about 10 - 15 seconds, at which point my machine starts
into swap-death, and the process must be manually killed. Just to be
clear, this is resident memory, thought virtual memory is always high
as well.

* What outcome did you expect instead?
To be able to continue using, editing, and running several queries
for the duration of my session. At least a couple of hours would be nice,
and without using an enormous amount of memory.


Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages mysql-workbench depends on:
ii libatk1.0-0 2.4.0-2
ii libatkmm-1.6-1 2.22.6-1
ii libc6 2.13-33
ii libcairo2 1.12.2-2
ii libcairomm-1.0-1 1.10.0-1
ii libctemplate2 2.2-3
ii libfontconfig1 2.9.0-6
ii libfreetype6 2.4.9-1
ii libgcc1 1:4.7.1-2
ii libgdk-pixbuf2.0-0 2.26.1-1
ii libgl1-mesa-glx [libgl1] 8.0.3-1
ii libglib2.0-0 2.32.3-1
ii libglibmm-2.4-1c2a 2.32.0-1
ii libgnome-keyring0 3.4.1-1
ii libgtk2.0-0 2.24.10-1
ii libgtkmm-2.4-1c2a 1:2.24.2-1
ii liblua5.1-0 5.1.5-2
ii libmysqlclient18 5.5.24+dfsg-4
ii libpango1.0-0 1.30.0-1
ii libpangomm-1.4-1 2.28.4-1
ii libpcre3 1:8.30-5
ii libpython2.7 2.7.3-1
ii libsigc++-2.0-0c2a 2.2.10-0.2
ii libsqlite3-0 3.7.13-1
ii libstdc++6 4.7.1-2
ii libtinyxml2.6.2 2.6.2-1
ii libuuid1 2.20.1-5.1
ii libx11-6 2:1.5.0-1
ii libxml2 2.8.0+dfsg1-4
ii libzip2 0.10.1-1
ii mysql-client 5.5.24+dfsg-4
ii mysql-client-5.5 [mysql-client] 5.5.24+dfsg-4
ii mysql-workbench-data 5.2.40+dfsg-1
ii python 2.7.3~rc2-1
ii python-mysql.connector 0.3.2-1
ii python-paramiko 1.7.7.1-2
ii python-pexpect 2.4-1
ii python-pysqlite2 2.6.3-3
ii python2.7 2.7.3-1
ii zlib1g 1:1.2.7.dfsg-13

Versions of packages mysql-workbench recommends:
ii mysql-utilities 1.0.5-1
ii ttf-bitstream-vera 1.10-8

Versions of packages mysql-workbench suggests:
ii gnome-keyring 3.4.1-4



To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
email Follow the discussionReplies 3 repliesReplies Make a reply

Replies

#1 Dmitry Smirnov
July 20th, 2012 - 09:10 pm ET | Report spam
Hi Daniel,

Thanks for your report.

It is a bit puzzling since just a week ago I was using M-W for several hours a
day and I didn't even bother to restart it for a week - I was just suspending
my workstation instead.

Also I've noticed that upstream have no open tickets regarding memory leaks
which I interpret as evidence that there is no such problem for all other
distributions.

Today I tried to reproduce the issue without success:
after ~50 trivial SELECT queries mysql-workbench-bin uses

VIRT : 683M
RES : 75200
SHR : 41300

with ~10 threads.

It is a heavy application indeed but I see no problem you describe.

Would you be able to provide more information how to reproduce please?

Thanks.

Regards,
Dmitry.


To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Similar topics