https://bugzilla.wikimedia.org/show_bug.cgi?id=29409

--- Comment #12 from Tim Starling <tstarl...@wikimedia.org> 2011-06-22 01:17:03 
UTC ---
I reproduced it under gdb with debugging symbols, and I've isolated it to some
extent. The bug occurs when an index is added to a new field, i.e. a field
added in the same ALTER TABLE. 

In sql_table.cc near line 6010:

      /* Key not found. Add the offset of the key to the add buffer. */
      ha_alter_info->index_add_buffer
           [ha_alter_info->index_add_count++]=
           new_key - ha_alter_info->key_info_buffer;
      key_part= new_key->key_part;
      end= key_part + new_key->key_parts;
      for(; key_part != end; key_part++)
      {
        /* Mark field to be part of new key */
        if ((field= table->field[key_part->fieldnr]))
          field->flags|= FIELD_IN_ADD_INDEX;

new_key->key_part->fieldnr appears to be a field index in the new table, but
it's used to attempt to fetch field information from the old table.

(gdb) print *new_key
$30 = {key_length = 32, flags = 40, key_parts = 1, extra_length = 0,
usable_key_parts = 2, block_size = 0, 
  algorithm = HA_KEY_ALG_UNDEF, {parser = 0x0, parser_name = 0x0}, key_part =
0x7ffff8a26208, 
  name = 0x7ffff8a22f50 "cl_collation", rec_per_key = 0x0, handler =
{bdb_return_if_eq = 0}, table = 0x0}

(gdb) print *key_part
$31 = {field = 0x0, offset = 751, null_offset = 0, length = 32, store_length =
0, key_type = 1, 
  fieldnr = 5, key_part_flag = 0, type = 0 '\000', null_bit = 0 '\000'}

(gdb) print key_part->fieldnr
$15 = 5

(gdb) print table->field[0]->field_name
$33 = 0x7ffff8a24599 "cl_from"
(gdb) print table->field[1]->field_name
$34 = 0x7ffff8a245a1 "cl_to"
(gdb) print table->field[2]->field_name
$35 = 0x7ffff8a245a7 "cl_sortkey"
(gdb) print table->field[3]->field_name
$36 = 0x7ffff8a245b2 "cl_timestamp"
(gdb) print table->field[4]->field_name
Cannot access memory at address 0x30
(gdb) print table->field[5]->field_name
warning: can't find linker symbol for virtual table for `Field' value
warning:   found `Field_longlong::~Field_longlong()' instead
$37 = 0x7ffff78ff544
"UH\211\345SH\203\354hH\211}\250H\211u\240\211U\234dH\213\004%("

table->field[5] points into arbitrary memory, and so the attempt to write to
table->field[5]->flags causes a segfault.

I'll add this to the MySQL bug once dev.mysql.com stops timing out.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.

_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to