Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.1.13
-
None
-
RHEL 6.7, pacemaker, replication
2.6.32-573.18.1.el6.x86_64
-
10.1.19
Description
The database had many transaction(update) from batch server. Suddenly master server had gone, slave server promote to new maser in replication with pacemker. The master server get the error [ERROR] mysqld got signal 11. About 10 minutes later, slave also shutdown abnormally. It also same error([ERROR] mysqld got signal 11).
And I used mysqbinlog to fine last SQL. I found similary transaction(same table, same update) in master and slave server.
I attached detail log(Last SQL using mysqlbinlog in master and slave, mysqld.err)
Attachments
Activity
Dear, Elena Stepanova.
We wanna solve this problem to patch mariadb until next week. How it is going this problem?
gks3117,
Thanks for the data, I was able to reproduce the problem.
As a workaround, if you are able to modify the application, you can replace nullif in the fragment of the query that you identified with IF:
- AND E.ORD_SYS_CD = IFNULL(MAX(nullif(carrier_code1,'')),MAX(SHIPPING_LINE2)) |
+ AND E.ORD_SYS_CD = IFNULL(MAX(if(carrier_code1='',null,carrier_code1)),MAX(SHIPPING_LINE2)) |
It should allow to avoid the crash until the bug is fixed.
|
Smaller test case |
CREATE TABLE t1 (f1 VARCHAR(10), f2 VARCHAR(40)); |
CREATE TABLE t2 (f3 VARCHAR(20)); |
PREPARE stmt FROM " |
SELECT (
|
SELECT IFNULL(f3,4) FROM t2
|
WHERE IFNULL(NULLIF(f1,''),1)
|
) AS sq
|
FROM t1
|
GROUP BY f2
|
"; |
EXECUTE stmt; |
|
Stack trace from 10.1 commit 12ac3ee11e8bc433432a2b3ba1bb79ea2e2d9965 |
#2 0x00007fb90c5530a9 in handle_fatal_signal (sig=11) at /data/src/10.1/sql/signal_handler.cc:294
|
#3 <signal handler called>
|
#4 0x00007fb90c5b7849 in Item_func::fix_fields (this=0x7fb900856bc8, thd=0x7fb902bf9070, ref=0x7fb900856ee0) at /data/src/10.1/sql/item_func.cc:208
|
#5 0x00007fb90c5b7869 in Item_func::fix_fields (this=0x7fb900856e58, thd=0x7fb902bf9070, ref=0x7fb9008e2ce0) at /data/src/10.1/sql/item_func.cc:208
|
#6 0x00007fb90c2c22ac in setup_conds (thd=0x7fb902bf9070, tables=0x7fb9008563f0, leaves=..., conds=0x7fb9008e2ce0) at /data/src/10.1/sql/sql_base.cc:8629
|
#7 0x00007fb90c3a03bd in setup_without_group (thd=0x7fb902bf9070, ref_pointer_array=0x7fb9008579f8, tables=0x7fb9008563f0, leaves=..., fields=..., all_fields=..., conds=0x7fb9008e2ce0, order=0x0, group=0x0, hidden_group_fields=0x7fb9008e2bc0, reserved=0x7fb90085591c) at /data/src/10.1/sql/sql_select.cc:645
|
#8 0x00007fb90c357e40 in JOIN::prepare (this=0x7fb9008e2898, rref_pointer_array=0x7fb9008558f8, tables_init=0x7fb9008563f0, wild_num=0, conds_init=0x7fb900856e58, og_num=0, order_init=0x0, skip_order_by=false, group_init=0x0, having_init=0x0, proc_param_init=0x0, select_lex_arg=0x7fb900855680, unit_arg=0x7fb9008559e0) at /data/src/10.1/sql/sql_select.cc:799
|
#9 0x00007fb90c600571 in subselect_single_select_engine::prepare (this=0x7fb900857060, thd=0x7fb902bf9070) at /data/src/10.1/sql/item_subselect.cc:3561
|
#10 0x00007fb90c5f6540 in Item_subselect::fix_fields (this=0x7fb900856f28, thd_param=0x7fb902bf9070, ref=0x7fb9008570b0) at /data/src/10.1/sql/item_subselect.cc:262
|
#11 0x00007fb90c2c03ad in setup_fields (thd=0x7fb902bf9070, ref_pointer_array=0x7fb900857868, fields=..., mark_used_columns=MARK_COLUMNS_READ, sum_func_list=0x7fb9008e2678, allow_sum_func=true) at /data/src/10.1/sql/sql_base.cc:7901
|
#12 0x00007fb90c357d7b in JOIN::prepare (this=0x7fb9008e2318, rref_pointer_array=0x7fb900854ad0, tables_init=0x7fb9008570f8, wild_num=0, conds_init=0x0, og_num=1, order_init=0x0, skip_order_by=false, group_init=0x7fb9008577f8, having_init=0x0, proc_param_init=0x0, select_lex_arg=0x7fb900854858, unit_arg=0x7fb900854158) at /data/src/10.1/sql/sql_select.cc:795
|
#13 0x00007fb90c3614a7 in mysql_select (thd=0x7fb902bf9070, rref_pointer_array=0x7fb900854ad0, tables=0x7fb9008570f8, wild_num=0, fields=..., conds=0x0, og_num=1, order=0x0, group=0x7fb9008577f8, having=0x0, proc_param=0x0, select_options=2416216832, result=0x7fb900857848, unit=0x7fb900854158, select_lex=0x7fb900854858) at /data/src/10.1/sql/sql_select.cc:3429
|
#14 0x00007fb90c35702c in handle_select (thd=0x7fb902bf9070, lex=0x7fb900854090, result=0x7fb900857848, setup_tables_done_option=0) at /data/src/10.1/sql/sql_select.cc:384
|
#15 0x00007fb90c327382 in execute_sqlcom_select (thd=0x7fb902bf9070, all_tables=0x7fb9008570f8) at /data/src/10.1/sql/sql_parse.cc:5894
|
#16 0x00007fb90c31d28f in mysql_execute_command (thd=0x7fb902bf9070) at /data/src/10.1/sql/sql_parse.cc:2960
|
#17 0x00007fb90c344ec6 in Prepared_statement::execute (this=0x7fb900b44470, expanded_query=0x7fb90d275a10, open_cursor=false) at /data/src/10.1/sql/sql_prepare.cc:4269
|
#18 0x00007fb90c343d37 in Prepared_statement::execute_loop (this=0x7fb900b44470, expanded_query=0x7fb90d275a10, open_cursor=false, packet=0x0, packet_end=0x0) at /data/src/10.1/sql/sql_prepare.cc:3901
|
#19 0x00007fb90c341dcf in mysql_sql_stmt_execute (thd=0x7fb902bf9070) at /data/src/10.1/sql/sql_prepare.cc:3033
|
#20 0x00007fb90c31d2c0 in mysql_execute_command (thd=0x7fb902bf9070) at /data/src/10.1/sql/sql_parse.cc:2971
|
#21 0x00007fb90c32aaba in mysql_parse (thd=0x7fb902bf9070, rawbuf=0x7fb9008e2088 "EXECUTE stmt", length=12, parser_state=0x7fb90d2765e0) at /data/src/10.1/sql/sql_parse.cc:7314
|
#22 0x00007fb90c3194e4 in dispatch_command (command=COM_QUERY, thd=0x7fb902bf9070, packet=0x7fb90453e071 "EXECUTE stmt", packet_length=12) at /data/src/10.1/sql/sql_parse.cc:1486
|
#23 0x00007fb90c31821b in do_command (thd=0x7fb902bf9070) at /data/src/10.1/sql/sql_parse.cc:1107
|
#24 0x00007fb90c44de63 in do_handle_one_connection (thd_arg=0x7fb902bf9070) at /data/src/10.1/sql/sql_connect.cc:1350
|
#25 0x00007fb90c44dbc7 in handle_one_connection (arg=0x7fb902bf9070) at /data/src/10.1/sql/sql_connect.cc:1262
|
#26 0x00007fb90c72f090 in pfs_spawn_thread (arg=0x7fb909027ef0) at /data/src/10.1/storage/perfschema/pfs.cc:1860
|
#27 0x00007fb90ba190a4 in start_thread (arg=0x7fb90d277b00) at pthread_create.c:309
|
#28 0x00007fb909bd187d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
|
The problem appeared in 10.1 tree with the following revision:
commit ce40ccaf24af2fe395f541cb1079256de8727ccd
|
Author: Alexander Barkov <bar@mariadb.org>
|
Date: Thu Jan 28 13:58:39 2016 +0400
|
|
|
MDEV-9181 (NULLIF(count(table.col)), 0) gives wrong result on 10.1.x
|
Wrapping args[0] and args[2] into an Item_cache for aggregate functions.
|
The original test case is attached.
mdev10347.test
|
Even small test |
DROP TABLE IF EXISTS t1,t2; |
CREATE TABLE t1 (f1 VARCHAR(10), f2 VARCHAR(40)); |
CREATE TABLE t2 (f3 VARCHAR(20)); |
PREPARE stmt FROM " |
SELECT (
|
SELECT NULL FROM t2
|
WHERE NULLIF(f1,'')
|
) AS sq
|
FROM t1
|
GROUP BY f2
|
"; |
EXECUTE stmt; |
I confirm that PreparedStatement SELECT using max fucntion(group function) in where cluase make singal 11.
My team use mariadb-jdbc-1.4.6 that useServerPrepStmts's default values is true. But maraidb-jdbc-1.2.6(<1.3.0) and mysql-5.1.39 jdbc connector did not make signal 11 error. I find that those connector' parameter(useServerPrepStmts)'s values is false. So it did not make signal error.
My team applied the parameter is false. Then it it did not make signal error!
Probably, it is bug. I provie the create table sql to determine my case. Thanks.