MySQL

:: DEVELOPER ZONE

Login / Register

  • MySQL.com
  • Developer Zone
  • Partners
  • Online Shop
  • Downloads
  • Documentation
  • Forums
  • Lists
  • Bugs
  • Events
  • User Groups
  • Guilds
  • Blogs
  • Support
  • Resources
  • Books
  • FAQ

Справочное руководство по MySQL 4.0. :: E Перенос на другие системы :: E.1 Отладка сервера MySQL :: E.1.4 Использование трассировки стека

  • Overview
  • MySQL Reference Manual
  • MaxDB Documentation
  • Connectors

Search the MySQL manual:


  • Справочное руководство по MySQL 4.0.

  • E.1 Отладка сервера MySQL
  • E.1.1 Компиляция MySQL для отладки
  • E.1.2 Создание трассировочных файлов
  • E.1.3 Отладка mysqld при помощи gdb
  • E.1.4 Использование трассировки стека
  • E.1.5 Использование журналов для определения причин ошибок в mysqld
  • E.1.6 Создание контрольного примера при повреждении таблиц

Get the MySQL Language Reference and MySQL Administrator's Guide from MySQL Press!


Additional languages

  • German


Learn about new MySQL releases, technical articles, events and more.

Subscribe to the monthly MySQL Newsletter!


Previous / Next / Up / Table of Contents

E.1.4. Использование трассировки стека

В некоторых операционных системах журнал ошибок в случае смерти mysqld будет содержать трассировку стека. Эти данные можно использовать для выяснения, где (и, может быть, почему) умер mysqld (see Раздел 4.9.1, «Журнал ошибок»). Для получения трассировки стека не следует компилировать mysqld с опцией -fomit-frame-pointer для gcc (see Раздел 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. Для этого нужно выполнить следующие действия:

  1. Скопируйте приведенные выше числовые значения в файл, например mysqld.stack.

  2. Создайте файл символов для сервера mysqld:

    nm -n libexec/mysqld > /tmp/mysqld.sym
    

    Следует учесть, что во многих бинарных поставках MySQL приведенный выше файл с именем mysqld.sym.gz уже имеется. В этом случае необходимо распаковать его следующим образом:

    gunzip < bin/mysqld.sym.gz > /tmp/mysqld.sym
    
  3. Выполните resolve_stack_dump -s /tmp/mysqld.sym -n mysqld.stack, чтобы вывести место остановки mysqld. Если и это не поможет определить причину останова mysqld, то следует сделать отчет об ошибке и включить в него данный вывод с комментарием. Следует учитывать, однако, что в большинстве случаев наличие лишь только трассировки стеков не поможет нам определить причину данной проблемы. Чтобы иметь возможность локализовать данный сбой или рекомендовать обходной путь, нам, как правило, необходимо знать, какой именно запрос привел к остановке mysqld и, желательно, иметь контрольный пример, чтобы мы могли воспроизвести данную проблему! See Раздел 1.8.1.3, «Как отправлять отчеты об ошибках или проблемах».


This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.

Top / Previous / Next / Up / Table of Contents

© 1995-2005 MySQL AB. All rights reserved.

  • About MySQL
  • Careers
  • Site Map
  • Contact Us
  • Legal
  • Privacy Policy
  • Trademark Info
  • No Software Patents!