Hello.
Make a bug or feature report at http://bugs.mysql.com.
Josh Trutwin [EMAIL PROTECTED] wrote:
Would it be possible to add:
ENGINE=MyISAM
To all the CREATE TABLE statements in the mysql_fix_privilege_tables
script? The server (tested with 5.0.3 and 5.0.4) crashes when
creating/altering these tables if the following is in /etc/my.cnf:
default-table-type=innodb
I had to drop all the new tables and added ENGINE=MyISAM to the CREATE
TABLE statements, re-ran the script and it worked fine.
Here is an example crash report:
050422 9:19:43InnoDB: Assertion failure in thread 245771 in file
../include/data0type.ic line 466
InnoDB: Failing assertion: type-len % type-mbmaxlen == 0
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/mysql/en/Forcing_recovery.html
InnoDB: about forcing recovery.
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.
key_buffer_size=8388600
read_buffer_size=131072
max_used_connections=1
max_connections=100
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size +
sort_buffer_size)*max_connections = 225791 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd=0x8ab7a70
Attempting backtrace. You can use the following information to find
out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0xbe5f3938, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x8180bef
0xb7e48c85
0x8295abc
0x829492a
0x829286c
0x82af069
0x82ae30c
0x82c5f99
0x823754f
0x8233119
0x8227b3f
0x8210552
0x823cb76
0x823f164
0x8196522
0x819d604
0x8194278
0x8193d85
0x8193192
0xb7e4354e
0xb7d71b8a
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
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd-query at 0x8ae2ae0 = ALTER TABLE time_zone
MODIFY Use_leap_seconds enum('Y','N') COLLATE utf8_general_ci
DEFAULT 'N' NOT NULL
thd-thread_id=6
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.
Number of processes running now: 0
Josh
--
For technical support contracts, goto https://order.mysql.com/?ref=ensita
This email is sponsored by Ensita.NET http://www.ensita.net/
__ ___ ___ __
/ |/ /_ __/ __/ __ \/ /Gleb Paharenko
/ /|_/ / // /\ \/ /_/ / /__ [EMAIL PROTECTED]
/_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.NET
___/ www.mysql.com
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
