MySQL драйвер segfaulting под mod_perl - где искать проблему - PullRequest
Новая
       31

MySQL драйвер segfaulting под mod_perl - где искать проблему

5 голосов
/ 08 октября 2008

У меня есть веб-приложение, которое отключается при перезапуске базы данных и пытается использовать старые подключения. Запуск его под gdb --args apache -X приводит к следующему выводу: 

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1212868928 (LWP 16098)]
0xb7471c20 in mysql_send_query () from /usr/lib/libmysqlclient.so.15

Я проверил, что все драйверы и база данных обновлены ( DBD :: mysql 4.0008, MySQL 5.0.32-Debian_7etch6-log).

К сожалению, я не могу воспроизвести это с помощью тривиального сценария: 

use DBI;
use Test::More tests => 2;

my $dbh = DBI->connect( "dbi:mysql:test", 'root' );

sub test_db {
    my ($number) = $dbh->selectrow_array("select 1 ");
    return $number;
}

is test_db, 1, "connected to db";

warn "restart db now";
getc;

is test_db, 1, "connected to db";

Что дает следующее: 

ok 1 - connected to db
restart db now at dbd-mysql-test.pl line 23.

DBD::mysql::db selectrow_array failed: MySQL server has gone away at dbd-mysql-test.pl line 17.
not ok 2 - connected to db
#   Failed test 'connected to db'
#   at dbd-mysql-test.pl line 26.
#          got: undef
#     expected: '1'

Это ведет себя правильно, сообщая мне, почему запрос не прошел.

Что меня озадачивает, так это то, что это сегментация, чего не следует делать. Поскольку это происходит только во время работы всего приложения (которое использует DBIx :: Class ), его трудно свести к тестовому случаю.

Где мне начать искать, чтобы отладить это? Кто-нибудь еще видел это?

ОБНОВЛЕНИЕ : дальнейшее подталкивание показало, что он, находящийся под mod_perl, был красной сельдью. Сокращая его до простого тестового скрипта, я теперь разместил в DBI список рассылки . Спасибо за ваши ответы.

Ответы [ 4 ]

3 голосов
/ 08 октября 2008

Это, вероятно, означает, что есть разница между вашей средой mod_perl и той, которую вы тестировали с помощью своего скрипта. Некоторые вещи для проверки:

  • Был ли ваш mod_perl скомпилирован с той же версией Perl

  • Являются ли @ INC одинаковыми для обоих

  • Используете ли вы темы в вашей настройке mod_perl? Я не верю, что DBD :: mysql полностью поточно-ориентирован.

2 голосов
/ 09 октября 2008

Если вы получаете segfault, у вас есть жадный файл ядра? Если нет, проверьте ulimit -c. Если это возвращает 0, ваша система не будет создавать файлы ядра, и вам придется это изменить. Если у вас есть файл ядра, вы можете использовать gdb или аналогичные инструменты для его отладки. Это не особенно весело , но это возможно. Запуск команды будет выглядеть примерно так: 

gbd /usr/bin/httpd core

Существует множество руководств по отладке основных файлов , разбросанных по сети.

Обновление: только что нашел ссылку для , обеспечивающую получение дампов ядра из mod_perl . Это должно помочь.

2 голосов
/ 09 октября 2008

Я видел эту проблему, но я не уверен, что у нее была та же причина, что и у вас. Вы случайно не используете определенный модуль для отправки писем (забыл имя, извините) из своего приложения? Когда у нас возникла проблема в проекте, после нескольких дней отладки мы обнаружили, что этот почтовый модуль делал странные вещи с дескрипторами открытых файлов, а затем отключили другой процесс, который называется консольным инструментом sendmail, который снова делал странные вещи с дескрипторами файлов. Я предполагаю, что одним из файловых дескрипторов, с которыми он связывался, было соединение с базой данных, но я все еще не уверен в этом. Проблема исчезла, когда мы перешли на другой модуль для отправки почты. Может быть, стоит посмотреть и на тебя.

1 голос
/ 16 августа 2010

Это известная проблема в старом DBD :: mysql. Обновите его (4.008 - , а не в актуальном состоянии).

К https://rt.cpan.org/Public/Bug/Display.html?id=37027 прикреплен простой тестовый скрипт это вызовет эту ошибку.

...