Re: MariaDB 5.2.9 and 5.2.10 crashes on executing attached query
Umm, just noticed: the log dump says that key_buffer_size=0, which is wrong. Actual value:

MariaDB [(none)]> show variables like "key_buffer_size";
--------------------------+

--------------------------+

--------------------------+
1 row in set (0.00 sec)

Re: MariaDB 5.2.9 and 5.2.10 crashes on executing attached query
Hi,

Could you upload the dump to ftp://ftp.askmonty.org/private? Only MariaDB developers can read it.

Thanks

Re: MariaDB 5.2.9 and 5.2.10 crashes on executing attached query
Hi Elena

Done, filename is bug_909635.sql

Re: MariaDB 5.2.9 and 5.2.10 crashes on executing attached query
Hi Anton,

Thank you.

Here is a simplified test case:

CREATE TABLE t1 (
a INT PRIMARY KEY,
b CHAR(255),
c VARCHAR(2048),
d VARCHAR(18990),
e CHAR(128),
f CHAR(192)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

INSERT INTO t1 VALUES
(1,'A','B','C','','D'),
(2,'Abcdefghi','E','F','','G');

CREATE TABLE t2 (
g INT PRIMARY KEY,
h CHAR(32),
i CHAR(255),
j TEXT
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

INSERT INTO t2
VALUES
(1,'M','','H'),
(2,'N','','H');

SELECT * FROM t1, t2
WHERE a = g ORDER BY b;

Reproducible on 5.1.60, 5.2.10, 5.3, 5.5 with certain combinations of engines:

1. MyISAM / MyISAM
2. MyISAM / InnoDB
3. Aria / MyISAM
4. Aria / InnoDB
5. InnoDB / InnoDB

Re: MariaDB 5.2.9 and 5.2.10 crashes on executing attached query
In 5.3, reproducible with the default optimizer_switch as well as with all OFFs.

Re: MariaDB 5.2.9 and 5.2.10 crashes on executing attached query
Stack trace from the current 5.3:

#3 <signal handler called>
#4 0x00007f87e79218b0 in memcpy () from /lib64/libc.so.6
#5 0x0000000000a16693 in write_tail (info=0x1daf358, block=0x1dc8920,
row_part=0x2020202020204014 <Address 0x2020202020204014 out of bounds>, org_length=44)
at ma_blockrec.c:1964
#6 0x0000000000a18cf6 in write_block_record (info=0x1daf358, old_record=0x0,
record=0x1d78dc0 "", row=0x1daf3b0, bitmap_blocks=0x1daf3b0, head_block_is_read=0 '\000',
row_pos=0x7f87dede8ff0, undo_lsn=1, old_record_checksum=0) at ma_blockrec.c:2900
#7 0x0000000000a1a862 in allocate_and_write_block_record (info=0x1daf358,
record=0x1d78dc0 "", row=0x1daf3b0, undo_lsn=1) at ma_blockrec.c:3534
#8 0x0000000000a1a97a in _ma_write_init_block_record (info=0x1daf358, record=0x1d78dc0 "")
at ma_blockrec.c:3574
#9 0x0000000000a575b6 in maria_write (info=0x1daf358, record=0x1d78dc0 "") at ma_write.c:157
#10 0x00000000009ef091 in ha_maria::write_row (this=0x1d786c0, buf=0x1d78dc0 "")
at ha_maria.cc:1135
#11 0x000000000061a74b in handler::ha_write_tmp_row (this=0x1d786c0, buf=0x1d78dc0 "")
at sql_class.h:3789
#12 0x000000000079a93d in end_write (join=0x1d6cd20, join_tab=0x1d75e18, end_of_records=false)
at sql_select.cc:16558
#13 0x0000000000797c8a in evaluate_join_record (join=0x1d6cd20, join_tab=0x1d75af8, error=0)
at sql_select.cc:15501
#14 0x00000000007974d4 in sub_select (join=0x1d6cd20, join_tab=0x1d75af8,
end_of_records=false) at sql_select.cc:15304
#15 0x0000000000797c8a in evaluate_join_record (join=0x1d6cd20, join_tab=0x1d757d8, error=0)
at sql_select.cc:15501
#16 0x00000000007974d4 in sub_select (join=0x1d6cd20, join_tab=0x1d757d8,
end_of_records=false) at sql_select.cc:15304
#17 0x0000000000796ca2 in do_select (join=0x1d6cd20, fields=0x0, table=0x1d76e30,
procedure=0x0) at sql_select.cc:14965
#18 0x0000000000776bbc in JOIN::exec (this=0x1d6cd20) at sql_select.cc:2262
#19 0x0000000000779105 in mysql_select (thd=0x1c2cbd8, rref_pointer_array=0x1c2f7a8,
tables=0x1cb1208, wild_num=1, fields=..., conds=0x1cb1c30, og_num=1, order=0x1cb1ea8,
group=0x0, having=0x0, proc_param=0x0, select_options=2147764736, result=0x1cb1f88,
unit=0x1c2f070, select_lex=0x1c2f558) at sql_select.cc:2925
#20 0x000000000076fd89 in handle_select (thd=0x1c2cbd8, lex=0x1c2efd0, result=0x1cb1f88,
setup_tables_done_option=0) at sql_select.cc:283
#21 0x00000000006feb1c in execute_sqlcom_select (thd=0x1c2cbd8, all_tables=0x1cb1208)
at sql_parse.cc:5148
#22 0x00000000006f5bd9 in mysql_execute_command (thd=0x1c2cbd8) at sql_parse.cc:2281
#23 0x00000000007014f7 in mysql_parse (thd=0x1c2cbd8,
rawbuf=0x1cb0ff0 "SELECT * FROM t1, t2\nWHERE a = g ORDER BY b", length=43,
found_semicolon=0x7f87dedeac98) at sql_parse.cc:6149
#24 0x00000000006f33ae in dispatch_command (command=COM_QUERY, thd=0x1c2cbd8,
packet=0x1ca7b89 "SELECT * FROM t1, t2\nWHERE a = g ORDER BY b", packet_length=43)
at sql_parse.cc:1227
#25 0x00000000006f26e2 in do_command (thd=0x1c2cbd8) at sql_parse.cc:922
#26 0x00000000006ef60a in handle_one_connection (arg=0x1c2cbd8) at sql_connect.cc:1193
#27 0x00007f87e8588a4f in start_thread () from /lib64/libpthread.so.0
#28 0x00007f87e797282d in clone () from /lib64/libc.so.6

Re: MariaDB 5.2.9 and 5.2.10 crashes on executing attached query
Problem is in temporary table (myisam).

Re: MariaDB 5.2.9 and 5.2.10 crashes on executing attached query
I can't understand what is going wrong in the MyISAM engine, up to the engine everything looks OK (maybe empty line leads for this problem, but I can't say for sure).

Re: MariaDB 5.2.9 and 5.2.10 crashes on executing attached query
Sorry for mistyping. Of course it is (M)Aria tables. BTW it is why we can't reproduce it on MySQL (IMHO).

Re: MariaDB crashes in write_tail on a select from UTF8 tables with a simple join and order by
Test case is hidden in comment #4.

Re: MariaDB crashes in write_tail on a select from UTF8 tables with a simple join and order by
This crash happens if the internal temporary table row length, needed to resolve the query, exceeds 64K
(The query used a UTF8 varchar(18990), which requires up to 56972 space for storage)
Will push the fix to 5.1

Re: MariaDB crashes in write_tail on a select from UTF8 tables with a simple join and order by
(the fix was pushed)

Re: MariaDB crashes in write_tail on a select from UTF8 tables with a simple join and order by
Sorry guys, is there a plan for the near future releasing 5.1/5.2 packages with this bug fixed? Or should we migrate to 5.3 series instead?

Launchpad bug id: 909635

Re: MariaDB crashes in write_tail on a select from UTF8 tables with a simple join and order by
We could do a new release of 5.1.61 and 5.2.11 early next week.
Sorry for the delay.
As there is a lot of work to do a release, we do older releases mainly when there is a security fix, some really really bad bug that hits a lot of people or if a support customer asks us to do so.