[MDEV-17986] crash when I insert on a table Created: 2018-12-12  Updated: 2018-12-13  Resolved: 2018-12-13

Status: Closed
Project: MariaDB Server
Component/s: N/A
Affects Version/s: 10.3.11
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Philip orleans Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Environment:

centos 7

Issue Links:
Duplicate
duplicates MDEV-16039 Crash when selecting virtual columns ... Closed

 Description   

it is not related to any engine, for if change the engine on the same table it crashes anyway. this is the issue that makes Mariadb crash

CREATE TABLE client_1.test (
 
  number bigint(20) NOT NULL,
 
  lrn bigint(20) NOT NULL DEFAULT 0,
 
  source varchar(15) NOT NULL DEFAULT 'reverse(substring_index(reverse(user()),''@'',1))',
 
  PRIMARY KEY (number)
 
)
 
ENGINE = INNODB,
 
AVG_ROW_LENGTH = 2048,
 
CHARACTER SET latin1,
 
COLLATE latin1_swedish_ci;

when I include that default, it inserts fine, if I do a replace on the same number, it crashes.
That default is meant to capture the IP address of the user, which I use for billing.

Again, the engine is not the issue.

 
 
 
 
pure virtual method called
 
terminate called without an active exception
 
181212 17:31:18 [ERROR] 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.
 
 
 
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
 
 
 
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.
 
 
 
Server version: 10.3.11-MariaDB
 
key_buffer_size=134217728
 
read_buffer_size=131072
 
max_used_connections=5
 
max_threads=65546
 
thread_count=12
 
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 25302073 K  bytes of memory
 
Hope that's ok; if not, decrease some variables in the equation.
 
 
 
Thread pointer: 0x7fb13846b008
 
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 = 0x7fc8f1c3cc60 thread_stack 0x30000
 
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x560e80e5561e]
 
/usr/sbin/mysqld(handle_fatal_signal+0x357)[0x560e808f63a7]
 
/lib64/libpthread.so.0(+0xf5d0)[0x7fc8f670d5d0]
 
/lib64/libc.so.6(gsignal+0x37)[0x7fc8f49e1207]
 
/lib64/libc.so.6(abort+0x148)[0x7fc8f49e28f8]
 
/lib64/libstdc++.so.6(_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x165)[0x7fc8f50da7d5]
 
/lib64/libstdc++.so.6(+0x5e746)[0x7fc8f50d8746]
 
/lib64/libstdc++.so.6(+0x5e773)[0x7fc8f50d8773]
 
/lib64/libstdc++.so.6(+0x5f2df)[0x7fc8f50d92df]
 
/usr/sbin/mysqld(_ZN16Item_func_or_sum4walkEM4ItemFbPvEbS1_+0x67)[0x560e806d04e7]
 
/usr/sbin/mysqld(_ZN16Item_func_or_sum4walkEM4ItemFbPvEbS1_+0x67)[0x560e806d04e7]
 
/usr/sbin/mysqld(_Z21fix_session_vcol_exprP3THDP19Virtual_column_info+0x3c)[0x560e807ca3fc]
 
/usr/sbin/mysqld(_Z11lock_tablesP3THDP10TABLE_LISTjj+0x452)[0x560e806c9732]
 
/usr/sbin/mysqld(_Z20open_and_lock_tablesP3THDRK14DDL_options_stP10TABLE_LISTbjP19Prelocking_strategy+0x8a)[0x560e806cadea]
 
/usr/sbin/mysqld(_Z12mysql_insertP3THDP10TABLE_LISTR4ListI4ItemERS3_IS5_ES6_S6_15enum_duplicatesb+0xf6)[0x560e806f8d46]
 
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x2008)[0x560e807220d8]
 
sql/item.h:2190(Item_args::walk_args(bool (Item::*)(void*), bool, void*))[0x560e807292db]
 
sql/item.h:2190(Item_args::walk_args(bool (Item::*)(void*), bool, void*))[0x560e8072be35]
 
sql/table.cc:2888(fix_session_vcol_expr(THD*, Virtual_column_info*))[0x560e8072cc9e]
 
sql/sql_base.cc:5182(fix_all_session_vcol_exprs)[0x560e808375fb]
 
sql/sql_base.cc:5005(open_and_lock_tables(THD*, DDL_options_st const&, TABLE_LIST*, bool, unsigned int, Prelocking_strategy*))[0x560e808cb540]
 
/lib64/libpthread.so.0(+0x7dd5)[0x7fc8f6705dd5]
 
/lib64/libc.so.6(clone+0x6d)[0x7fc8f4aa8ead]
 
 
 
Trying to get some variables.
 
Some pointers may be invalid and cause the dump to abort.
 
Query (0x7fb138546020): replace dataqueue(number) values('7274433019')
 
Connection ID (thread ID): 48
 
Status: NOT_KILLED
 
 
 
Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on
 
 
 
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
 
information that should help you find out what is causing the crash.
 
Wed Dec 12 17:31:37 2018 PerconaFT recovery starting in env /var/lib/mysql/
 
Wed Dec 12 17:31:37 2018 PerconaFT recovery scanning backward from 2177833191
 
Wed Dec 12 17:31:37 2018 PerconaFT recovery bw_end_checkpoint at 2177833191 timestamp 1544635835242697 xid 2177833187 (bw_newer)
 
Wed Dec 12 17:31:37 2018 PerconaFT recovery bw_begin_checkpoint at 2177833187 timestamp 1544635835242623 (bw_between)
 
Wed Dec 12 17:31:37 2018 PerconaFT recovery turning around at begin checkpoint 2177833187 time 74
 
Wed Dec 12 17:31:37 2018 PerconaFT recovery starts scanning forward to 2177833191 from 2177833187 left 4 (fw_between)
 
Wed Dec 12 17:31:37 2018 PerconaFT recovery closing 2 dictionaries
 
Wed Dec 12 17:31:37 2018 PerconaFT recovery making a checkpoint
 
Wed Dec 12 17:31:37 2018 PerconaFT recovery done



 Comments   
Comment by Alice Sherepa [ 2018-12-13 ]

Thanks for the report!
It is the same problem as MDEV-16039, I am closing this one for now, please watch the progress there.

CREATE or replace TABLE t2 (
 
  number bigint(20) NOT NULL,
 
  lrn bigint(20) NOT NULL DEFAULT 0,
 
  source varchar(15) NOT NULL DEFAULT (reverse(substring_index(reverse(user()),'@',1))),
 
  PRIMARY KEY (number)
 
)engine=innodb;
 
 
 
replace t2(number) values('1');
 
replace t2(number) values('1');

10.3.11

 
sql/item.h:943(Item::max_display_length() const)[0x5645751742bb]
 
sql/item.h:4565(Used_tables_and_const_cache::used_tables_and_const_cache_join(Item const*))[0x56457542ca41]
 
sql/item_strfunc.cc:111(Item_str_func::fix_fields(THD*, Item**))[0x56457544fd8b]
 
sql/item_func.cc:363(Item_func::fix_fields(THD*, Item**))[0x56457542ca7f]
 
sql/item_strfunc.cc:111(Item_str_func::fix_fields(THD*, Item**))[0x56457544fd8b]
 
sql/table.cc:2864(fix_vcol_expr(THD*, Virtual_column_info*))[0x5645752b6aa8]
 
sql/sql_base.cc:5182(fix_all_session_vcol_exprs)[0x5645751c3a5f]
 
sql/sql_base.cc:5005(open_and_lock_tables(THD*, DDL_options_st const&, TABLE_LIST*, bool, unsigned int, Prelocking_strategy*))[0x5645751c5422]
 
sql/sql_insert.cc:760(mysql_insert(THD*, TABLE_LIST*, List<Item>&, List<List<Item> >&, List<Item>&, List<Item>&, enum_duplicates, bool))[0x5645751f2a07]
 
sql/sql_parse.cc:4733(mysql_execute_command(THD*))[0x564575218d97]
 
sql/sql_class.h:1810(mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool))[0x56457521e299]
 
sql/sql_parse.cc:1850(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool))[0x56457522033a]
 
sql/sql_parse.cc:1397(do_command(THD*))[0x564575220abe]
 
sql/sql_connect.cc:1402(do_handle_one_connection(CONNECT*))[0x5645752e830f]
 
sql/sql_connect.cc:1310(handle_one_connection)[0x5645752e8434]
 
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba)[0x7f5774b356ba]
 
x86_64/clone.S:111(clone)[0x7f577399a41d]
 
 
 
Trying to get some variables.
 
Some pointers may be invalid and cause the dump to abort.
 
Query (0x7f57080115c0): replace t2(number) values('1')

10.3 839cf16bb2de078d

 
==28966==ERROR: AddressSanitizer: use-after-poison on address 0x62b000000d68 at pc 0x55b7f374ce17 bp 0x7fbc55badfb0 sp 0x7fbc55badfa0
 
READ of size 8 at 0x62b000000d68 thread T27
 
    #0 0x55b7f374ce16 in Item_args::walk_args(bool (Item::*)(void*), bool, void*) /git/10.3/sql/item.h:2190
 
    #1 0x55b7f374dc62 in Item_func_or_sum::walk(bool (Item::*)(void*), bool, void*) /git/10.3/sql/item.h:4692
 
    #2 0x55b7f374ce90 in Item_args::walk_args(bool (Item::*)(void*), bool, void*) /git/10.3/sql/item.h:2190
 
    #3 0x55b7f374dc62 in Item_func_or_sum::walk(bool (Item::*)(void*), bool, void*) /git/10.3/sql/item.h:4692
 
    #4 0x55b7f3b00d52 in fix_session_vcol_expr(THD*, Virtual_column_info*) /git/10.3/sql/table.cc:2886
 
    #5 0x55b7f3734483 in fix_all_session_vcol_exprs /git/10.3/sql/sql_base.cc:5183
 
    #6 0x55b7f3735549 in lock_tables(THD*, TABLE_LIST*, unsigned int, unsigned int) /git/10.3/sql/sql_base.cc:5361
 
    #7 0x55b7f37333ce in open_and_lock_tables(THD*, DDL_options_st const&, TABLE_LIST*, bool, unsigned int, Prelocking_strategy*) /git/10.3/sql/sql_base.cc:5005
 
    #8 0x55b7f36ab239 in open_and_lock_tables(THD*, TABLE_LIST*, bool, unsigned int) /git/10.3/sql/sql_base.h:502
 
    #9 0x55b7f37e0657 in mysql_insert(THD*, TABLE_LIST*, List<Item>&, List<List<Item> >&, List<Item>&, List<Item>&, enum_duplicates, bool) /git/10.3/sql/sql_insert.cc:760
 
    #10 0x55b7f3877ce4 in mysql_execute_command(THD*) /git/10.3/sql/sql_parse.cc:4724
 
    #11 0x55b7f388d598 in mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool) /git/10.3/sql/sql_parse.cc:8091
 
    #12 0x55b7f386805b in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool) /git/10.3/sql/sql_parse.cc:1850
 
    #13 0x55b7f38651f3 in do_command(THD*) /git/10.3/sql/sql_parse.cc:1395
 
    #14 0x55b7f3bb8136 in do_handle_one_connection(CONNECT*) /git/10.3/sql/sql_connect.cc:1402
 
    #15 0x55b7f3bb7b13 in handle_one_connection /git/10.3/sql/sql_connect.cc:1308
 
    #16 0x55b7f4edee08 in pfs_spawn_thread /git/10.3/storage/perfschema/pfs.cc:1862
 
    #17 0x7fbc6d0776b9 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76b9)
 
    #18 0x7fbc6c50c41c in clone (/lib/x86_64-linux-gnu/libc.so.6+0x10741c)

Comment by Philip orleans [ 2018-12-13 ]

This is not the exact same problem as MDEV-16039. That case is about a generated column. This is about a column with an expression as default.
It may be the same cause, though.

Comment by Alice Sherepa [ 2018-12-13 ]

I added a comment there to check this case after the bug will be fixed.

Generated at Thu Feb 08 08:40:38 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.