Une adresse a besoin de contexte
Une pile native peut contenir des adresses sans noms de fonctions utiles. La symbolication relie ces adresses aux artefacts de la version correspondante. La correspondance exacte compte : plateforme, architecture et identité du binaire sont plus fiables qu’un nom de fichier ressemblant à celui de la version. Les erreurs managées et natives peuvent nécessiter des enquêtes différentes.
Intégrer les artefacts à la livraison
Conservez les symboles produits par votre chaîne de compilation avec un identifiant de version stable. Évitez qu’un ordinateur de développeur soit la seule archive. Définissez qui y accède et combien de temps ils restent disponibles pour les versions prises en charge. Envoyez uniquement les formats compatibles avec l’intégration actuelle, puis vérifiez le résultat.
Vérifier avant un incident
Provoquez une erreur contrôlée dans une version de test pour vérifier que le rapport est exploitable. Confirmez la plateforme, la version et les fonctions résolues. Si des noms manquent, examinez la correspondance des artefacts et leur traitement avant de conclure à un défaut de capture. Ne remplacez pas un artefact par un autre binaire sous le même identifiant.
Relier le diagnostic à la santé de la version
Une pile lisible explique une erreur, mais ne définit pas sa priorité. Croisez le rapport avec la récurrence, les sessions touchées et la répartition des versions dans Pulseframe. Après correction, surveillez la nouvelle version tout en gardant les anciennes versions prises en charge visibles. Couverture des symboles et impact joueur sont deux questions distinctes : une bonne méthode répond aux deux.
