boostorg / boostorg/stacktrace

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

Abierto
#129 1 comentario 0 reacciones 0 asignados Ver en GitHub
enhancement help wanted
Lenguaje dominante
C++
Estrellas
494
Forks
86
Merge medio
8 d 20 h
PR fusionados (30 d)
3

Descripción

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](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/dbgeng/nf-dbgeng-idebugsymbols-getmodulebyoffset) followed by [IDebugSymbols::GetModuleNames](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/dbgeng/nf-dbgeng-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](https://developercommunity.visualstudio.com/t/capturestackbacktrace-randomly-fails-after-initial/1383213). 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?

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Línea de trabajo

Empieza localizando la implementación de stacktrace basada en MSVC y revisa cómo determina actualmente los nombres de los módulos. Revisa IDebugSymbols::GetModuleByOffset, GetModuleNames y RtlCaptureStackBackTrace; se considera terminado cuando se incluyen las rutas de las imágenes de los módulos y se aborda el caso de stacktrace vacío indicado, sin romper el comportamiento existente de stacktrace.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
cpp
Área
operating-systems, tooling
Tipo de issue
Nueva funcionalidad
Dificultad
4/5
Tiempo estimado
3-5 días
Estado de actividad
Estancado
Claridad
Bastante claro
Aptitud para principiantes
38/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.