Bug#682162: mysql-workbench: Massive Memory Leak

[Dragomir Dragnev]

Package: mysql-workbench
Version: 5.2.44+dfsg-1~exp1
Followup-For: Bug #682162

Hi Dmitry,
I have the same effects like Daniel and 5.2.44 didn't make any difference

Executed from terminal:
$ mysql-workbench
Initializing AdvancedSidebar factory method
Initializing mforms factory
** Message: Gnome keyring daemon seems to not be available. Stored passwords
will be lost once quit
Creating WBOptions
Ready.

** Message: overview.home built-in command is being overwritten

(mysql-workbench-bin:9975): Gtk-CRITICAL **: gtk_tree_view_unref_tree_helper:
assertion `node != NULL' failed

(mysql-workbench-bin:9975): Gtk-CRITICAL **: gtk_tree_view_unref_tree_helper:
assertion `node != NULL' failed

(mysql-workbench-bin:9975): Gtk-CRITICAL **: gtk_tree_view_unref_tree_helper:
assertion `node != NULL' failed

(mysql-workbench-bin:9975): Gtk-CRITICAL **: gtk_tree_view_unref_tree_helper:
assertion `node != NULL' failed

(mysql-workbench-bin:9975): Gtk-CRITICAL **: gtk_tree_view_unref_tree_helper:
assertion `node != NULL' failed

(mysql-workbench-bin:9975): Gtk-CRITICAL **: gtk_tree_view_unref_tree_helper:
assertion `node != NULL' failed
Terminated


After executing 6-7 times this query:
select * from mysql.no_such_table;

with no result at all but just error:
1 14:39:38 select * from mysql.no_such_table LIMIT 0, 1000 Error
Code: 1146. Table 'mysql.no_such_table' doesn't exist 0.041 sec
2 14:40:53 select * from mysql.no_such_table LIMIT 0, 1000 Error
Code: 1146. Table 'mysql.no_such_table' doesn't exist 0.000 sec
3 14:40:55 select * from mysql.no_such_table LIMIT 0, 1000 Error
Code: 1146. Table 'mysql.no_such_table' doesn't exist 0.000 sec
4 14:40:57 select * from mysql.no_such_table LIMIT 0, 1000 Error
Code: 1146. Table 'mysql.no_such_table' doesn't exist 0.000 sec
5 14:41:02 select * from mysql.no_such_table LIMIT 0, 1000 Error
Code: 1146. Table 'mysql.no_such_table' doesn't exist 0.000 sec
6 14:41:10 select * from mysql.no_such_table LIMIT 0, 1000 Error
Code: 1146. Table 'mysql.no_such_table' doesn't exist 0.000 sec

at this point the memory usage is already 822M, on next run usage jumps to
1.2G
and increase with 100M at second, and i kill it fast because of the swap-death
effect. If I try to close the program instead of executing the query once more
the same effect happens so killing is inevitable.

I am on KDE4(4.8.4) with Openbox(3.5.0-4)
Tested with Mysql server 5.5.24-9(localhost) and 5.0.51a-24+lenny5(remote)

Hope i helped,
Dragomir Dragnev



-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.5.4 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages mysql-workbench depends on:
ii libatkmm-1.6-1 2.22.6-1
ii libc6 2.13-35
ii libcairo2 1.12.2-2
ii libctemplate2 2.2-3
ii libgcc1 1:4.7.1-7
ii libgdk-pixbuf2.0-0 2.26.1-1
ii libgl1-mesa-glx [libgl1] 8.0.4-2
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-2
ii libgtkmm-2.4-1c2a 1:2.24.2-1
ii liblua5.1-0 5.1.5-4
ii libmysqlclient18 5.5.24+dfsg-9
ii libmysqlcppconn6 1.1.1-2
ii libodbc1 2.2.14p2-5
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~rc2-2.1
ii libsigc++-2.0-0c2a 2.2.10-0.2
ii libsqlite3-0 3.7.13-1
ii libstdc++6 4.7.1-7
ii libtinyxml2.6.2 2.6.2-1
ii libuuid1 2.20.1-5.2
ii libx11-6 2:1.5.0-1
ii libxml2 2.8.0+dfsg1-5
ii libzip2 0.10.1-1.1
ii mysql-client 5.5.24+dfsg-9
ii mysql-client-5.5 [mysql-client] 5.5.24+dfsg-9
ii mysql-workbench-data 5.2.44+dfsg-1~exp1
ii python 2.7.3~rc2-1
ii python-mysql.connector 0.3.2-1
ii python-paramiko 1.7.7.1-3
ii python-pexpect 2.4-1
ii python-pysqlite2 2.6.3-3
ii python2.7 2.7.3~rc2-2.1
ii unixodbc 2.2.14p2-5

Versions of packages mysql-workbench recommends:
pn mysql-utilities <none>
ii ttf-bitstream-vera 1.10-8

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

-- no debconf information


--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Dmitry Smirnov]

Hi Dragomir,

Thank you for detailed report.

I'm on KDE as well and I have the very same set of libraries installed yet I
can't reproduce the issue. The only difference between our configuration that
I've spotted is kernel -- I have Linux 3.2.0-3-amd64 installed.

Could you try with Linux 3.2.0-3-amd64 please?

Thanks.

Regards,
Dmitry.

--
Regards,
Dmitry.

[Dragomir Dragnev]

Hi Dmitry,

I didn't get to test with the stock kernel, but I played a little with
valgrind and at one point (on 5-6 query) this starts to flood infinitely:

==12581== 9,749,448 bytes in 135,409 blocks are possibly lost in loss record
33,777 of 33,779
==12581== at 0x4C272B8: calloc (vg_replace_malloc.c:566)
==12581== by 0xB280E38: g_malloc0 (in /lib/x86_64-linux-
gnu/libglib-2.0.so.0.3200.3)
==12581== by 0xA4AF694: g_closure_new_simple (in /usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0.3200.3)
==12581== by 0xA4B0BFA: g_cclosure_new (in /usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0.3200.3)
==12581== by 0xA4C7731: g_signal_connect_data (in /usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0.3200.3)
==12581== by 0x15C94F4B: ??? (in /usr/lib/x86_64-linux-
gnu/gtk-2.0/2.10.0/engines/libqtcurve.so)
==12581== by 0x15C95115: ??? (in /usr/lib/x86_64-linux-
gnu/gtk-2.0/2.10.0/engines/libqtcurve.so)
==12581== by 0x15C95115: ??? (in /usr/lib/x86_64-linux-
gnu/gtk-2.0/2.10.0/engines/libqtcurve.so)
==12581== by 0x15C951E2: ??? (in /usr/lib/x86_64-linux-
gnu/gtk-2.0/2.10.0/engines/libqtcurve.so)
==12581== by 0x15C9520B: ??? (in /usr/lib/x86_64-linux-
gnu/gtk-2.0/2.10.0/engines/libqtcurve.so)
==12581== by 0xA4B0723: g_closure_invoke (in /usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0.3200.3)
==12581== by 0xA4C17AF: ??? (in /usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0.3200.3)

.... and so on and so on

So i tested to change default GTK2 theme from QtCurve to Qt4 from system
settings and without kde restart tested mysql-workbench again with full
success no more memory leaks or anything - just looking ugly..

So for temporary sloution without global change ot GTK2 theme:
GTK2_RC_FILES=/usr/share/themes/Qt4/gtk-2.0/gtkrc mysql-workbench

Dmitry what GTK2 theme do you use? I wonder is it some general bug in QtCurve,
some messed up settings of QtCurve or some misuse of it by mysql-workbench.

Also I tested with qtcurve experimental version 1.8.14-1 (current: 1.8.12-2)
with the same result:
sudo aptitude -t experimental install kde-style-qtcurve kwin-style-qtcurve
qtcurve-i18n

And finally I downgraded mysql-workbench from 5.2.44+dfsg-1~exp1 to
5.2.40+dfsg-1+b1 and the above solution does work for the memory leak problem
but there pops-up another bug that is missing in 5.2.44: with the same query:
select * from mysql.no_such_table;
it prints the error that the table does not exist, but on the status line
stays "Executing Query..." and now the program can not be closed any more and
acts stragnly...
Apparently in 5.2.44 this bug is fixed so I am going back with experimental
and staying there...

Regards,
Drago

[Dmitry Smirnov]

Hi Dragomir,

On Wed, 17 Oct 2012 23:38:28 Dragomir Dragnev wrote:
> So i tested to change default GTK2 theme from QtCurve to Qt4 from system
> settings and without kde restart tested mysql-workbench again with full
> success no more memory leaks or anything - just looking ugly..
>
> So for temporary sloution without global change ot GTK2 theme:
> GTK2_RC_FILES=/usr/share/themes/Qt4/gtk-2.0/gtkrc mysql-workbench
>

You've found the problem, thank you. :)

Could you please also try with

--force-sw-render
and
--force-opengl-render

to see if it have any effect on leak?

> Dmitry what GTK2 theme do you use? I wonder is it some general bug in
> QtCurve, some messed up settings of QtCurve or some misuse of it by
> mysql-workbench.

I'm with Oxygen (kde-style-oxygen, gtk2-engines-oxygen, gtk3-engines-oxygen,
kde-config-gtk-style) and I don't have any *-qtcurve packages installed.

>
> Also I tested with qtcurve experimental version 1.8.14-1 (current:
> 1.8.12-2) with the same result:
> sudo aptitude -t experimental install kde-style-qtcurve kwin-style-qtcurve
> qtcurve-i18n

Looks like problematic package is

gtk2-engines-qtcurve

See more

https://bugs.freedesktop.org/show_bug.cgi?id=54657#c4

> And finally I downgraded mysql-workbench from 5.2.44+dfsg-1~exp1 to
> 5.2.40+dfsg-1+b1 and the above solution does work for the memory leak
> problem but there pops-up another bug that is missing in 5.2.44: with the
> same query: select * from mysql.no_such_table;
> it prints the error that the table does not exist, but on the status line
> stays "Executing Query..." and now the program can not be closed any more
> and acts stragnly...

Sorry about that. Version 5.2.40+dfsg-2 is fixed in that regards.
For a while I couldn't backport fix for "hangs on exit" because upstream have
no public code repository (VCS). :(

Finally last week I uploaded fixed 5.2.40 to "unstable" and just today it
migrated to "testing" probably hours after you tried buggy version.

> Apparently in 5.2.44 this bug is fixed so I am going back with experimental
> and staying there...

:)

Thank you for all the troubleshooting and feedback.

Cheers,
Dmitry.

[Dragomir Dragnev]

Hi Dmitry,

Sorry for the slow response..

On Thursday 18 October 2012 01:59:23 Dmitry Smirnov wrote:
> Could you please also try with
>
> --force-sw-render
> and
> --force-opengl-render
>
> to see if it have any effect on leak?

No difference at all.

> Looks like problematic package is
>
> gtk2-engines-qtcurve
>
> See more
>
> https://bugs.freedesktop.org/show_bug.cgi?id=54657#c4

Indeed I did couple of downgrades of gtk2-engines-qtcurve from 1.8.15-2 down
to 1.6.4-1 and there the problem disappears, apparently it is introduced
somewhere between 1.6.4-1 and 1.8.1-1.

> Sorry about that. Version 5.2.40+dfsg-2 is fixed in that regards.
> For a while I couldn't backport fix for "hangs on exit" because upstream
> have no public code repository (VCS). :(
>
> Finally last week I uploaded fixed 5.2.40 to "unstable" and just today it
> migrated to "testing" probably hours after you tried buggy version.

Yep, in 5.2.40+dfsg-2 no such problem.. thanks:)

Regards,
Dragomir

[Dmitry Smirnov]

On Sat, 10 Nov 2012 09:26:40 Daniel Fussell wrote:
> I checked the change log for the updated 1.8.15-3 version of the package
> and saw the "fix memory leak" entry earlier. So I updated it, switched
> back to qtcurves, ulimit-ed the virtual memory to 1.2GB, and started
> mysql-workbench from that shell.
>
> After getting to the SQL editor, the virtual memory was at 1GB (compared
> to 600MB for Adwaita), and after the 4th query it started it's explosive
> memory leak, same as before. So it would appear there is still an issue
> in the qtcurve libs, or maybe workbench abusing the theme in some
> strange way. For kicks and giggles I ran 228 simple queries with the
> Adwaita theme, and the virtual memory only went up by about 50MB, but I
> suspect that's for the command and result history.
>
> There is the gtk_tree_view_unref_tree_helper `node != NULL` assertions
> that shows up on the terminal after the second query and every query
> thereafter. Perhaps there is still a memory leak from a local pointer
> getting reset without freeing memory-intensive qtcurve objects first.
>
> Grazie,
> Daniel

Thank you for fantastic feedback Daniel. Much appreciated.

All the best,
Dmitry.

[Boris Pek]

Hi,

> I checked the change log for the updated 1.8.15-3 version of the package
> and saw the "fix memory leak" entry earlier.

That was another memory leak. That's why this bug is not closed.

> So I updated it, switched
> back to qtcurves, ulimit-ed the virtual memory to 1.2GB, and started
> mysql-workbench from that shell.
>
> After getting to the SQL editor, the virtual memory was at 1GB (compared
> to 600MB for Adwaita), and after the 4th query it started it's explosive
> memory leak, same as before. So it would appear there is still an issue
> in the qtcurve libs, or maybe workbench abusing the theme in some
> strange way. For kicks and giggles I ran 228 simple queries with the
> Adwaita theme, and the virtual memory only went up by about 50MB, but I
> suspect that's for the command and result history.
>
> There is the gtk_tree_view_unref_tree_helper `node != NULL` assertions
> that shows up on the terminal after the second query and every query
> thereafter. Perhaps there is still a memory leak from a local pointer
> getting reset without freeing memory-intensive qtcurve objects first.

Yes, it looks that bug can be related with processing GtkTreeView elements,
but nor I nor upstream have no enough free time to research the problem right
now. Hope we will find it soon.

Best regards,
Boris