[MDEV-6368] assertion xid_seqno > trx_sys_cur_xid_seqno Created: 2014-06-20  Updated: 2021-05-13  Resolved: 2016-06-01

Status: Closed
Project: MariaDB Server
Component/s: Galera
Affects Version/s: 5.5.37-galera, 10.1, 5.5-galera
Fix Version/s: 10.2.1

Type: Bug Priority: Major
Reporter: Daniel Black Assignee: Nirbhay Choubey (Inactive)
Resolution: Fixed Votes: 0
Labels: galera
Environment:

ubuntu precise x86_64

Attachments: File my.cnf     HTML File syslog     File valgrind.mysqld.7706    
Issue Links:
Relates
relates to MDEV-9909 Enable plugins for MTR Closed
Sprint: 10.1.14

 Description   

compiled in debug mode (-DCMAKE_BUILD_TYPE=Debug in debian/rules as argument to cmake)

Jun 20 09:24:29 venus mysqld: 140620  9:24:29  InnoDB: Assertion failure in thread 669300480 in file trx0sys.c line 1005
 
Jun 20 09:24:29 venus mysqld: InnoDB: Failing assertion: xid_seqno > trx_sys_cur_xid_seqno
 
Jun 20 09:24:29 venus mysqld: InnoDB: We intentionally generate a memory trap.



 Comments   
Comment by Nirbhay Choubey (Inactive) [ 2014-06-20 ]

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

Comment by Nirbhay Choubey (Inactive) [ 2014-06-20 ]

I guess the attached valgrind output is linked to MDEV#6300?

Comment by Daniel Black [ 2014-06-21 ]

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.

Comment by Daniel Black [ 2014-07-24 ]

sorry, have been unable to reproduce this.

Comment by Elena Stepanova [ 2016-04-19 ]

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.

Comment by Nirbhay Choubey (Inactive) [ 2016-05-02 ]

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

Comment by Nirbhay Choubey (Inactive) [ 2016-05-03 ]

http://lists.askmonty.org/pipermail/commits/2016-May/009343.html

Comment by Jan Lindström (Inactive) [ 2016-05-03 ]

Latest version ok from me.

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