msvc-based stacktrace should also allow to determine the module image path
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 38/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- cpp
- Lĩnh vực
- operating-systems, tooling
Hướng nghiên cứu
Bắt đầu bằng cách xác định phần triển khai stacktrace dựa trên MSVC và đọc cách nó hiện xác định tên module. Xem xét IDebugSymbols::GetModuleByOffset, GetModuleNames và RtlCaptureStackBackTrace; được xem là hoàn tất khi các đường dẫn image của module được đưa vào và trường hợp stacktrace rỗng được báo cáo được xử lý mà không làm hỏng hành vi stacktrace hiện có.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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?
- Ngôn ngữ chính
- C++
- Star
- 497
- Fork
- 86
- Merge trung bình
- 8 ngày 20 giờ
- Pull request đã merge (30 ngày)
- 3
Hướng dẫn đóng góp
Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của boostorg/stacktrace
-
`std::formatter` specialization Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 52/100
boostorg/stacktrace#233 ·
-
Ошибка в Inscape Đang mở
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 15/100
boostorg/stacktrace#211 · 1 bình luận ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
boostorg/stacktrace#208 · 6 bình luận ·
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 48/100
boostorg/stacktrace#197 · 3 bình luận ·
-
Implementation with `libdwfl`? Đang mởenhancement help wanted
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
boostorg/stacktrace#176 · 1 bình luận ·
Tất cả issue của boostorg/stacktrace
Issue tương tự
-
ai_reviewed
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
ydb-platform/ydb#53869 · 3 bình luận ·
-
bug cert blocker needs triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
project-chip/connectedhomeip#74373 ·
-
[request] tracy/0.14.1 Đang mởupstream update
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
conan-io/conan-center-index#31035 ·
-
Bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
-
documentation
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 85/100
vllm-project/vllm-ascend#17329 ·