I'm pretty sure this bug only exists in gentoo. I could not reproduce it on any other distro of linux or from the original source. I was able to reproduce this several times on 3 different platforms running gentoo (intel-x86, amd-x86, and amd-64). I ran revdep-rebuild to make sure all the libraries were linked correctly and the crash still occured.
Issuing a query with a GRANT like the following crashes mysql:
mysql> grant select on ws_orders to shipper;
ERROR 2013 (HY000): Lost connection to MySQL server during query
Below is from mysqld error log:
Version: '5.0.19-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 Gentoo Linux mysql-5.0.19
mysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 92783 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
Cannot determine thread, fp=0xbe1fe058, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x8b35e78 = grant select on ws_orders to shipper
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.
Below is my emerge --info:
Portage 2.0.54 (default-linux/x86/2005.1, gcc-3.3.6, glibc-2.3.5-r2, 220.127.116.11 i686)
System uname: 18.104.22.168 i686 Intel(R) Xeon(TM) CPU 1.80GHz
Gentoo Base System version 1.6.14
dev-lang/python: 2.3.5-r2, 2.4.2
sys-devel/autoconf: 2.13, 2.59-r7
sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
CFLAGS="-O3 -march=i686 -pipe"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O3 -march=i686 -pipe"
FEATURES="autoconfig distlocks sandbox sfperms strict"
USE="x86 alsa apache2 apm arts avi bash-completion berkdb bitmap-fonts bzip2 cli crypt cups curl dba dri eds emacs emboss encode expat foomaticdb gd gdbm gif gpm gstreamer gtk2 imagemagick imlib ipv6 jpeg libg++ libwww mad mhash mikmod mmap motif mp3 mpeg mysql ncurses nls nptl nptlonly ogg oggvorbis opengl oss pam pcre pdflib pear perl php png python qt quicktime readline sdl session simplexml spell ssl tcpd tiff truetype truetype-fonts type1-fonts udev vorbis xml xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc"
Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
*** Bug 126636 has been marked as a duplicate of this bug. ***
query SQL: USE mydns;# MySQL ha restituito un insieme vuoto (i.e. zero righe).
GRANT SELECT ON rr
TO gentoouser;# MySQL ha restituito un insieme vuoto (i.e. zero righe).
==> works for me
emerge -pv mysql
[ebuild R ] dev-db/mysql-5.0.19 USE="berkdb cluster extraengine max-idx-128 perl ssl -big-tables -debug -embedded -minimal -srvdir -static"
Need at least emerge -pv mysql, since we do not apply significant patches to "C" code, you can try to build MySQL from the source, using the configure options you could see during emerge phase (or in /var/tmp/portage/mysql-5.0.19/work/mysql/config.log)
If you chose to build from sources read the MySQL docs signaled during the crash.
Mysql GRANT crash only happens on an upgrade from mysql 4.0 to mysql 5.0.
The user needs to run the following commands to fix this:
mysqlcheck --check-upgrade --all-databases --auto-repair
I don't know if this can be included in the ebuild or what, but I feel the user at least needs to be notified.
(In reply to comment #3)
> Mysql GRANT crash only happens on an upgrade from mysql 4.0 to mysql 5.0.
Yuck?! The databases are not compatible even between 4.0 and 4.1 (http://www.gentoo.org/doc/en/mysql-upgrading.xml), how did you suppose that it'll straight work when upgraded from 4.0 to 5.0?
It was actually an upgrade from 4.0 to 4.1 to 5.0.
The mentioned query works correctly and it's not supported to do a straight 4.0 --> 5.0 upgrade, or any else major version upgrade in mysql, without at least executing the various update scripts (mysql_fix_privileges in this case).
Closing this bug, best regards, CHTEKK.