MySQL Bugs: #10181: mysqld.exe crash with an access violation after INSERT INTO mysql.host

Bug #10181	mysqld.exe crash with an access violation after INSERT INTO mysql.host
Submitted:	26 Apr 2005 15:50	Modified:	1 Jun 2005 3:21
Reporter:	MySQL-Front Team	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server	Severity:	S1 (Critical)
Version:	5.0.4-beta	OS:	Windows (Windows XP)
Assigned to:	Reggie Burnett	CPU Architecture:	Any

Description:
While executing the query
INSERT INTO `mysql`.`host` SET Host='NewHost', Db='';
mysqld.exe with the follwing message

Die Anweisung in "0x0051c448" verweist auf Speicher in "0x00000000". Der Vorgang "read" konnte nicht auf dem Speicher durchgeführt werden.

(Access violation at 0x0051c448 - cannont read from 0x00000000.)

After this I cannot restart mysqld.exe.

To restart mysqld.exe I have to restore my backup of the mysql database in the filesystem.

After this I was able to reproduce this bug on the same way.

I don't know if there is any problem with my tables in the mysql database - they are very old and has been update from version to version to version to version to version to version to version...

Nevertheless: Also if there is bug in that files - this bug is not acceptable.

How to repeat:
I can offer the mysql database on file base after the crash and after the restore.

I wasn't able to repeat with a server 5.0.5:

c:\mysql\bin>mysql -uroot mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 5.0.5-beta-debug

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> INSERT INTO `mysql`.`host` SET Host='NewHost', Db='';
Query OK, 1 row affected (0.14 sec)

mysql>

Like mentioned maybe the bug occurs based on a problem with the tables.

Seems you are not interessed to locate the bug.

Because of this it's better we don't report bugs further more...

Could you please provide the tables are you mentioned.

Thanks in advance.

... attached as requested.

I wasn't able to repeat it again, however I needed to re-set the root
password according instructions at: 

http://dev.mysql.com/doc/mysql/en/resetting-permissions.html

could you please provide the original root password and your my.ini
or my.cnf file. If I won't to repeat it then I will need your whole data
directory.

Thanks in advance.

After shutdown the server and try to start it again I got the below
output:

c:\mysql\bin>mysqld-nt --standalone --console
050426 15:57:14  InnoDB: Started; log sequence number 0 43655
050426 15:57:14  InnoDB: Starting recovery for XA transactions...
050426 15:57:14  InnoDB: 0 transactions in prepared state after recovery
050426 15:57:14 [ERROR] mysqld-nt: Got signal 11. Aborting!

050426 15:57:14 [ERROR] Aborting

050426 15:57:14  InnoDB: Starting shutdown...
050426 15:57:16 [Note] mysqld-nt: Shutdown complete

could you please verifiy it the same occurs on your side.

Thanks in advance.

I used mysqld.exe instead of mysqld-nt.

050426 23:23:21  InnoDB: Started; log sequence number 0 213217474
050426 23:23:21  InnoDB: Starting recovery for XA transactions...
050426 23:23:21  InnoDB: 0 transactions in prepared state after recovery
050426 23:23:21 [ERROR] mysqld-nt.exe: Got signal 11. Aborting!

050426 23:23:21 [ERROR] Aborting

050426 23:23:21  InnoDB: Starting shutdown...
050426 23:23:23 [Note] mysqld-nt.exe: Shutdown complete

This not happens on Linux. Verified on Slackware.

Miguel has said that this fails on linux.

patch is on 4.1 tree

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/internals/25363

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/internals/25410

Fixed in 5.0.7 and 4.1.13

Noted in 4.1.13, 5.0.7 changelogs.