Bug #39550 | Mysql server crash for backup if view created from consecutive views. | ||
---|---|---|---|
Submitted: | 19 Sep 2008 22:55 | Modified: | 15 Dec 2008 13:19 |
Reporter: | Hema Sridharan | Email Updates: | |
Status: | Can't repeat | Impact on me: | |
Category: | MySQL Server: Backup | Severity: | S3 (Non-critical) |
Version: | mysql-6.0-backup | OS: | Linux |
Assigned to: | Jørgen Løland | CPU Architecture: | Any |
[19 Sep 2008 22:55]
Hema Sridharan
[20 Oct 2008 11:05]
Jørgen Løland
The suggested test script does not fail anymore, but I am able to get the error if I add more views. Adding 2 more views before the first backup reproduces the crash.
[20 Oct 2008 11:08]
Jørgen Løland
I experimented a bit with commenting out backup statements and got some strange results: create database v; use v; create table t1(id int); create view v1 as select * from t1; create view v2 as select * from v1; (...) create view v14 as select * from v13; # --echo Backup no 1 # --replace_column 1 # # backup database v to 'v1.bak'; create view v15 as select * from v14; # --echo Backup no 2 # --replace_column 1 # # backup database v to 'v2.bak'; create view v16 as select * from v15; # create view v17 as select * from v16; # create view v18 as select * from v17; # create view v19 as select * from v18; --echo Backup no 3 --replace_column 1 # backup database v to 'v3.bak'; ---------------------------------- With view v16: * Only backup #3: passed * Backup #1 and #3: passed * Backup #2 and #3: passed * Backup #1, #2 and #3: crash on #3 With view v17: * Only backup #3: crash on #3 * Backup #1 and #3: passed * Backup #2 and #3: passed * Backup #1, #2 and #3: passed With view v18: * Only backup #3: crash on #3 * Backup #1 and #3: crash on #3 * Backup #2 and #3: passed * Backup #1, #2 and #3: passed With view v19: * Only backup #3: crash on #3 * Backup #1 and #3: crash on #3 * Backup #2 and #3: crash on #3 * Backup #1, #2 and #3: crash on #3
[17 Nov 2008 11:58]
Jørgen Løland
Update with latest info: *Stack trace from gdb when the error occurs:* ----------- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xaf8ea790 (LWP 25466)] 0x082161c4 in Field::maybe_null (this=0x962d0b8) at ../../sql/field.h:283 283 inline bool maybe_null(void) { return null_ptr != 0 || table->maybe_null; } (gdb) bt #0 0x082161c4 in Field::maybe_null (this=0x962d0b8) at ../../sql/field.h:283 #1 0x0836d3e1 in create_tmp_field (thd=0x9567830, table=0x9964a58, item=0x996a7a0, type=Item::FIELD_ITEM, copy_func=0xaf8e8450, from_field=0x9965360, default_field=0x9965350, group=false, modify_item=false, table_cant_handle_bit_fields=false, make_copy_field=false, convert_blob_length=0) at sql_select.cc:11523 #2 0x0836e807 in create_tmp_table (thd=0x9567830, param=0x99881c4, fields=@0x996a0f8, group=0x0, distinct=false, save_sum_fields=true, select_options=2416204288, rows_limit=18446744073709551615, table_alias=0x99698b0 "v5") at sql_select.cc:11944 #3 0x084a3f46 in select_union::create_result_table (this=0x99881b8, thd_arg=0x9567830, column_types=0x996a0f8, is_union_distinct=false, options=2416204288, table_alias=0x99698b0 "v5", bit_fields_as_long=false) at sql_union.cc:129 #4 0x084a56a6 in mysql_derived_prepare (thd=0x9567830, lex=0x956894c, orig_table_list=0x99698b8) at sql_derived.cc:139 #5 0x084a5247 in mysql_handle_derived (lex=0x956894c, processor=0x84a54fc <mysql_derived_prepare(THD*, LEX*, TABLE_LIST*)>) at sql_derived.cc:56 #6 0x08349a18 in open_normal_and_derived_tables (thd=0x9567830, tables=0x9978008, flags=0) at sql_base.cc:4163 #7 0x084f12be in obs::TableObj::do_serialize (this=0x975fef8, thd=0x9567830, serialization=0x95ebd64) at si_objects.cc:2130 ------------ (gdb) p table $1 = (TABLE *) 0x0 *I run the following test:* --------------------------- create database v; use v; create table t1(id int); create view v1 as select * from t1; create view v2 as select * from v1; create view v3 as select * from v2; create view v4 as select * from v3; create view v5 as select * from v4; create view v6 as select * from v5; create view v7 as select * from v6; create view v8 as select * from v7; create view v9 as select * from v8; create view v10 as select * from v9; create view v11 as select * from v10; create view v12 as select * from v11; create view v13 as select * from v12; create view v14 as select * from v13; create view v15 as select * from v14; create view v16 as select * from v15; create view v17 as select * from v16; *And the following script in gdb:* ---------------------------------- b kernel.cc:195 run b stream_v1.c:1258 c c 6 b sql_select.cc:11928 c c 9 # how field looks like when it works p *((Item_field*)item)->field p ((Item_field*)item)->field->table c # how field looks like when it crashes p *((Item_field*)item)->field p ((Item_field*)item)->field->table *I get the following output from this script* --------------------------------------------- The one that works: (gdb) p *((Item_field*)item)->field $2 = {_vptr.Field = 0x893eb88, ptr = 0x9962a69 "", null_ptr = 0x9962a68 "ÿ", table = 0x95f59c8, orig_table = 0x95bacb8, table_name = 0x95f5a48, field_name = 0x997cee8 "id", comment = {str = 0x89a02b7 "", length = 0}, key_start = {map = 0}, part_of_key = {map = 0}, part_of_key_not_clustered = {map = 0}, part_of_sortkey = {map = 0}, part_of_key_wo_keyread = {map = 0}, unireg_check = Field::NONE, field_length = 11, flags = 0, field_index = 0, null_bit = 2 '\002', is_created_from_null_item = false} (gdb) p ((Item_field*)item)->field->table The one that crashes: (gdb) p *((Item_field*)item)->field $5 = {_vptr.Field = 0x0, ptr = 0x3333 <Address 0x3333 out of bounds>, null_ptr = 0x0, table = 0x0, orig_table = 0x199980, table_name = 0x0, field_name = 0x0, comment = { str = 0xcccc000 <Address 0xcccc000 out of bounds>, length = 0}, key_start = {map = 7376896189632872448}, part_of_key = {map = 0}, part_of_key_not_clustered = {map = 34359751475}, part_of_sortkey = { map = 676334066378735616}, part_of_key_wo_keyread = { map = 562949953421312}, unireg_check = Field::NONE, field_length = 0, flags = 0, field_index = 0, null_bit = 0 '\0', is_created_from_null_item = false} So, field has not been set properly in this case, or has been overwritten. A strange thing is that if I change the view names from v<#> to vvvv<#> (or any other >3 chars before the id), the bug goes away. That makes me think that the memory location is overwritten somewhere.
[5 Dec 2008 13:18]
Jørgen Løland
To figure out where the uninitialized field comes from, I added Item iterators to the code run just before the crash. E.g., in sql_derived.cc:mysql_derived_prepare: bool mysql_derived_prepare(THD *thd, LEX *lex, TABLE_LIST *orig_table_list) { SELECT_LEX_UNIT *unit= orig_table_list->derived; ulonglong create_options; DBUG_ENTER("mysql_derived_prepare"); bool res= FALSE; if (unit) { // ADDED CODE STARTS HERE List_iterator_fast<Item> lst(unit->types); Item *itm; int myint=0; while ((itm=lst++)) { myint++; } ... I find the uninitialized Item at this level as well.
[5 Dec 2008 13:19]
Jørgen Løland
Tried to debug on another machine. The bug still appears, but not for the same Item.
[15 Dec 2008 13:19]
Jørgen Løland
The new server interface (si_object) has been pushed to the backup tree. I am no longer able to reproduce this bug, even if I create as much as 50.
[15 Dec 2008 13:21]
Jørgen Løland
Likely fixed by wl#4264, which was pushed to 6.0.9 December 8.