searching for reviewer(glandium)
c43d2dbaf59e: Bug 1451891 - Fix race conditions in __wrap_dlerror. r=glandium a=pascalc
Jim Chen <nchen@mozilla.com> - Wed, 25 Jul 2018 13:59:30 -0400 - rev 478170
Push 9562 by nbeleuzu@mozilla.com at 2018-07-31 13:30 +0000
Bug 1451891 - Fix race conditions in __wrap_dlerror. r=glandium a=pascalc __wrap_dlerror uses a single pointer for all threads, which means one thread could get the dlerror result from another thread. Normally this wouldn't cause crashes. However, because dlerror results come from a per-thread buffer, if a thread exits and our saved dlerror result came from that thread, the saved pointer could then refer to invalid memory. The proper way to fix this is to use TLS and have a per-thread pointer for __wrap_dlerror. However, instead of using up a TLS slot, this patch keeps the single pointer for custom messages, and fallback to per-thread dlerror call for system messages. While the race condition still exists, I think the risk is acceptable. Even when races occur, they should no longer cause crashes. MozReview-Commit-ID: 4hGksidjiVz
5cc046f46541: Bug 1469676 - Reduce max-run-time for various build tasks; r=glandium
Gregory Szorc <gps@mozilla.com> - Wed, 20 Jun 2018 20:59:01 +0000 - rev 477347
Push 9382 by cbrindusan@mozilla.com at 2018-06-21 15:23 +0000
Bug 1469676 - Reduce max-run-time for various build tasks; r=glandium The max-run-time for tasks appears to have been mostly cargo culted. In particular, a value of 36000 (10 hours) is quite absurd: no single task takes that long to execute. This commit reduces the max-run-time of several tasks to more reasonable values. The goal here is to prevent excessively long-running tasks. There is definitely room to further tweak values to further mitigate long-running tasks. But let's bite off the biggest chunk first, since that doesn't require much mental effort. There is a possibility I overshot on some of these tasks. If we get timeouts, we can always increase the timeout again. Differential Revision: https://phabricator.services.mozilla.com/D1716
a7384267f89c: Bug 1460989 - Hold system linker lock while modifying debug map. r=glandium, a=RyanVM
Jim Chen <nchen@mozilla.com> - Fri, 15 Jun 2018 04:24:10 -0400 - rev 476921
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1460989 - Hold system linker lock while modifying debug map. r=glandium, a=RyanVM When we modify the debug map, we could be racing with the system linker, either when we modify the entries or when we change page protection flags. To fix the race, we need to take the system linker's internal lock when we perform any kind of modification on the debug map. One way to hold the system linker lock is to call dl_iterate_phdr, and perform our actions inside the callback, which is invoked with the lock being held. However, dl_iterate_phdr is only present on Android 5.0+, and even then, dl_iterate_phdr is only protected by the linker lock on Android 6.0+. This means that with this patch, we can only safely modify the debug map on Android 6.0+, which I think is acceptable for an operation that only benefits a debugger. MozReview-Commit-ID: BowBEO8tu8Z
05c128083f25: Bug 1464501 - Part 2: Install rust-size toolchain. r=glandium
Eric Rahm <erahm@mozilla.com> - Thu, 07 Jun 2018 17:06:48 -0700 - rev 476856
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1464501 - Part 2: Install rust-size toolchain. r=glandium
9c26abfd1b73: Bug 1464501 - Part 1: Add rust-size toolchain. r=glandium
Eric Rahm <erahm@mozilla.com> - Thu, 07 Jun 2018 16:47:58 -0700 - rev 476855
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1464501 - Part 1: Add rust-size toolchain. r=glandium
7e85e1b2f6fa: Bug 1464501 - Part 2: Install rust-size toolchain. r=glandium
Eric Rahm <erahm@mozilla.com> - Thu, 07 Jun 2018 17:06:48 -0700 - rev 476718
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1464501 - Part 2: Install rust-size toolchain. r=glandium
e891ab259427: Bug 1464501 - Part 1: Add rust-size toolchain. r=glandium
Eric Rahm <erahm@mozilla.com> - Thu, 07 Jun 2018 16:47:58 -0700 - rev 476717
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1464501 - Part 1: Add rust-size toolchain. r=glandium
badcfe94e6a7: Bug 1466242 Look for Sprintf.h instead of Assertions.h in the symbolstore test r=glandium
Tom Ritter <tom@mozilla.com> - Tue, 05 Jun 2018 10:44:03 -0500 - rev 476119
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1466242 Look for Sprintf.h instead of Assertions.h in the symbolstore test r=glandium It turns out sometimes (in the LTO+CFI case at least) Assertions.h will not be present in the opt build, presumably because it was optimized out. MozReview-Commit-ID: GB3GIoSdIUK
cdaaa5caac74: Bug 1467605 - Disable processing of fetch dependencies; r=glandium
Gregory Szorc <gps@mozilla.com> - Thu, 07 Jun 2018 23:05:58 +0000 - rev 476099
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1467605 - Disable processing of fetch dependencies; r=glandium 90dca0906337 accidentally broke `mach artifact toolchain --from-build` because that code is attempting to load toolchain tasks in isolation. The new "use_fetches" transform added to toolchain tasks requires that "fetch" tasks are already processed and their references are available to toolchain tasks. This commit adds a mechanism to effectively disable the "use_fetches" transform when called by `mach artifact toolchain`. It is a hack. I suspect future planned work around artifacts/fetches will necessitate additional changes to the `mach artifact toolchain` code. But this can be deferred to a later day: this commit unbusts `mach artifact toolchain` and isn't super hacky, so it seems more reasonable than backing out fetch tasks completely. Differential Revision: https://phabricator.services.mozilla.com/D1588
12b8065ee9fc: Bug 1452204 part 2 - Use RtlCaptureContext to capture context for current thread and remove walker thread. r=glandium
Xidorn Quan <me@upsuper.org> - Mon, 04 Jun 2018 19:23:27 +1000 - rev 475949
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1452204 part 2 - Use RtlCaptureContext to capture context for current thread and remove walker thread. r=glandium GetThreadContext() returns a context pointing to its own frame when it gets called with the current thread handle. That frame can go away after it returns. This patch instead uses RtlCaptureContext(), which captures the context of its caller, when walking the current thread. In the past, we also used a walker thread when nullptr is passed in for aThread, but the check doesn't cover all the cases, and having another thread is apparently more complicated than this approach. MozReview-Commit-ID: 3TAatDc9BLh
6df1a71c5fe2: Bug 1452204 part 1 - Correctly set walkCallingThread. r=glandium
Xidorn Quan <me@upsuper.org> - Mon, 04 Jun 2018 19:17:32 +1000 - rev 475948
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1452204 part 1 - Correctly set walkCallingThread. r=glandium GetCurrentThread() returns a pseudo handle, so comparing it against the passed in argument doesn't make sense in most cases. This patch changes it to using the thread id for comparison, which is guaranteed to be unique in the whole lifetime of a thread. MozReview-Commit-ID: 5TNAgLkcS6m
90dca0906337: Bug 1460777 - Taskgraph tasks for retrieving remote content; r=dustin, glandium
Gregory Szorc <gps@mozilla.com> - Wed, 06 Jun 2018 14:37:49 -0700 - rev 475857
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1460777 - Taskgraph tasks for retrieving remote content; r=dustin, glandium Currently, many tasks fetch content from the Internets. A problem with that is fetching from the Internets is unreliable: servers may have outages or be slow; content may disappear or change out from under us. The unreliability of 3rd party services poses a risk to Firefox CI. If services aren't available, we could potentially not run some CI tasks. In the worst case, we might not be able to release Firefox. That would be bad. In fact, as I write this, gmplib.org has been unavailable for ~24 hours and Firefox CI is unable to retrieve the GMP source code. As a result, building GCC toolchains is failing. A solution to this is to make tasks more hermetic by depending on fewer network services (which by definition aren't reliable over time and therefore introduce instability). This commit attempts to mitigate some external service dependencies by introducing the *fetch* task kind. The primary goal of the *fetch* kind is to obtain remote content and re-expose it as a task artifact. By making external content available as a cached task artifact, we allow dependent tasks to consume this content without touching the service originally providing that content, thus eliminating a run-time dependency and making tasks more hermetic and reproducible over time. We introduce a single "fetch-url" "using" flavor to define tasks that fetch single URLs and then re-expose that URL as an artifact. Powering this is a new, minimal "fetch" Docker image that contains a "fetch-content" Python script that does the work for us. We have added tasks to fetch source archives used to build the GCC toolchains. Fetching remote content and re-exposing it as an artifact is not very useful by itself: the value is in having tasks use those artifacts. We introduce a taskgraph transform that allows tasks to define an array of "fetches." Each entry corresponds to the name of a "fetch" task kind. When present, the corresponding "fetch" task is added as a dependency. And the task ID and artifact path from that "fetch" task is added to the MOZ_FETCHES environment variable of the task depending on it. Our "fetch-content" script has a "task-artifacts" sub-command that tasks can execute to perform retrieval of all artifacts listed in MOZ_FETCHES. To prove all of this works, the code for fetching dependencies when building GCC toolchains has been updated to use `fetch-content`. The now-unused legacy code has been deleted. This commit improves the reliability and efficiency of GCC toolchain tasks. Dependencies now all come from task artifacts and should always be available in the common case. In addition, `fetch-content` downloads and extracts files concurrently. This makes it faster than the serial application which we were previously using. There are some things I don't like about this commit. First, a new Docker image and Python script for downloading URLs feels a bit heavyweight. The Docker image is definitely overkill as things stand. I can eventually justify it because I want to implement support for fetching and repackaging VCS repositories and for caching Debian packages. These will require more packages than what I'm comfortable installing on the base Debian image, therefore justifying a dedicated image. The `fetch-content static-url` sub-command could definitely be implemented as a shell script. But Python is readily available and is more pleasant to maintain than shell, so I wrote it in Python. `fetch-content task-artifacts` is more advanced and writing it in Python is more justified, IMO. FWIW, the script is Python 3 only, which conveniently gives us access to `concurrent.futures`, which facilitates concurrent download. `fetch-content` also duplicates functionality found elsewhere. generic-worker's task payload supports a "mounts" feature which facilitates downloading remote content, including from a task artifact. However, this feature doesn't exist on docker-worker. So we have to implement downloading inside the task rather than at the worker level. I concede that if all workers had generic-worker's "mounts" feature and supported concurrent download, `fetch-content` wouldn't need to exist. `fetch-content` also duplicates functionality of `mach artifact toolchain`. I probably could have used `mach artifact toolchain` instead of writing `fetch-content task-artifacts`. However, I didn't want to introduce the requirement of a VCS checkout. `mach artifact toolchain` has its origins in providing a feature to the build system. And "fetching artifacts from tasks" is a more generic feature than that. I think it should be implemented as a generic feature and not something that is "toolchain" specific. I think the best place for a generic "fetch content" feature is in the worker, where content can be defined in the task payload. But as explained above, that feature isn't universally available. The next best place is probably run-task. run-task already performs generic, very-early task preparation steps, such as performing a VCS checkout. I would like to fold `fetch-content` into run-task and make it all driven by environment variables. But run-task is currently Python 2 and achieving concurrency would involve a bit of programming (or adding package dependencies). I may very well port run-task to Python 3 and then fold fetch-content into it. Or maybe we leave `fetch-content` as a standalone script. MozReview-Commit-ID: AGuTcwNcNJR
e54687f110b1: Bug 1460777 - Extract GPG keys to standalone files; r=glandium
Gregory Szorc <gps@mozilla.com> - Fri, 11 May 2018 10:38:35 -0700 - rev 475856
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1460777 - Extract GPG keys to standalone files; r=glandium After this change, we consistently import GPG keys from files in the GCC build scripts. MozReview-Commit-ID: BcyvCQoGbMS
52ef9348401d: Bug 1460777 - Taskgraph tasks for retrieving remote content; r=dustin,glandium
Gregory Szorc <gps@mozilla.com> - Wed, 06 Jun 2018 09:37:38 -0700 - rev 475842
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1460777 - Taskgraph tasks for retrieving remote content; r=dustin,glandium Currently, many tasks fetch content from the Internets. A problem with that is fetching from the Internets is unreliable: servers may have outages or be slow; content may disappear or change out from under us. The unreliability of 3rd party services poses a risk to Firefox CI. If services aren't available, we could potentially not run some CI tasks. In the worst case, we might not be able to release Firefox. That would be bad. In fact, as I write this, gmplib.org has been unavailable for ~24 hours and Firefox CI is unable to retrieve the GMP source code. As a result, building GCC toolchains is failing. A solution to this is to make tasks more hermetic by depending on fewer network services (which by definition aren't reliable over time and therefore introduce instability). This commit attempts to mitigate some external service dependencies by introducing the *fetch* task kind. The primary goal of the *fetch* kind is to obtain remote content and re-expose it as a task artifact. By making external content available as a cached task artifact, we allow dependent tasks to consume this content without touching the service originally providing that content, thus eliminating a run-time dependency and making tasks more hermetic and reproducible over time. We introduce a single "fetch-url" "using" flavor to define tasks that fetch single URLs and then re-expose that URL as an artifact. Powering this is a new, minimal "fetch" Docker image that contains a "fetch-content" Python script that does the work for us. We have added tasks to fetch source archives used to build the GCC toolchains. Fetching remote content and re-exposing it as an artifact is not very useful by itself: the value is in having tasks use those artifacts. We introduce a taskgraph transform that allows tasks to define an array of "fetches." Each entry corresponds to the name of a "fetch" task kind. When present, the corresponding "fetch" task is added as a dependency. And the task ID and artifact path from that "fetch" task is added to the MOZ_FETCHES environment variable of the task depending on it. Our "fetch-content" script has a "task-artifacts" sub-command that tasks can execute to perform retrieval of all artifacts listed in MOZ_FETCHES. To prove all of this works, the code for fetching dependencies when building GCC toolchains has been updated to use `fetch-content`. The now-unused legacy code has been deleted. This commit improves the reliability and efficiency of GCC toolchain tasks. Dependencies now all come from task artifacts and should always be available in the common case. In addition, `fetch-content` downloads and extracts files concurrently. This makes it faster than the serial application which we were previously using. There are some things I don't like about this commit. First, a new Docker image and Python script for downloading URLs feels a bit heavyweight. The Docker image is definitely overkill as things stand. I can eventually justify it because I want to implement support for fetching and repackaging VCS repositories and for caching Debian packages. These will require more packages than what I'm comfortable installing on the base Debian image, therefore justifying a dedicated image. The `fetch-content static-url` sub-command could definitely be implemented as a shell script. But Python is readily available and is more pleasant to maintain than shell, so I wrote it in Python. `fetch-content task-artifacts` is more advanced and writing it in Python is more justified, IMO. FWIW, the script is Python 3 only, which conveniently gives us access to `concurrent.futures`, which facilitates concurrent download. `fetch-content` also duplicates functionality found elsewhere. generic-worker's task payload supports a "mounts" feature which facilitates downloading remote content, including from a task artifact. However, this feature doesn't exist on docker-worker. So we have to implement downloading inside the task rather than at the worker level. I concede that if all workers had generic-worker's "mounts" feature and supported concurrent download, `fetch-content` wouldn't need to exist. `fetch-content` also duplicates functionality of `mach artifact toolchain`. I probably could have used `mach artifact toolchain` instead of writing `fetch-content task-artifacts`. However, I didn't want to introduce the requirement of a VCS checkout. `mach artifact toolchain` has its origins in providing a feature to the build system. And "fetching artifacts from tasks" is a more generic feature than that. I think it should be implemented as a generic feature and not something that is "toolchain" specific. I think the best place for a generic "fetch content" feature is in the worker, where content can be defined in the task payload. But as explained above, that feature isn't universally available. The next best place is probably run-task. run-task already performs generic, very-early task preparation steps, such as performing a VCS checkout. I would like to fold `fetch-content` into run-task and make it all driven by environment variables. But run-task is currently Python 2 and achieving concurrency would involve a bit of programming (or adding package dependencies). I may very well port run-task to Python 3 and then fold fetch-content into it. Or maybe we leave `fetch-content` as a standalone script. MozReview-Commit-ID: AGuTcwNcNJR
60ed097650b8: Bug 1460777 - Extract GPG keys to standalone files; r=glandium
Gregory Szorc <gps@mozilla.com> - Fri, 11 May 2018 10:38:35 -0700 - rev 475841
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1460777 - Extract GPG keys to standalone files; r=glandium After this change, we consistently import GPG keys from files in the GCC build scripts. MozReview-Commit-ID: BcyvCQoGbMS
2c96cab39473: Bug 1464869 - Fix flake8/pep8 issue by hand in accessible/ r=glandium
Sylvestre Ledru <sledru@mozilla.com> - Fri, 25 May 2018 23:13:28 -0700 - rev 475762
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1464869 - Fix flake8/pep8 issue by hand in accessible/ r=glandium MozReview-Commit-ID: 5hKo37QtOtz
a9f0b8f30751: Bug 1464869 - Run autopep8 on accessible r=glandium
Sylvestre Ledru <sledru@mozilla.com> - Fri, 25 May 2018 23:13:03 -0700 - rev 475761
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1464869 - Run autopep8 on accessible r=glandium MozReview-Commit-ID: BvNs14gxYdr
79526c87b470: Bug 1464869 - Fix flake8/pep8 issue by hand in mozglue/ r=glandium
Sylvestre Ledru <sledru@mozilla.com> - Fri, 25 May 2018 21:28:12 -0700 - rev 475758
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1464869 - Fix flake8/pep8 issue by hand in mozglue/ r=glandium MozReview-Commit-ID: 4U31tUZPm8U
c6bccca0305d: Bug 1466746 - Install python-zstandard in debian-base; r=glandium
Gregory Szorc <gps@mozilla.com> - Mon, 04 Jun 2018 23:21:19 -0700 - rev 475727
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1466746 - Install python-zstandard in debian-base; r=glandium Let's install python-zstandard for both Python 2 and Python 3 in all our Debian-based images so it is readily available for use. MozReview-Commit-ID: 1L8zDc5MYXA
ff61a3c3aa07: Bug 1466746 - Debian packages for python-zstandard; r=glandium
Gregory Szorc <gps@mozilla.com> - Mon, 04 Jun 2018 23:10:59 -0700 - rev 475726
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1466746 - Debian packages for python-zstandard; r=glandium python-zstandard's 0.9.1 source distribution contains a debian/ directory. On Squeeze, producing a Debian package is straightforward. On Wheezy, we need to hack up Build-Depends because Wheezy doesn't have a package for the Hypothesis fuzzing library. This package is only used for testing and our package building disables testing, so we don't even need to further hack up the packaging to disable tests. MozReview-Commit-ID: 6raXjdzggCH
6db1c34fc853: Bug 1466746 - dh-python backport for wheezy; r=glandium
Gregory Szorc <gps@mozilla.com> - Mon, 04 Jun 2018 23:06:01 -0700 - rev 475725
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1466746 - dh-python backport for wheezy; r=glandium dh-python isn't available in Wheezy. Let's backport it so we can build Python packages that use it. Fortunately for us, the package builds without any modifications. The only customization we need is to ensure our custom Python packages are present in order to satisfy Build-Depends. MozReview-Commit-ID: CqZtwvosA6K
bb7dec4331c1: Bug 1457482 Add --enable-lto that turns on LTO r=glandium
Tom Ritter <tom@mozilla.com> - Fri, 13 Apr 2018 15:55:39 -0500 - rev 475720
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1457482 Add --enable-lto that turns on LTO r=glandium MozReview-Commit-ID: DjICW7OKqzB
8b89c933a703: Bug 1457482 Add an LTO Build Target r=glandium
Tom Ritter <tom@mozilla.com> - Wed, 30 May 2018 12:27:25 -0500 - rev 475719
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1457482 Add an LTO Build Target r=glandium This build target doesn't have LTO enabled on it (yet) MozReview-Commit-ID: 56tAHMyvH7o
36132fa62b44: Bug 1457482 Correct elfhack's LTO detection to handle -flto=thin r=glandium
Tom Ritter <tom@mozilla.com> - Fri, 01 Jun 2018 10:10:16 -0500 - rev 475718
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1457482 Correct elfhack's LTO detection to handle -flto=thin r=glandium MozReview-Commit-ID: LnDLrDN0W9O
bfc39006be1b: Bug 1457482 Add lld to the clang-6-pre-linux64 toolchain for use in the LTO build r=glandium
Tom Ritter <tom@mozilla.com> - Fri, 13 Apr 2018 15:22:57 -0500 - rev 475717
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1457482 Add lld to the clang-6-pre-linux64 toolchain for use in the LTO build r=glandium MozReview-Commit-ID: KYY0DqFxbDE
4431cecd4c2d: Bug 1452204 part 2 - Use RtlCaptureContext to capture context for current thread. r=glandium
Xidorn Quan <me@upsuper.org> - Mon, 04 Jun 2018 19:23:27 +1000 - rev 475528
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1452204 part 2 - Use RtlCaptureContext to capture context for current thread. r=glandium GetThreadContext() returns a context pointing to its own frame when it gets called with the current thread handle. That frame can go away after it returns. This patch instead uses RtlCaptureContext(), which captures the context of its caller, when walking the current thread. MozReview-Commit-ID: 3TAatDc9BLh
72fc40daf6cd: Bug 1452204 part 1 - Correctly set walkCallingThread. r=glandium
Xidorn Quan <me@upsuper.org> - Mon, 04 Jun 2018 19:17:32 +1000 - rev 475527
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1452204 part 1 - Correctly set walkCallingThread. r=glandium GetCurrentThread() returns a pseudo handle, so comparing it against the passed in argument doesn't make sense in most cases. This patch changes it to using the thread id for comparison, which is guaranteed to be unique in the whole lifetime of a thread. MozReview-Commit-ID: 5TNAgLkcS6m
73a2ea4007a0: Bug 1465585: Disable stl wrapping in some places under toolkit/mozapps/update. r=glandium
Emilio Cobos Álvarez <emilio@crisal.io> - Thu, 31 May 2018 17:09:47 +0200 - rev 475078
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1465585: Disable stl wrapping in some places under toolkit/mozapps/update. r=glandium This is disabled already in updater-common.build and similar places, so that they can use UniquePtr and include <new>. These files were getting around it because they didn't include the stl at all, but now they include <utility> transitively for std::move. MozReview-Commit-ID: IaU9mRbbCAk
314e3ae1520f: Bug 1461851 - Properly add the source URL in the profiler metadata. r=glandium
Panos Astithas <past@mozilla.com> - Tue, 15 May 2018 16:44:44 -0700 - rev 474666
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1461851 - Properly add the source URL in the profiler metadata. r=glandium MozReview-Commit-ID: 53M4bGolmJk
602bdd9d5a96: Bug 1461851 - Properly add the source URL in the profiler metadata. r=glandium
Panos Astithas <past@mozilla.com> - Tue, 15 May 2018 16:44:44 -0700 - rev 474662
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1461851 - Properly add the source URL in the profiler metadata. r=glandium MozReview-Commit-ID: 53M4bGolmJk
a4465713555b: Bug 1460989 - Check page protection flags again after mprotect(); r=glandium
Jim Chen <nchen@mozilla.com> - Wed, 30 May 2018 11:47:07 -0400 - rev 474661
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1460989 - Check page protection flags again after mprotect(); r=glandium We are apparently still crashing even after mprotect() with write flag returns successfully. This patch reads the flags again after mprotect() returns, and hopefully the flags will tell the truth of whether the page is truly writable or not after calling mprotect(). MozReview-Commit-ID: Jsg8vHKFEvJ
97a4c70be42c: Bug 1461982 - Tidy up pref replacement. r=glandium
Nicholas Nethercote <nnethercote@mozilla.com> - Mon, 21 May 2018 11:56:05 +1000 - rev 474064
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1461982 - Tidy up pref replacement. r=glandium MozReview-Commit-ID: DYSxB3aqxIG
da719c9ebc3b: Bug 1461982 - Factor out some repeated code. r=glandium.
Nicholas Nethercote <nnethercote@mozilla.com> - Mon, 21 May 2018 11:54:18 +1000 - rev 474063
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1461982 - Factor out some repeated code. r=glandium. MozReview-Commit-ID: 10MmfP5hmvn
1becc594554c: Bug 1460600: Remove unsupported --enable-system-hunspell flag. r=glandium
Kris Maglione <maglione.k@gmail.com> - Thu, 10 May 2018 10:36:53 -0700 - rev 473641
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1460600: Remove unsupported --enable-system-hunspell flag. r=glandium Our bundled Hunspell now significantly differs from upstream Hunspell. Most importantly, it supports loading dictionaries from jar: URIs, which is now a requirement for loading bundled and extension dictionaries. This means that system Hunspell libraries are no longer compatible with our spell checker code. We should remove the option to use them so that users don't fall into the trap of trying to use them. MozReview-Commit-ID: 2ihJe6YOnGf
144d50bc6891: Bug 1460720 Do not define _aligned_malloc - instead define _aligned_malloc_impl and export _aligned_malloc r=glandium
Tom Ritter <tom@mozilla.com> - Tue, 15 May 2018 11:10:48 -0500 - rev 473047
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1460720 Do not define _aligned_malloc - instead define _aligned_malloc_impl and export _aligned_malloc r=glandium MozReview-Commit-ID: 3EwAd81Iz7r
8d15ab11df3b: Bug 1420350 Enable jemalloc on MinGW r=glandium
Tom Ritter <tom@mozilla.com> - Wed, 07 Mar 2018 10:49:28 -0600 - rev 473046
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1420350 Enable jemalloc on MinGW r=glandium MozReview-Commit-ID: 6YUeFAJocHj
813d8cffc9c9: Bug 1457295 Trick clang+lld+lto into ordering NSModules correctly also r=glandium
Tom Ritter <tom@mozilla.com> - Fri, 27 Apr 2018 09:29:37 -0500 - rev 472928
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1457295 Trick clang+lld+lto into ordering NSModules correctly also r=glandium MozReview-Commit-ID: 4JgOOVhA3YU
f4a56903882a: Bug 1457483 Retrieve nm from environment for check_vanilla_allocations.py r=glandium
Tom Ritter <tom@mozilla.com> - Fri, 27 Apr 2018 10:25:35 -0500 - rev 472925
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1457483 Retrieve nm from environment for check_vanilla_allocations.py r=glandium MozReview-Commit-ID: HIZpMk4Ierb
8c97493f2d4c: Bug 1448749 Resolve undefined references to '_imp__mozalloc_abort' in the MinGW build r=glandium
Tom Ritter <tom@mozilla.com> - Wed, 16 May 2018 22:02:05 -0500 - rev 472856
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1448749 Resolve undefined references to '_imp__mozalloc_abort' in the MinGW build r=glandium MozReview-Commit-ID: 5enjU5Xp8G9
cab870519a15: Bug 1443823 Apply no-keep-inline-dllexport to MinGW x64 also r=glandium
Tom Ritter <tom@mozilla.com> - Fri, 23 Mar 2018 14:35:30 -0500 - rev 472761
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1443823 Apply no-keep-inline-dllexport to MinGW x64 also r=glandium MozReview-Commit-ID: 2Nyw738ZHou
eac1b2073bf4: Bug 1456183 - Add gio-unix as part of the list of GTK dependencies. r=glandium
Nicolas B. Pierron <nicolas.b.pierron@gmail.com> - Thu, 26 Apr 2018 10:14:40 +0000 - rev 472740
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1456183 - Add gio-unix as part of the list of GTK dependencies. r=glandium
23b5cf2c6824: Bug 1457483 Retrieve nm from environment for check_vanilla_allocations.py r=glandium
Tom Ritter <tom@mozilla.com> - Fri, 27 Apr 2018 10:25:35 -0500 - rev 472715
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1457483 Retrieve nm from environment for check_vanilla_allocations.py r=glandium MozReview-Commit-ID: HIZpMk4Ierb
77041935decb: Bug 1422930 - Fix SpiderMonkey includedir installs. r=glandium
Philip Chimento <philip.chimento@gmail.com> - Mon, 14 May 2018 10:29:00 -0400 - rev 472520
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1422930 - Fix SpiderMonkey includedir installs. r=glandium Somehow the header files were being installed directly into $prefix/include, rather than $prefix/include/mozjs-60. Something else changed somewhere that affected this, since this code was the same in older mozjs versions, but this seems the most logical place to fix it.
fcfbfc7d96d9: Bug 1401776 - Raise fd limit to 4096 on Unix. r=glandium,mcmanus
Jed Davis <jld@mozilla.com> - Thu, 10 May 2018 17:36:32 -0600 - rev 472457
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1401776 - Raise fd limit to 4096 on Unix. r=glandium,mcmanus This is to accommodate non-networking fd usage (IPC transports, various databases, .xpi files, etc.), so it's separate from Necko's existing manipulation of the fd limit, which is tied into Necko's internal limits on how many sockets it will try to poll at once. Note that resource limits are inherited by child processes, so this needs to be done only in the parent. This patch also removes similar code used on Solaris and Mac OS X. The Mac case (bug 1036682) refers to fd use by graphics textures, which shouldn't be consuming fds anymore (even transiently) as of bug 1161166. MozReview-Commit-ID: 2uodrkW5sUn
1591f55d3e32: Bug 1457359 - Update mp4parse and disable FallibleVec when jemalloc is disabled. r=glandium,jya
Matthew Gregan <kinetik@flim.org> - Thu, 10 May 2018 12:11:51 +1200 - rev 472054
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1457359 - Update mp4parse and disable FallibleVec when jemalloc is disabled. r=glandium,jya Update mp4parse-rust to 0c8e1d91464aaa63b82ebf076b63cda1df4230d1, which adds uuid parsing support and exports the mp4parse_fallible feature from mp4parse_capi. Update gkrust to pass MOZ_MEMORY as a feature, and use that to conditionally enable mp4parse_fallible/FallibleVec. MozReview-Commit-ID: 2HDYbL2CGgJ
b5fac38dc791: Bug 1457359 - Update mp4parse and disable FallibleVec when jemalloc is disabled. r=glandium,jya
Matthew Gregan <kinetik@flim.org> - Thu, 10 May 2018 12:11:51 +1200 - rev 472045
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1457359 - Update mp4parse and disable FallibleVec when jemalloc is disabled. r=glandium,jya Update mp4parse-rust to 0c8e1d91464aaa63b82ebf076b63cda1df4230d1, which adds uuid parsing support and exports the mp4parse_fallible feature from mp4parse_capi. Update gkrust to pass MOZ_MEMORY as a feature, and use that to conditionally enable mp4parse_fallible/FallibleVec. MozReview-Commit-ID: 2HDYbL2CGgJ
b4aafc195b9f: Bug 1457598 Add MinGW and GCC scripts to the resources of fxc2 and nsis to ensure they get rebuilt r=glandium
Tom Ritter <tom@mozilla.com> - Fri, 27 Apr 2018 16:36:54 -0500 - rev 472024
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1457598 Add MinGW and GCC scripts to the resources of fxc2 and nsis to ensure they get rebuilt r=glandium MozReview-Commit-ID: GuF9IFXKy9T
6feab03068cb: Bug 1460451 - Add /usr/bin/python3 to Debian images; r=glandium
Gregory Szorc <gps@mozilla.com> - Wed, 09 May 2018 19:54:21 -0700 - rev 471854
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1460451 - Add /usr/bin/python3 to Debian images; r=glandium The python3-minimal package provides /usr/bin/python3 on Debian. This commit installs this package so a `python3` executable is provided. This required backporting the package to wheezy. The final patch is trivial. But I wasted a bit of time figuring out why `mk-build-deps` wasn't working. It would no-op and exit 0 and then the build would complain about missing dependencies! glandium's theory is that the ":any" multiarch support on wheezy isn't complete. Removing ":any" seems to make things "just work." MozReview-Commit-ID: FBicpK4SmkQ
c79c482d50a3: Bug 1453444 - Add support for versioned lld binaries r=glandium
Sylvestre Ledru <sledru@mozilla.com> - Wed, 09 May 2018 13:53:16 +0200 - rev 471801
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1453444 - Add support for versioned lld binaries r=glandium Can be used: ac_add_options --enable-linker=lld-7 or ac_add_options --enable-linker=lld MozReview-Commit-ID: GfDevGeooU4
a42df29b0d3d: Bug 1455767 - As we have gcc 6 as requirement, use -fuse-ld everywhere instead of the -B trick r=glandium
Sylvestre Ledru <sledru@mozilla.com> - Thu, 26 Apr 2018 13:27:36 +0200 - rev 471765
Push 9374 by jlund@mozilla.com at 2018-06-18 21:43 +0000
Bug 1455767 - As we have gcc 6 as requirement, use -fuse-ld everywhere instead of the -B trick r=glandium + simplify the code MozReview-Commit-ID: 1Qz5H8VkfpD