J´utilise ddd (interface de gdb) pour debugger des applications OpenGL sous Linux. Déjà, j´ai à chaque fois une erreur dans une bibliothèque liée à DRI (direct rendering ...). Pas grave, je continue. Ensuite certains bugs qui n´ont aucune relation avec OpenGL ou quoi que ce soit de "graphique" provoquent un serieux crash (ecran noir, plus de souris, plus de clavier, pas de possibilite de se relogger en mode texte ou même de faire un soft reboot). Je precise que ce n´est pas le cas quand je lance le même programme en dehors de gdb, j´ai alors une segmentation fault bien propre. Je commence à en avoir marre de faire des hard reboots. Quelqu´un aurait-il des infos ou même une solution ?

un problème que j´ai eu sous windows en compilant des appli avec gcc c´est que souvent gcc crée plein de variable sur la pile ou sur le tas mais il n´alloue pas un tas suffisement grand. Moralité, ça fait un seg fault avant que gdb ou autre n´ait eu la possibilité de se lancer.

Je ne sais pas si ça peut être se qui t´arrive (il faudrait que tu donne plus de détail sur les conditions de tes erreurs) mais si c´est possible, essaye d´allouer tes gros tableau avec new ou malloc plutot qu´en static dans le code.

[troll]
P.S. comme quoi, même Linux peut faire des plantages moches...
[/troll]

En fait, j´ai à chaque fois pu repérer les bugs. Je pense que ça n´était pas des problèmes d´allocations mémoire. La dernière fois, c´était parce que j´allais voir des adresses "illicites" (désolé, je connais pas la terminologie adéquate). Donc logiquement, ça me donne un segmentation fault. Mais je ne comprends pas pourquoi ça me donne un crash sous ddd (enfin gdb...). Surtout que c´est complètement aléatoire. Le même programme peut aussi bien me donner un "segmentation fault" bien propre sous ddd ou un crash bien moche. Je me demande si ça vient pas de ddd justement. Je vais essayer avec gdb sans interface pour voir.

il faut savoir qu´en debug et en release, les contextes mémoire sont bien différents.
Certains programmes peuvent passer en débug et non en release.

Le fait que ce soit aléatoire peut etre plusieurs choses : par exemple, un débordement :
si tu as un tableau
int T[50], et que tu écris sur l´élément 55, est ce que ça va planter ou non ?
--> personne ne sait, c´est un facteur chance, ça dépend si ton tableau est alloué pres d´un bord de segment ou non, ça dépend des variables qui sont déclarées apres le tableau qui peuvent etre écrasées, etc...

Ce que je te conseille, c´est de lancer le test, mais pas en plein écran d´abord. Ensuite, de mettre un break point au début du programme, et de faire avancer pas a pas.
Controle tes valeurs de retour, et essaies, en faisant avancer pas a pas, de reserrer sur la zone ou ça plante. par dichotomie, tu devrais y arriver.
Tu sauras alors dans quelle partie du programme ça plante, et ça t´aidera a mieux cerner le soucis...

C´est à peu près ce que je fais mais je ne peux pas éviter le crash même en lançant l´application dans une fenêtre et pas en plein écran. Je repère donc facilement la cause du plantage. Mais un reboot par bug, ça fait un peu lourd quand même...

Oui, c´est moche de devoir rebooter a chaque fois :-/

Si ton code est portable, tu n´as qu´a l´essayer sous Windows, sous Visual C++.
Le débuggueur de visual est le meilleur que j´ai jamais vu, peut etre que ça pourra t´aider a localiser l´erreur.