MySQL Administrator Locks when trying to do User Administration

Yes, the same here.

I have found more Infos...
If you look with strace when it hangs, you will see the following:

futex(0xbfd6c958, FUTEX_WAIT, 2, NULL

Same bug with MySQL Server 4.x

I Can't work with this kind of behaviour. It really is very annoying! Still hapening to me.

Same bug here - updated to latest as of the time of this comment.

Confirmed. The backtrace I can see suggests a forgotten pthread_mutex_unlock...

#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7da02ae in __lll_mutex_lock_wait ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb7d9cfbb in _L_mutex_lock_33 () from /lib/tls/i686/cmov/libpthread.so.0
#3 0x08703e34 in ?? ()
#4 0x08703e34 in ?? ()
#5 0x08703e34 in ?? ()
#6 0x08703e34 in ?? ()
#7 0xb707bd52 in gettext () from /lib/tls/i686/cmov/libc.so.6
#8 0x08064b4c in Gtk::CellRenderer_Generation::generate_cellrenderer<Glib::ustring> ()
#9 0x0806be10 in std::operator+<char, std::char_traits<char>, std::allocator<char> > ()
#10 0x0806c0f4 in std::operator+<char, std::char_traits<char>, std::allocator<char> > ()
#11 0x0808ee35 in Glib::ListHandle<Gtk::CellRenderer*, Glib::Container_Helpers::TypeTraits<Gtk::CellRenderer*> >::~ListHandle ()
#12 0x0809def5 in Glib::ListHandle<Gtk::CellRenderer*, Glib::Container_Helpers::TypeTraits<Gtk::CellRenderer*> >::~ListHandle ()
#13 0x0810f78f in Gtk::manage<Gtk::TextView> ()
#14 0x0811127c in Gtk::manage<Gtk::Widget> ()
#15 0x0811129a in Gtk::manage<Gtk::Widget> ()
#16 0xb75f4d97 in Glib::MainLoop::create () from /usr/lib/libglibmm-2.4.so.1
#17 0xb728cb92 in g_idle_dispatch (source=0x86e02f0,
    callback=0xb7da53b4 <pthread_functions+500>, user_data=0xfffffffc)
    at gmain.c:3796
#18 0xb728a876 in IA__g_main_context_dispatch (context=0x8204c50)
    at gmain.c:1916
#19 0xb728d936 in g_main_context_iterate (context=0x8204c50, block=1,
    dispatch=1, self=0x81cf318) at gmain.c:2547
#20 0xb728dc58 in IA__g_main_loop_run (loop=0x83e18c0) at gmain.c:2751
#21 0xb7750495 in IA__gtk_main () at gtkmain.c:1026
#22 0xb7af2275 in Gtk::Main::run_impl () from /usr/lib/libgtkmm-2.4.so.1
#23 0xb7af2166 in Gtk::Main::run () from /usr/lib/libgtkmm-2.4.so.1
#24 0x0812c211 in std::vector<Glib::ustring, std::allocator<Glib::ustring> >::_M_insert_aux ()
#25 0x08064b68 in Gtk::CellRenderer_Generation::generate_cellrenderer<Glib::ustring> ()
#26 0x0808e2af in Glib::ListHandle<Gtk::CellRenderer*, Glib::Container_Helpers::TypeTraits<Gtk::CellRenderer*> >::~ListHandle ()
#27 0x0808ef08 in Glib::ListHandle<Gtk::CellRenderer*, Glib::Container_Helpers::TypeTraits<Gtk::CellRenderer*> >::~ListHandle ()
#28 0x08080fa0 in Glib::ustring::ustring<char const*> ()
#29 0x08081143 in Glib::ustring::ustring<char const*> ()
#30 0xb75f8586 in Glib::SignalProxyNormal::slot0_void_callback ()
   from /usr/lib/libglibmm-2.4.so.1
#31 0xb7307423 in IA__g_cclosure_marshal_VOID__VOID (closure=0x83f5cb0,
    return_value=0x0, n_param_values=1, param_values=0xbfd1e96c,
    invocation_hint=0xbfd1e85c, marshal_data=0xb75f8540) at gmarshal.c:77
#32 0xb72fb79f in IA__g_closure_invoke (closure=0x83f5cb0,
    return_value=0xfffffffc, n_param_values=4294967292,
    param_values=0xfffffffc, invocation_hint=0xfffffffc) at gclosure.c:490
#33 0xb730a7ec in signal_emit_unlocked_R (node=0x8258258, detail=0,
    instance=0x83d5440, emission_return=0x0, instance_and_params=0xbfd1e96c)
    at gsignal.c:2508
#34 0xb730bb19 in IA__g_signal_emit_valist (instance=0x83d5440, signal_id=142,
    detail=0, var_args=<value optimized out>) at gs...

This is a very evil upstream bug, see
http://bugs.mysql.com/bug.php?id=17879

A workaround is to start the administrator via
DEBUG_DONT_SPAWN_FETCHES=1 mysql-admin
from the command line.

This is a possible workaround for the problem - not changing any compilation options for mysql-admin, but just adding a wrapper script.

Note re: the the patch: the change to mysql-admin.dirs can probably be removed, it's a leftover piece from an earlier version of the patch.

gdb backtrace of the hang:

#0 0xb7dd9c1c in __pthread_sigsuspend (set=0xb7ddf19c)
    at ../linuxthreads/sysdeps/unix/sysv/linux/pt-sigsuspend.c:54
#1 0xb7dd930d in __pthread_wait_for_restart_signal (self=0xb7ddf860) at pthread.c:1216
#2 0xb7ddb8fe in __pthread_alt_lock (lock=0xbfd99a08, self=0xb7ddf860) at restart.h:34
#3 0xb7dd7ffd in *__GI___pthread_mutex_lock (mutex=0xbfd999f8) at mutex.c:123
#4 0x08064b6c in Gtk::CellRenderer_Generation::generate_cellrenderer<Glib::ustring> ()
#5 0x0806be30 in std::operator+<char, std::char_traits<char>, std::allocator<char> > ()
#6 0x0806c114 in std::operator+<char, std::char_traits<char>, std::allocator<char> > ()
#7 0x0808ecb5 in Glib::ListHandle<Gtk::CellRenderer*, Glib::Container_Helpers::TypeTraits<Gtk::CellRenderer*> >::~ListHandle ()
#8 0x0809dbc5 in Glib::ListHandle<Gtk::CellRenderer*, Glib::Container_Helpers::TypeTraits<Gtk::CellRenderer*> >::~ListHandle ()
#9 0x0810fb1f in Gtk::manage<Gtk::TextView> ()
#10 0x0811160c in Gtk::manage<Gtk::Widget> ()
#11 0x0811162a in Gtk::manage<Gtk::Widget> ()
#12 0xb7aef34a in sigc::slot0<bool>::operator() (this=0x86a2500) at slot.h:440
#13 0xb7567ecd in glibmm_source_callback (data=0x86a2500) at main.cc:195
#14 0xb71e7b92 in g_idle_dispatch (source=0x86a2a48, callback=0xb7ddf19c <__JCR_LIST__+392>,
    user_data=0xfffffffc) at gmain.c:3796
#15 0xb71e5876 in IA__g_main_context_dispatch (context=0x8205cb8) at gmain.c:1916
#16 0xb71e8936 in g_main_context_iterate (context=0x8205cb8, block=1, dispatch=1, self=0x81d03a0)
    at gmain.c:2547
#17 0xb71e8c58 in IA__g_main_loop_run (loop=0x83ef5c0) at gmain.c:2751
#18 0xb76d7495 in IA__gtk_main () at gtkmain.c:1026
#19 0xb7aef073 in Gtk::Main::run_impl (this=0xbfd99c70) at main.cc:504
#20 0xb7aeef2e in Gtk::Main::run () at main.cc:451
#21 0x0812cc41 in std::vector<Glib::ustring, std::allocator<Glib::ustring> >::_M_insert_aux ()
#22 0x08064b88 in Gtk::CellRenderer_Generation::generate_cellrenderer<Glib::ustring> ()
#23 0x0808e12f in Glib::ListHandle<Gtk::CellRenderer*, Glib::Container_Helpers::TypeTraits<Gtk::CellRenderer*> >::~ListHandle ()
#24 0x0808ed88 in Glib::ListHandle<Gtk::CellRenderer*, Glib::Container_Helpers::TypeTraits<Gtk::CellRenderer*> >::~ListHandle ()
#25 0x08080dd0 in Glib::ustring::ustring<char const*> ()
#26 0x08080f73 in Glib::ustring::ustring<char const*> ()
#27 0xb7aaa3a8 in sigc::slot0<void>::operator() (this=0x8404324) at slot.h:440
#28 0xb7570081 in Glib::SignalProxyNormal::slot0_void_callback (self=0x83e2060, data=0x8404320)
    at signalproxy.cc:95
#29 0xb7261423 in IA__g_cclosure_marshal_VOID__VOID (closure=0x8404380, return_value=0x0,
    n_param_values=1, param_values=0xbfd98e8c, invocation_hint=0xbfd98d7c, marshal_data=0xb757003c)
    at gmarshal.c:77
#30 0xb725579f in IA__g_closure_invoke (closure=0x8404380, return_value=0xfffffffc,
    n_param_values=4294967292, param_values=0xfffffffc, invocation_hint=0xfffffffc) at gclosure.c:490
#31 0xb72647ec in signal_emit_unlocked_R (node=0x8260378, detail=0, instance=0x83e2060,
    emission_return=0x0, instance_and_params=0xbfd98e8c) at gsignal.c:2508
#32 0xb7265b19 in IA__g_signal_emit_valist...

I read the upstream bug report and see that this bug has been fixed.

Confirmed on keithCu's comment above.

I suppose this will require a MOTU UVF exception request as well as a sync request from ubuntu-archive. Expect an updated package soon.

Thanks,

Thank You!

Zak B. Elep wrote:
> Confirmed on keithCu's comment above.
>
> I suppose this will require a MOTU UVF exception request as well as a sync request from ubuntu-archive. Expect an updated package soon.
>
> Thanks,
>
>
> ** Changed in: mysql-admin (Ubuntu)
> Assignee: (unassigned) => Zak B. Elep
> Status: Confirmed => In Progress
>
>

This is the upstream patch for the problem.

r338 | akojima | 2006-05-04 23:27:03 +0100 (Thu, 04 May 2006) | 2 lines

fixed bug in debian that causes hangup when clicking on user admin page

Just tried the patch, didn't work after borking out of an invalid conversion from `unsigned char' to `const char *'.

It would be better to get the new Debian package to be synced into Dapper.

I'm not sure that the problem is fixed, the deadlock still seems to occur for me - both using a build with just the important part of r338 patched in, and with a build of the current source in svn.

I have a patch which seems to help with the issue.
With the patch, an error appears the first time the User Administration panel is clicked, either:

Could not retrieve catalogs from server
MySQL Error Nr. 0

or

Could not retrieve schema table definitions from server
MySQL Error Nr. 0

But there appear to be no other ill effects, and the user administration panel is accessible. The error occurs because the patch causes an error to be returned for a mysql query, if an existing query is already in progress. In addition, the error occurs at a point where the program would otherwise have locked up completely. The parallel queries are not expected to occur within the program - appears to be due to some differences in signal generation in recent libgtk2.

There doesn't appear to be much else that can be done without an overhaul of how the locking is done in mysql-admin.

Convert pthread_mutex_lock to pthread_mutex_trylock, as a minimal workaround for the lockup.

Adding myself to the list of one having the same problem. Any word yet?

Same here. Most of the technical stuff that have been uttered is completely incomprehensible to me, but I do know that I am afflicted by the same problem. I just installed mysql and mysql-admin today.

From the terminal

export DEBUG_DONT_SPAWN_FETCHES=1
mysql-admin

seems to fix the problem for me (6.06 LTS)

I wanted to chime in... thanks all for your postings they helped me a ton!

I'm Using:

- Ubuntu "Dapper" 6.06 (LTS)
- MySQL 5.0.22-Debian_0ubuntu6.06-log
- MySQL Admin 1.1.6

Same for me. MySQL Admin "locks up" and sits forever accessing the database when I click on User Admin.
What has been previously posted worked for me also as a workaround...

typing from the terminal command line: DEBUG_DONT_SPAWN_FETCHES=1 mysql-admin

Just like the above poster I found the comments here tremendously useful. Just in case it isn't obvious, if you want to fix the link in your Applications menu and not have to drop to the terminal, put a file named mysql-admin-fixed.sh in your local bin directory with this in it:

#!/bin/bash
export DEBUG_DONT_SPAWN_FETCHES=1
mysql-admin

then run: chmod +x mysql-admin-fixed.sh.

When you are done use the Alacarte Menu Editor to change the MySQL-Administrator entry to point to your script.

Forgive my asking, but shouldn't this have been dealt with by now? 4 months have passed since the bug was assigned and there seem to be no signs of it being fixed.

The problem is still there, don't bet on anything in Universe ever being fixed, except for releases.... this should be promoted to main, because Ubuntu needs complete CLI and GUI configuring for base servers...

Oh, and at least make that workaround official...

Oh, and at least make that workaround official... BTW, might be helpful:

DEBUG_DONT_SPAWN_FETCHES=1 mysql-admin
zsh: correct 'mysql-admin' to 'mysqladmin' [nyae]? n
Warning: The option nice is not known. Please file a bug report if this is a valid option.

** (mysql-admin:6890): CRITICAL **: void MGFileBrowserList::get_row_object(const Gtk::TreeIter&, std::string&): assertion `iter' failed

I've tried the workaround, exporting the variable both through a shell script and manually. The problem still seems to exist.
Can we hope that this will be fixed in edgy?

Oh, I apologize. The workaround does TECHNICALLY work. However, when I go to User Administration, it still hangs for about 2 minutes. This is better than crashing, although still obviously a bug.

Just a confirmation: Found out this problem is still present in Edgy.

Mysqladmin is next to useless if you cannot even do simple stuff like managing users.

There's a simple workaround in the upstream bug, so mysql-admin is
useful. However, it's disappointing from the user perspective when
simple bugs are ignored :(

This bug is still present in Edgy, the workaround still works.

Changing my KDE menu shortcut to:
DEBUG_DONT_SPAWN_FETCHES=1 /usr/bin/mysql-admin

worked like a breeze.

This has been fixed in Debian.

and of course, Feisty

If Dapper and Edgy are still supported, then this should be fixed in
them as well. Hard to call it support otherwise..

I suppose this could be fit for MOTU-SRU...

Fixed in Feisty for a while now, and changing status to suit.

What about Dapper?

There are several duplicates of this bug so this makes it a good candidate for an SRU.