[MDEV-8632] Segmentation fault on INSERT Created: 2015-08-17  Updated: 2015-11-09  Resolved: 2015-11-09

Status: Closed
Project: MariaDB Server
Component/s: OTHER
Affects Version/s: 5.3.12, 5.5.45, 10.0.21, 10.1.6
Fix Version/s: 5.5.47, 10.0.23, 10.1.9

Type: Bug Priority: Major
Reporter: Konstantin Assignee: Oleksandr Byelkin
Resolution: Fixed Votes: 0
Labels: None
Environment:

Debian 7.8 (kernel=3.2.0-4-amd64), 16GB RAM
CentOS 7.1 (kernel=3.10.0-229.11.1.el7.x86_64), 8GB RAM

Attachments: File my.cnf    
Sprint: 10.1.9-2

 Description   

I have got a segmentation fault error with query.
A client take a message - Error Code: 2013. Lost connection to MySQL server during query.

Query

 
insert into _tmp (id, r)
 
select id,p from
 
(
 
  select id, 
  d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d as p
 
  from (
 
    select id, if(r=r,1,2) as d
 
    from _tmp
 
  ) a
 
) b
 
on duplicate key update r=p;

Table _tmp has a structure:

CREATE TABLE `_tmp` (
 
  `id` int(10) unsigned NOT NULL,
 
  `r` float NOT NULL,
 
  PRIMARY KEY (`id`)
 
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

But if simplify query the error will go away.
For example: replace one or more '+d' on '+1'
or replace 'r=r' on 'r=1'
or replace 'r=p' on 'r=1'.

The error is repeatable on MariaDB 5.5.45, 10.0.21, 10.1.6.
There is no error on Mysql 5.5 and 5.0.

Error log shows:

150817  4:15:17 [ERROR] mysqld got signal 11 ;
 
 
 
Server version: 10.1.6-MariaDB-1~wheezy-log
 
key_buffer_size=134217728
 
read_buffer_size=2097152
 
max_used_connections=3
 
max_threads=102
 
thread_count=2
 
It is possible that mysqld could use up to
 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 759823 K  bytes of memory
 
Hope that's ok; if not, decrease some variables in the equation.
 
 
 
Thread pointer: 0x0x7f333dbde008
 
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 = 0x7f3370172e30 thread_stack 0x48000
 
/usr/sbin/mysqld(my_print_stacktrace+0x2b)[0x7f3370cb658b]
 
/usr/sbin/mysqld(handle_fatal_signal+0x455)[0x7f337084de05]
 
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf0a0)[0x7f336fe3f0a0]
 
 
 
Trying to get some variables.
 
Some pointers may be invalid and cause the dump to abort.
 
Query (0x7f335602d020): is an invalid pointer
 
Connection ID (thread ID): 5
 
Status: NOT_KILLED

------------------------------------------

Binary log mariadb-bin.000001 is in the private uploads.

 Comments   
Comment by Elena Stepanova [ 2015-08-18 ]

Thanks for the report and the test case.

Stack trace from 5.5 e40bc659335f7f8b69427ed2d215c34c045a5ed7

 
#3  <signal handler called>
 
#4  0x00000000013766f0 in vtable for Item_ref ()
 
#5  0x000000000069761d in count_field_types (select_lex=0x7f1c96384a70, param=0x7f1c96562b98, fields=..., reset_with_sum_func=false) at 5.5/sql/sql_select.cc:20894
 
#6  0x0000000000664fc7 in JOIN::prepare_stage2 (this=0x7f1c96562998) at 5.5/sql/sql_select.cc:932
 
#7  0x0000000000664ecd in JOIN::prepare (this=0x7f1c96562998, rref_pointer_array=0x7f1c96384ce0, tables_init=0x7f1c965f46b0, wild_num=0, conds_init=0x0, og_num=0, order_init=0x0, skip_order_by=false, group_init=0x0, having_init=0x0, proc_param_init=0x0, select_lex_arg=0x7f1c96384a70, unit_arg=0x7f1c96384390) at 5.5/sql/sql_select.cc:906
 
#8  0x000000000066c831 in mysql_select (thd=0x7f1c96381060, rref_pointer_array=0x7f1c96384ce0, tables=0x7f1c965f46b0, wild_num=0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=3489925888, result=0x7f1c96562900, unit=0x7f1c96384390, select_lex=0x7f1c96384a70) at 5.5/sql/sql_select.cc:3072
 
#9  0x00000000006632f1 in handle_select (thd=0x7f1c96381060, lex=0x7f1c963842e0, result=0x7f1c96562900, setup_tables_done_option=1073741824) at 5.5/sql/sql_select.cc:319
 
#10 0x0000000000637731 in mysql_execute_command (thd=0x7f1c96381060) at 5.5/sql/sql_parse.cc:3060
 
#11 0x000000000063f062 in mysql_parse (thd=0x7f1c96381060, rawbuf=0x7f1c9652a078 "insert into _tmp (id, r)\nselect id,p from\n(\n  select id, \n  d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d as p\n  from (\n    select id, if(r=r,1,2) as d\n    from _tmp\n  ) a\n) b\non duplicate key"..., length=211, parser_state=0x7f1c88bb5670) at 5.5/sql/sql_parse.cc:5909
 
#12 0x0000000000632ca5 in dispatch_command (command=COM_QUERY, thd=0x7f1c96381060, packet=0x7f1c964e6061 "insert into _tmp (id, r)\nselect id,p from\n(\n  select id, \n  d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d+d as p\n  from (\n    select id, if(r=r,1,2) as d\n    from _tmp\n  ) a\n) b\non duplicate key"..., packet_length=211) at 5.5/sql/sql_parse.cc:1079
 
#13 0x0000000000631e31 in do_command (thd=0x7f1c96381060) at 5.5/sql/sql_parse.cc:793
 
#14 0x0000000000734f49 in do_handle_one_connection (thd_arg=0x7f1c96381060) at 5.5/sql/sql_connect.cc:1269
 
#15 0x0000000000734cc3 in handle_one_connection (arg=0x7f1c96381060) at 5.5/sql/sql_connect.cc:1185
 
#16 0x00007f1cb134db50 in start_thread (arg=<optimized out>) at pthread_create.c:304
 
#17 0x00007f1caf60395d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
 
#18 0x0000000000000000 in ?? ()

Comment by Oleksandr Byelkin [ 2015-11-06 ]

Problem is memory overrun. ref_pointer_array_size is 50 but all_fields has 51 element.

Comment by Oleksandr Byelkin [ 2015-11-06 ]

Problem made by Item_field::update_value_transformer which leads to huge Item_ref chain...

Comment by Oleksandr Byelkin [ 2015-11-06 ]

every transformation of field d generate longer and longer chain of fields r

Comment by Oleksandr Byelkin [ 2015-11-06 ]

revision-id: 22150288580624fd22407897faaf0b93c71a22b6 (mariadb-5.5.46-3-g2215028)
parent(s): df804208657dfae10e24d656d9228f05e57b14a5
committer: Oleksandr Byelkin
timestamp: 2015-11-06 16:36:41 +0100
message:

DEV-8632 Segmentation fault on INSERT

View/derived fields should be taken into account when we build ref_pointer_array constructed.

DBUG_ASSERTs added to avoid memory overrun.

—

Comment by Sergey Vojtovich [ 2015-11-09 ]

Looks good.

Generated at Thu Feb 08 07:28:36 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.