Suppress GC when calling the API callback during error reporting

RESOLVED DUPLICATE of bug 908881

Status

()

RESOLVED DUPLICATE of bug 908881
5 years ago
5 years ago

People

(Reporter: terrence, Assigned: terrence)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 obsolete attachment)

(Assignee)

Description

5 years ago
Created attachment 793550 [details] [diff] [review]
hazard_expandErrorArgs-v0.diff

This is currently causing the static analysis to report hazards because the analysis does not do dataflow and, thus, cannot tell that callers that pass NULL to TwoByteCharsToUTF8CharsZ cannot JS_ReportError. I think it would be problematic in any case to receive an OOM in the middle of error reporting, so suppressing GC over this API exposed callback seems like the right thing to do, regardless of exact rooting.

Bill, is this assessment reasonable?
Attachment #793550 - Flags: review?(wmccloskey)
(Assignee)

Comment 1

5 years ago
Oh dear, that second doesn't actually logic when I re-read it. How about:

"I think it would be problematic in any case to make any significant use of JSAPI in the middle of error reporting, so suppressing GC should not change behavior in practice."
I'm pretty sure that this is not the only path that can GC during JS_ReportError. How will this actually fix the TwoByteCharsToUTF8CharsZ problem?
(Assignee)

Comment 3

5 years ago
Comment on attachment 793550 [details] [diff] [review]
hazard_expandErrorArgs-v0.diff

Derp, you are right. This will not fix anything. I will give this hazard some more thought.
Attachment #793550 - Attachment is obsolete: true
Attachment #793550 - Flags: review?(wmccloskey)
(Assignee)

Updated

5 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 908881
You need to log in before you can comment on or make changes to this bug.