2010-11-10 10 views
0

J'ai une application fonctionnant sous Solaris 8 (SunOS 5.8 Generic_108528-27 sun4u sparc SUNW, Sun-Fire-880) et elle fonctionne correctement depuis plusieurs jours jusqu'à récemment, elle s'est écrasée. Il y avait un module de surveillance qui a redémarré l'application quand il s'est écrasé. Cependant, il a couru et s'est écrasé encore et encore. Après avoir examiné les vidages de base, j'ai constaté qu'il s'est écrasé sur les appels de fonction du système tels que sondage, écrire et envoyer. J'ai examiné le contenu des variables passées aux fonctions et ils avaient l'air bien. Je n'ai aucune idée de comment résoudre ce problème. Quelqu'un peut-il aider à donner des indications sur où aller? Merci d'avance.C Programmation Erreur de segmentation sur poll()

ci-dessous montre un des exemples de vidage de base sur sondage:

bash $ gdb APPLX applx.core
GDB est un logiciel libre et vous êtes invités à distribuer des copies de celui-ci
sous certaines conditions; tapez "show copy" pour voir les conditions.
Il n'y a absolument aucune garantie pour GDB; tapez "show warranty" pour plus de détails.
GDB 4,16 (sparc-soleil solaris2.5), Copyright since 1996 Software, Inc ...

avertissement: fichier exec est plus récent que le fichier de base.
Le noyau a été généré par `applx -h '.
Programme terminé avec le signal 11, erreur de segmentation.
Lecture de symboles à partir de /usr/lib/libsocket.so.1...done.
Lecture des symboles à partir de /usr/lib/libnsl.so.1...done.
Lecture de symboles à partir de /usr/lib/libgen.so.1...done.
Lecture de symboles à partir de /usr/lib/libc.so.1...done.
Lecture de symboles à partir de /usr/lib/libdl.so.1.done.
Lecture des symboles à partir de /usr/lib/libmp.so.2...done.
Lecture de symboles à partir de /usr/platform/SUNW,Sun-Fire-880/lib/libc_psr.so.1.done.
# 0 0xff219ec4 dans _libc_poll()
(BDG) bt
# 0 0xff219ec4 dans _libc_poll()
# 1 0xff1cccac dans _select()
# 2 0x1cf08 en boucle() à/home/ian123/APPLX/src/task.c: 1450
# 3 0x1e0d4 dans state_start (local = 0) dans /home/ian123/applx/src/state.c:1047
# 4 0x1a0f4 dans main (argc = 537600, argv = 0x83400)
à /home/ian123/applx/src/main.c:578
(gdb) jusqu'à
# 1 0xff1cccac dans _select()
(gdb) up
# 2 0x1cf08 dans loop() dans/home/ian123/applx/src/task.c: 1450
1450 r = sélection (maxfd, rfdsp, wfdsp, efdsp, tvp);
(BDG) p maxfd
1 $ = 23
(BDG) p rfdsp
$ 2 = (fd_set *) 0xb8020
(BDG) p wfdsp
$ 3 = (fd_set *) 0x0
(BDG) p efdsp
$ 4 = (fd_set *) 0x0
(BDG) p tvp
5 $ = (struct timeval *) 0xb81a0
(BDG) p * rfdsp
6 $ = {fds_bits = {7610424, 0}}
(gdb) p * tvp
$ 7 = {tv_sec = 0, tv_usec = 380002}

+0

Juste pour éliminer les possibilités, le programme est multithread (dans ce cas, vous pourriez regarder la pile pour le thread wron)? – nos

+0

Salut nos, c'est un filetage unique. Merci – user502865

+1

@ user502865 dans ce cas, je commencerais à chercher des débordements de tampon/corruption de tas quelque part. – nos

Répondre

0

Si GDB vous montrer le code source où le défaut de segmentation a eu lieu alors cela peut rapidement conduire à une meilleure compréhension du problème.

+0

Comme vous pouvez voir la sortie de gdb que j'ai posté avec la question, le contenu des variables m'a semblé bon. – user502865

+0

J'ai vu cela mais la faute de segmentation réelle s'est produite dans libc_poll plutôt que l'appel de votre boucle de fonction pour sélectionner. Si vous pouviez avoir une visibilité ici, cela pourrait aider beaucoup. –

2

Quand j'enquête sur une erreur de segmentation et je ne sais pas où ça se passe, j'utilise la commande gdb suivante:

x/1i <program_counter> 

(contre Substitut < programme> pour ... (roulement de tambour de votre architecture) ... compteur de programme, par exemple: $ eip sur x86, je suppose que c'est $ pc ou similaire sur SPARC).

Indique l'instruction de défaut. De là, j'examine les registres qui contiennent des adresses de mémoire.