Assert in Diagnostics_area::sql_errno()
Bug #425115 reported by
Seppo Jaakola
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MySQL patches by Codership |
Fix Released
|
High
|
Seppo Jaakola |
Bug Description
Running high conflict rate load against 2 node cluster causes assert with current 5.1.37 merged trunk version.
Here is the assert:
mysqld: sql_class.h:1178: uint Diagnostics_
090906 11:44:08 - mysqld got signal 6 ;
Load is 70/30 update transactions for one table with 10 rows.
Here is load:
~/sqlgen --user=root --password=rootpass --port=3306 --host=ardennes --host=batak --create=0 --tables=1 --rows=10 --selects=70 --updates=30 --duration=20 --trans-min=1 --trans-max=5 --users=8
Related branches
Changed in codership-mysql: | |
status: | In Progress → Fix Committed |
Changed in codership-mysql: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
Here is debug level log from asserting node:
WSREP BF kill, with seqno: 41069 c:mm_galera_ post_rollback( ):1460: trx st c:mm_galera_ post_rollback( ):1460: trx st area::sql_ errno() const: Assertion `m
090906 11:44:08 [Warning] Aborting query: UPDATE comm00 SET x = (x + 1) % 65537,
y = ((y*x % 65537) + (54078*y % 65537) + (y*z % 65537)) % 65537, z = ((z*x % 65
537) + (z*y % 65537) + (54078*z % 65537)) % 65537, r = 0.898559 WHERE p = 9
090906 11:44:08 [Note] WSREP kill trx QUERY_EXEC for 164679
090906 11:44:08 [Warning] WSREP kill query for: -1499456624
090906 11:44:08 [Note] DEBUG: mm_galera.
ate: 0 at galera_rolledback for: 9223372036854775807
090906 11:44:08 [Note] WSREP in dispatch_command, aborting UPDATE comm00 SET x =
(x + 1) % 65537, y = ((y*x % 65537) + (54078*y % 65537) + (y*z % 65537)) % 6553
7, z = ((z*x % 65537) + (z*y % 65537) + (54078*z % 65537)) % 65537, r = 0.898559
WHERE p = 9
090906 11:44:08 [Note] DEBUG: mm_galera.
ate: 0 at galera_rolledback for: 9223372036854775807
mysqld: sql_class.h:1178: uint Diagnostics_
_status == DA_ERROR' failed.
090906 11:44:08 - 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.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.
key_buffer_ size=8384512 size=131072 connections= 10 size)*max_ threads = 337751 K
read_buffer_
max_used_
max_threads=151
threads_connected=6
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd: 0xa912d80 c:process_ query_write_ set_applying( ):856 job_queue. c:job_queue_ end_job( ):189: job: 0 c:mm_galera_ recv(): 1223: worker: 0 with c:process_ query_write_ set():904: remote job_queue. c:job_queue_ start_job( ):146: job: c:process_ query_write_ set_applying( ):856 job_queue. c:job_queue_ end_job( ):189: job: 0 c:mm_galera_ pre_commit( ):1559: trx is mi c:mm_galera_ recv(): 1223: worker: 0 with read_next_ block() :612: could not read full read_next_ block() :612: c...
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...
090906 11:44:08 [Note] DEBUG: mm_galera.
: GALERA ws commit for: 46424 41069
090906 11:44:08 [Note] DEBUG: galera_
complete
090906 11:44:08 [Note] DEBUG: mm_galera.
seqno: (46425 - 41070) type: GCS_ACT_TORDERED recvd
090906 11:44:08 [Note] DEBUG: mm_galera.
trx seqno: 46425 41070 last_seen_trx: 46424 46425, cert: 0
090906 11:44:08 [Note] DEBUG: galera_
0 starting
090906 11:44:08 [Note] DEBUG: mm_galera.
: GALERA ws commit for: 46425 41070
090906 11:44:08 [Note] DEBUG: galera_
complete
090906 11:44:08 [Note] DEBUG: mm_galera.
ssing from galera: 164690
090906 11:44:08 [Note] DEBUG: mm_galera.
seqno: (46426 - 41071) type: GCS_ACT_TORDERED recvd
090906 11:44:08 [Note] DEBUG: local.c:
cache block, last:20802 cur:20802
090906 11:44:08 [Note] DEBUG: local.c: