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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
