| Bug #19192 | CHECK TABLE EXTENDED / REPAIR TABLE show no errors. ALTER TABLE crashes | ||
|---|---|---|---|
| Submitted: | 19 Apr 2006 11:03 | Modified: | 15 Jun 2006 3:54 | 
| Reporter: | Shane Bester (Platinum Quality Contributor) | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: MyISAM storage engine | Severity: | S3 (Non-critical) | 
| Version: | 5.0.19,5.0-bk | OS: | Windows (Windows) | 
| Assigned to: | Sergey Vojtovich | CPU Architecture: | Any | 
   [19 Apr 2006 11:03]
   Shane Bester        
  
 
   [19 Apr 2006 11:12]
   MySQL Verification Team        
  Stack trace:
LeadUpVec+0x5e [memcpy.asm @ 261]
_mi_rec_pack [mi_dynrec.c @ 725]
_mi_write_blob_record [mi_dynrec.c @ 88]
mi_write [mi_write.c @ 147]
ha_myisam::write_row [ha_myisam.cpp @ 320]
copy_data_between_tables [sql_table.cpp @ 4100]
mysql_alter_table [sql_table.cpp @ 3749]
mysql_execute_command [sql_parse.cpp @ 3021]
mysql_parse [sql_parse.cpp @ 5710]
dispatch_command [sql_parse.cpp @ 1720]
do_command [sql_parse.cpp @ 1516]
handle_one_connection [sql_parse.cpp @ 1159]
pthread_start [my_winthread.c @ 63]
_threadstart [thread.c @ 196]
kernel32!BaseThreadStart+0x34
  if (type == FIELD_BLOB)
      {
	if (!blob->length)
	  flag|=bit;
	else
	{
	  char *temp_pos;
	  size_t tmp_length=length-mi_portable_sizeof_char_ptr;
	  memcpy((byte*) to,from,tmp_length);
	  memcpy_fixed(&temp_pos,from+tmp_length,sizeof(char*)); 
	  memcpy(to+tmp_length,temp_pos,(size_t) blob->length);  <-------CRASH
	  to+=tmp_length+blob->length;
	}
 
   [20 Apr 2006 18:19]
   John David Duncan        
  I can reproduce this bug on FreeBSD/i386 but not on Mac OS X/PPC. (Maybe that means it shows up only on intel?)
   [20 Apr 2006 18:29]
   Sergey Vojtovich        
  Hi Shane, I'm working on very similiar bug report: BUG#17001. Could you please apply following patch and let me know if it solves this problem? ===== sql/sql_table.cc 1.303 vs edited ===== --- 1.303/sql/sql_table.cc 2006-03-30 18:14:51 +05:00 +++ edited/sql/sql_table.cc 2006-04-20 19:45:59 +05:00 @@ -3197,7 +3197,7 @@ uint db_create_options, used_fields; enum db_type old_db_type,new_db_type; bool need_copy_table; - bool no_table_reopen= FALSE; + bool no_table_reopen= FALSE, varchar= FALSE; DBUG_ENTER("mysql_alter_table"); thd->proc_info="init"; @@ -3399,6 +3399,8 @@ Field **f_ptr,*field; for (f_ptr=table->field ; (field= *f_ptr) ; f_ptr++) { + if (field->type() == MYSQL_TYPE_STRING) + varchar= TRUE; /* Check if field should be dropped */ Alter_drop *drop; drop_it.rewind(); @@ -3665,7 +3667,8 @@ ~(ALTER_CHANGE_COLUMN_DEFAULT|ALTER_OPTIONS) || (create_info->used_fields & ~(HA_CREATE_USED_COMMENT|HA_CREATE_USED_PASSWORD)) || - table->s->tmp_table); + table->s->tmp_table || + (table->s->frm_version < FRM_VER_TRUE_VARCHAR && varchar)); create_info->frm_only= !need_copy_table; /*
   [20 Apr 2006 21:06]
   MySQL Verification Team        
  Sergey, I tried the patch and it crashed in exactly the same place as before - same stack trace also :(
   [21 Apr 2006 9:46]
   Sergey Vojtovich        
  Shane, thanks for testing my patch. Indeed I haven't noticed that symptoms are a bit different. But caused by same reason: ALTER TABLE x ALTER COLUMN dirid DROP DEFAULT; At this point we have frm created by 5.0 and MYD/MYI created by earlier version. SELECT * FROM x; Server crash. My patch ensures that running ALTER TABLE always recreates MYD/MYI files for tables created by earlier MySQL version when there is VARCHAR columns. However your dataset doesn't have VARCHARs. That is why my patch wasn't useful. I have to find better solution for this problem.
   [21 Apr 2006 10:48]
   Sergey Vojtovich        
  Shane,
I was able to find better solution for this problem. At least it seems to work well.
This fix keeps frm and MYD/MYI versions in sync. However having frm file created
in 5.0 and MYI/MYD in earlier versions will likely result in server crash.
===== sql/sql_table.cc 1.303 vs edited =====
--- 1.303/sql/sql_table.cc      2006-03-30 18:14:51 +05:00
+++ edited/sql/sql_table.cc     2006-04-21 15:43:30 +05:00
@@ -3665,7 +3665,8 @@
                     ~(ALTER_CHANGE_COLUMN_DEFAULT|ALTER_OPTIONS) ||
                     (create_info->used_fields &
                      ~(HA_CREATE_USED_COMMENT|HA_CREATE_USED_PASSWORD)) ||
-                    table->s->tmp_table);
+                    table->s->tmp_table ||
+                    table->s->mysql_version < 50300);
   create_info->frm_only= !need_copy_table;
   /*
 
   [21 Apr 2006 11:23]
   MySQL Verification Team        
  Sergey, with the last patch applied, the server doesn't crash anymore on this ALTER TABLE statement ;-)
   [3 May 2006 23:00]
   Sergei Golubchik        
  Shane, could you try to find out how this table was created ? What MySQL version, what sequence of DDL statements.
   [1 Jun 2006 9:57]
   Sergey Vojtovich        
  I was able to repeat reported table layout with 4.0.24. This problem was solved in 4.0.25 with second patch for BUG#6236 (by Monty).
   [1 Jun 2006 13:16]
   Sergey Vojtovich        
  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/7159
   [7 Jun 2006 15:02]
   Sergey Vojtovich        
  Pushed into tree currently marked as 5.0.23.
   [14 Jun 2006 11:42]
   Sergey Vojtovich        
  Pushed into tree currently marked as 5.1.12.
   [15 Jun 2006 3:54]
   Paul DuBois        
  Noted in 5.0.23, 5.1.12 changelogs. An ALTER TABLE operation that does not need to copy data, when executed on a table created prior to MySQL 4.0.25, could result in a server crash for subsequent accesses to the table.
