Debugger: onExceptionUnwind resumption values can cause assertions

RESOLVED FIXED in mozilla11

Status

()

Core
JavaScript Engine
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: jimb, Assigned: jimb)

Tracking

unspecified
mozilla11
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [inbound])

Attachments

(1 attachment)

(Assignee)

Description

6 years ago
Created attachment 572241 [details] [diff] [review]
Have stubs::AnyFrameEpilogue call the full ScriptEpilogue before StackFrame::functionEpilogue, not just ScriptDebugEpilogue after functionEpilogue.

The debugger tests don't try returning all four kinds of resumption values
from an onExceptionUnwind handler, and under JaegerMonkey, forcing a
constructor to return a primitive can cause an assertion:

Assertion failure: !args.rval().isPrimitive(), at /home/jimb/moz/dbg/js/src/jsinterp.cpp:651

This patch changes AnyFrameEpilogue to match what the interpreter and
mjit::Compiler::emitReturn does, and adds test cases for all the resumption
values.
Attachment #572241 - Flags: review?(jorendorff)
(Assignee)

Updated

6 years ago
Blocks: 687683
Comment on attachment 572241 [details] [diff] [review]
Have stubs::AnyFrameEpilogue call the full ScriptEpilogue before StackFrame::functionEpilogue, not just ScriptDebugEpilogue after functionEpilogue.

Does rearranging the order of ScriptEpilogue and functionEpilogue matter? It could if there's a JSD1 debugging hook that gets called from ScriptEpilogue, but I don't think it really matters. Either order is fine.

r=me.
Attachment #572241 - Flags: review?(jorendorff) → review+
(Assignee)

Comment 2

6 years ago
(In reply to Jason Orendorff [:jorendorff] from comment #1)
> Does rearranging the order of ScriptEpilogue and functionEpilogue matter? It
> could if there's a JSD1 debugging hook that gets called from ScriptEpilogue,
> but I don't think it really matters. Either order is fine.

I think it doesn't matter, because all functionEpilogue does is 'put' the call object or arguments object. Those objects have to work properly both before and after that call. If anyone can access the actual stack slots they used to alias, then I guess one could see that they're not aliased any more. But can they?
(Assignee)

Comment 3

6 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/4ecf595875a5
Status: NEW → ASSIGNED
Whiteboard: [inbound]

Comment 4

6 years ago
When pushing to inbound, please can you set the assignee & target milestone (https://wiki.mozilla.org/Tree_Rules/Inbound#Please_do_the_following_after_pushing_to_inbound), thanks :-)

https://hg.mozilla.org/mozilla-central/rev/4ecf595875a5
Assignee: general → jimb
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla11
(Assignee)

Comment 5

6 years ago
(In reply to Ed Morley [:edmorley] from comment #4)
> When pushing to inbound, please can you set the assignee & target milestone
> (https://wiki.mozilla.org/Tree_Rules/
> Inbound#Please_do_the_following_after_pushing_to_inbound), thanks :-)
> 
> https://hg.mozilla.org/mozilla-central/rev/4ecf595875a5

Thanks; I'll do this in the future.
You need to log in before you can comment on or make changes to this bug.