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  
Hi!

>>>>> "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/ld-linux.so.2
>> #1  0x00a3730e in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0
>> #2  0x00a33f3b in _L_mutex_lock_35 () from /lib/tls/libpthread.so.0
>> #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...)

Regards,
Monty
Thread
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