Open Bug 1715467 Opened 3 years ago Updated 3 years ago

Investigate removing the check after frame pointer walking in DoMozStackWalkThread

Categories

(Core :: mozglue, task)

task

Tracking

()

People

(Reporter: glandium, Unassigned)

References

(Depends on 1 open bug)

Details

Followup for https://phabricator.services.mozilla.com/D115962?id=447107#inline-649839

The normal situation for stack walking on Win64 is that we take the program counter, check where the instruction is, and if it's in a known function, we use RtlVirtualUnwind, which hopefully allows to pseudo-unwind, giving us the register values as they would be were we to return from the function. When we're not in a know function, we check if the rbp register contains a value on the stack, and assume the address it points to contains the value of the next frame pointer. This can be used to traverse JIT frames, which, in most cases, do store and adjust the frame pointer (push rbp; mov rbp, rsp).

However, even when all the JIT frames involved do store and adjust the frame pointer, the first function that calls into the JIT (MaybeEnterJit) does not use the rbp register to store a frame pointer. So the last JIT frame we walk through will return a frame pointer that doesn't look like a valid one, and we currently stop stack-walking.

But in that situation, even though rbp is not a valid frame pointer, it is still the valid value that was in the register before the JIT was entered (assuming all the JIT frames did the right thing). The program counter value for where the JIT would return to, which we got at the same time, would be valid too (again, assuming all the JIT frames did the right thing), and so would the stack pointer. With all these values, we should find that the program counter points to a valid function, which would then make us call RtlVirtualUnwind, which would then find the next register values based on the unwind info, allowing to go further down the stack.

You need to log in before you can comment on or make changes to this bug.