MySQL Bugs: #4580: MySQL 4.1 crashes badly after having upgraded from 4.0.

Bug #4580	MySQL 4.1 crashes badly after having upgraded from 4.0.
Submitted:	17 Jul 2004 11:32	Modified:	21 Oct 2004 23:09
Reporter:	Alexander M. Turek	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server: Installing	Severity:	S2 (Serious)
Version:	4.1.3	OS:	Linux (Linux 2.6.7)
Assigned to:		CPU Architecture:	Any

Description:
I am using the source distribution of MySQL on my Linux 2.6.7 machine.
When trying to start mysqld 4.1.3 after having upgraded from MySQL 4.0.20, MySQL crashes badly because it could not find the new tables in the mysql database.
The only workaround at the moment is to move the old mysql database out of MySQL datadir, run mysql_install_db and restore the old tables afterwards.
If mysql_install_db is run without having removing the mysql database makes mysql_install_db crash, too.

Additionally, the mysqld.err logfile was filled with 15 MB (!) of the following kind:

040717 1:33:10 mysql.user table is not updated to new password format; Disabling new password usage until mysql_fix_privilege_tables is run
040717 1:33:10 Warning: Can't open time zone table: Table 'mysql.time_zone_leap_second' doesn't exist trying to live without them
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=16777216
read_buffer_size=131072
max_used_connections=0
max_connections=100
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 233983 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x8482168
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...
frame pointer (ebp) is NULL, did you compile with
-fomit-frame-pointer? Aborting backtrace!
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at (nil) is invalid pointer
thd->thread_id=0
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.

How to repeat:
Upgrade from MySQL 4.0.20 to 4.1.3 and see what happens.

Suggested fix:
Please make mysqld exit more nicely if something is wrong with the grant tables.

I would be great if mysqld could still start with old grant tables from MySQL 4.0 and / or 3.23, so the tables can be upgraded using mysql_fix_privilege_tables.

Did you read and applied the instructions:
2.5.2 Upgrading from Version 4.0 to 4.1
http://dev.mysql.com/doc/mysql/en/Upgrading-from-4.0.html

if following the recommendation above you continue with the same
problem please show for us where it failed.

Thanks

Miguel,

yes, I have read the instructions, but they don't solve my problem. In fact the do not even seem to touch it...

Well, where does it fail...? After having upgraded my MySQL server distribution, I try to run `mysqld_safe` still having the old database files from MySQL 4.0.20 inside the datadir, but nothing happens. The server does not respond, it pollutes the logfiles with the entries I already mentioned and its two processes (one for mysqld_safe and one for mysqld) can only be killed "the hard way" by using `kill -KILL process1 process2`.
The same thing happens when running mysql_install_db.

Please try to reproduce the problem yourself. I could reproduce it on _every_ system on which I upgraded from MySQL 4.0 to 4.1.

Regards,

Alexander

I wasn't able to repeat the crash.

it probably means the problem is in your mysql database.

Can you attach the files from it to this bugreport (you can mark them "private" if you want only us to be able to download them) ?

Attach binary table files - frm, MYD, and MYI - but *not* table dump as generated by mysqldump!

Sergei,

Thank you for your quick answer.

It is really strange that you could not reproduce it because, as I said, I could reproduce it on every machine on which I upgraded to MySQL 4.1.

In order to provide these table definition files, I would have to downgrade one of my testing machines back to MySQL 4.0.20 and this will take some time, so please do not kill this report. ;-)

Anyway, I doubt that my old table definition files are the main cause, as MySQL 4.1.3 is actually able to read them. As I said in my initial post, the crash is gone and MySQL works like a charm, if I move my old "mysql" database directory to some backup location, run mysql_install_db and replace the newly created tables by my old ones from MySQL 4.0.20. I suppose the problem is that MySQL chokes on the fact that not all of the required tables are present. Maybe it checks for some, finds the ones from MySQL 4.0.20 and happily believes that even the ones that were added in 4.1 are present.
Having a look at the log output I provided, we find a warning right before the big error output saying that MySQL did not find the timezone tables and tries to live without them. This fact could hint into the same direction.

Anyway, you'll get the files you requested. :-)

Regards,

Alexander

Unfortunately, the warning about missing time_zone_leap_second table doesn't tell that much - I see this warning every time I run mysqld 4.1 with 3.23 or 4.0 privilege tables, it is normal and never caused a crash for me (yet).

Sorry for not having replied that long.
The problem seems to be gone in MySQL 4.1.5, as far as I can tell.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".