Closed
Bug 1471310
Opened 8 years ago
Closed 8 years ago
Clear the Installed flag when removing the MemoryProtectionExceptionHandler
Categories
(Core :: JavaScript Engine, enhancement)
Core
JavaScript Engine
Tracking
()
RESOLVED
FIXED
mozilla63
| Tracking | Status | |
|---|---|---|
| firefox63 | --- | fixed |
People
(Reporter: away, Assigned: away)
Details
Attachments
(2 files)
|
1.50 KB,
patch
|
luke
:
review+
|
Details | Diff | Splinter Review |
|
1.30 KB,
patch
|
nbp
:
review+
|
Details | Diff | Splinter Review |
I have a feeling that this may be the reason behind some occasional oranges that I see around `MOZ_ASSERT(!sHandlingException)`.
Attachment #8987906 -
Flags: review?(luke)
Comment 1•8 years ago
|
||
What oranges are you seeing using this code path?
I added more uses of the Memory Protection handler with Bug 1437600. I am currently interested in any bug which might be related. I write down the analysis of these crashes in Bug 1263794.
I don't have access to those bugs.
Most recently I did a try run of switching Windows builds to clang-cl and hit this pretty frequently in xpcshell: https://treeherder.mozilla.org/#/jobs?repo=try&revision=278fc5b212a95fa15123c8887bb4662d0d6242de
But I've seen this assertion on and off for ages on try, I don't recall specific bugs.
Comment 3•8 years ago
|
||
Comment on attachment 8987906 [details] [diff] [review]
VEHorange
Review of attachment 8987906 [details] [diff] [review]:
-----------------------------------------------------------------
Hah, yes indeed.
Attachment #8987906 -
Flags: review?(luke) → review+
My patch merely moved the failure slightly later :(
Assertion failure: tree.empty(), at z:/build/build/src/js/src/ds/MemoryProtectionExceptionHandler.cpp:81
And worse, I don't even get .dmp files for these failures now.
nbp, I think I'll need your help investigating this...
Comment 6•8 years ago
|
||
(In reply to David Major [:dmajor] from comment #2)
> I don't have access to those bugs.
Done.
(In reply to David Major [:dmajor] from comment #4)
> Assertion failure: tree.empty(), at
> z:/build/build/src/js/src/ds/MemoryProtectionExceptionHandler.cpp:81
This assertion likely means that we are leaking a JSRuntime when we exit the program, or that we failed to unregister a memory region from the memory protection system (which would report false positive).
I am tempted to just remove this assertion and hope that it would be reported in some other ways by AWSY / DMD.
> Most recently I did a try run of switching Windows builds to clang-cl and
> hit this pretty frequently in xpcshell:
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=278fc5b212a95fa15123c8887bb4662d0d6242de
>
> But I've seen this assertion on and off for ages on try, I don't recall
> specific bugs.
It sounds to me that we the current SEGV handler is removed as soon as we hit a SEGV. But being able to reach the uninstall function would imply that the SEGV got caught and we might have executed the rest of the program without the memory protection SEGV handler.
I guess the easiest fix would be to use the same code in the SEGV handler and in the uninstall function. (i.e. if (sHandlingException.compareExachange(false, true)) … )
Flags: needinfo?(emanuel.hoogeveen)
(In reply to Nicolas B. Pierron [:nbp] {backlog: 39} from comment #6)
> I guess the easiest fix would be to use the same code in the SEGV handler
> and in the uninstall function. (i.e. if
> (sHandlingException.compareExachange(false, true)) … )
I'm not sure what this really buys over just clearing sExceptionHandlerInstalled.
> I am tempted to just remove this assertion and hope that it would be
> reported in some other ways by AWSY / DMD.
For very selfish reasons I'd be happy to do this and get unblocked, though I feel somewhat uneasy about it. Emanuel, any thoughts on this?
Emanuel hasn't been on Bugzilla in a while, and while I'd really like his input I can't afford to wait on this bug. We can tweak this later if necessary but for now let's try to get this landed.
Attachment #8988761 -
Flags: review?(nicolas.b.pierron)
Comment 9•8 years ago
|
||
I don't entirely understand whether this is causing oranges or if it's preventing useful output on existing oranges, but either way it doesn't seem like it's catching any actual problems so I'm fine with removing it.
> Emanuel hasn't been on Bugzilla in a while, and while I'd really like his input I can't afford to wait on this bug.
Sorry, I'll be properly back in about a week.
Flags: needinfo?(emanuel.hoogeveen)
Updated•8 years ago
|
Attachment #8988761 -
Flags: review?(nicolas.b.pierron) → review+
Comment 10•8 years ago
|
||
Pushed by dmajor@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/96b22e24de05
Clear the Installed flag when removing the MemoryProtectionExceptionHandler. r=luke
https://hg.mozilla.org/integration/mozilla-inbound/rev/83a705caf1f2
Disable the emptiness assertion in ProtectedRegionTree. r=nbp
Comment 11•8 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/96b22e24de05
https://hg.mozilla.org/mozilla-central/rev/83a705caf1f2
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox63:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
You need to log in
before you can comment on or make changes to this bug.
Description
•