Nirbhay Choubey (Inactive) added a comment - 2014-06-20 15:35 Is it reproducible in normal conditions? My builds are all 'Debug' and I have so far not noticed this. Do you have a reproducible test case? I see a similar issue reported here : https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1282034

Nirbhay Choubey (Inactive) added a comment - 2014-06-20 15:36 I guess the attached valgrind output is linked to MDEV#6300?

Daniel Black added a comment - 2014-06-21 02:45 It was reproducible in the scene that the same syslog output occurred on every restart. I reverted to a standard build and am running valgrind to find data for #6300 on this server currently. I can start to looking at this bug after the memleak. If I get a gdb breakpoint at the assert line number if there any particular data structures to print out? Any other early configuration items I can try? Though the valgrind output was attempting to find the resolution to #6300 the server didn't really start or get the application interaction to get required to examine the #6300 for that memory leak.

Daniel Black added a comment - 2014-07-24 03:58 sorry, have been unable to reproduce this.

Elena Stepanova added a comment - 2016-04-19 20:08 - edited One easy way to reproduce the assertion failure is to run sys_vars.wsrep_start_position_basic with --innodb : perl ./mtr sys_vars.wsrep_start_position_basic --mysqld=--innodb ... CURRENT_TEST: sys_vars.wsrep_start_position_basic mysqltest: At line 17: query 'SET @@global.wsrep_start_position='00000000-0000-0000-0000-000000000000:-1'' failed: 2013: Lost connection to MySQL server during query 160419 23:04:12 InnoDB: Assertion failure in thread 140642953611008 in file trx0sys.c line 1002 InnoDB: Failing assertion: xid_seqno > trx_sys_cur_xid_seqno InnoDB: We intentionally generate a memory trap. However, the stack trace looks totally different: Stack trace from 5.5-galera commit 9c89b84d46e0645820acb9e3cc339af10c68cfb7 #5 0x00007fe9fba5d538 in abort () from /lib64/libc.so.6 #6 0x0000000000a227b5 in trx_sys_update_wsrep_checkpoint (xid=0x7fe9fd4a1eb0, sys_header=0x7fe9f7fdc026 "", mtr=0x7fe9fd4a1410) at /src/5.5-galera/storage/xtradb/trx/trx0sys.c:1002 #7 0x00000000009a0bec in innobase_wsrep_set_checkpoint (hton=0x7fe9fb7edc60, xid=0x7fe9fd4a1eb0) at /src/5.5-galera/storage/xtradb/handler/ha_innodb.cc:14381 #8 0x000000000078478d in set_SE_checkpoint (unused=0x0, plugin=0x7fe9fd4a1e38, arg=0x7fe9fd4a1eb0) at /src/5.5-galera/sql/wsrep_mysqld.cc:178 #9 0x000000000064407d in plugin_foreach_with_mask (thd=0x0, func=0x784644 <set_SE_checkpoint(THD*, plugin_ref, void*)>, type=1, state_mask=4294967287, arg=0x7fe9fd4a1eb0) at /src/5.5-galera/sql/sql_plugin.cc:2344 #10 0x00000000007847c2 in wsrep_set_SE_checkpoint (xid=0x7fe9fd4a1eb0) at /src/5.5-galera/sql/wsrep_mysqld.cc:185 #11 0x0000000000790959 in wsrep_set_local_position (value=0x7fe9eca169e0 "00000000-0000-0000-0000-", '0' <repeats 12 times>, ":-1") at /src/5.5-galera/sql/wsrep_var.cc:152 #12 0x00000000007909e2 in wsrep_start_position_update (self=0x1550de0 <Sys_wsrep_start_position>, thd=0x7fe9eee1ff20, type=OPT_GLOBAL) at /src/5.5-galera/sql/wsrep_var.cc:160 #13 0x0000000000597b94 in sys_var::update (this=0x1550de0 <Sys_wsrep_start_position>, thd=0x7fe9eee1ff20, var=0x7fe9eca722d8) at /src/5.5-galera/sql/set_var.cc:200 #14 0x0000000000598c02 in set_var::update (this=0x7fe9eca722d8, thd=0x7fe9eee1ff20) at /src/5.5-galera/sql/set_var.cc:667 #15 0x00000000005987c9 in sql_set_variables (thd=0x7fe9eee1ff20, var_list=0x7fe9eee24120) at /src/5.5-galera/sql/set_var.cc:570 #16 0x000000000062ffea in mysql_execute_command (thd=0x7fe9eee1ff20) at /src/5.5-galera/sql/sql_parse.cc:3630 #17 0x0000000000638987 in mysql_parse (thd=0x7fe9eee1ff20, rawbuf=0x7fe9eca72078 "SET @@global.wsrep_start_position='00000000-0000-0000-0000-", '0' <repeats 12 times>, ":-1'", length=75, parser_state=0x7fe9fd4a3250) at /src/5.5-galera/sql/sql_parse.cc:6521 #18 0x00000000006381d4 in wsrep_mysql_parse (thd=0x7fe9eee1ff20, rawbuf=0x7fe9eca72078 "SET @@global.wsrep_start_position='00000000-0000-0000-0000-", '0' <repeats 12 times>, ":-1'", length=75, parser_state=0x7fe9fd4a3250) at /src/5.5-galera/sql/sql_parse.cc:6354 #19 0x0000000000629c18 in dispatch_command (command=COM_QUERY, thd=0x7fe9eee1ff20, packet=0x7fe9eefa5b61 "SET @@global.wsrep_start_position='00000000-0000-0000-0000-", '0' <repeats 12 times>, ":-1'", packet_length=75) at /src/5.5-galera/sql/sql_parse.cc:1248 #20 0x0000000000628874 in do_command (thd=0x7fe9eee1ff20) at /src/5.5-galera/sql/sql_parse.cc:885 #21 0x000000000072fad7 in do_handle_one_connection (thd_arg=0x7fe9eee1ff20) at /src/5.5-galera/sql/sql_connect.cc:1286 #22 0x000000000072f856 in handle_one_connection (arg=0x7fe9eee1ff20) at /src/5.5-galera/sql/sql_connect.cc:1199 #23 0x0000000000cbbff0 in pfs_spawn_thread (arg=0x7fe9eee2b860) at /src/5.5-galera/storage/perfschema/pfs.cc:1015 #24 0x00007fe9fd11d0a4 in start_thread () from /lib64/libpthread.so.0 #25 0x00007fe9fbb0c04d in clone () from /lib64/libc.so.6 nirbhay_c , if you think it's a different problem, please feel free to convert it into a separate bug report, or tell me to do so. Reproducible on current 10.1 too. I didn't try 10.0, but I assume it wouldn't go anywhere there.

Nirbhay Choubey (Inactive) added a comment - 2016-05-02 22:38 jplindst The patch is a bit large and touches some key parts so I have also asked Seppo and Teemu for their opinion. http://lists.askmonty.org/pipermail/commits/2016-May/009338.html

Nirbhay Choubey (Inactive) added a comment - 2016-05-03 15:08 http://lists.askmonty.org/pipermail/commits/2016-May/009343.html

Jan Lindström (Inactive) added a comment - 2016-05-03 18:37 Latest version ok from me.