Partición segfaulting del controlador MySQL bajo mod_perl - dónde buscar el problema

Question

Tengo una aplicación web que segmenta cuando la base de datos se reinicia e intenta usar las conexiones anteriores. Correr bajo gdb --args apache -X conduce al siguiente resultado:

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

He comprobado que los conductores y la base de datos son todo hasta la fecha (DBD::mysql 4.0008, MySQL 5.0.32-Debian_7etch6-log).

un fastidio que no puedo reproducir este con un guión trivial:

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

que da el siguiente:

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' 

Esto comporta correctamente, decirme por qué la petición falló.

Lo que me sorprende es que es segfaulting, lo que no debería hacer. Como solo parece suceder cuando se está ejecutando toda la aplicación (que usa DBIx::Class), es difícil reducirla a un caso de prueba.

¿Dónde debería empezar a buscar para depurar esto? ¿Alguien más ha visto esto?

ACTUALIZACIÓN: un nuevo impulso demostró que estar bajo mod_perl era una pista falsa. Después de haberlo reducido a un script de prueba simple, ahora lo he publicado en el DBI mailing list. Gracias por tus respuestas.

Answer 1

Este es un problema conocido en el viejo DBD :: mysql. Actualícela (4.008 es no actualizado).

Hay un sencillo script de prueba adjunto al https://rt.cpan.org/Public/Bug/Display.html?id=37027 que desencadenará este error.

Answer 2

Lo que esto significa probablemente es que hay una diferencia entre su entorno mod_perl y el que estaba probando a través de su secuencia de comandos. Algunas cosas a comprobar:

• ¿Su mod_perl elaborado con la misma versión de Perl

• son del @ INC el mismo para ambos

• ¿Está utilizando los hilos en la configuración de su mod_perl? No creo que DBD :: mysql sea completamente seguro para subprocesos.

Answer 3

He visto este problema, pero no estoy seguro de que tenga la misma causa que la suya. ¿Está utilizando por casualidad un determinado módulo para enviar correos (olvidó el nombre, lo siento) de su aplicación? Cuando tuvimos el problema en un proyecto, después de días de depuración descubrimos que este módulo de correo estaba haciendo cosas extrañas con los descriptores de archivos abiertos, y luego desconecté otro proceso que llamó a la herramienta de consola sendmail, que nuevamente hizo cosas extrañas con los descriptores de archivos. Creo que uno de los descriptores de archivos con los que se metió fue la conexión a la base de datos, pero aún no estoy seguro de eso. El problema desapareció cuando cambiamos a otro módulo para enviar correos. Tal vez también vale la pena buscarlo.

Answer 4

Si obtiene una segfault, ¿tiene un archivo core greated? Si no, verifique ulimit -c. Si eso devuelve 0, su sistema no creará archivos centrales y tendrá que cambiar eso. Si tiene un archivo core, puede usar gdb o herramientas similares para depurarlo. No es particularmente divertido , pero es posible. El inicio del comando se verá algo como:

gbd /usr/bin/httpd core 

Hay un montón de tutoriales para debugging core files esparcidos por la Web.

Actualización: Acabo de encontrar una referencia para ensuring you get core dumps from mod_perl. Eso debería ayudar.