Aborto simultáneo() en dos hilos

Tengo una traza inversa con algo que no había visto antes. Ver bastidor 2 en estos temas:.Aborto simultáneo() en dos hilos

Thread 31 (process 8752): 
#0 0x00faa410 in __kernel_vsyscall() 
#1 0x00b0b139 in sigprocmask() from /lib/libc.so.6 
#2 0x00b0c7a2 in abort() from /lib/libc.so.6 
#3 0x00752aa0 in __gnu_cxx::__verbose_terminate_handler() from /usr/lib/libstdc++.so.6 
#4 0x00750505 in ??() from /usr/lib/libstdc++.so.6 
#5 0x00750542 in std::terminate() from /usr/lib/libstdc++.so.6 
#6 0x00750c65 in __cxa_pure_virtual() from /usr/lib/libstdc++.so.6 
#7 0x00299c63 in ApplicationFunction() 

Thread 1 (process 8749): 
#0 0x00faa410 in __kernel_vsyscall() 
#1 0x00b0ad80 in raise() from /lib/libc.so.6 
#2 0x00b0c691 in abort() from /lib/libc.so.6 
#3 0x00b4324b in __libc_message() from /lib/libc.so.6 
#4 0x00b495b6 in malloc_consolidate() from /lib/libc.so.6 
#5 0x00b4b3bd in _int_malloc() from /lib/libc.so.6 
#6 0x00b4d3ab in malloc() from /lib/libc.so.6 
#7 0x08147f03 in AnotherApplicationFunction()

Al abrir con el BGF y conseguir traza me da secuencia 1. Más tarde vi el estado raro que el hilo 31 es en este tema es de la biblioteca que tuvimos problemas con eso, creo que el accidente es causado por eso.

¿Qué significa? Dos hilos al mismo tiempo haciendo algo ilegal? ¿O es uno de ellos, causando de alguna manera abort() en el otro?

El sistema operativo es Linux Red Hat Enterprise 5.3, es un servidor multiprocesador.

Fuente

2011-02-23 Dmitry Yudakov

Estás en Linux, ¿por qué no solo ejecutas valgrind (específicamente los módulos memcheck, helgrind y DRD)? –

Gracias, voy a consultar con ellos. Es un programa complejo y valgrind generalmente da toneladas de cosas, pero intentaré analizar algunas partes aisladas –

parece que podría ser daños en el montón, detectada por malloc en hilo 1, causando o causado por el error en la rosca 31.

Algunos pieza rota de código sobrescribir a.o. el vtable en el hilo 31 podría causar esto fácilmente.

Fuente

2011-02-23 16:48:50 Erik

Es difícil estar seguro, pero mi primera sospecha al ver estos rastros de pila sería una corrupción de memoria (posiblemente un desbordamiento del búfer en el montón). Si ese es el caso, entonces la corrupción es probablemente la causa raíz de que ambos hilos terminen en abort.

¿Puedes valgrind tu aplicación?

Fuente

2011-02-23 16:48:15 NPE

Sí, lo comprobaré con valgrind –

Es posible que el motivo por el que se interrumpió el subproceso 31 sea porque destruyó el montón de aplicaciones de alguna manera. Luego, cuando el hilo principal intentó asignar memoria, la estructura de datos del montón estaba en mal estado, lo que provocó que la asignación fallara y abortara la aplicación nuevamente.

Fuente

2011-02-23 16:49:59

Respuesta

Cuestiones relacionadas