В некоторых операционных системах журнал ошибок в случае смерти mysqld будет содержать трассировку стека. Эти данные можно использовать для выяснения, где (и, может быть, почему) умер mysqld (see section 4.9.1 Журнал ошибок). Для получения трассировки стека не следует компилировать mysqld с опцией -fomit-frame-pointer для gcc (see section E.1.1 Компиляция MySQL для отладки).
Если файл ошибок содержит что-нибудь похожее на следующее:
mysqld got signal 11; The manual section 'Debugging a MySQL server' tells you how to use a stack trace and/or the core file to produce a readable backtrace that may help in finding out why mysqld died Attemping backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong
stack range sanity check, ok, backtrace follows 0x40077552 0x81281a0 0x8128f47 0x8127be0 0x8127995 0x8104947 0x80ff28f 0x810131b 0x80ee4bc 0x80c3c91 0x80c6b43 0x80c1fd9 0x80c1686
то можно определить, где произошла остановка mysqld. Для этого нужно выполнить следующие действия:
nm -n libexec/mysqld > /tmp/mysqld.symСледует учесть, что во многих бинарных поставках MySQL приведенный выше файл с именем `mysqld.sym.gz' уже имеется. В этом случае необходимо распаковать его следующим образом:
gunzip < bin/mysqld.sym.gz > /tmp/mysqld.sym