Re: Windows launcher process enabled by default on Nightly
Hi Aaron, It sounds cool, but I'm trying to understand what it means :) Do I understand correctly that the main benefit is security? Cheers, David On 27/09/2018 17:19, Aaron Klotz wrote: > Hi everybody, > > Yesterday evening bug 1488554 [1] merged to mozilla-central, thus > enabling the launcher process by default on Windows Nightly builds. This > change is at the build config level. > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Windows launcher process enabled by default on Nightly
On 2018-09-27 17:19, Aaron Klotz wrote: * If you use Visual Studio, you may install the Child Process Debugging Power Tool [3] which, once configured, will make the VS debugger automagically attach to the launcher's child processes. I'm using "Spawned Process Catcher X" that works better, but has to be manually repacked for VS2017, you can download it here: https://janbambas.cz/moz/SpawnedProcessCatcher-2017.vsix -hb- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Windows launcher process enabled by default on Nightly
Hi Aaron, Great work getting this landed, and thanks for doing the work to minimize the impact on everyone! On Thu, Sep 27, 2018, at 11:19 AM, Aaron Klotz wrote: > 2. Debugging the browser process > > > If you launch Firefox via a debugger, the initial process will now be > the launcher process instead of the browser process. To debug the > browser process, here are your options: > > * You can attach your debugger to the browser process once it has > started. Obviously this solution is less than ideal if you want to debug > something during startup; We have `MOZ_DEBUG_CHILD_PROCESS` for e10s content processes[1]. Would something similar (or maybe just supporting that?) be useful for the browser process as well? > * If you use WinDbg, you may start your debugging session from the > command line with the "-o" option to ensure that the debugger attaches > to all child processes. If you prefer opening your executable via the > GUI, you may select the "Debug child processes also" checkbox within the > "Open Executable" file picker. > * If you use Visual Studio, you may install the Child Process Debugging > Power Tool [3] which, once configured, will make the VS debugger > automagically attach to the launcher's child processes. Can we make these work automatically via mozdebug so that `mach run --debug` works directly? -Ted 1. https://mikeconley.ca/blog/2014/04/25/electrolysis-debugging-child-processes-of-content-for-make-benefit-glorious-browser-of-firefox/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Windows launcher process enabled by default on Nightly
Hi everybody, Yesterday evening bug 1488554 [1] merged to mozilla-central, thus enabling the launcher process by default on Windows Nightly builds. This change is at the build config level. What is the launcher process? = Simply put, on Windows builds, the launcher process is an initial process hosted by firefox.exe that is responsible for configuring and starting the "real" browser process. Such configurations include early initialization of the DLL blocklist, as well as the setting of other Windows process mitigations. How does this affect startup perf? == A new test has been added to the xperf-e10s suite in Talos to track regressions in total elapsed startup time of both the launcher and browser processes. Previous tests on try have shown the perf impact to be less than 1%, but that is on a small data set, hence the interest in gathering more data from Nightly. On Windows 10 devices with magnetic hard disks, users may actually see a performance *improvement* due to an altered search path for DLL loading that results in reduced HDD seeking. As a developer, how does this affect me? If you are not running Windows, you are unaffected! \o/ If you are running Windows, there are two possible issues: 1. Automation - If you are doing some kind of automation that waits for the Firefox process to finish, you'll find that the initial Firefox process exits sooner than the browser, appearing to your script that Firefox is already done when in fact it is still running. This is because, by default, the launcher process only lives long enough to stand up the browser process and transfer foreground to the new browser's window. In order to make the launcher wait for the browser to complete, pass the --wait-for-browser flag on the command line. The launcher will wait for the entire life of the browser process, and will also propagate the browser process's exit code as its own. The launcher also accepts the presence of the MOZ_AUTOMATION environment variable as an implicit --wait-for-browser request. I have already fixed up our automation to supply this parameter when necessary, so I expect everything in Mozilla's CI system to already Just Work. |mach run| and |mach gtest| also automagically add --wait-for-browser when necessary. mozregression updates are being tracked by bug 1494398 [2]. 2. Debugging the browser process If you launch Firefox via a debugger, the initial process will now be the launcher process instead of the browser process. To debug the browser process, here are your options: * You can attach your debugger to the browser process once it has started. Obviously this solution is less than ideal if you want to debug something during startup; * If you use WinDbg, you may start your debugging session from the command line with the "-o" option to ensure that the debugger attaches to all child processes. If you prefer opening your executable via the GUI, you may select the "Debug child processes also" checkbox within the "Open Executable" file picker. * If you use Visual Studio, you may install the Child Process Debugging Power Tool [3] which, once configured, will make the VS debugger automagically attach to the launcher's child processes. How to Help === If you encounter any bugs, please file them blocking bug 1481546 [4] and needinfo me. As always, feel free to reach out to me if you have any questions/concerns/comments. Thanks, Aaron [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1488554 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1494398 [3] https://blogs.msdn.microsoft.com/devops/2014/11/24/introducing-the-child-process-debugging-power-tool/ [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1481546 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: mozilla-central Fails to Build on Mac With Latest Xcode (10.0)
On Wednesday, September 19, 2018 at 12:01:03 AM UTC+5:30, Haik Aftandilian wrote: > If you don't build on macOS, read no further. > > With the latest XCode (10.0) just released, mozilla-central fails to build > due to bug 1492210 "nsCocoaUtils.mm compile error on macOS 10.13 with 10.14 > SDK" [1]. I recommend avoiding installing the new XCode until we have this > fixed. If you've configured your builds to use an older SDK and not the > default XCode install, you will not be affected. > > Haik > > 1. https://bugzilla.mozilla.org/show_bug.cgi?id=1492210 I downgraded to 10.13 sdk but I still see the black screen. I download 10.13 sdk from their site and ran it. It removed the files in `/Library/Developer/CommandLineTools/Packages/` but i still have black screen ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
