| Bug #86149 | MySQL Group Replication Crash - Failing assertion: !cursor->index->is_committed | ||
|---|---|---|---|
| Submitted: | 1 May 2017 17:00 | Modified: | 1 Jun 2017 18:13 |
| Reporter: | Kenny Gryp | Email Updates: | |
| Status: | No Feedback | Impact on me: | |
| Category: | MySQL Server: Group Replication | Severity: | S3 (Non-critical) |
| Version: | 5.7.17 | OS: | CentOS |
| Assigned to: | CPU Architecture: | Any | |
[1 May 2017 17:00]
Kenny Gryp
[1 May 2017 17:01]
Kenny Gryp
.
[1 May 2017 18:13]
MySQL Verification Team
Thank you for the bug report. To file a bug is asked to test the issue with our last released version which is currently 5.7.18, also you didn't mention if from your side you tried what the log error recommend: "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. Attempting to collect some information that could help diagnose the problem. As this is a crash and something is definitely wrong, the information collection process might fail.". Regarding repeatable test case how QA could test the fix done?, very hard for development and QA could do a fix without repeatable test case. Thanks.
[2 Jun 2017 1:00]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".
[21 Jan 2022 2:55]
zhijun long
2022-01-20 16:56:51 0x7f7ebdd3d700 InnoDB: Assertion failure in thread 140182327383808 in file row0ins.cc line 288 InnoDB: Failing assertion: !cursor->index->is_committed() InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 08:56:51 UTC - 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. Attempting to collect some information that could help diagnose the problem. As this is a crash and something is definitely wrong, the information collection process might fail. key_buffer_size=16777216 read_buffer_size=262144 max_used_connections=3900 max_threads=0 thread_count=1655 connection_count=1655 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 154509 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x7f7e75f28000 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 = 7f7ebdd3b4f0 thread_stack 0x40000 /usr/local/mysql/bin/mysqld(my_print_stacktrace+0x3c)[0xe4a9ec] /usr/local/mysql/bin/mysqld(handle_fatal_signal+0x509)[0x66eb79] /lib64/libpthread.so.0(+0xf700)[0x7f84bcad5700] /lib64/libc.so.6(gsignal+0x37)[0x7f84bb2a54e7] /lib64/libc.so.6(abort+0x148)[0x7f84bb2a6bd8] /usr/local/mysql/bin/mysqld[0x615810] /usr/local/mysql/bin/mysqld[0x5fdbd5] /usr/local/mysql/bin/mysqld(_Z23row_ins_sec_index_entryP12dict_index_tP8dtuple_tP9que_thr_tb+0x12d)[0xf5c7bd] /usr/local/mysql/bin/mysqld(_Z12row_ins_stepP9que_thr_t+0x19c)[0xf5cd9c] /usr/local/mysql/bin/mysqld[0xf6a6bc] /usr/local/mysql/bin/mysqld(_ZN11ha_innobase9write_rowEPh+0x252)[0xe983c2] /usr/local/mysql/bin/mysqld(_ZThn1384_N11ha_innopart17write_row_in_partEjPh+0x6a)[0xeaa1da] /usr/local/mysql/bin/mysqld(_ZN16Partition_helper12ph_write_rowEPh+0xf3)[0xb2cc03] /usr/local/mysql/bin/mysqld(_ZN7handler12ha_write_rowEPh+0x1e8)[0x6c8058] /usr/local/mysql/bin/mysqld(_Z12write_recordP3THDP5TABLEP9COPY_INFOS4_+0x675)[0xd80d25] /usr/local/mysql/bin/mysqld(_ZN14Sql_cmd_insert12mysql_insertEP3THDP10TABLE_LIST+0x899)[0xd81dd9] /usr/local/mysql/bin/mysqld(_ZN14Sql_cmd_insert7executeEP3THD+0xf2)[0xd827c2] /usr/local/mysql/bin/mysqld(_Z21mysql_execute_commandP3THDb+0xacd)[0xbd5b1d] /usr/local/mysql/bin/mysqld(_Z11mysql_parseP3THDP12Parser_state+0x2ed)[0xbdc6bd] /usr/local/mysql/bin/mysqld(_Z16dispatch_commandP3THDPK8COM_DATA19enum_server_command+0x201b)[0xbde8fb] /usr/local/mysql/bin/mysqld(_Z10do_commandP3THD+0x267)[0xbdf6d7] /usr/local/mysql-5.7.32-2-linux-x86_64/lib/plugin/threadpool.so(_Z26threadpool_process_requestP3THD+0xf3)[0x7f84bce89e33] /usr/local/mysql-5.7.32-2-linux-x86_64/lib/plugin/threadpool.so(+0x5cf5)[0x7f84bce8acf5] /usr/local/mysql/bin/mysqld(pfs_spawn_thread+0x164)[0x1172e14] /lib64/libpthread.so.0(+0x7e15)[0x7f84bcacde15] /lib64/libc.so.6(clone+0x6d)[0x7f84bb370f9d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (7f7f9c963838): is an invalid pointer Connection ID (thread ID): 103506335 Status: NOT_KILLED
[9 May 2024 11:15]
jinwei shen
2024-04-01T15:14:07.284740Z 119 [ERROR] [MY-013183] [InnoDB] Assertion failure: row0ins.cc:268:!cursor->index->is_committed() thread 281472136103936 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 2024-04-01T15:14:07Z UTC - mysqld got signal 6 ; Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware. BuildID[sha1]=fed0db3c573e3e48dbf861d2a838447e5a71ae5a Thread pointer: 0xffff977c8000 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 = ffff56afbf58 thread_stack 0x100000 /data/percona/sql/bin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x44) [0x1a2c324] /data/percona/sql/bin/mysqld(print_fatal_signal(int)+0x358) [0xfabc18] /data/percona/sql/bin/mysqld(my_server_abort()+0x8c) [0xfabd0c] /data/percona/sql/bin/mysqld(my_abort()+0x14) [0x1a2ad64] /data/percona/sql/bin/mysqld(ut_dbg_assertion_failed(char const*, char const*, unsigned long)+0x188) [0x1af98f8] /data/percona/sql/bin/mysqld(row_ins_sec_index_entry_low(unsigned int, unsigned long, dict_index_t*, mem_block_info_t*, mem_block_info_t*, dtuple_t*, unsigned long, que_thr_t*, bool)+0xfd4) [0x832b14] /data/percona/sql/bin/mysqld(row_ins_sec_index_entry(dict_index_t*, dtuple_t*, que_thr_t*, bool)+0x968) [0x826cc8] /data/percona/sql/bin/mysqld() [0x867f00] /data/percona/sql/bin/mysqld(row_upd_step(que_thr_t*)+0x204) [0xbb9cc4] /data/percona/sql/bin/mysqld() [0x85ebb0] /data/percona/sql/bin/mysqld(ha_innobase::update_row(unsigned char const*, unsigned char*)+0x170) [0xbb8d90] /data/percona/sql/bin/mysqld(ha_innopart::update_row_in_part(unsigned int, unsigned char const*, unsigned char*)+0x40) [0x1a70cc0] /data/percona/sql/bin/mysqld() [0x1a747fc] /data/percona/sql/bin/mysqld(handler::ha_update_row(unsigned char const*, unsigned char*)+0x144) [0xbb8ab4] /data/percona/sql/bin/mysqld(Sql_cmd_update::update_single_table(THD*)+0x768) [0xd42c28] /data/percona/sql/bin/mysqld(Sql_cmd_dml::execute(THD*)+0x550) [0x86aa10] /data/percona/sql/bin/mysqld(mysql_execute_command(THD*, bool)+0xb14) [0x7bd534] /data/percona/sql/bin/mysqld(dispatch_sql_command(THD*, Parser_state*)+0x3f0) [0x8aa7b0] /data/percona/sql/bin/mysqld(dispatch_command(THD*, COM_DATA const*, enum_server_command)+0xb04) [0x8fae24] /data/percona/sql/bin/mysqld(do_command(THD*)+0x470) [0x8f86f0] /data/percona/sql/bin/mysqld() [0x8f4bb8] /data/percona/sql/bin/mysqld() [0xa91920] /usr/lib64/libpthread.so.0(+0x87ac) [0xffffaae067ac] /usr/lib64/libc.so.6(+0xd547c) [0xffffaa91847c] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (ffff616d5838): UPDATE tt_24_p SET t3 = false WHERE ipkey >= 75571 AND ipkey >= 467975 Connection ID (thread ID): 119 Status: NOT_KILLED
[9 May 2024 11:16]
jinwei shen
this bug also exists in MySQL 8.0.32
[25 Jun 2024 11:02]
Gal Cohen
We also see this issue in 8.0.34, we see it in envs where we can not reproduce it. Do you know if it was addressed?
[25 Jun 2024 11:02]
Gal Cohen
We also see this issue in 8.0.34, we see it in envs where we can not reproduce it. Do you know if it was addressed?
