Frage

Ich habe ein Webapp, die Segfaults, wenn die Datenbank in neu gestartet und versucht, die alten Verbindungen zu verwenden. Laufen sie unter gdb --args apache -X führt zu folgenden Ausgabe:

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

Ich habe überprüft, dass die Treiber und Datenbank, die alle auf dem neuesten Stand sind ( DBD :: mysql 4,0008, MySQL 5.0.32-Debian_7etch6-log).

Dummer kann ich nicht reproduzieren diese mit einem trivialen Skript:

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";

Was gibt folgendes:

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'

Dies verhält sich korrekt, mir zu sagen, warum die Anforderung fehlgeschlagen ist.

Was Stümpfe mich ist, dass es Speicherzugriffsfehler, die es nicht tun sollte. Da es nur geschehen wird, wenn die ganze App ausgeführt wird (die verwendet DBIx :: Class ), ist es schwer, es zu einem Testfall zu reduzieren.

Wo soll ich anfangen, dies zu schauen zu debuggen? Hat jemand gesehen?

UPDATE : weiter Stoßen zeigte, dass es unter mod_perl ist eine falsche Fährte war. Nachdem es zu einem einfachen Testskript reduziert ich jetzt auf die DBI Mailingliste . Vielen Dank für Ihre Antworten.

War es hilfreich?

Lösung

Dies ist ein bekanntes Problem in alten DBD :: mysql. Rüsten Sie es (4,008 ist nicht auf dem neuesten Stand).

Es ist ein einfaches Testskript an https: // rt. cpan.org/Public/Bug/Display.html?id=37027 das wird diesen Fehler auslösen.

Andere Tipps

Was dies bedeutet wahrscheinlich ist, dass es ein Unterschied zwischen Ihrer mod_perl Umwelt ist und die, die Sie über Ihr Skript zu testen wurden. Einige Dinge zu überprüfen:

  • Wurde Ihr Mod_perl mit der gleichen Version von Perl kompiliert

  • Sind die von @ INC für beide gleich

  • Sind Sie mit Threads in Ihrem Mod_perl Setup? Ich glaube nicht, DBD glaube :: mysql vollständig Thread-sicher ist.

Ich habe dieses Problem gesehen, aber ich bin nicht sicher, ob es die gleiche Ursache wie bei Ihnen hat. Sind Sie zufällig ein bestimmtes Modul für das Senden von E-Mail (den Namen vergessen, sorry) mit Ihrer Anwendung? Wenn wir das Problem in einem Projekt hatten, nach Tagen des Debugging fanden wir, dass dieser E-Mail-Modul seltsame Dinge mit offenen Dateideskriptoren tat, gegabelten dann einem anderen Prozess ab, den die Konsole Tool Sendmail genannt, die wieder seltsame Dinge mit Filedeskriptoren taten. Ich denke, eine der Filedeskriptoren damit messed um die Verbindung zur Datenbank war, aber ich bin immer noch nicht sicher. Das Problem verschwand, wenn wir für das Senden von E-Mail an ein anderes Modul eingeschaltet. Vielleicht lohnt es sich einen Blick für Sie.

Wenn Sie eine segfault bekommen, haben Sie eine Core-Datei greated? Wenn nicht, überprüfen Sie ulimit -c. Wenn die 0 zurückgibt, wird Ihr System nicht Core-Dateien erstellen und Sie werden feststellen, dass sie ändern müssen. Wenn Sie eine Core-Datei zu tun haben, können Sie gdb oder ähnliche Werkzeuge verwenden, um es zu debuggen. Es ist nicht besonders Spaß , aber es ist möglich. Der Start des Kommandos so etwas wie aussehen:

gbd /usr/bin/httpd core

Es gibt viele Tutorials für Core-Dateien Debuggen über das Web verteilt.

Update: habe gerade eine Referenz für Sie gewährleisten erhalten Core-Dumps von mod_perl . Das sollte helfen.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top