Some crash stacks report the wrong source line numbers |
||||
Issue description
If you load reports such as 648c8577d7a3f8f7, either in the Crash tool or loading the minidump into WinDbg, then the source lines sometimes seem to be incorrect. e.g. in this report the failure is listed at:
void MoveHoleDownAndFillWithLeafElement(size_t hole, T&& leaf_element) {
...
while (child_pos < size_) {
size_t second_child = child_pos + 1;
if (nodes_[second_child] <= nodes_[child_pos]) [1]
child_pos = second_child;
hole = MoveHole(child_pos, hole); [2]
child_pos *= 2;
}
...
}
Both Crash and WinDbg show the crash having been at [1], but based on the additional inlined stack entries displayed under WinDbg, the crash appears actually to have been at [2].
(I'll file a bug for this against LLVM and link here)
,
Jan 18 2018
I think we can dig into this by compiling work_queue_sets.cc (the file calling into intrusive_heap.h) and staring at the .cv_loc directives in the assembly for MoveHoleDownAndFillWithLeafElement.
,
Jan 18 2018
Yeah, things get messed up when we inline and we use the last location from the line table. Here's a small example:
volatile int x;
static void inline inlined() { __debugbreak(); }
int main() {
++x; // line 4
inlined(); // line 5
++x; // line 6
}
Here's windbg's stack trace:
0:000> k
# Child-SP RetAddr Call Site
00 (Inline Function) --------`-------- t!inlined [C:\src\llvm-project\build\t.cpp @ 2]
01 000000a3`1f99f958 00007ff7`136b8975 t!main+0xa [C:\src\llvm-project\build\t.cpp @ 4]
02 (Inline Function) --------`-------- t!invoke_main+0x22 [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 78]
03 000000a3`1f99f960 00007ff8`cb668364 t!__scrt_common_main_seh+0x11d [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 283]
04 000000a3`1f99f9a0 00007ff8`cb817091 KERNEL32!BaseThreadInitThunk+0x14
05 000000a3`1f99f9d0 00000000`00000000 ntdll!RtlUserThreadStart+0x21
The line number in 'main' is off by one.
We should have all the info we need already, we're just not correctly translating it into the line table format.
,
Jan 19 2018
,
Feb 21 2018
I think this is fixed now (?) |
||||
►
Sign in to add a comment |
||||
Comment 1 by thakis@chromium.org
, Jan 9 2018Cc: r...@chromium.org inglorion@chromium.org