Hi JS hackers,
I have a patch queue (unrelated to JS) that causes an (expected)
assertion to trigger in a mochitest, and when nsStackWalker is invoked
to print out a stack trace, it ends up crashing due to finding a bad
value on the stack. The second last valid frame printed is
js::jit::InvokeFunction, and the last valid frame printed is what I
assume to be in JIT code. The crashing frame pointer is 0xffffff88
(which I'm told is a magic number the JS engine uses).
I don't know if my patches are causing the problem or not (I'm hoping
not), so I have a couple of questions.
1. In a debug build, should JIT code always be stack walkable?
2. Is there an easy way one of you would be able to tell whether this is
a bug in the JITted code, or I can rule it out so I can look harder at
my patches or existing code? What information can I give to help?
The crash is easily reproducible; you can see it on try here
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=b02537901def
and I have an rr recording of it locally.
If I explicitly check for 0xffffff88 and abort the stack walking when I
find it, then the mochitest completes without a problem; so what the
stack walker is interpreting as a frame pointer must not actually be
used as a frame pointer in the end.
Grateful for any hints on how to proceed.
Thanks,
Cameron
_______________________________________________
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
