I’ve filed this as:
Please note that these systems are not officially supported, as per:
MySQL Community Manager
Oracle Canada - Hardware and Software, Engineered to Work Together.
Office: Toronto, Canada
On May 2, 2014, at 3:29 PM, Stewart Smith <stewart@stripped> wrote:
> Hi all,
> seeing as the page to register an account for filing a MySQL bug doesn't
> work (even from a text based browser) and just times out or gives a 500
> Internal Server Error.... I'll "file" this one here.
> So, at least for MySQL 5.6 (I haven't looked at previous versions, but I
> strongly suspect the last few have this as well), the code in
> sync0sync.ic for manipulating and loocking at mutex->lock_word is
> missing a barrier.
> This would affect multi CPU systems of both POWER and ARM (although I
> haven't tried on ARM). I could incredibly reliably reproduce on a POWER8
> system but likely also hit on POWER7.
> I've reproduced *very* reliably with a frest MySQL 5.6.17 build (from
> source) on a big endian host (e.g. Fedora) with a simple mysqlslap run:
> mysqlslap --concurrency=128 --iterations=2 --number-int-cols=2
> --number-char-cols=3 --auto-generate-sql --number-of-queries=10000
> (this could probably be paired down)
> What's interesting to note is that the test suite passes but a simple
> very small stress test like the above makes the server hit an assert in
> the InnoDB list code (in create read view) that's protected by.. yep,
> one of these mutexes. Obviously nobody's hammering this too hard on
> multicore ARM yet.
> If you disable the use of GCC atomics for these mutexes and instead fall
> back to pthread mutex, it all works fine.
> The fix is fairly simple:
> 1) ib_mutex_test_and_set needs a __sync_synchronize() before the call to
> 2) mutex_reset_lock_word needs a __sync_synchronize() before
> os_atomic_test_and_set_byte() call
> 3) and __sync_synchronize() is needed after the read in
> The barriers aren't required on x86.
> MariaDB, Percona Server and Percona XtraBackup are probably also
> affected, although I haven't tried these.
> MySQL Internals Mailing List
> For list archives: http://lists.mysql.com/internals
> To unsubscribe: http://lists.mysql.com/internals