Opened 9 years ago
Closed 9 years ago
#6988 closed enhancement (fixed)
firefox-41.0.2
Reported by: | Fernando de Oliveira | Owned by: | |
---|---|---|---|
Priority: | high | Milestone: | 7.9 |
Component: | BOOK | Version: | SVN |
Severity: | normal | Keywords: | |
Cc: |
Description (last modified by )
https://ftp.mozilla.org/pub/firefox/releases/41.0.2/source/firefox-41.0.1.source.tar.xz
https://ftp.mozilla.org/pub/firefox/releases/41.0.2/MD5SUMS
d71f0f761c51aeae03e367001afc9f8d
https://ftp.mozilla.org/pub/firefox/releases/41.0.2/MD5SUMS.asc
Now 41.0.2, fixes Mozilla Foundation Security Advisory 2015-115
"Security researcher Abdulrahman Alqabandi reported that the fetch() API did not correctly implement the Cross-Origin Resource Sharing (CORS) specification, allowing a malicious page to access private data from other origins. Mozilla developer Ben Kelly independently reported the same issue. CVE-2015-7184"
Following 41.0.1 items NOT changed. In practice, that CVE is still marked as "reserved"
https://www.mozilla.org/en-US/security/known-vulnerabilities/firefox/#firefox41.0.1
Security Advisories for Firefox
Sorted by Impact key level, not original time stamp order.
None
https://www.mozilla.org/en-US/firefox/41.0.1/releasenotes/
Release Notes
Firefox Notes Version 41.0.1, first offered to Release channel users on September 30, 2015 View notes for: Desktop Android What’s New New • Reference: Release notes for Firefox 41.0 Fixed • Fix a startup crash related to Yandex toolbar and Adblock Plus (1209124) • Fix potential hangs with Flash plugins (1185639) • Fix a regression in the bookmark creation (1206376) • Fix a startup crash with some Intel Media Accelerator 3150 graphic cards (1207665) • Fix a graphic crash, occurring occasionally on Facebook (1178601)
Change History (6)
comment:1 by , 9 years ago
Description: | modified (diff) |
---|---|
Owner: | changed from | to
Status: | new → assigned |
Summary: | firefox-41.0.1 → firefox-41.0.2 |
comment:2 by , 9 years ago
Priority: | normal → high |
---|
comment:3 by , 9 years ago
Fixed at r16533, I do not understand why my -j1 elapsed time was so much less than for 41.0 (on the same machine, both running 7.8).
comment:4 by , 9 years ago
If what I write in the following is true, just add "using parallelism=N", where N is found below. No need to rebuild, for statistics.
In the past it happened to me, and after a couple of releases, I discovered that it was not honoring mozconfig and automatically setting the flag: MOZ_MAKE_FLAGS.
I find its value with
$ grep 'make -j' firefox-41.0-simulation-2015.09.30-19h08m32s.log make -j4 -C /tmp/mozilla-release/firefox-build-dir make -j4 -C /tmp/mozilla-release/firefox-build-dir install
That time, I discovered that no matter what I had in mozconfig, it gave never -j1, then introduced:
MOZ_MAKE_FLAGS='-jN' make -f client.mk MOZ_MAKE_FLAGS='-jN' make -f client.mk install INSTALL_SDK=
where N is an integer, 1 ≤ N ≤ threads/cpu.
Or define globally MOZ_MAKE_FLAGS for the build, with export ... unset may work.
If it is the same problem, hopefully, flag is still named MOZ_MAKE_FLAGS and solution above may work.
To be sure, no need for a complete build. Sufficient start the build until four or five lines after making splines.
comment:5 by , 9 years ago
Ken, Are you holding off closing this ticket for timing issues? I have this:
Laptop, parallelism=8 1133.2 Elapsed Time - firefox-41.0.2.source SBU=11.153
Development system, parallelism=12 972.6 Elapsed Time - firefox-41.0.2.source SBU=10.458
I have some changes I want to make to FF and friends for the new freetype. I also took #6998 so I can do all at the same time. If you want, I can close this when I'm done.
comment:6 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Didn't realise I'd forgotten to close it! I'm happy with the current SBU.
Interesting that going from 8 to 12 CPUs makes an insignificant difference to the SBU. I know that when I build with -j 4 and it eventually starts to do the linking everything grinds to a halt (in one case, literally - my desktop on a 4GB machine was unusable for a couple of minutes, and the clock didn't get updated during that), but perhaps the current code is not very parallelizable.
Changing priority to 'high' since this is now a vulnerability fix.