Percona Server with XtraDB

InnoDB: Error: semaphore wait has lasted > 600 seconds. InnoDB: We intentionally crash the server, because it appears to be hung. InnoDB: Assertion failure in thread <nr> in file srv0srv.cc line 2124. Abort (sig=6) in srv_error_monitor_thread (III)

Reported by Roel Van de Paar on 2013-10-12
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Server
Status tracked in 5.6
5.1
Undecided
Unassigned
5.5
Undecided
Unassigned
5.6
High
Laurynas Biveinis

Bug Description

This bug (III) on revid 5.6.13-rc60.6-469-debug, seen after Bug 1236696 (II) patch was included. Original was bug 1234426 (I) which was likely a duplicate/symptom of bug 1235285.

This issue is seen in 3 instances with threads=15, and in one instance with threads=1 (!)

Laurynas, attaching 4 different occurrences. Everything is included: stacks, full stacks, vardirs, cores (in vardir tars under /master-data/), binary + ldd.

Tags: qa Edit Tag help

Related branches

lp:~laurynas-biveinis/percona-server/bug1239062
Merged into lp:percona-server at revision 503
Stewart Smith (community): Approve on 2013-11-29
Vlad Lesin: Approve (g2) on 2013-11-06
description: updated
description: updated
description: updated
Roel Van de Paar (roel11) wrote :

Large attachment uploading, which has 4 occurrences as described above. One has --threads=1 only!

description: updated
Roel Van de Paar (roel11) wrote :

3 Failed uploads to LP. Tried GG drive via email and worked first time. Laurynas, please ref email.

No relation to the priority mutexes / RW locks.

Roel -

Please check if this is reproducible with lp:~laurynas-biveinis/percona-server/bug1239062-exp, rev 483.

    The issue is the backoff loop in
    log_preflush_pool_modified_pages() turning into an infinite loop
    when the function is called with dirty buffer pool, the innermost
    loop enters, and a buffer pool flush list flush that fully cleans
    the pool starts and fully completes before the next
    buf_flush_list_in_progress() check. Then that check will keep on
    returning false until something dirties the buffer pool (which
    may never happen on startup/shutdown/set workload).

    This is not very likely to occur on realistic workloads, but more
    likely in MTR testcases (by a combination of small buffer pools,
    deterministic workloads, innodb_checkpoint_now, etc.)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers