Closed Bug 1483865 Opened Last year Closed Last year

MOZ_ASSERT(uintptr_t(aPtr) < uintptr_t(&aPtr)) fails in rr chaos mode

Categories

(Core :: XPCOM, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla63
Tracking Status
firefox63 --- fixed

People

(Reporter: roc, Assigned: kmag)

Details

Attachments

(1 file)

This was added in https://hg.mozilla.org/integration/mozilla-inbound/rev/71f70ce6f9314111dc05fe8dceaac43edfda6659#l1.54.

rr chaos mode aggressively randomizes address space layout so the main thread stack could be anywhere, so this assertion often fires when running Firefox under chaos mode.

I'm not aware of any normative requirement that the Linux main thread stack be at the top of the address space. I see that it turned out not to be the case on Android.

Arguably rr chaos mode is not that important, but Mozilla developers have used it quite a bit. I suggest that this assertion is just too fragile and should be removed.
In fact, on some Linux platforms, the stack even grows up instead of down, so the address of the stack is pretty much guaranteed to not be at the top of the address space on those. Even outside those platforms, there's no guarantee it's top-most. That you can make it happen with rr chaos mode is an obvious demonstration that such guarantees don't exist.
(In reply to Mike Hommey [:glandium] from comment #1)
> In fact, on some Linux platforms, the stack even grows up instead of down

Not any Linux platforms that we support.
Assignee: nobody → kmaglione+bmo
This assertion was always meant to be a best-effort thing to catch obvious
errors, but the cases where the assumptions it makes fail have been growing. I
could remove it entirely, but I'd be happier keeping at least some basic
sanity checks.

This compromise continues allowing any address below the first argument
pointer, and extends the assertion to also allow anything more than 2KiB above
it. We could probably get away with stretching that to at least 4KiB, but 2
seems safer, and likely enough to catch the obvious cases.
Comment on attachment 9001733 [details]
Bug 1483865: Make NotStackAllocated assertion a bit safer. r?froydnj

Nathan Froyd [:froydnj] has approved the revision.
Attachment #9001733 - Flags: review+
Backout by shindli@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/dfc1e2e0156d
Backed out changeset a5f51c76930c for bustages in builds/worker/workspace/build/src/xpcom/components/nsComponentManager.cpp on a CLOSED TREE
Backed out changeset a5f51c76930c (Bug 1483865) for bustages in builds/worker/workspace/build/src/xpcom/components/nsComponentManager.cpp on a CLOSED TREE

Problematic push: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=a5f51c76930c49160bf5e909301d8e7f1a83e379&filter-resultStatus=testfailed&filter-resultStatus=busted&filter-resultStatus=exception&filter-classifiedState=unclassified
Failure: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&fromchange=8c6a05c61d397cc70412052f36670b2c452c1ec1&selectedJob=195351501
Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=195351501&repo=mozilla-inbound&lineNumber=10971

18:37:42     INFO -  mozmake.EXE[4]: *** [Unified_cpp_xpcom_components0.obj] Error 1
18:37:42     INFO -  mozmake.EXE[4]: Leaving directory 'z:/build/build/src/obj-firefox/xpcom/components'
18:37:42     INFO -  z:/build/build/src/config/recurse.mk:74: recipe for target 'xpcom/components/target' failed
18:37:42     INFO -  mozmake.EXE[3]: *** [xpcom/components/target] Error 2
18:37:42     INFO -  mozmake.EXE[3]: *** Waiting for unfinished jobs....
Flags: needinfo?(kmaglione+bmo)
https://hg.mozilla.org/mozilla-central/rev/47149b145d57
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
Flags: needinfo?(kmaglione+bmo)
You need to log in before you can comment on or make changes to this bug.