Closed
Bug 700822
Opened 13 years ago
Closed 12 years ago
Land hardening option and win32 ExecutableAllocator randomization
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
FIXED
mozilla13
Tracking | Status | |
---|---|---|
firefox11 | - | --- |
People
(Reporter: cdleary, Assigned: cdleary)
References
Details
Attachments
(1 file)
888 bytes,
patch
|
bzbarsky
:
review+
|
Details | Diff | Splinter Review |
Separate bug for landing data/resolution, based on patch 2 in bug 677272 (which I should have split into different bugs to begin with). It's been rebased, pushed to try: https://hg.mozilla.org/try/pushloghtml?changeset=a19f0237eb77
Assignee | ||
Comment 1•13 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/ecc57a1b8b89 https://hg.mozilla.org/integration/mozilla-inbound/rev/1bf4c1a6412b
Target Milestone: --- → mozilla11
Comment 2•13 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/ecc57a1b8b89 https://hg.mozilla.org/mozilla-central/rev/1bf4c1a6412b
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Comment 3•13 years ago
|
||
ehr 1bf4c1a6412b has been backed out
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 4•13 years ago
|
||
Yeah, sorry about that -- I thought I had added a backout cset comment, but apparently not. Have to debug the frequent WinXP reftest failure caused by the win32 randomization patch today.
Assignee | ||
Updated•13 years ago
|
Status: REOPENED → ASSIGNED
Assignee | ||
Comment 5•13 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/6ea9d4ad53a0 (backout) Need to debug failing Windows XP reftest.
Target Milestone: mozilla11 → ---
Updated•13 years ago
|
tracking-firefox11:
--- → +
Assignee | ||
Comment 6•12 years ago
|
||
Take 2, with WinXP workaround: https://hg.mozilla.org/integration/mozilla-inbound/rev/9e93f190f64c It looked good on try, hopefully it sticks.
Target Milestone: --- → mozilla13
Assignee | ||
Comment 7•12 years ago
|
||
dvander gave post-push r+ on the workaround, because I felt like I could use a sanity check. Thanks, David!
Comment 8•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/9e93f190f64c
Status: ASSIGNED → RESOLVED
Closed: 13 years ago → 12 years ago
Resolution: --- → FIXED
Comment 9•12 years ago
|
||
Why do we need the separate RandomizeIsBrokenImpl and RandomizeIsBroken?
Comment 10•12 years ago
|
||
It's not clear why we need to track this for FF11. Please re-nominate if you disagree with this bug being untracked for FF11.
Assignee | ||
Comment 11•12 years ago
|
||
(In reply to Boris Zbarsky (:bz) from comment #9) > Why do we need the separate RandomizeIsBrokenImpl and RandomizeIsBroken? I was trying to get the compiler intrinsic guards for |static type val = expr()| to avoid calling RandomizeIsBroken twice if you race to create runtimes from different threads. Kind of a hack, but I think it should work out okay. I can file a followup bug if you think that's too heinous.
Comment 12•12 years ago
|
||
I thinks it's OK for that, assuming the compiler handles such a race correctly, but then you need a nice comment explaining that's what's going on!
Assignee | ||
Comment 13•12 years ago
|
||
(In reply to Boris Zbarsky (:bz) from comment #12) > I thinks it's OK for that, assuming the compiler handles such a race > correctly, but then you need a nice comment explaining that's what's going > on! Yeah, mea culpa. Will pastebin r? you on IRC in a little while for a comment patch. :-)
Assignee | ||
Comment 14•12 years ago
|
||
Attachment #600451 -
Flags: review?(bzbarsky)
Comment 15•12 years ago
|
||
Comment on attachment 600451 [details] [diff] [review] Add explanatory comment. r=me
Attachment #600451 -
Flags: review?(bzbarsky) → review+
Comment 16•12 years ago
|
||
Though are you sure that all our compilers do threadsafety stuff here?
Assignee | ||
Comment 17•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/941481edc290
Assignee | ||
Comment 18•12 years ago
|
||
(In reply to Boris Zbarsky (:bz) from comment #16) > Though are you sure that all our compilers do threadsafety stuff here? I'm not totally sure about MSVC, but, even if they do race, they're writing the same atomic-sized value (int) to the static, so you should get consistency anyway. Kind of hacky, but I'm not sure we even really support this mutliple runtimes racing for creation on multiple threads use case anyway, it's kind of a best-effort approach on my part for a simple thread-safe memoization.
You need to log in
before you can comment on or make changes to this bug.
Description
•