List:Internals« Previous MessageNext Message »
From:Michael Widenius Date:November 29 2008 4:13am
Subject:Re: more on deadlocks in 5.1bzr MySQL code
View as plain text  

>>>>> "MARK" == MARK CALLAGHAN <mdcallag@stripped> writes:

MARK> On Thu, Nov 27, 2008 at 10:58 AM, Michael Izioumtchenko
MARK> <michael.izioumtchenko@stripped> wrote:
>> Hi,
>> here's another occurrence, see below. I have a few questions:
>> - is the problems about the deadlocks in mysql-stress-test in 5.1.31 known?
>> If so is there a bug number for it?
>> - given a coredump, do you happen to know if there's a way to extract
>> anything useful from thread stack
>> that gdb shows like this:
>> Thread 8 (process 3650):
>> #0  0x007c37a2 in _dl_sysinfo_int80 () from /lib/
>> #1  0x00a3730e in __lll_mutex_lock_wait () from /lib/tls/
>> #2  0x00a33f3b in _L_mutex_lock_35 () from /lib/tls/
>> #3  0xaa7c0918 in ?? ()
>> #4  0x096dd478 in ?? ()
>> #5  0x00000000 in ?? ()
>> - is there a way to dump MySQL lock graph, given a coredump, or a running
>> process attached to gdb,
>> or maybe if you could point me where to look in the code to try to make it
>> dump the lock information to the log, say every minute

MARK> MySQL is not like Innodb. Too many threads wait directly on
MARK> pthread_mutex_t or something that looks like it, so you can't get lock
MARK> wait/hold data when a thread is stuck and the server won't detect
MARK> deadlock on these locks. You could extend the fast mutexes
MARK> implementation in mysys/thr_mutex.c to track this data. I have done
MARK> that to count lock waits per lock and per lock caller.

I am just now working on a wrong mutex usage detector in
MySQL-5.1-maria tree which will then be pulled into MySQL 6.0.  This
detector will, in debug builds, detect wrong mutex usage and report
them when they occur.  While testing this, I have already found a lot
of serious hangup bugs in MySQL 5.1!

Hopefully this is ready within a few days (just now chasing a hard to
find bug in the MySQL code detected by the detector that stops me from
pushing the code...)

more on deadlocks in 5.1bzr MySQL codeMichael Izioumtchenko27 Nov
  • Re: more on deadlocks in 5.1bzr MySQL codeMARK CALLAGHAN27 Nov
    • Re: more on deadlocks in 5.1bzr MySQL codeJonas Oreland27 Nov
    • Re: more on deadlocks in 5.1bzr MySQL codeMichael Widenius29 Nov
    • Re: more on deadlocks in 5.1bzr MySQL codeMichael Izioumtchenko1 Dec