msvc-based stacktrace should also allow to determine the module image path
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 38/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- cpp
- Área
- operating-systems, tooling
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.
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 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?
- Lenguaje dominante
- C++
- Estrellas
- 497
- Forks
- 86
- Merge medio
- 8 d 20 h
- PR fusionados (30 d)
- 3
Guía de contribución
No hay ninguna guía de contribución indexada para este repositorio
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de boostorg/stacktrace
-
`std::formatter` specialization Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 52/100
boostorg/stacktrace#233 ·
-
Ошибка в Inscape Abierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 15/100
boostorg/stacktrace#211 · 1 comentario ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
boostorg/stacktrace#208 · 6 comentarios ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 48/100
boostorg/stacktrace#197 · 3 comentarios ·
-
Implementation with `libdwfl`? Abiertoenhancement help wanted
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
boostorg/stacktrace#176 · 1 comentario ·
Todos los issues de boostorg/stacktrace
Issues similares
-
ai_reviewed
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
ydb-platform/ydb#53869 · 3 comentarios ·
-
bug cert blocker needs triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
project-chip/connectedhomeip#74373 ·
-
[request] tracy/0.14.1 Abiertoupstream update
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
conan-io/conan-center-index#31035 ·
-
Bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
documentation
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
vllm-project/vllm-ascend#17329 ·