Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle the end of unwinding better #193

Closed
Gankra opened this issue Jun 4, 2021 · 3 comments
Closed

Handle the end of unwinding better #193

Gankra opened this issue Jun 4, 2021 · 3 comments

Comments

@Gankra
Copy link
Collaborator

Gankra commented Jun 4, 2021

The end of an unwind is an awkward thing, because you need to distinguish between "this method failed to compute a caller frame" and "this method is confident that there are no more stack frames". Right now we don't bother making that distinction, and instead just always try all the methods, stopping only when they all fail. As a result we can "hallucinate" extra frames at the bottom of the stack with scanning.

Breakpad has some places where it considers a method computing "null" for certain register values as a confident assertion that the stack if fully unwound. This seems the most reasonable to do for CFI.

We should do better here, but the bottom of the stack is the least interesting so it's not a big deal if it's full of garbage.

@luser
Copy link
Collaborator

luser commented Jun 4, 2021

It might be worth thinking about the desired API here a little bit. Right now the GetCallerFrame returns Option<StackFrame>, so you either get a frame or you don't. It might be nice at the very least to use a tri-state enum like:

enum UnwindResult {
  Caller(StackFrame),
  NoMoreFrames,
  CouldNotUnwind,
}

@Gankra
Copy link
Collaborator Author

Gankra commented Jun 14, 2021

@Gankra
Copy link
Collaborator Author

Gankra commented Oct 16, 2021

done

@Gankra Gankra closed this as completed Oct 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants