Crash addresses may be mistakenly attributed to RAII destructors

[iainireland]

In bug 1837205, we noticed a large number of crashes in JS::Rooted<T>::~Rooted, the destructor for an RAII type we use to root garbage-collected objects on the stack. Digging into the crashes, I noticed that ~30% of the crashes had the same two functions in their proto signature (js::Lambda and CloneFunctionReuseScript). Looking at a dozen or so minidumps, though, there was no consistent pattern in the instructions at the crash site. This is weird, because ~Rooted is (in release builds) a simple one-line function:

  ~Rooted() {
    MOZ_ASSERT(*this->stack == this);
    *this->stack = this->prev;
  }

Looking at the crash reports, it looks like many of them (and in particular most/all of the Lambda/CloneFunctionReuseScript reports) have stacks that look like this:

0  None     @0x00000001cf43041c               context
1  xul.dll  JS::Rooted<JSObject*>::~Rooted()  inlined
1  xul.dll  js::Lambda(...)                   scan

It seems plausible that we are getting crash addresses, scanning backwards through the address space until we find a known function, and then attributing them to that function. This might explain why ~Rooted shows up so frequently: it is usually inlined as the very last thing in a function, so any crash address after that point looks like it is part of the destructor.

This may be a problem in the stackwalker?

[gabrielesvelto]

This is most likely due to stack scanning. The crashes these come from are caused by flaky hardware so there's not much we can do.

[iainireland]

Can we detect these cases / filter them out somehow? If we knew how big each function was, we could detect when stack scanning started outside the bounds of the function we're reporting.

[luser]

Is that top frame JIT code? We've struggled with walking out of JIT frames since Spidermonkey grew a JIT. I'm not sure if anything has improved on that front.