Server crashes in handler::increment_statistics on inserting into a view

[Elena Stepanova]

#4 <signal handler called>
#5 0x081ed089 in handler::increment_statistics (this=0x946eca0,
    offset=&system_status_var::ha_write_count) at sql_class.h:3645
#6 0x0843b610 in handler::ha_write_row (this=0x946eca0, buf=0x946c1f8 "\377")
    at handler.cc:4939
#7 0x0838d8ee in write_record (thd=0x93ef128, table=0x946e108, info=0xae978628)
    at sql_insert.cc:1692
#8 0x0838b958 in mysql_insert (thd=0x93ef128, table_list=0x9487578, fields=...,
    values_list=..., update_fields=..., update_values=..., duplic=DUP_ERROR,
    ignore=false) at sql_insert.cc:887
#9 0x082e66b6 in mysql_execute_command (thd=0x93ef128) at sql_parse.cc:3233
#10 0x082eef92 in mysql_parse (thd=0x93ef128,
    rawbuf=0x94874c8 "INSERT INTO v2 (a) VALUES (1)", length=29,
    found_semicolon=0xae979234) at sql_parse.cc:6153
#11 0x082e1955 in dispatch_command (command=COM_QUERY, thd=0x93ef128,
    packet=0x9446341 "INSERT INTO v2 (a) VALUES (1) ", packet_length=30)
    at sql_parse.cc:1228
#12 0x082e0dff in do_command (thd=0x93ef128) at sql_parse.cc:923
#13 0x082ddcf5 in handle_one_connection (arg=0x93ef128) at sql_connect.cc:1218
#14 0xb778eb25 in start_thread () from /lib/libpthread.so.0

bzr version-info
revision-id: <email address hidden>
date: 2012-06-01 14:56:47 +0200
build-date: 2012-06-02 01:57:21 +0400
revno: 3536

Also reproducible on maria-5.5 revno 3425.
Could not reproduce on maria-5.2, mysql-5.1, mysql-5.5, mysql-trunk.
Reproducible with MyISAM, Aria, InnoDB.
Reproducible with default optimizer_switch as well as with all OFF values.

# Test case:

CREATE TABLE t1 (a INT);
CREATE ALGORITHM=MERGE VIEW v1 AS SELECT a1.* FROM t1 AS a1, t1 AS a2;
CREATE ALGORITHM=MERGE VIEW v2 AS SELECT * FROM v1;
INSERT INTO v2 (a) VALUES (1) ;

# End of test case

[Igor Babaev (igorb-seattle)]

I assign this bug to Sanja as he takes care of INTSERT into <view>.

[Timour Katchaounov (timour)]

The actual cause of the crash is that when handler::increment_statistics() is called from write_record() -> handler::ha_write_row(), the state of the ha_heap object is such that ha_heap::table == NULL.

When comparing the execution of MariaDB 5.3/5.5 (where the crash is observed) with MariaDB 5.2 or mysql-trunk (no crash), the main difference is as follows.

MariaDB 5.3/5.5 creates two temporary tables, named 'v1', and 'v2', one per each view. The call two write_record() gets as its table argument the object of the temporary table named 'v1'. Apparently the handler for this table and possibly the table object itself is not initialized properly.

MariaDB 5.2 and mysql-trunk do not create temporary tables at all.

The question is what is wrong - is MariaDB 5.3/5.5 supposed to create and use temporary tables at all or not? The function that decides on temp table creation is mysql_derived_prepare(). In MariaDB 5.2 there are two clear branches where one deals with temp tables, and the other with merged views. However the logic of mysql_derived_prepare() has changed in MariaDB 5.3/5.5, and at least to me it appears that a temp table is created always.

I will ask Igor for help on the above question since he modified heavily this code. Depending on the intended behavior, I will analyze the bug further.

[Igor Babaev (igorb-seattle)]

I've assigned this bug to Sanja as he usually takes care of INSERT INTO <view>.