Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

msvc-based stacktrace should also allow to determine the module image path

Ouverte
#129 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
38/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
À l'abandon
Stack technique
cpp

Piste de recherche

Commencez par localiser l’implémentation de stacktrace basée sur MSVC et examinez la manière dont elle détermine actuellement les noms des modules. Examinez IDebugSymbols::GetModuleByOffset, GetModuleNames et RtlCaptureStackBackTrace ; le travail est terminé lorsque les chemins des images des modules sont inclus et que le cas signalé d’un stacktrace vide est traité sans modifier le comportement existant de stacktrace.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

enhancement help wanted

The current msvc-based stacktrace only determines the module name - not its complete path - contrary to the full featured unixoid implementation. It turns out that this is rather simple to realize and valuable when attempting to analyze application problems by inspecting the referred to image paths. It means that you first calls IDebugSymbols::GetModuleByOffset followed by IDebugSymbols::GetModuleNames using the ImageNameBuffer, ImageNameBufferSize, and ImageNameSize parameters. I'm using this extended information in my own stacktrace implementation.

There is another way of improving the quality of msvc stacktraces related to the problem described capturestackbacktrace-randomly-fails-after-initial. I'm aware that the current stacktrace implementation has eliminated any explicit call of CoInitializeEx, but that does not prevent the user to make such a call. Instead of rewriting RtlCaptureStackBackTrace as suggested in this article, a very simple workaround seems to help here. Before calling RtlCaptureStackBackTrace with a static buffer (128), just call RtlCaptureStackBackTrace with the FramesToCapture equal to just 1 ignoring this stub call, which prevents the potential empty stacktrace situation for the second call.

Would there be interest for a corresponding PULL request?

Langage dominant
C++
Étoiles
497
Forks
86
Métriques de merge des PR
Aucune PR mergée en 30 j

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de boostorg/stacktrace

Toutes les issues de boostorg/stacktrace

Issues similaires

Plus d'issues C++

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.