Openapoc: Aucun véhicule correspondant à l'ID "VEHICLE_794" CTD

Créé le 23 nov. 2017  ·  33Commentaires  ·  Source: OpenApoc/OpenApoc

Du Log suite à un CTD...

W 52740355833 bool __cdecl OpenApoc::Vehicle::popFinishedMissions(class OpenApoc::GameState &): Pas de prochaine mission de véhicule, au ralenti
E 52741482678 classe std::shared_ptr__cdecl OpenApoc::Vehicle::get(const class OpenApoc::GameState &,const class OpenApoc::UString &): Aucun véhicule correspondant à l'ID "VEHICLE_794"
0x00000001402F9D30 PHYSFS_writeSLE16+0x15f400
0x000000014020208A PHYSFS_writeSLE16+0x6775a
0x00000001401FFD3A PHYSFS_writeSLE16+0x6540a
0x00000001400A784C PHYSFS_swapULE64+0x6600c
0x000000013FFA3D32 PHYSFS_swapULE64+0xfffffffffff624f2
0x000000013FF7F210 PHYSFS_swapULE64+0xfffffffffff3d9d0
0x000000014017E015 PHYSFS_swapULE64+0x13c7d5
0x0000000077A159CD BaseThreadInitThunk+0xd
0x0000000077C4A561 RtlUserThreadStart+0x21

image

image

Commentaire le plus utile

Cette erreur persistera dans les sauvegardes - donc si la cause d'origine d'un mauvais StateRefs'est déjà produit, et que vous enregistrez, cela inclura cette "mauvaiseté" dans la sauvegarde, il n'est donc pas surprenant que le rechargement d'une sauvegarde "cassé" provoque la même erreur.

Le message d'erreur ci-dessus s'affiche lorsque le jeu essaie d'utiliser cet objet "cassé" et réalise que quelque chose ne va pas, pas une erreur en soi. L'échec peut s'être produit il y a quelque temps, juste l'objet cassé non encore utilisé.

Donc, si vous testez cela avec la même sauvegarde et que vous n'avez pas créé de nouveau jeu depuis le correctif, cela ne nous dit probablement pas grand-chose.

Tous les 33 commentaires

Juste un avertissement
Ce CTD a maintenant buggé deux jeux.
Les deux sur la « carte facile »
Les deux avec l'ID de véhicule 794~
Cliquer sur "Limp Along" vous ramène directement au bureau.

Ce backtrace semble incorrect, comme s'il ne peut pas trouver les symboles de débogage (il utilise donc simplement le symbole le plus proche qu'il peut trouver, qui se trouve être physfs).

Si vous utilisez les versions d'appveyor, pouvez-vous extraire le package "debug" par-dessus ? Donc les fichiers .pdb sont dans le même répertoire que le .exe ?

Et "essayez de boiter" ne fonctionnera tout simplement pas pour certaines erreurs (comme celle-ci), car l'erreur dit en fait "Nous sommes sur le point de planter, et voici pourquoi :", alors essayer de continuer ne fait que planter :)

En tant qu'objectif à plus long terme, il peut être possible de vider l'état actuel de « sauvegarde » en cas d'erreur, cela pourrait nous donner des informations utiles sur ce qui ne va pas... Mais cela peut tomber exactement dans le même problème (si les données internes ne peuvent pas faire confiance, nous pouvons juste planter en essayant d'écrire la sauvegarde)

@JonnyH Pas de problème, rentrerai du travail lundi...

Actuellement à la hauteur de mes globes oculaires chez les jeunes gymnastes :D

quel jeune? ) j'espère que c'est légal XD

@makus82 malheureusement, ce week-end et durent tous, mais les derniers étaient trop jeunes. Mais les événements universitaires quand je les fais sont toujours amusants - des femmes chaudes, toutes légales

En ce qui concerne le CTD, veuillez trouver le journal, la sauvegarde, etc. ci-joint. Il suffit de démarrer l'heure et le jeu va planter...

J'ai fait comme @JonnyH l'a dit et

openapoc_log.txt

save_Easy 1.zip

Et une variation différente sur le même fichier de sauvegarde...

image

openapoc_log.txt

Encore une fois en 0,1-117
Même en faisant une installation propre (effacez toutes les données apoc existantes à l'exception des sauvegardes, extrayez à nouveau du zip)

image

Je peux fournir quelques détails.
Étapes à reproduire :

  1. démarrer le jeu en difficulté moyenne (peut-être n'importe laquelle)
  2. vendre un véhicule terrestre (peut-être n'importe lequel)
  3. sauvegarder la partie
  4. chargement du jeu
  5. reprendre le jeu

@OverDrone

Ah, oui, dans tous les jeux où je reçois ce CTD, je vends mon wolfhound APC et Stormdog pour obtenir quelques milliers de dollars supplémentaires en espèces pour les véhicules que je n'utilise jamais.

Je vais faire un test sur un jeu lorsque je ne vends PAS de véhicules et voir si cette erreur se produit.
Actuellement, n'importe quel jeu a vendu n'importe quel véhicule, il plante...

Hmmmm, je viens de recevoir ce plantage sur un jeu où je n'ai vendu AUCUNE unité au sol... Cela semble remarquablement similaire...

image
image
image

Même problème ici... je ne peux pas vendre l'option veicle et de débogage qui m'amène au bureau...
une idée de résolution ?

Le code de l'écran de transaction ressemble à un gâchis. Difficile de résoudre ce problème sans refactorisation.

Toujours présent sur 0.1-167 ( OpenApoc-x64-v0.1-167-gf31d8b8b ) ce qui est un peu embêtant... Le bug de mort du véhicule est signalé trié. Je me demande pourquoi ce bug refuse d'être écrasé ?

image
image
image

Avez-vous chargé un jeu ou commencé un nouveau ?
Essayez de tester sur un nouveau jeu.

Je viens de démarrer un nouveau jeu sur une nouvelle installation pour vérifier. Confirmera si toujours un problème.

OK, le jeu a planté apparemment en raison du problème # 255 avant que je puisse confirmer que ce problème est résolu.

Cela dit, j'ai pu vendre Stormdog et Wolfhound APC et pas encore 794 CTD, mais je n'ai pas non plus réussi à terminer le premier jour sans interruption de jeu :(

Veuillez consulter le commentaire le plus récent sur #255 pour le journal et les écrans du crash qui a mis fin à mon nouveau jeu

@redv Le crash du véhicule semble résolu, cependant, le problème semble s'être étendu aux agents également, ce bug persiste...

image
image

Est-ce qu'il plante lorsque vous quittez le jeu ?

Cela se produit en quittant le jeu OU en entrant dans l'écran de base (le cas ci-dessus était en train de quitter)

@redv Malheureusement, je viens d'avoir à nouveau l'erreur Agent 45 sur une nouvelle installation propre et un nouveau jeu d'OpenApoc. Cela s'est produit en quittant le jeu comme suit...

La version du jeu est la dernière version (0.1-172 au moment de la rédaction)

image
image
image

Cliquer sur "Limp Along" produit cette variante...
image
image

Lorsque l'application détruit la classe GameState, détruit d'abord la liste des agents, puis les bases, les installations, les laboratoires, etc. La classe Lab contient sa propre liste d'agents (scientifiques), mais les classes d'agents déjà détruites. Ainsi, le bug se produit.
Le PR #337 corrige ce bug.
Comme solution de contournement possible, retirez les scientifiques du laboratoire avant de quitter le jeu.

@redv
Malheureusement, toujours une variante de ce problème dans la version OpenApoc-debug-x64-v0.1-169-g921de2a3

Cette fois, je déplace des agents (à pied à travers les tubes humains) vers un incident extraterrestre dans les bidonvilles. Je me prépare également à piller un temple CoS, l'erreur se produit avec le bâtiment et les agents sélectionnés.

image
image
image

Attachez s'il vous plaît la dernière sauvegarde avant CTD.

@redv et voilà. Pour répéter l'erreur, envoyez la Valkyrie au temple CoS juste au NE de la base et envoyez les deux agents androïdes dans l'incident des bidonvilles qui apparaît après une minute ou deux À PIED.

Une erreur se produit lorsque la Valkyrie arrive au temple CoS et que vous sélectionnez les agents à l'intérieur pour attaquer le bâtiment.

save_Medium Test 1.zip

Savegame était un nouveau jeu créé aujourd'hui sur une nouvelle installation d'OpenApoc. Le jeu en est à ses premières minutes de jeu...

Le bug se produit lorsque le jeu essaie de charger des ressources pour la battlemap. La carte contient plusieurs blocs choisis au hasard dans un ensemble. On dirait que l'un d'eux conduit à un bogue lors du chargement des ressources.
C'est-à-dire que si vous répétez les mêmes actions plusieurs fois, tôt ou tard, la carte de bataille CoS sera chargée avec succès. Cette carte sera sans le mauvais bloc.

  1. Bogue. Besoin de comprendre pourquoi le jeu ne peut pas charger certains blocs de carte.

L'AGENT_35 est le phisiste quantique Peter Jones.
Lorsque le bug de chargement de la carte se produit, le jeu lors du crash appelle les destructeurs. Les destructros d'agents s'exécutent avant les destructeurs de labos. Le destructeur de labo essaie de libérer des agents, mais les agents ont déjà disparu de la mémoire. Ainsi, le deuxième bogue se produit dans la classe StateRef qui contient l'agent dans la classe Lab.

  1. Bogue. Je pense que la classe StateRef est une grosse erreur architecturale. Mieux vaut utiliser des pointeurs C réguliers. Je pense que le modèle "observateur" peut résoudre la plupart des problèmes. Au moins je vais essayer de trouver une bonne solution.

Merci redv ; faites-moi savoir quand vous avez une idée de la solution qui peut fonctionner

Quant aux cartes, cela pourrait-il être lié au problème #284 ? Je remarque un certain nombre de cartes CoS et quelques autres semblent générer des erreurs lorsque des éléments sont lâchés par des unités tuées/assommées/paniques.

Nouveau plantage sur 0.1-200 , cette fois à l'ouverture de l'écran agent... Ayant déjà vendu le Stormdog.
image
image
image

La sélection de "Limp Along" fait cela

image
image

Équipement cette fois :(
Créez, s'il vous plaît, un nouveau numéro. Parce que celui-ci est trop profond dans la file d'attente des problèmes.

Confirmant qu'il s'agit toujours d'un problème, la vente de n'importe quel véhicule provoque l'apparition de celui-ci lorsque tout ce qui lui est associé est appelé.

I 417929443733 void __cdecl anonyme-namespace'::SDLRawBackend::setTrack(class std::shared_ptr): Réglage de la piste sur 0,000,019,B87,324,D20
I 422315537514 void __cdecl anonymous-namespace'::SDLRawBackend::playSample(class std::shared_ptr<class OpenApoc::Sample>,float): Placed sound 0,000,019,BFD,B86,6B0 on queue I 422432359150 void __cdecl OpenApoc::VEquipScreen::setSelectedVehicle(class std::shared_ptr<class OpenApoc::Vehicle>): Selecting vehicle "Valkyrie Interceptor 90" I 422432639858 void __cdecl OpenApoc::VEquipScreen::setSelectedVehicle(class std::shared_ptr<class OpenApoc::Vehicle>): Selecting vehicle "Valkyrie Interceptor 90" I 424865493463 void __cdecl anonyme-namespace'::SDLRawBackend::playSample(class std::shared_ptr,float): Son placé 0,000,019,BFD,B86,6B0 en file d'attente
I 427732686087 classe std::shared_ptr__cdecl OpenApoc::Vehicle::addEquipment(class OpenApoc::GameState &,struct glm::tvec2,classe OpenApoc::StateRef): Equipé "Valkyrie Interceptor 90" avec équipement général "Module Passager"
I 430232009610 void __cdecl anonymous-namespace'::SDLRawBackend::playSample(class std::shared_ptr<class OpenApoc::Sample>,float): Placed sound 0,000,019,BFD,B86,6B0 on queue I 432298883338 void __cdecl anonyme-namespace'::SDLRawBackend::playSample(class std::shared_ptr,float): Son placé 0,000,019,BFD,B86,6B0 en file d'attente
W 432416803536 void __cdecl OpenApoc::StateRef::resolve(void) const : l'objet AEquipmentType a un préfixe non valide - ID "AEQUIPMENTTYPE_" attendu "VEHICLE_794"
E 432419555645 classe std::shared_ptr__cdecl OpenApoc::AEquipmentType::get(const class OpenApoc::GameState &,const class OpenApoc::UString &): Aucun type d'équipement correspondant à l'ID "VEHICLE_794"
0x00007FF712CA8C70 PHYSFS_writeSLE16+0x917d0
0x00007FF712AF1F6C PHYSFS_swapULE64+0xef91c
0x00007FF712B5D944 PHYSFS_swapULE64+0x15b2f4
0x00007FF712B5FA0A PHYSFS_swapULE64+0x15d3ba
0x00007FF712B63967 PHYSFS_swapULE64+0x161317
0x00007FF712B61F0E PHYSFS_swapULE64+0x15f8be
0x00007FF712B56B98 PHYSFS_swapULE64+0x154548
0x00007FF712A79F49 PHYSFS_swapULE64+0x778f9
0x00007FF712A233D8 PHYSFS_swapULE64+0x20d88
0x00007FF7129FF6A0 PHYSFS_swapULE64+0xffffffffffffd050
0x00007FF712BFAE25 PHYSFS_swapULE64+0x1f87d5
0x00007FFF402C3034 BaseThreadInitThunk+0x14
0x00007FFF41181431 `RtlUserThreadStart+0x21``

Plusieurs jours de tests approfondis, et je n'ai pas vu ce bug depuis
Problème de clôture.

Merci beaucoup Jarskih, RedV et JonnyH

Bug toujours actif en juillet 2019. Restaurez la partie sauvegardée, puis continuez. Erreur immédiate. Fermez la fenêtre d'erreur et cela se répète.
Image1
save_Shot down UFO.zip

Cette erreur persistera dans les sauvegardes - donc si la cause d'origine d'un mauvais StateRefs'est déjà produit, et que vous enregistrez, cela inclura cette "mauvaiseté" dans la sauvegarde, il n'est donc pas surprenant que le rechargement d'une sauvegarde "cassé" provoque la même erreur.

Le message d'erreur ci-dessus s'affiche lorsque le jeu essaie d'utiliser cet objet "cassé" et réalise que quelque chose ne va pas, pas une erreur en soi. L'échec peut s'être produit il y a quelque temps, juste l'objet cassé non encore utilisé.

Donc, si vous testez cela avec la même sauvegarde et que vous n'avez pas créé de nouveau jeu depuis le correctif, cela ne nous dit probablement pas grand-chose.

Oui, les 3 sauvegardes précédentes ont également buggé. Je peux revenir aux sauvegardes précédentes si cela peut aider.

Cette page vous a été utile?
0 / 5 - 0 notes