Cómo analizar la información de seguimiento de fallos
Sin embargo, debido a que los parámetros de compilación de MySQL implementados en la línea en los primeros días no estaban muy estandarizados, los rastreos que causaron algunos fallos de MySQL no parecían tan transparentes, eran muy difíciles de entender o incluso no tenían sentido. en absoluto. Esto nos trae muchos inconvenientes a la hora de solucionar problemas. Por supuesto, este problema se resolvió usando google-breakpad para obtener un miniconjunto de datos de fallas de MySQL, pero esa es una historia para otro día y no entraré en eso aquí.
¿Es cierto que no se puede deducir nada de tales rastreos? incierto. Analicemos uno de los fracasos de esta semana.
En línea, una biblioteca de respaldo de la versión 5.5 falló repentinamente después de ejecutarse durante 3 meses. El rastreo del fallo es:
/u01/mysql/bin/mysqld(my_print_stacktrace 0x39)[0x7b1b69 ]<. /p>
/u01/ mysql/bin/mysqld(my_print_stacktrace 0x39)[0x7b1b69]
/u01/ mysql/bin/mysqld(handle_segfault 0x43c)[0x4fa39c]
/lib64/libpthread.so.0[0x344dc0f520]
/u01/mysql/bin/mysqld[0x7fb4c1]
/lib64/libpthread.so.0[0x344dc077e1]
/lib64/libc.so.6(clone 0x6d)[0x344d8e68ed
Esta información de rastreo es típica de las primeras compilaciones e implementaciones de MySQL. La información de rastreo es difícil de leer. Sin embargo, según la experiencia y algo de sentido común, este es un hilo con una relación de llamada muy simple, porque el pthread creado en el rastreo solo llama a la función mysqld una vez. Por lo tanto, supongo que este hilo puede ser un hilo en segundo plano. ¿Qué línea de código es la dirección 0x7fb4c1 que muestra la capa mysqld? Esto es muy crítico para que analicemos el problema.
Después de adivinar, es hora de verificar, ¡y GDB interviene! Utilice GDB para desmontar en la máquina correspondiente.
Nota:
1. ¡No realice operaciones relacionadas con GDB durante los períodos pico de trabajo!
2. ¡Esté muy familiarizado con las operaciones de GDB que está realizando!
3. ¡Es mejor notificar al DBA correspondiente!
¡Entonces, levántate! Dirección de desmontaje en línea 0x7fb4c1. Primero verifique qué función es:
gdb -p 31639 -ex "disassemble?0x7fb4c1?" --ex "quit" --batch--ex "quit" --batch gt ; /tmp/g1.log
Volcado de código ensamblador de 0x7fb4c1 a 0x7fb4f1:
0x00000000007fb4c1: cmp esi, (rax)
0x00000000007fb4c3: jne 0x7fb4b0 <; /p>
0x00000000007fb4c5: mov 0xc(r8), edi
0x00000000007fb4c9: cmp 0x4(rax), edi
0x00000000007fb4cc: jne 0x7fb4b0
0x 00000000007fb4ce: mov 0x60(rax), rdi
0x00000000007fb4ce: mov 0x60(rax), rdi3449
3450 buf_pool = buf_pool_from_array(j);
3451 p >
0x00000000007fb46d: mov r12, -0x740(rbp)
0x00000000007fb474: nopl 0x0(rax)
0x00000000007fb486: prueba r12, r12
0x00 000000007fb489: je 0x7fb908
0x00000000007fb48f : lea (r9, r9, 2), rdi
0x00000000007fb493 : mov r12, rax
0x00000000007 fb496: xor edx, edx
0x00000000007fb498: shl $0x3, rdi
0x00000000007fb49c: mov -0x6c8(rbp, rdi, 1), esi
0x00000000007fb4b4: test rax, rax
0x00000000007fb4b7: je 0x7fb900
3452 blocks_num = UT_LIST_GET_LEN(buf_pool-gt;flush_list);
0x00000000007fb4c1: cmp esi, (rax)
0x000000 00007fb4c3:jne 0x7fb4b0
0x00000000007fb4c5: mov 0xc(r8), edi
0x00000000007fb4c9: cmp 0x4(rax), edi
0x00000000007fb4cc: jne 0x7fb4b0 p>
0
x00000000007fb4ce: mov 0x60(rax), rdi
0x00000000007fb4d2: cmp rdi, 0x10(r11)
0x00000000007fb4d6: jne 0x7fb4b0
0x0000 0007fb4d8:nopl 0x0(rax , rax, 1)
3453 bpage = UT_LIST_GET_FIRST(buf_pool-gt;flush_list);
3454 new_blocks_num = 0;
0x00000000007fb4a3: lea -0x6d0(rbp , rdi, 1), r8
0x00000000007fb4ab: jmp 0x7fb4c1
0x00000000007fb4ad: nopl (rax)
3455
3456 encontrado = FALSO ;
3457 while (bpage != NULL) {
3458 if (prev_flush_info[j].space == bpage-gt;space
3459 amp; amp; prev_flush_info[j].offset == bpage-gt; offset
0x00000000007fb4b0: mov 0x40(rax), rax
3460 amp; /p>
0x00000000007fb4bd: add $ 0x1, rdx
¡Finalmente vea el código familiar!
¡Se puede determinar que la esencia del problema es causada por la excepción en línea! 3452. Es decir, se accede a buf_pool-gt; flux_list.count con una dirección de memoria ilegal.
Este código es una variable de memoria a la que srv_master_thread. La excepción ocurrió en otro lugar, causando esto. La memoria está contaminada. En cuanto al motivo, no tengo idea. Lo analizaré cuando lo encuentre más tarde.
En este punto, hemos podido. Profundice en el rastreo de MySQL y descubra el misterio de la dirección en el rastreo. Aún no se ha resuelto, y se puede descubrir otra información en el rastreo, y los consejos de los expertos detrás de él pueden quedar claros de un vistazo.
Dirección original: Cómo analizar el rastreo de fallos, gracias al autor original por compartirlo.