[Bug 1657256] Re: Percona crashes when doing a a 'larger' update

[Rafael David Tinoco]

Possibly related commits:

commit 40497577ffd9f85557b15e08ad913f627b2e9530
Author: Sergey Vojtovich <svoj at mariadb.org>
Date:   Fri Aug 29 16:02:46 2014 +0400

    Backport from 10.0:

    MDEV-6450 - MariaDB crash on Power8 when built with advance tool
                chain

    InnoDB mutex_exit() function calls __sync_test_and_set() to release
    the lock. According to manual this function is supposed to create
    "acquire" memory barrier whereas in fact we need "release" memory
    barrier at mutex_exit().

    The problem isn't repeatable with gcc because it creates
    "acquire-release" memory barrier for __sync_test_and_set().
    ATC creates just "acquire" barrier.

commit 5569132ffebba3fd2e37964543f658ed24d8caaf
Author: Michael Widenius <monty at mariadb.org>
Date:   Tue Aug 19 19:28:35 2014 +0300

    MDEV-6450 - MariaDB crash on Power8 when built with advance tool
chain

    Part of this work is based on Stewart Smitch's memory barrier and lower priori
    patches for power8.

    - Added memory syncronization for innodb & xtradb for power8.
    - Added HAVE_WINDOWS_MM_FENCE to CMakeList.txt
    - Added os_isync to fix a syncronization problem on power
    - Added log_get_lsn_nowait which is now used srv_error_monitor_thread to ensur
      if log mutex is locked.

    All changes done both for InnoDB and Xtradb

commit 82ce2a2503a95e8bdc76c351a87e98c93445a433
Author: Sergey Vojtovich <svoj at mariadb.org>
Date:   Mon Aug 4 11:55:38 2014 +0400

    MDEV-6450 - MariaDB crash on Power8 when built with advance
                tool chain

    Reverted addition to the original patch:
    InterlockedExchangeAcquire and InterlockedAndRelease are
    supported only on Itanium-based systems.

commit 53360fd45f89e9b16aac69625820988702a339ee
Author: Sergey Vojtovich <svoj at mariadb.org>
Date:   Thu Jul 31 14:31:05 2014 +0400

    MDEV-6450 - MariaDB crash on Power8 when built with advance
                tool chain

    This is an addition to the original patch. On Windows
    InterlockedExchange implies full memory barrier, whereas
    only acquire/release barriers required.

commit c0ebb3f38811c6a0e3e2b49b3ae40b4ea0c2b0e9
Author: Sergey Vojtovich <svoj at mariadb.org>
Date:   Fri Jul 18 15:16:25 2014 +0400

    MDEV-6450 - MariaDB crash on Power8 when built with advance tool
                chain

    InnoDB mutex_exit() function calls __sync_test_and_set() to release
    the lock. According to manual this function is supposed to create
    "acquire" memory barrier whereas in fact we need "release" memory
    barrier at mutex_exit().

    The problem isn't repeatable with gcc because it creates
    "acquire-release" memory barrier for __sync_test_and_set().
    ATC creates just "acquire" barrier.

    Fixed by creating proper barrier at mutex_exit() by using
    __sync_lock_release() instead of __sync_test_and_set().

--------

Mario,

I provided you: http://inaddy.ddns.net:3333/~inaddy/trusty_percona-
xtradb-cluster-5.5_5.5.37-25.10%2bdfsg-0ubuntu0.14.04.3.debdiff based on
this last patch. This was the only patch backport from 10.0.

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1657256

Title:
  Percona crashes when doing a a 'larger' update

Status in percona-xtradb-cluster-5.5 package in Ubuntu:
  In Progress

Bug description:
  I'm trying to set up percona-xtradb-cluster-5.5 on PPC machine. While
  the package installs fine, as soon as I run sysbench oltp becnhmark
  against it, Percona dies (even when I start the benchmark with just
  one connection).

  I can also crash mysql manually, by updating the sbtest table (which
  is created by the sysbench utility):

  mysql> update sbtest set pad = 'mario1' limit 1000000;
  ERROR 2013 (HY000): Lost connection to MySQL server during query

  Sometimes I need to repeat this update (with different values for
  'pad' field) few times. This happens regardless of whether I run the
  UPDATE inside the transaction or not.

  This is the assertion found in the log file:

  170117 21:10:55  InnoDB: Assertion failure in thread 70366668321152 in file buf0buf.ic line 1277
  InnoDB: Failing assertion: block->page.buf_fix_count > 0

  This is a single-node percona-xtradb-cluster server, without
  wsrep_provied configured, run inside 14.04 lxc container on 16.04
  host.

  I'm attaching the full log file, mysql configuration file and the core
  dumped.

  The version of the package installed is this 5.5.37-25.10+dfsg-
  0ubuntu0.14.04.2.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/percona-xtradb-cluster-5.5/+bug/1657256/+subscriptions