Description:
when upgrading from one minor version of mysqld to another one, e.g. 5.0.40 to 5.0.66a and
mysqldump/reload wasn't done, there are cases when corruptions appear after upgrade. 

InnoDB: You should dump + drop + reimport the table to fix the
InnoDB: corruption. If the crash happens at the database startup, see
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html about
InnoDB: forcing recovery. Then dump + drop + reimport.
080922 14:07:56InnoDB: Assertion failure in thread 4868 in file .\btr\btr0btr.c line 624
InnoDB: Failing assertion: btr_node_ptr_get_child_page_no(node_ptr, offsets) ==
buf_frame_get_page_no(page)
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.

mysqld-nt.exe!btr_page_get_father_for_rec
mysqld-nt.exe!btr_validate_level
mysqld-nt.exe!btr_validate_tree
mysqld-nt.exe!row_check_table_for_mysql
mysqld-nt.exe!ha_innobase::check
mysqld-nt.exe!handler::ha_check
mysqld-nt.exe!mysql_admin_table
mysqld-nt.exe!mysql_check_table
mysqld-nt.exe!mysql_execute_command
mysqld-nt.exe!mysql_parse
mysqld-nt.exe!dispatch_command
mysqld-nt.exe!do_command
mysqld-nt.exe!handle_one_connection
mysqld-nt.exe!pthread_start
mysqld-nt.exe!_callthreadstart

How to repeat:
import the attached testcase into 5.0.40.
upgrade to 5.0.66a and run "check table t1 extended"

import into 5.0.40, then shutdown and run 5.0.66a on datafiles. check table crashes

Attachment: bug39585.sql (text/x-sql), 351.36 KiB.

5.0.48 -> 5.0.66a seems to work fine

5.0.42->5.0.60 crashes
5.0.46->5.0.48 crashes.

not necessarily an innodb bug.  myisam table also becomes corrupted.  So i think this was
a result of some character set sorting bugfixes.

mysql> check table t1 extended;
+---------+-------+----------+------------------------------------+
| Table   | Op    | Msg_type | Msg_text                           |
+---------+-------+----------+------------------------------------+
| test.t1 | check | error    | Key in wrong position at page 9216 |
| test.t1 | check | error    | Corrupt                            |
+---------+-------+----------+------------------------------------+
2 rows in set (0.02 sec)

Can mysql_upgrade or 'check table .. for upgrade' be made to detect these old incompatible
data files?

I suspect the fix for bug #29461 caused binary file incompatibilities.

some suggestions how we could address the risk of this problem:

o) versioning .frm files
o) including huge *INCOMPATIBLE* warning in the change history notes
o) check table for upgrade should always check for situations that could lead to problems
like this, so that mysql_upgrade will rebuild a table.

The real cause is a fix for bug #27562: "ascii.xml invalid?".

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/commits/55574

2689 Georgi Kodinov	2008-10-07
      Bug #39585: innodb and myisam corruption after binary upgrade from <=5.0.46 to
>=5.0.48
      
      There was a change in the binary format introduced in 5.0.48 by the ascii collation
definition 
      update fix for bug 27562.
      This was undetected by CHECK TABLE.
      Fixed by checking if there are fields with the ascii collation in tables created
with 
      versions before 5.0.48.

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/commits/55598

2760 Ramil Kalimullin	2008-10-07
      Fix for bug#39585: innodb and myisam corruption after binary 
      upgrade from <=5.0.46 to >=5.0.48
      
      Problem: 'check table .. for upgrade' doesn't detect 
      incompatible collation changes made in 5.0.48.
      
      Fix: check for incompatible collation changes.

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/commits/55771

2765 Ramil Kalimullin	2008-10-08
      Fix for bug#39585: innodb and myisam corruption after binary 
      upgrade from <=5.0.46 to >=5.0.48
      
      Problem: 'check table .. for upgrade' doesn't detect 
      incompatible collation changes made in 5.0.48.
      
      Fix: check for incompatible collation changes.

Pushed into 5.1.30  (revid:ramil@mysql.com-20081008135257-ekvn8gs483wl1z27) (version
source revid:ramil@mysql.com-20081008135257-ekvn8gs483wl1z27) (pib:4)

Noted in 5.1.29 (not 5.1.30) changelog.

CHECK TABLE ... FOR UPGRADE did not check for incompatible collation 
changes made in MySQL 5.0.48.

Setting report to NDI pending push to 6.0.x.

Pushed into 6.0.8-alpha  (revid:ramil@mysql.com-20081008135257-ekvn8gs483wl1z27) (version
source revid:ramil@mysql.com-20081008135520-olnw953qny9nyxx6) (pib:5)

Noted in 6.0.8 changelog.

Pushed into 5.1.29-ndb-6.2.17  (revid:ramil@mysql.com-20081008135257-ekvn8gs483wl1z27)
(version source revid:tomas.ulin@sun.com-20081028140209-u4emkk1xphi5tkfb) (pib:5)

Pushed into 5.1.29-ndb-6.3.19  (revid:ramil@mysql.com-20081008135257-ekvn8gs483wl1z27)
(version source revid:tomas.ulin@sun.com-20081028194045-0353yg8cvd2c7dd1) (pib:5)

Pushed into 5.1.29-ndb-6.4.0  (revid:ramil@mysql.com-20081008135257-ekvn8gs483wl1z27)
(version source revid:jonas@mysql.com-20081101082305-qx5a1bj0z7i8ueys) (pib:5)

was this fixed in the 5.0 branch?

Shane,

The fix was to fine-tune the 5.1 upgrade code. There was nothing to fix in 5.0