On Tue, Apr 08, 2014 at 02:28:02PM -0700, Bill McCloskey wrote: > Hi everyone, > > Starting today, we have new mochitests that show up as M-e10s (1 2 3 4 5). > These are mochitests-plain running inside an e10s content process. Aside from > being in a separate process, they work pretty much the same as normal. Some > tests have been disabled for e10s. If you add a new test and it doesn't work > in e10s mode, you can disable it with the following mochitest.ini gunk: > > [your_test.html] > skip-if = e10s > > We have about 85% of mochitests-plain running right now. I'm hoping to make a > big push to get this number up to 100%, but there are still some prerequisite > bugs that I want to fix first. In the meantime, we can at least identify > regressions in the tests that run. > > Right now, these tests are running on inbound, central, try, fx-team, and > b2g-inbound. In a few days, they'll be running on all trunk trees. If you do > a try push, e10s tests will run iff mochitests-plain run. We don't have a > specific trychooser syntax for them yet. > > The tests are restricted to Linux and Linux64 opt builds right now. > Eventually we'll expand them to debug builds and maybe to other platforms. We > also want to get other test suites running in e10s. As testing ramps up, > we're going to have more and more test suites running e10s side-by-side with > non-e10s. The eventual goal is of course to disable non-e10s tests once we've > shipped an e10s browser. Until then, we'll have to balance resource usage > with test coverage. > > If you want to run in e10s mode locally, it's pretty simple: > > mach mochitest-plain --e10s > > As usual, you can pass in specific tests or directories as well as chunking > options. Debugging in e10s is a little harder. Passing the --debugger=gdb > option will only attach the debugger to the parent process. If you want to > debug the content process, set the environment variable > MOZ_DEBUG_CHILD_PROCESS=1. When the child starts up, it will go to sleep > after printing its PID: > > CHILDCHILDCHILDCHILD > debug me @ <pid> > > At that point you can run gdb as follows: > > gdb $OBJDIR/dist/bin/plugin-container <pid> > > Then you can set breakpoints in the child and resume it with "continue".
or if you know ahead of time you want to debug the child you can set follow-fork-mode to child, and maybe you can use the attach command to attach once the child is running from the debugger the parent is running in, but if I've tried either of those recently I don't remember it. Trev > > Most of the work for this was done by Ted, Armen, Aki, and Mark Hammond. > Thanks guys! > > -Bill > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform
signature.asc
Description: Digital signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
