[MDEV-17597] [Draft] pure virtual method called in or around handler::ha_external_lock upon downgrade from newer 10.2 Created: 2018-11-01  Updated: 2018-11-29  Resolved: 2018-11-29

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

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Elena Stepanova
Resolution: Duplicate Votes: 1
Labels: None

Issue Links:
Duplicate
is duplicated by MDEV-17839 Crash (pure virtual method called) in... Closed

 Description   

https://travis-ci.org/elenst/travis-tests/jobs/446776223

Version: '10.2.18-MariaDB-log'  socket: '/home/travis/logs/current1_1/mysql.sock'  port: 13000  MariaDB Server
pure virtual method called
terminate called without an active exception
181027  4:03:34 [ERROR] mysqld got signal 6 ;
 
Server version: 10.2.18-MariaDB-log
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=5
max_threads=153
thread_count=11
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467249 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x7f0300000a88
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 = 0x7f036414fe80 thread_stack 0x49000
mysys/stacktrace.c:268(my_print_stacktrace)[0x55e34b081e1b]
sql/signal_handler.cc:168(handle_fatal_signal)[0x55e34ab4c9b5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f0367d84330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f03673d7c37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f03673db028]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x155)[0x7f0367ad0535]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5e6d6)[0x7f0367ace6d6]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5e703)[0x7f0367ace703]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5f1bf)[0x7f0367acf1bf]
sql/handler.cc:5895(handler::ha_external_lock(THD*, int))[0x55e34ab55f33]
sql/lock.cc:719(unlock_external)[0x55e34ac12ffb]
sql/lock.cc:429(mysql_unlock_tables(THD*, st_mysql_lock*, bool))[0x55e34ac132bc]
sql/sql_base.cc:844(close_thread_tables(THD*))[0x55e34a984cb7]
sql/sql_parse.cc:6305(mysql_execute_command(THD*))[0x55e34a9c7569]
sql/sql_parse.cc:8011(mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool))[0x55e34a9cf3ca]
sql/sql_parse.cc:1824(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool))[0x55e34a9d17f1]
sql/sql_parse.cc:1380(do_command(THD*))[0x55e34a9d1ddd]
sql/sql_connect.cc:1335(do_handle_one_connection(CONNECT*))[0x55e34aa9210f]
sql/sql_connect.cc:1243(handle_one_connection)[0x55e34aa92234]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f0367d7c184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f036749effd]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7f030000f140): UPDATE `t7` SET `col_char` = 'o' WHERE `pk` = 2099 /* QNO 1275 CON_ID 15 */
Connection ID (thread ID): 15
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

elenst-mdev14046 1348571d03a3b335fe5d772cbbb27c13f24c62e0

perl /home/travis/rqg//runall-new.pl --grammar=conf/mariadb/oltp-transactional.yy --grammar2=conf/mariadb/oltp_and_ddl.yy --gendata=conf/mariadb/innodb_upgrade.zz --gendata-advanced --mysqld=--server-id=111 --scenario=Upgrade --duration=90 --basedir2=/home/travis/old --basedir1=/home/travis/server --mysqld=--innodb-page-size=8K --mysqld=--innodb-compression-algorithm=none --mysqld=--loose-innodb-file-format=Barracuda --mysqld=--loose-innodb-file-per-table=1 --gendata=conf/mariadb/innodb_upgrade.zz --no-mask --seed=1540611984 --threads=4 --queries=100M --mysqld=--loose-max-statement-time=20 --mysqld=--loose-lock-wait-timeout=20 --mysqld=--loose-innodb-lock-wait-timeout=10 --mysqld=--loose-innodb_log_compressed_pages=on --mtr-build-thread=300 --vardir1=/home/travis/logs/current1_1

The downgrade was performed from 10.2 76318d55aa0f5cb2ef5282538d8997b308c48204.

Not reproducible right away.



 Comments   
Comment by Elena Stepanova [ 2018-11-02 ]

marko said on Slack:

This should be a `handler` object with broken vtable. There is a default implementation `handler::external_lock()`, so it shouldn’t be due to that.
`handler::ha_external_lock()` is calling quite a few functions.
I hope it is feasible to test this with ASAN.

Comment by Elena Stepanova [ 2018-11-29 ]

Test cases are in MDEV-14440 and MDEV-17839. The one in MDEV-17839 was derived directly from this test failure.

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