Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Assertion failure in file rem0rec.cc : line 580, is it schema related ?

Description

Hi,

We encountered crashes with our Xtradb Clusters (5.6.44) : assertions failure in file rem0rec line 580
The exact same situation of https://bugs.launchpad.net/percona-x...r/+bug/1589919, the stacktrace is identical

Now, if I can believe the stacktrace it crashed while deleting row, and it looks related to foreign keys stuff

I looked into the schema and noticed :

  • I had ~40 tables without primary keys (innodb)

  • Some of them even have ON DELETE CASCADE FK constraints


Galera does not support DELETE without primary keys, so it make sense it should not support ON DELETE CASCADE on tables without primary keys ?

It looks like it work (I guess thanks to wsrep_certify_nonpk and an internal PK), and we know this kind of queries are being made everyday without apparent issues, but I wonder if this is a valid concern regarding this assertion failure crash

If someone is willing to dig into this crash, I'm available

(this is a repost of my forum entry, sorry for duplicatas)

Thank you,

Environment

None

Attachments

1
  • 26 Aug 2019, 01:18 PM

Smart Checklist

Activity

Show:

Jira Bot April 4, 2020 at 10:56 AM

Hello ,
It's been 52 days since this issue went into Incomplete and we haven't heard
from you on this.

At this point, our policy is to Close this issue, to keep things from getting
too cluttered. If you have more information about this issue and wish to
reopen it, please reply with a comment containing "jira-bot=reopen".

Jira Bot March 27, 2020 at 10:56 AM

Hello ,
It's jira-bot again. Your bug report is important to us, but we haven't heard
from you since the previous notification. If we don't hear from you on
this in 7 days, the issue will be automatically closed.

Jira Bot March 12, 2020 at 9:56 AM

Hello ,
I'm jira-bot, Percona's automated helper script. Your bug report is important
to us but we've been unable to reproduce it, and asked you for more
information. If we haven't heard from you on this in 3 more weeks, the issue
will be automatically closed.

Lalit Choudhary February 12, 2020 at 9:37 AM

Hi

https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1589919

https://jira.mariadb.org/browse/MDEV-11131

these are the related report similar to this bug, but so not a reproducible test case.

As you mentioned it happens when you run delete operation, can you provide a reproduciable test case?

You try to create the same on a test environment with similar mysql configuration and tables.

La Cancellera Yoann January 20, 2020 at 2:34 PM

Hi

Happened again today with 5.6.46. This time I do not have any myisam tables, but I do have innodb fulltexts indexes

Stacktrace is identical :

0x92c63b my_print_stacktrace + 59
0x691faa handle_fatal_signal + 1178
0x7fd22aa47390 _end + 694620744
0x7fd229e00428 _end + 681747168
0x7fd229e0202a _end + 681754338
0xa08bd6 sym_tab_rebind_lit(sym_node_t*, void const*, unsigned long) + 23046
0xa0b34e wsrep_rec_get_foreign_key(unsigned char*, unsigned long*, unsigned char const*, dict_index_t*, dict_index_t*, unsigned long) + 126
0x987a2b wsrep_append_foreign_key(trx_t*, dict_foreign_t*, unsigned char const*, dict_index_t*, unsigned long, wsrep_key_type) + 1243
0xa195d9 std::vector<FetchIndexRootPages::Index, std::allocator<FetchIndexRootPages::Index> >::M_insert_aux(gnu_cxx::_normal_iterator<FetchIndexRootPages::Index*, std::vector<FetchIndexRootPages::Index, std::allocator<FetchIndexRootPages::Index> > >, FetchIndexRootPages::Index const&) + 14217
0xa436e7 std::vector<dict_col_t const*, std::allocator<dict_col_t const*> >::push_back(dict_col_t const* const&) + 3735
0xa48689 std::vector<dict_col_t const*, std::allocator<dict_col_t const*> >::push_back(dict_col_t const* const&) + 24121
0xa4912f std::vector<dict_col_t const*, std::allocator<dict_col_t const*> >::push_back(dict_col_t const* const&) + 26847
0xa2ab96 row_decompress_column(unsigned char const*, unsigned long*, unsigned char const*, unsigned long, row_prebuilt_t*) + 13590
0x989813 ha_innobase::wsrep_append_keys(THD*, wsrep_key_type, unsigned char const*, unsigned char const*) + 5539
0x5dbf2b handler::ha_delete_row(unsigned char const*) + 171
0x86399f mysql_delete(THD*, TABLE_LIST*, Item*, SQL_I_List<st_order>*, unsigned long long, unsigned long long) + 4271
0x71b30f mysql_execute_command(THD*) + 19583
0x71fad8 mysql_parse(THD*, char*, unsigned int, Parser_state*, bool) + 1256
0x7203b4 handle_bootstrap + 196
0x7232c8 dispatch_command(enum_server_command, THD*, char*, unsigned int) + 9800
0x724ce4 do_command(THD*) + 580
0x6e8482 do_handle_one_connection(THD*) + 386
0x6e8690 handle_one_connection + 64
0x964da6 pfs_spawn_thread + 326

 

Is there anything specific to check ?

Incomplete

Details

Assignee

Reporter

Affects versions

Priority

Smart Checklist

Created August 22, 2019 at 8:52 AM
Updated March 6, 2024 at 10:07 PM
Resolved April 4, 2020 at 10:56 AM