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
