MySQL Bugs: #17879: MySQL Administrator hangs after pressing User Administration Icon

Bug #17879	MySQL Administrator hangs after pressing User Administration Icon
Submitted:	2 Mar 2006 22:28	Modified:	13 Oct 2006 16:39
Reporter:	Marcin Deka	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Administrator	Severity:	S2 (Serious)
Version:	1.1.10	OS:	Linux (Linux Debian 3.1)
Assigned to:	Alfredo Kojima	CPU Architecture:	Any
Tags:	User Management

Description:
MySQL Administrator hangs after pressing User Administration Icon. It is not
possible to stop the proccess with 'stop' button in the bottom.
It says 'retrieving data from MySQL...      Please wait..."
The window contens is not refreshed, aplication totaly frozen.

How to repeat:
see description

Suggested fix:
no fix known

I have the same problem.
The problem only occurs when using user administration.
Hope they solve this problem very quickly.

I have the same problem. This is indeed very critical. It renders the usefullnes of this app to 0. 
On windows everything works very smooth. In Linux there seems to be missing a lot of functionality. I even can't create just a table, it keeps giving me stupid errors about syntax, while on windows it has no problem at all with the same input. (just basic table.)

Thank you for the bug report. Same on Fedora Core 4.

Also hangs on fedora core 5 64 bit.

version is mysql 5.0.18
mysql administrator 1.1.6

databases running on raid1 array on 3ware 9500s-8

Bug: http://bugs.mysql.com/bug.php?id=18485 was marked as duplicate
of this one.

Workaround for this bug:

Set environment variable DEBUG_DONT_SPAWN_FETCHES=1 

e.g. 

export DEBUG_DONT_SPAWN_FETCHES=1
mysql-administrator

The workaround works with my 1.1.6 version on Gentoo against 5.0 and 4.1 servers. I've also experienced this with Ubuntu Dapper, but I can't test the fix right now, but I'll assume it works.

I've tested workaround on Debian 3.1 and it helps. Now it is possible to run user administration.

As workaround is ok I'm changing severity to S2 (Seriuos).

It works under Ubuntu Dapper Drake.

Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at
    http://www.mysql.com/doc/en/Installing_source_tree.html

Additional info:

Installed debian and was able to repeat. Probably related to the version of gtk+2 in it. It has been fixed, so next release should work normally.

Hi Alfredo,
is the module which should be checked out is the one at http://mysql.bkbits.net:8080/mysql-5.0

I checked this out, and cannot find any mysql-administrator files; I would have expected MDispatcher.cc in a set of common components, as well as MInstanceInfo.cc in a set of mysql-administrator specific files.

Btw, as far as I could tell, the reason for the lock up is that MInstanceInfo::lock_mysql is supposed to prevent multiple concurrent uses of the same object. However, the only thread which could use the lock is the one which locked it. So if in the GTK run loop, another event occurs which triggers a synchronous MySQL lookup, then a deadlock occurs. I can't see any Debian/Ubuntu-specific patches which might cause extra events (in this case, a focus event on one of the trees), but I might have missed it, or it could be new behaviour in GTK+ 2.8.

The GUI tool sources are no longer in bk. You can fetch them with subversion, using the following commands:

svn co http://svn.mysql.com/svnpublic/mysql-gui-common/1.0
mv 1.0 mysql-gui-common
svn co http://svn.mysql.com/svnpublic/mysql-administrator/1.1
mv 1.1 mysql-administrator

Thanks for that information.
However, I still get a hang after applying the change from r338 - I assume the important change is the move of the assignment to _first_show?

I also built from the current code in svn, but the recursive lock in lock_mysql still occurs via lock_mysql() -> dispatcher.dispatch() -> Gtk::Main::instance->run() -> gtk_tree_view_button_press -> lock_mysql()

1.1.10 has been released, please try it:
http://dev.mysql.com/downloads/administrator/1.1.html
I have tried it on debian unstable, with latest everything and it seemed to work.

If it still doesn't work for you, please give me the following info:
- CPU type and number of processors/cores (including hyperthreading details)
- version of debian in use 
- version of kernel, libc
- version of gtk+2, gtkmm, glib-2
- actually, a full listing of packages you have installed would be helpfull so I can reproduce the same environment as you have there (ie, gzip and attach the output of dpkg -L)

Thanks.

The OS is Ubuntu Dapper - I'm attaching some screenshots, backtraces, package information and platform details.

I tested without the ubuntulooks theme, same problem.
The statically linked version of 1.1.10 works (as one might expect).

I can't attach any files - you can download the archive from http://www.lyranthe.org/hang_debug_info.tar.gz

One further thing if you're trying to reproduce - as it's a race condition, it doesn't usually happen when X is tunnelled across an ssh connection.

I've posted a patch for a minimal workaround in Ubuntu at
https://launchpad.net/distros/ubuntu/+source/mysql-admin/+bug/29802

The patch itself is at
http://librarian.launchpad.net/2622753/mysql-admin-lockup.patch

It uses pthread_mutex_trylock instead of pthread_mutex_lock, at the cost of an error dialog appearing when the problem occurs.

It's obviously not designed as a permanent fix, but just as a lesser evil until the locking is reworked.

I'd appreciate comments on the patch contents.

Hi,

version 1.1.10 compiled from source doesnt work for me. It steel needs workaround!

My system is:
P4 2,26GHz uniprocesor
Debian 3.1 with kernel 2.6.16.9
libc comming with Debian 3.1 (2.3.2.ds1-2)
below from sources:
gtk+ 2.8.18
gtkmm 2.8.5
glib-2 2.8.6
glibmm 2.8.6
libsigc++ 2.0.17

list of installed packages (Debian 3.1 - Marcin Deka)

Attachment: list.readme.gz (application/gzip, text), 6.39 KiB.

I've added a file with a packages installed in my Debian 3.1

Every other lib required by mysql-admin not present on the list I've compiled from sources.

It appears to me that lock_mysql() is of no use whatsoever. Either the main loop can call a MySQL function again (due to a callback), causing a deadlock - or it can't, in which case we didn't need lock_mysql() anyway.
The only other threads of execution besides the main loop are operating within the mysql lock, and are of no interest in this lockup issue.

However, it seems to me that replacing the locking system is going to be a major effort, and besides my earlier patch, all currently synchronous mysql calls need to be replaced with asynchronous calls including callbacks.

What that means for the "stop" UI button, I don't know. What does the "stop" button do if there are multiple mysql calls in flight?

I'm willing to try to supply patches, if some guidance can be given as to the operation of the "stop" button. Can it just be removed?

I have the same issue with mysql-administrator-1.1.10-1 on SuSE Linux 10.1.

I've tested the workaround and it helps.

This patch works for me on SUSE Linux 10.1 with mysql-administrator 1.1.10

--- source/linux/MAUserAdministrationPanel.cc
+++ source/linux/MAUserAdministrationPanel.cc
@@ -2141,6 +2141,9 @@
   Gtk::TreeIter node= cnode;
   bool is_host= false;
 
+  if (_first_show) { // called before show() returned
+    return;
+  }
   if (node)
   {
     _user_browser->get_row_user(node, username, host);

without the patch, User Administration _allways_ hangs. Versions of libraries in SL 10.1:
$ rpm -q  gtk2 glib2 gtkmm24 glibmm24 libsigc++2
gtk2-2.8.10-39
glib2-2.8.5-21
gtkmm24-2.8.2-15
glibmm24-2.8.3-16
libsigc++2-2.0.17-14

I've tried this on Ubuntu dapper (x86_64) and was able to repeat it.
This has been fixed now.

I'm having this same problem on Linux FC3 with MySQL 5.0.6, mysql-administrator v1.2.4rc. I tried setting the environment variable DEBUG_DONT_SPAWN_FETCHES=1, but that didn't help. 

What I've noticed is that when you select User Administration, each schema is being queried for info. I have several schemas with a large number of tables (>1000) each.  When I drop those schemas (after backing up of course) the problem goes away. MySQL Admin is not searching through >15000 tables for whatever it is looking for. There is still a bit of a delay, but then I didn't drop everything, just the schemas with large numbers of tables.

mysqlcc doesn't have this problem.

I've still got this bug as well.
Any chance of re-opening it?

I'm using now MySQL GUI Tools Bundle r4 and its working fine.
It seems it is libs version related problem.
I'm using newest gtk+, glib and bla bla ...
Mysql is 5.0.26 standard.

I'm not convinced it's a libs issue. In typical Gentoo-ricer fashion, I also have the latest libs, and still experience this problem.

Does the app completely freeze up (no redraws or anything) or does it just stay there doing nothing?

It freezes. No redrawing.
Also I have just upgraded to 1.2.4rc ( binary ) and retested - same thing.

I might be missing something but is this closed? 
I get the same under Debian (3.1) on server and unstable/testing on client
The workaround works...
Correction:  under Debian at least the executable is mysql-admin (not mysql-administrator)

I created a mysql-admin.safe file /usr/bin/mysql-admin.safe containing
export DEBUG_DONT_SPAWN_FETCHES=1
mysql-admin

and this works fine... I suppose you could put it in /bin and have it in the PATH before mysql-admin in /usr/bin but since its a GUI app I just changed my shortcuts to the .safe version

an update was made to the code so that tables are now loaded on demand, thus minimizing delays on user info selection

This bug still exists in the latest GUI Tools package. Should I create a new bug, or can someone re-activate this one?

Version 1.1.10 of Administrator on Ubuntu 6.10 Edgy has the same issue.  It locks up only when going to user management.