[MDEV-11526] Server crashes in in TABLE::init Created: 2016-12-10  Updated: 2017-02-09  Resolved: 2017-02-09

Status: Closed
Project: MariaDB Server
Component/s: Virtual Columns
Affects Version/s: None
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Sergei Golubchik
Resolution: Cannot Reproduce Votes: 0
Labels: 10.2-rc

Attachments: File testcase2.test    
Issue Links:
Relates
relates to MDEV-5800 indexes on virtual (not materialized)... Closed

 Description   

The test case is attached.
It's a bit different from MDEV-11525, although equally ugly, the reasons and disclaimers are the same.
This one needs to be run with --repeat=N, if it does not fail right away.

bb-10.2-vcols b584734d242e7c56647889e5e9c97e4a11ab5e52

 
#3  <signal handler called>
 
#4  0x00007fc12b9aa636 in TABLE::init (this=0x7fc102cd9c70, thd=0x7fc102c16070, tl=0x7fc102c641b8) at /data/src/bb-10.2-vcols/sql/table.cc:4443
 
#5  0x00007fc12b8386f9 in open_table (thd=0x7fc102c16070, table_list=0x7fc102c641b8, ot_ctx=0x7fc12c9ce070) at /data/src/bb-10.2-vcols/sql/sql_base.cc:1921
 
#6  0x00007fc12b83af57 in open_and_process_table (thd=0x7fc102c16070, lex=0x7fc102c19a80, tables=0x7fc102c641b8, counter=0x7fc12c9ce158, flags=0, prelocking_strategy=0x7fc12c9ce170, has_prelocking_list=false, ot_ctx=0x7fc12c9ce070) at /data/src/bb-10.2-vcols/sql/sql_base.cc:3397
 
#7  0x00007fc12b83c049 in open_tables (thd=0x7fc102c16070, options=..., start=0x7fc12c9ce128, counter=0x7fc12c9ce158, flags=0, prelocking_strategy=0x7fc12c9ce170) at /data/src/bb-10.2-vcols/sql/sql_base.cc:3910
 
#8  0x00007fc12b961957 in open_tables (thd=0x7fc102c16070, tables=0x7fc12c9ce128, counter=0x7fc12c9ce158, flags=0, prelocking_strategy=0x7fc12c9ce170) at /data/src/bb-10.2-vcols/sql/sql_base.h:236
 
#9  0x00007fc12b977def in mysql_alter_table (thd=0x7fc102c16070, new_db=0x7fc102c647c0 "test", new_name=0x0, create_info=0x7fc12c9cfa50, table_list=0x7fc102c641b8, alter_info=0x7fc12c9cf9a0, order_num=0, order=0x0, ignore=false) at /data/src/bb-10.2-vcols/sql/sql_table.cc:8615
 
#10 0x00007fc12b9efa23 in Sql_cmd_alter_table::execute (this=0x7fc102c648e0, thd=0x7fc102c16070) at /data/src/bb-10.2-vcols/sql/sql_alter.cc:324
 
#11 0x00007fc12b8b2168 in mysql_execute_command (thd=0x7fc102c16070) at /data/src/bb-10.2-vcols/sql/sql_parse.cc:6116
 
#12 0x00007fc12b8b6a44 in mysql_parse (thd=0x7fc102c16070, rawbuf=0x7fc102c64088 "ALTER TABLE `CC` ADD KEY rkr_index_1 ( `col_varchar_nokey` )", length=60, parser_state=0x7fc12c9d0dd0, is_com_multi=false, is_next_command=false) at /data/src/bb-10.2-vcols/sql/sql_parse.cc:7790
 
#13 0x00007fc12b8a4794 in dispatch_command (command=COM_QUERY, thd=0x7fc102c16070, packet=0x7fc102e21071 "ALTER TABLE `CC` ADD KEY rkr_index_1 ( `col_varchar_nokey` )", packet_length=60, is_com_multi=false, is_next_command=false) at /data/src/bb-10.2-vcols/sql/sql_parse.cc:1799
 
#14 0x00007fc12b8a316e in do_command (thd=0x7fc102c16070) at /data/src/bb-10.2-vcols/sql/sql_parse.cc:1359
 
#15 0x00007fc12b9ea77a in do_handle_one_connection (connect=0x7fc1284754b0) at /data/src/bb-10.2-vcols/sql/sql_connect.cc:1354
 
#16 0x00007fc12b9ea507 in handle_one_connection (arg=0x7fc1284754b0) at /data/src/bb-10.2-vcols/sql/sql_connect.cc:1260
 
#17 0x00007fc12bd2670c in pfs_spawn_thread (arg=0x7fc115fe7770) at /data/src/bb-10.2-vcols/storage/perfschema/pfs.cc:1862
 
#18 0x00007fc12aeda0a4 in start_thread (arg=0x7fc12c9d2300) at pthread_create.c:309
 
#19 0x00007fc128e8787d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111



 Comments   
Comment by Elena Stepanova [ 2017-01-02 ]

Also reproducible on bb-10.2-monty as of 349d69e2e

Comment by Sergei Golubchik [ 2017-02-08 ]

I don't seem to be able to repeat it in the latest bb-10.2-serg (as of 8884b88a131)

Comment by Elena Stepanova [ 2017-02-09 ]

It disappeared from bb-10.2-serg starting from this revision:

commit 8884b88a131201caee965ddbe3d43d392c44d1e3
 
Author: Sergei Golubchik <serg@mariadb.org>
 
Date:   Mon Feb 6 23:52:47 2017 +0100
 
 
 
    MDEV-11640 gcol.gcol_select_myisam fails in buildbot on Power
 
    
    JOIN_CACHE's were initialized in  check_join_cache_usage()
 
    from make_join_readinfo(). After that make_join_readinfo() was looking
 
    whether it's possible to use keyread. Later, after make_join_readinfo(),
 
    optimizer decided whether to use filesort. And even later, at the
 
    execution time, from join_read_first(), keyread was actually enabled.
 
    
    The problem is, that if a query uses a vcol, base columns that it
 
    depends on are automatically added to the read_set - because they're
 
    needed to calculate the vcol. But if we're doing keyread, vcol is taken
 
    from the index, not calculated, and base columns do not need to  be
 
    in the read set (even should not be - as they aren't getting values).
 
    
    The bug was that JOIN_CACHE used read_set with base columns,
 
    they were not read because of keyread, so it was caching garbage.
 
    
    So read_set is only known after the keyread was decided. And after the
 
    filesort was decided, as filesort doesn't use keyread. But
 
    check_join_cache_usage() needs to be done in make_join_readinfo(),
 
    as the code below depends on these checks,
 
    
    Fix: keep JOIN_CACHE checks where they were, but move initialization
 
    down to the very end of JOIN::optimize_inner. If keyread was enabled,
 
    update the read_set to include only columns that are part of the index.
 
    Copy the keyread logic from join_read_first() to happen at optimize time.

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