Abandon simultané () dans deux threads

J’ai un backtrace avec quelque chose que je n’ai jamais vu auparavant. Voir le cadre 2 dans ces fils:

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 () 

En l’ouvrant avec gdb et en obtenant un backtrace, cela me donne le thread 1. Plus tard, j’ai vu l’état étrange dans lequel se trouve le thread 31. Ce thread provient de la bibliothèque avec laquelle nous avons eu des problèmes.

Alors, ça veut dire quoi? Deux threads faisant simultanément quelque chose d’illégal? Ou est-ce l’un d’entre eux, provoquant en quelque sorte un avortement () dans l’autre?

Le système d’exploitation est Linux Red Hat Enterprise 5.3, c’est un serveur multiprocesseur.

On dirait que cela pourrait être une corruption de tas, détectée par malloc dans le thread 1, provoquant ou provoqué par l’erreur dans le thread 31.

Un morceau de code cassé écrasant la vtable dans le thread 31 pourrait facilement causer ceci.

Il est difficile d’être sûr, mais mon premier soupçon en voyant ces traces de stack serait une corruption de mémoire (éventuellement un dépassement de tampon sur le tas). Si tel est le cas, alors la corruption est probablement la cause première des deux threads qui se retrouvent en abort .

Pouvez-vous valgrind votre application?

Il est possible que la raison pour laquelle le thread 31 a été interrompu soit parce qu’il a détruit le tas d’applications. Ensuite, lorsque le thread principal a essayé d’allouer de la mémoire, la structure de données du tas était en mauvais état, entraînant l’échec de l’allocation et annulant à nouveau l’application.