Crash pendant la mission en mode temps réel
liste gdb
`Thread 1 "principal" signal reçu SIGSEGV, Défaut de segmentation.
OpenApoc::BattleHazard::update (this=0x6000000d, state=..., ticks=1)
à /home/atrosha/OpenApoc/game/state/battle/battlehazard.cpp:490
490 if (ticksUntilVisible > 0)
(gdb) pile d'informations
at /home/atrosha/OpenApoc/game/state/battle/battlehazard.cpp:490
state=..., ticks=1)
at /home/atrosha/OpenApoc/game/state/battle/battle.cpp:1675
at /home/atrosha/OpenApoc/game/state/gamestate.cpp:959
at /home/atrosha/OpenApoc/game/ui/tileview/battleview.cpp:1443
initialStage=...) at /home/atrosha/OpenApoc/framework/framework.cpp:584
at /home/atrosha/OpenApoc/game/main.cpp:26`
Hmm, on dirait que BattleHazard::update() est appelé sur un objet indésirable -0x6000000d n'a pas l'air raisonnable pour un pointeur de tas....
Je pense que cela est dû à un itérateur invalidé : BattleHazard::update
peut finir par appeler BattleHazard::expand
, qui à son tour peut appeler die()
sur un BattleHazard à proximité. Si l'aléa détruit est le suivant dans l'itération, alors l'itérateur utilisé dans Battle::update
devient invalide (voir https://en.cppreference.com/w/cpp/container/set/erase)
C'est la seule explication qui me vient à l'esprit
De plus, j'ai terminé cette mission en mode temps réel sans aucune erreur plus tard.
Si étrange.
Réponse agréable et rapide. Puis-je vous citer dans ma prochaine vidéo ?
Commentaire le plus utile
536 pourrait résoudre ce problème, mais il sera difficile à tester car ce bogue se produit une fois dans une lune bleue. Nous devrions fermer ce problème une fois que nous avons fusionné la demande d'extraction et rouvrir si le bogue persiste.