[MDEV-11262] TokuDB assertion failure Created: 2016-11-09  Updated: 2016-12-19  Resolved: 2016-12-19

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - TokuDB
Affects Version/s: 10.1.13
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Hartmut Holzgraefe Assignee: Sergei Golubchik
Resolution: Incomplete Votes: 0
Labels: need_feedback

Attachments: File error.log    

 Description   

/opt/install/mariadb-10.1.13/storage/tokudb/hatoku_cmp.cc:441 cmp_toku_int: Assertion `Handlerton: false ' failed (errno=11)
: Resource temporarily unavailable

The assertion was hit due to the num_bytes parameter not being in the valid range of 1 to 8 bytes.

Backtrace after running through c++filt:

/opt/mariadb-10.1.13/lib/plugin/ha_tokudb.so(db_env_do_backtrace(_IO_FILE*)+0x1b)[0x7f787110063b]
/opt/mariadb-10.1.13/lib/plugin/ha_tokudb.so(+0x837a3)[0x7f78711007a3]
/opt/mariadb-10.1.13/lib/plugin/ha_tokudb.so(toku_get_and_clear_basement_stats(ftnode*)+0x0)[0x7f7871182710]
/opt/mariadb-10.1.13/lib/plugin/ha_tokudb.so(+0x105b08)[0x7f7871182b08]
/opt/mariadb-10.1.13/lib/plugin/ha_tokudb.so(toku_hton_assert_fail(char const*, char const*, char const*, int, int)+0x7e)[0x7f78710c4e4e]
/opt/mariadb-10.1.13/lib/plugin/ha_tokudb.so(+0x5e79a)[0x7f78710db79a]
/opt/mariadb-10.1.13/lib/plugin/ha_tokudb.so(+0x5e8e5)[0x7f78710db8e5]
/opt/mariadb-10.1.13/lib/plugin/ha_tokudb.so(+0xd60e0)[0x7f78711530e0]
/opt/mariadb-10.1.13/lib/plugin/ha_tokudb.so(+0x7fead)[0x7f78710fcead]
/opt/mariadb-10.1.13/lib/plugin/ha_tokudb.so(+0xd2b2f)[0x7f787114fb2f]
/opt/mariadb-10.1.13/lib/plugin/ha_tokudb.so(+0xb4539)[0x7f7871131539]
/opt/mariadb-10.1.13/lib/plugin/ha_tokudb.so(+0xb471d)[0x7f787113171d]
/opt/mariadb-10.1.13/lib/plugin/ha_tokudb.so(toku_db_start_range_lock(__toku_db*, __toku_db_txn*, __toku_dbt const*, __toku_dbt const*, toku::lock_request::type, toku::lock_request*)+0xde)[0x7f7871131e4e]
/opt/mariadb-10.1.13/lib/plugin/ha_tokudb.so(toku_db_get_range_lock(__toku_db*, __toku_db_txn*, __toku_dbt const*, __toku_dbt const*, toku::lock_request::type)+0x46)[0x7f7871132616]
/opt/mariadb-10.1.13/lib/plugin/ha_tokudb.so(toku_db_put(__toku_db*, __toku_db_txn*, __toku_dbt*, __toku_dbt*, unsigned int, bool)+0x112)[0x7f7871159c92]
/opt/mariadb-10.1.13/lib/plugin/ha_tokudb.so(autotxn_db_put(__toku_db*, __toku_db_txn*, __toku_dbt*, __toku_dbt*, unsigned int)+0x46)[0x7f787115d4d6]
/opt/mariadb-10.1.13/lib/plugin/ha_tokudb.so(ha_tokudb::insert_row_to_main_dictionary(unsigned char*, __toku_dbt*, __toku_dbt*, __toku_db_txn*)+0x94)[0x7f78710ca334]
/opt/mariadb-10.1.13/lib/plugin/ha_tokudb.so(ha_tokudb::write_row(unsigned char*)+0x909)[0x7f78710db099]
/opt/mariadb/bin/mysqld(handler::ha_write_row(unsigned char*)+0x147)[0x7f78b741aac7]
/opt/mariadb/bin/mysqld(write_record(THD*, TABLE*, st_copy_info*)+0x6b)[0x7f78b729338b]
/opt/mariadb/bin/mysqld(mysql_load(THD*, sql_exchange*, TABLE_LIST*, List<Item>&, List<Item>&, List<Item>&, enum_duplicates, bool, bool)+0x2164)[0x7f78b752e0b4]
/opt/mariadb/bin/mysqld(mysql_execute_command(THD*)+0x5ba4)[0x7f78b72b0c54]
/opt/mariadb/bin/mysqld(mysql_parse(THD*, char*, unsigned int, Parser_state*)+0x276)[0x7f78b72b4346]
/opt/mariadb/bin/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0x2125)[0x7f78b72b7275]
/opt/mariadb/bin/mysqld(do_command(THD*)+0x161)[0x7f78b72b7c31]
/opt/mariadb/bin/mysqld(do_handle_one_connection(THD*)+0x194)[0x7f78b736b094]
/opt/mariadb/bin/mysqld(handle_one_connection+0x37)[0x7f78b736b267]
/lib64/libpthread.so.0(+0x7df5)[0x7f78b6a56df5]
/lib64/libc.so.6(clone+0x6d)[0x7f78b4e671ad]



 Comments   
Comment by Elena Stepanova [ 2016-11-12 ]

There was a similar upstream bug: https://bugs.launchpad.net/percona-server/+bug/1501633
The stack trace seems to be somewhat different, but the assertion is the same, and importantly the TokuDB version where it was observed is exactly the same (5.6.26-74.0, which corresponds to what we had in MariaDB 10.1.13).
The upstream bug was fixed in the next 5.6.27-75.0. So, if it's indeed the same bug, it should be fixed in the current 10.1.

hholzgra,
What should we do about it? Is it possible to upgrade MariaDB on the instance where the failure was observed, and see if it happens again?

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