Bug #47150 Assertion in Field_long::val_int() on MERGE + TRIGGER + multi-table UPDATE
Submitted: 5 Sep 2009 11:13 Modified: 18 Dec 2009 23:52
Reporter: Philip Stoev Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Optimizer Severity:S2 (Serious)
Version:5.1,5.4 OS:Any
Assigned to: Sergei Glukhov CPU Architecture:Any

[5 Sep 2009 11:13] Philip Stoev
Description:
The following sequence that contains VIEWs, TRIGGERs, MERGE tables and multi-table UPDATE causes mysqld to assert as follows:

mysqld: field.cc:3682: virtual longlong Field_long::val_int(): Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' failed.

#6  0x000000315a42bec9 in __assert_fail () from /lib64/libc.so.6
#7  0x000000000060cbcc in Field_long::val_int (this=0x1d363b0) at field.cc:3682
#8  0x000000000056b8de in Item_field::val_int (this=0x1d83a20) at item.cc:2029
#9  0x00000000005ae320 in Arg_comparator::compare_int_signed (this=0x1d87540) at item_cmpfunc.cc:1260
#10 0x00000000005be61a in Arg_comparator::compare (this=0x1d87540) at item_cmpfunc.h:71
#11 0x00000000005b2979 in Item_func_eq::val_int (this=0x1d87490) at item_cmpfunc.cc:1645
#12 0x00000000005bcf48 in Item_equal::add (this=0x1d866e8, c=0x1d83a20) at item_cmpfunc.cc:5075
#13 0x00000000005bcfca in Item_equal::update_const (this=0x1d866e8) at item_cmpfunc.cc:5212
#14 0x00000000006d232a in update_const_equal_items (cond=0x1d866e8, tab=0x1d86b38) at sql_select.cc:8200
#15 0x00000000006d228e in update_const_equal_items (cond=0x1d7ff08, tab=0x1d86b38) at sql_select.cc:8193
#16 0x00000000006d27f6 in join_read_const_table (tab=0x1d86b38, pos=0x1d80440) at sql_select.cc:11541
#17 0x00000000006dc148 in make_join_statistics (join=0x1d80380, tables_arg=0x1d81f40, conds=0x1d7ff08, keyuse_array=0x1d81940) at sql_select.cc:2647
#18 0x00000000006de38a in JOIN::optimize (this=0x1d80380) at sql_select.cc:954
#19 0x00000000006e23d3 in mysql_select (thd=0x1cbdd88, rref_pointer_array=0x1d41ee8, tables=0x1d42840, wild_num=0, fields=@0x7f3304eb7760, conds=0x1d7ff08, og_num=0, order=0x0,
    group=0x0, having=0x0, proc_param=0x0, select_options=1342177408, result=0x1d802b8, unit=0x1d418f0, select_lex=0x1d41d18) at sql_select.cc:2384
#20 0x000000000070348f in mysql_multi_update (thd=0x1cbdd88, table_list=0x1d42840, fields=0x1d41e20, values=0x1d42200, conds=0x1d7ff08, options=0, handle_duplicates=DUP_ERROR,
    ignore=false, unit=0x1d418f0, select_lex=0x1d41d18) at sql_update.cc:1228
#21 0x0000000000656d9d in mysql_execute_command (thd=0x1cbdd88) at sql_parse.cc:3090
#22 0x00000000008152df in sp_instr_stmt::exec_core (this=0x1d724d8, thd=0x1cbdd88, nextp=0x7f3304eb8a88) at sp_head.cc:2905
#23 0x0000000000815517 in sp_lex_keeper::reset_lex_and_exec_core (this=0x1d72518, thd=0x1cbdd88, nextp=0x7f3304eb8a88, open_tables=false, instr=0x1d724d8) at sp_head.cc:2734
#24 0x000000000081b6b7 in sp_instr_stmt::execute (this=0x1d724d8, thd=0x1cbdd88, nextp=0x7f3304eb8a88) at sp_head.cc:2848
#25 0x00000000008177ef in sp_head::execute (this=0x1d40fc8, thd=0x1cbdd88) at sp_head.cc:1252
#26 0x0000000000818b19 in sp_head::execute_trigger (this=0x1d40fc8, thd=0x1cbdd88, db_name=0x1d462d8, table_name=0x1d462e8, grant_info=0x1d48cf0) at sp_head.cc:1555
#27 0x0000000000826c47 in Table_triggers_list::process_triggers (this=0x1d48c18, thd=0x1cbdd88, event=TRG_EVENT_INSERT, time_type=TRG_ACTION_AFTER, old_row_is_record1=true)
    at sql_trigger.cc:2013
#28 0x00000000006ee8bb in write_record (thd=0x1cbdd88, table=0x1d457f8, info=0x1d75be8) at sql_insert.cc:1595
#29 0x00000000006eebfe in select_insert::send_data (this=0x1d75ba8, values=@0x1cbfd18) at sql_insert.cc:3144
#30 0x00000000006bcb7b in end_send (join=0x1d77df8, join_tab=0x1d77570, end_of_records=false) at sql_select.cc:12012
#31 0x00000000006c3aa9 in evaluate_join_record (join=0x1d77df8, join_tab=0x1d77328, error=0) at sql_select.cc:11272
#32 0x00000000006c3cf2 in sub_select (join=0x1d77df8, join_tab=0x1d77328, end_of_records=false) at sql_select.cc:11163
#33 0x00000000006d5277 in do_select (join=0x1d77df8, fields=0x1cbfd18, table=0x0, procedure=0x0) at sql_select.cc:10913
#34 0x00000000006e7687 in JOIN::exec (this=0x1d77df8) at sql_select.cc:2209
#35 0x00000000006e246f in mysql_select (thd=0x1cbdd88, rref_pointer_array=0x1cbfde0, tables=0x1d26c28, wild_num=0, fields=@0x1cbfd18, conds=0x0, og_num=0, order=0x0, group=0x0,
    having=0x0, proc_param=0x0, select_options=3492039168, result=0x1d75ba8, unit=0x1cbf7e8, select_lex=0x1cbfc10) at sql_select.cc:2398
#36 0x00000000006e79c7 in handle_select (thd=0x1cbdd88, lex=0x1cbf748, result=0x1d75ba8, setup_tables_done_option=1073741824) at sql_select.cc:268
#37 0x00000000006572e7 in mysql_execute_command (thd=0x1cbdd88) at sql_parse.cc:3193
#38 0x000000000065d3eb in mysql_parse (thd=0x1cbdd88,
    inBuf=0x1d26078 "REPLACE   testdb_A . t1_base_1_A  ( `int`,`pk`,`int_key` ) SELECT   `int`,`pk`,`int_key` FROM testdb_A . t1_part_2_A  AS A", length=122,
    found_semicolon=0x7f3304ebaed0) at sql_parse.cc:5931
#39 0x000000000065e215 in dispatch_command (command=COM_QUERY, thd=0x1cbdd88,
    packet=0x1d11e39 "REPLACE   testdb_A . t1_base_1_A  ( `int`,`pk`,`int_key` ) SELECT   `int`,`pk`,`int_key` FROM testdb_A . t1_part_2_A  AS A  ", packet_length=124)
    at sql_parse.cc:1213
#40 0x000000000065f5e4 in do_command (thd=0x1cbdd88) at sql_parse.cc:854
#41 0x000000000064bf15 in handle_one_connection (arg=0x1cbdd88) at sql_connect.cc:1127
#42 0x000000315b0073da in start_thread () from /lib64/libpthread.so.0
#43 0x000000315a4e627d in clone () from /lib64/libc.so.6

How to repeat:
This test case was automatically culled from a 20K-line query log, so it may still contain redundant items. However, it seems that at least the trigger, the multi-table UPDATE inside the trigger and the MERGE table are all required.

CREATE TABLE `table0_int_autoinc` ( `int` int, pk integer auto_increment, `int_key` int,        primary key (pk), key (`int_key` ));
CREATE TABLE `table1_int_autoinc` ( `int` int, pk integer auto_increment, `int_key` int,        primary key (pk), key (`int_key` ));
INSERT IGNORE INTO table1_int_autoinc VALUES  ('4', NULL, NULL);
CREATE TABLE `table10_int_autoinc` ( `int` int, pk integer auto_increment, `int_key` int,       primary key (pk), key (`int_key` ));

CREATE SCHEMA IF NOT EXISTS testdb_A DEFAULT CHARACTER SET  utf8;
CREATE TABLE IF NOT EXISTS testdb_A . t1_base_1_A  LIKE test . table10_int_autoinc;
CREATE TABLE IF NOT EXISTS testdb_A . t1_part_2_A  ENGINE = MyISAM PARTITION BY KEY (pk) PARTITIONS 2 AS SELECT   `int`,`pk`,`int_key` FROM testdb_A . t1_base_1_A   A WHERE `pk` BETWEEN 9 AND 0;
CREATE TABLE IF NOT EXISTS testdb_A . t1_base_2_A LIKE test . table1_int_autoinc;
CREATE  ALGORITHM = MERGE VIEW testdb_A . t1_view_1_A  AS SELECT   `int`,`pk`,`int_key` FROM testdb_A . t1_base_2_A  AS A;

CREATE TABLE IF NOT EXISTS testdb_A . t1_temp_2_A  LIKE test . table0_int_autoinc;
CREATE OR REPLACE ALGORITHM = MERGE VIEW testdb_A . t1_view_2_A  AS SELECT   `int`,`pk`,`int_key` FROM testdb_A . t1_temp_2_A  AS A WHERE `pk` BETWEEN 2 AND 9;
INSERT INTO testdb_A . t1_base_1_A SELECT * FROM test . table1_int_autoinc;
INSERT INTO testdb_A . t1_base_2_A SELECT * FROM test . table1_int_autoinc;
CREATE TABLE IF NOT EXISTS testdb_A . t1_merge_1_A LIKE test . table1_int_autoinc;
ALTER TABLE testdb_A . t1_merge_1_A ENGINE = MERGE UNION ( testdb_A . t1_base_1_A , testdb_A . t1_base_2_A );

DELIMITER |;
CREATE TRIGGER testdb_A . tr1_2_A  AFTER INSERT ON t1_base_1_A FOR EACH ROW BEGIN UPDATE   testdb_A . t1_view_2_A  AS A NATURAL JOIN testdb_A . t1_view_1_A  B SET A. `int_key` = 9, B. `pk` = 1 ; END|
DELIMITER ;|
INSERT   testdb_A . t1_part_2_A  ( `int`,`pk`,`int_key` ) SELECT   * FROM testdb_A . t1_merge_1_A  A;
REPLACE   testdb_A . t1_base_1_A  ( `int`,`pk`,`int_key` ) SELECT   `int`,`pk`,`int_key` FROM testdb_A . t1_part_2_A  AS A  ;
[22 Sep 2009 11:23] Bugs System
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/84104

3124 Sergey Glukhov	2009-09-22
      Bug#47150 Assertion in Field_long::val_int() on MERGE + TRIGGER + multi-table UPDATE
      On PREPARE stage(see test case) we call mark_common_columns() func which
      creates ON condition for NATURAL JOIN and sets appropriate
      table read_set bitmaps for fields which are used in ON condition.
      On EXECUTE stage mark_common_columns() is not called, we set
      necessary read_set bitmaps in setup_conds(). But 'B.f1' field
      is already processed and related item alredy fixed before
      setup_conds() as updated field and setup_conds can not set
      read_set bitmap because of that.
      The fix is to set read_set bitmap in Item_direct_view_ref
      for appropriate field even if the item is fixed.
     @ mysql-test/r/join.result
        test result
     @ mysql-test/t/join.test
        test case
     @ sql/item.cc
        On PREPARE stage(see test case) we call mark_common_columns() func which
        creates ON condition for NATURAL JOIN and sets appropriate
        table read_set bitmaps for fields which are used in ON condition.
        On EXECUTE stage mark_common_columns() is not called, we set
        necessary read_set bitmaps in setup_conds(). But 'B.f1' field
        is already processed and related item alredy fixed before
        setup_conds() as updated field and setup_conds can not set
        read_set bitmap because of that.
        The fix is to set read_set bitmap in Item_direct_view_ref
        for appropriate field even if the item is fixed.
[28 Sep 2009 7:11] Bugs System
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/84789

3124 Sergey Glukhov	2009-09-28
      Bug#47150 Assertion in Field_long::val_int() on MERGE + TRIGGER + multi-table UPDATE
      The bug is not related to MERGE table or TRIGGER. More correct description
      would be 'assertion on multi-table UPDATE + NATURAL JOIN + MERGEABLE VIEW'.
      On PREPARE stage(see test case) we call mark_common_columns() func which
      creates ON condition for NATURAL JOIN and sets appropriate
      table read_set bitmaps for fields which are used in ON condition.
      On EXECUTE stage mark_common_columns() is not called, we set
      necessary read_set bitmaps in setup_conds(). But 'B.f1' field
      is already processed and related item alredy fixed before
      setup_conds() as updated field and setup_conds can not set
      read_set bitmap because of that.
      The fix is to set read_set bitmap for appropriate table field even
      if Item_direct_view_ref item which represents a refernce to this field
      is fixed.
     @ mysql-test/r/join.result
        test result
     @ mysql-test/t/join.test
        test case
     @ sql/item.cc
        The bug is not related to MERGE table or TRIGGER. More correct description
        would be 'assertion on multi-table UPDATE + NATURAL JOIN + MERGEABLE VIEW'.
        On PREPARE stage(see test case) we call mark_common_columns() func which
        creates ON condition for NATURAL JOIN and sets appropriate
        table read_set bitmaps for fields which are used in ON condition.
        On EXECUTE stage mark_common_columns() is not called, we set
        necessary read_set bitmaps in setup_conds(). But 'B.f1' field
        is already processed and related item alredy fixed before
        setup_conds() as updated field and setup_conds can not set
        read_set bitmap because of that.
        The fix is to set read_set bitmap for appropriate table field even
        if Item_direct_view_ref item which represents a refernce to this field
        is fixed.
[28 Sep 2009 13:22] Bugs System
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/84858

3139 Sergey Glukhov	2009-09-28
      Bug#47150 Assertion in Field_long::val_int() on MERGE + TRIGGER + multi-table UPDATE
      The bug is not related to MERGE table or TRIGGER. More correct description
      would be 'assertion on multi-table UPDATE + NATURAL JOIN + MERGEABLE VIEW'.
      On PREPARE stage(see test case) we call mark_common_columns() func which
      creates ON condition for NATURAL JOIN and sets appropriate
      table read_set bitmaps for fields which are used in ON condition.
      On EXECUTE stage mark_common_columns() is not called, we set
      necessary read_set bitmaps in setup_conds(). But 'B.f1' field
      is already processed and related item alredy fixed before
      setup_conds() as updated field and setup_conds can not set
      read_set bitmap because of that.
      The fix is to set read_set bitmap for appropriate table field even
      if Item_direct_view_ref item which represents a refernce to this field
      is fixed.
     @ mysql-test/r/join.result
        test result
     @ mysql-test/t/join.test
        test case
     @ sql/item.cc
        The bug is not related to MERGE table or TRIGGER. More correct description
        would be 'assertion on multi-table UPDATE + NATURAL JOIN + MERGEABLE VIEW'.
        On PREPARE stage(see test case) we call mark_common_columns() func which
        creates ON condition for NATURAL JOIN and sets appropriate
        table read_set bitmaps for fields which are used in ON condition.
        On EXECUTE stage mark_common_columns() is not called, we set
        necessary read_set bitmaps in setup_conds(). But 'B.f1' field
        is already processed and related item alredy fixed before
        setup_conds() as updated field and setup_conds can not set
        read_set bitmap because of that.
        The fix is to set read_set bitmap for appropriate table field even
        if Item_direct_view_ref item which represents a refernce to this field
        is fixed.
[29 Sep 2009 3:23] Bugs System
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/84927

3144 Sergey Glukhov	2009-09-29
      Bug#47150 Assertion in Field_long::val_int() on MERGE + TRIGGER + multi-table UPDATE
      The bug is not related to MERGE table or TRIGGER. More correct description
      would be 'assertion on multi-table UPDATE + NATURAL JOIN + MERGEABLE VIEW'.
      On PREPARE stage(see test case) we call mark_common_columns() func which
      creates ON condition for NATURAL JOIN and sets appropriate
      table read_set bitmaps for fields which are used in ON condition.
      On EXECUTE stage mark_common_columns() is not called, we set
      necessary read_set bitmaps in setup_conds(). But 'B.f1' field
      is already processed and related item alredy fixed before
      setup_conds() as updated field and setup_conds can not set
      read_set bitmap because of that.
      The fix is to set read_set bitmap for appropriate table field even
      if Item_direct_view_ref item which represents a refernce to this field
      is fixed.
     @ mysql-test/r/join.result
        test result
     @ mysql-test/t/join.test
        test case
     @ sql/item.cc
        The bug is not related to MERGE table or TRIGGER. More correct description
        would be 'assertion on multi-table UPDATE + NATURAL JOIN + MERGEABLE VIEW'.
        On PREPARE stage(see test case) we call mark_common_columns() func which
        creates ON condition for NATURAL JOIN and sets appropriate
        table read_set bitmaps for fields which are used in ON condition.
        On EXECUTE stage mark_common_columns() is not called, we set
        necessary read_set bitmaps in setup_conds(). But 'B.f1' field
        is already processed and related item alredy fixed before
        setup_conds() as updated field and setup_conds can not set
        read_set bitmap because of that.
        The fix is to set read_set bitmap for appropriate table field even
        if Item_direct_view_ref item which represents a refernce to this field
        is fixed.
[6 Oct 2009 9:00] Bugs System
Pushed into 5.1.40 (revid:joro@sun.com-20091006073316-lea2cpijh9r6on7c) (version source revid:sergey.glukhov@sun.com-20090929022338-1t6w2ecpg0j6u1p1) (merge vers: 5.1.40) (pib:11)
[14 Oct 2009 15:37] Paul DuBois
Noted in 5.1.40 changelog.

A multiple-table UPDATE involving a natural join and a mergeable view
raised an assertion. 

Setting report to NDI pending push into 5.5.x+.
[22 Oct 2009 6:35] Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20091022063126-l0qzirh9xyhp0bpc) (version source revid:alik@sun.com-20091019135554-s1pvptt6i750lfhv) (merge vers: 6.0.14-alpha) (pib:13)
[22 Oct 2009 7:07] Bugs System
Pushed into 5.5.0-beta (revid:alik@sun.com-20091022060553-znkmxm0g0gm6ckvw) (version source revid:alik@sun.com-20091013094238-g67x6tgdm9a7uik0) (merge vers: 5.5.0-beta) (pib:13)
[22 Oct 2009 19:42] Paul DuBois
Noted in 5.5.0, 6.0.14 changelogs.
[18 Dec 2009 10:34] Bugs System
Pushed into 5.1.41-ndb-7.1.0 (revid:jonas@mysql.com-20091218102229-64tk47xonu3dv6r6) (version source revid:jonas@mysql.com-20091218095730-26gwjidfsdw45dto) (merge vers: 5.1.41-ndb-7.1.0) (pib:15)
[18 Dec 2009 10:49] Bugs System
Pushed into 5.1.41-ndb-6.2.19 (revid:jonas@mysql.com-20091218100224-vtzr0fahhsuhjsmt) (version source revid:jonas@mysql.com-20091217101452-qwzyaig50w74xmye) (merge vers: 5.1.41-ndb-6.2.19) (pib:15)
[18 Dec 2009 11:05] Bugs System
Pushed into 5.1.41-ndb-6.3.31 (revid:jonas@mysql.com-20091218100616-75d9tek96o6ob6k0) (version source revid:jonas@mysql.com-20091217154335-290no45qdins5bwo) (merge vers: 5.1.41-ndb-6.3.31) (pib:15)
[18 Dec 2009 11:19] Bugs System
Pushed into 5.1.41-ndb-7.0.11 (revid:jonas@mysql.com-20091218101303-ga32mrnr15jsa606) (version source revid:jonas@mysql.com-20091218064304-ezreonykd9f4kelk) (merge vers: 5.1.41-ndb-7.0.11) (pib:15)
[10 Sep 2014 6:56] Roel Van de Paar
Just FYI, this bug is still present in MySQL 5.6.20

2014-09-10 19:47:39 19032 [Note] /sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug: ready for connections.
Version: '5.6.20-debug-log'  socket: '/sda/324483/current1_1/tmp/master.sock'  port: 13000  MySQL Community Server (GPL)
mysqld-debug: /bzr/mysql-5.6/sql/field.cc:3819: virtual longlong Field_long::val_int(): Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set,
 field_index))' failed.
16:51:04 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

key_buffer_size=1048576
read_buffer_size=131072
max_used_connections=4
max_threads=151
thread_count=2
connection_count=2
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 61081 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7fefe3a54000
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7ff01738be20 thread_stack 0x40000
/sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug(my_print_stacktrace+0x35)[0xa902dc]
/sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug(handle_fatal_signal+0x3f3)[0x7234a3]
/lib64/libpthread.so.0(+0xf130)[0x7ff016dd8130]
/lib64/libc.so.6(gsignal+0x39)[0x7ff015be1989]
/lib64/libc.so.6(abort+0x148)[0x7ff015be3098]
/lib64/libc.so.6(+0x2e8f6)[0x7ff015bda8f6]
/lib64/libc.so.6(+0x2e9a2)[0x7ff015bda9a2]
/sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug(_ZN10Field_long7val_intEv+0x75)[0x8f727f]
/sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug(_ZN12ha_partition28set_auto_increment_if_higherEP5Field+0x33)[0xe147b5]
/sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug(_ZN12ha_partition10update_rowEPKhPh+0x4dc)[0xe0a1d4]
/sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug(_ZN7handler13ha_update_rowEPKhPh+0x165)[0x6421ab]
/sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x1bf6)[0x85f1fe]
/sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug(_Z21mysql_execute_commandP3THD+0x272a)[0x7d1052]
/sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug(_Z11mysql_parseP3THDPcjP12Parser_state+0x485)[0x7d8fa4]
/sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug(_Z16dispatch_command19enum_server_commandP3THDPcj+0xcbe)[0x7cc557]
/sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug(_Z10do_commandP3THD+0x33e)[0x7cb646]
/sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug(_Z24do_handle_one_connectionP3THD+0x1b6)[0x793a61]
/sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug(handle_one_connection+0x33)[0x79354a]
/sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug(pfs_spawn_thread+0x159)[0xade888]
/lib64/libpthread.so.0(+0x7df3)[0x7ff016dd0df3]
/lib64/libc.so.6(clone+0x6d)[0x7ff015ca23dd]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7fefd5c20010): UPDATE   `view_table500_innodb_compressed_key_pk_parts_2_int` SET `c21` = 2 WHERE `pk` >= 'b'
Connection ID (thread ID): 9
Status: NOT_KILLED
[10 Sep 2014 6:56] Roel Van de Paar
Maybe a missed code path?
[10 Sep 2014 6:59] Roel Van de Paar
Maybe different assert. In any case, logged as bug #73869