Discussion :

[exenios]

Bonjour,
je suis actuellement en train d'essayer de créer un petit jeu qui utilise un système de tilemap. J'utilise donc une classe "Map" qui possède une méthode "charger" mais après le déroulement normal de la méthode , le "return true" renvoie au début de la méthode avant d'y sortir.
J'utilise Code blocks et le débuggeur GDB, j'ai remarqué ça en cherchant une segmentation fault, en exécutant le programme ligne après ligne. Je vous mets quand même un code simplifié au cas ou.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
bool Test::load()
{
    std::ifstream stream;
    stream.open("map.txt", std::ios::in);
    std::string version;
    if(stream.is_open())
    {
        //on lit la version dans le fichier
        stream>>version;
        if(version == "1.00")
        {
            //on utilise le fichier pour créer la carte...
        }
        stream.close();
        return true;
    }
    return false;
}

Donc par curiosité, je voudrais savoir pourquoi le "return true" renvoie d'abord à la ligne de la déclaration de "version" avant de quitter et si cela pourrait être la cause de ma segfault?
Merci d'avance.

[ternel]

Il est possible que le compilateur ait regroupé les returns. Ca ressemble à la fermeture du if.

Par contre, ce n'est pas ca qui cause une segfault.

une segfault vient toujours d'un *n'importe_quoi qu'il soit fait directement ou non.

Les formes les plus classiques sont:

• *nullptr qui est le même que *NULL
• un pointeur déjà libéré
• un dépassement de capacité dans une boucle (pense par exemple à [] sur un vector)
• la référence vers "du rien", (souvent, le retour d'une référence vers une variable locale)

[ternel]

Cela dit, pour chercher une segfault dans gdb, tu lances le programme. Au plantage, tu affiche la stack/backtrace.
Le fautif est normalement le pointeur, le tableau ou la référence le plus en haut de la pile.

La cause, elle, est à "l'autre bout du code".

[exenios]

Merci de la réponse,
Finalement j'ai fait bien plus simple, j'ai mit la déclaration de "version" directement dans le if() et là tout va bien.

Pour la segfault, j'avais déjà trouvé les causes principales sur internet mais j'ai énormément de mal à trouver d'où vient celle la. Elle se produit aléatoirement (pas à chaque exécution). Et le débuggeur ne l'annonce qu'au moment de la fermeture de la fenêtre. Il n'arrive pas à localiser l'erreur qui provient de ntdll et la call stack ne remonte pas jusqu'à mon code.
Je commence à me demander si cela ne vient pas d'une des bibliothèques que j'utilise.

[ternel]

En ce cas, bon courage.

éventuellement, montre nous ta callstack.

Essaie de mettre un point d'arrêt dans les destructeurs des classes principales ou avant les éventuelles fonctions de nettoyage (comme le SDL_quit() de la SDL)

[exenios]

Finalement, je pense avoir trouvé d'où ça venait.
J'utilisais la méthode "c_str()" sur un string que j'envoyais à une fonction alors qu'il n'y en avait pas besoin. Je n'ai pas fait beaucoup de testes mais il ne semble plus avoir de segmentation fault.
Merci pour tes réponses.