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]
