New issue
Advanced search Search tips
Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Feb 21
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Blocked on:
issue 803661

Blocking:
issue 636111



Sign in to add a comment

Some crash stacks report the wrong source line numbers

Project Member Reported by w...@chromium.org, Jan 9 Back to list

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)
 
Blocking: 636111
Cc: r...@chromium.org inglorion@chromium.org
Owner: r...@chromium.org
Status: Assigned
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.
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.
Blockedon: 803661
Status: Fixed
I think this is fixed now (?)

Sign in to add a comment