Ne peut pas analayze le problème de vidage de Core pour l'application multithread ......... (Aide requise)

Je travaille sur l'application multhithreading quand jamais le vidage de processus il génère toujours le noyau comme indiqué ci-dessous je ne suis pas capable de comprendre où il dumping réellement.Ne peut pas analayze le problème de vidage de Core pour l'application multithread ......... (Aide requise)

GNU gdb Red Hat Linux (6.5-25.el5rh) 
Copyright (C) 2006 Free Software Foundation, Inc. 
GDB is free software, covered by the GNU General Public License, and you are 
welcome to change it and/or distribute copies of it under certain conditions. 
Type "show copying" to see the conditions. 
There is absolutely no warranty for GDB. Type "show warranty" for details. 
This GDB was configured as "x86_64-redhat-linux-gnu"...(no debugging symbols found) 
Using host libthread_db library "/lib64/libthread_db.so.1". 


warning: exec file is newer than core file. 
Core was generated by `multithreadprocess                  '. 
Program terminated with signal 11, Segmentation fault. 
#0 0x0000000000448f7a in std::ostream::operator<<() 
(gdb) where 
0x000000000044bd32 in std::ostream::operator<<() 
#1 0x0000000000450b21 in std::ostream::operator<<() 
#2 0x000000000042eda9 in std::string::operator=() 
#3 0x00000030582062e7 in start_thread() from /lib64/libpthread.so.0 
#4 0x00000030576ce3bd in clone() from /lib64/libc.so.6 

(gdb)thread apply all bt 
Thread 6 (process 11674): 
#0 0x000000305820a687 in [email protected]@GLIBC_2.3.2() from /lib64/libpthread.so.0 
#1 0x0000000000431140 in std::string::operator=() 
#2 0x00000030582062e7 in start_thread() from /lib64/libpthread.so.0 
#3 0x00000030576ce3bd in clone() from /lib64/libc.so.6 

Thread 5 (process 11683): 
#0 0x000000305820cbfb in write() from /lib64/libpthread.so.0 
#1 0x0000000000449151 in std::ostream::operator<<() 
#2 0x000000000043b74a in std::string::operator=() 
#3 0x000000000046c3f4 in std::string::substr() 
#4 0x000000000046e3c1 in std::string::substr() 
#5 0x00000000004305a4 in std::string::operator=() 
#6 0x00000030582062e7 in start_thread() from /lib64/libpthread.so.0 
#7 0x00000030576ce3bd in clone() from /lib64/libc.so.6 

Thread 4 (process 11744): 
#0 0x00000030576c5896 in poll() from /lib64/libc.so.6 
#1 0x0000000000474f1c in std::string::substr() 
#2 0x000000000043b889 in std::string::operator=() 
#3 0x0000000000474dbc in std::string::substr() 
#4 0x00000000004306a5 in std::string::operator=() 
#5 0x00000030582062e7 in start_thread() from /lib64/libpthread.so.0 
#6 0x00000030576ce3bd in clone() from /lib64/libc.so.6 

Thread 3 (process 11864): 
#0 0x000000305820a687 in [email protected]@GLIBC_2.3.2() from /lib64/libpthread.so.0 
#1 0x0000000000431140 in std::string::operator=() 
#2 0x00000030582062e7 in start_thread() from /lib64/libpthread.so.0 
#3 0x00000030576ce3bd in clone() from /lib64/libc.so.6 

Thread 2 (process 11866): 
#0 0x000000305820a687 in [email protected]@GLIBC_2.3.2() from /lib64/libpthread.so.0 
#1 0x0000000000431140 in std::string::operator=() 
#2 0x00000030582062e7 in start_thread() from /lib64/libpthread.so.0 
#3 0x00000030576ce3bd in clone() from /lib64/libc.so.6 

Thread 1 (process 11865): 
#0 0x000000000044bd32 in std::ostream::operator<<() 
#1 0x0000000000450b21 in std::ostream::operator<<() 
#2 0x000000000042eda9 in std::string::operator=() 
#3 0x00000030582062e7 in start_thread() from /lib64/libpthread.so.0 
#4 0x00000030576ce3bd in clone() from /lib64/libc.so.6

Si je donne bt complet, il montre comme celui-ci

(gdb) bt full 
#0 0x000000000044bd32 in std::ostream::operator<<() 
No symbol table info available. 
#1 0x0000000000450b21 in std::ostream::operator<<() 
No symbol table info available. 
#2 0x000000000042eda9 in std::string::operator=() 
No symbol table info available. 
#3 0x00000030582062e7 in start_thread() from /lib64/libpthread.so.0 
No symbol table info available. 
#4 0x00000030576ce3bd in clone() from /lib64/libc.so.6 
No symbol table info available.

Source

2010-02-22 Rama

note: "avertissement: le fichier exécut est plus récent que le fichier core". Tu ferais mieux de relancer avec l'exécutable que vous avez actuellement. – Drakosha

Toutes les lignes listées semblent provenir de bibliothèques standard - je suggère de recompiler le code avec des symboles, et de reproduire le crash, si possible directement dans gdb. –

Me semble que vous utilisez iostream dans une application multithread sans les drapeaux appropriés. Voir this. En particulier, notez qu'il dit

Lorsque vous construisez une application qui utilise les classes iostream de la libc de fonctionner dans un environnement multithread, compiler et lier le code source de l'application à l'aide la option -mt Cette option transmet -D_REENTRANT au préprocesseur et -lthread à l'éditeur de liens.

Ceci est pour une plate-forme particulière; vos exigences peuvent varier.

Source

2010-02-22 16:25:16

Sous Linux, -D_REENTRANT est généralement un no-op, et il est très peu probable qu'il ait quelque chose à voir avec le problème. –

GDB 6.5 est assez ancien. Vous obtiendrez probablement des traces de pile significativement meilleures à partir de (actuelles) GDB 7.0.1.

Vous semblez également essayer de déboguer le code optimisé, construit sans indicateur -g, et vous ne pouvez pas déboguer le bon exécutable (GDB prévient que votre exécutable est plus récent que votre noyau).

Assurez-vous que votre exécutable et tous les bibliothèques répertoriées dans info shared sortie GDB exactement match entre le système où votre noyau a été produit et le système sur lequel vous analysez le noyau (si elles ne sont pas les pareil) - c'est primordial - s'il y a une discordance, vous obtiendrez probablement des traces de pile fictives (et les traces de pile que vous avez postées me semblent complètement fausses).

Source

2010-02-24 07:11:55

Ne peut pas analayze le problème de vidage de Core pour l'application multithread ......... (Aide requise)

Répondre

Questions connexes