Re: New e10s tests on tinderbox

2014-04-09 Thread Ehsan Akhgari
Just to be explicit, this means that changesets which regress these 
tests will be backed out, right?


On 2014-04-08, 5:28 PM, 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.

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



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: New e10s tests on tinderbox

2014-04-09 Thread Bill McCloskey
- Original Message -
 From: Ehsan Akhgari ehsan.akhg...@gmail.com
 To: Bill McCloskey wmcclos...@mozilla.com, dev-platform 
 dev-platform@lists.mozilla.org
 Sent: Wednesday, April 9, 2014 6:51:46 AM
 Subject: Re: New e10s tests on tinderbox
 
 Just to be explicit, this means that changesets which regress these
 tests will be backed out, right?

Yes.

-Bill
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


New e10s tests on tinderbox

2014-04-08 Thread Bill McCloskey
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.

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


Re: New e10s tests on tinderbox

2014-04-08 Thread Trevor Saunders
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


Re: New e10s tests on tinderbox

2014-04-08 Thread Bobby Holley
This is awesome! Great job getting us this far.

On Tue, Apr 8, 2014 at 2:28 PM, Bill McCloskey wmcclos...@mozilla.comwrote:

 We have about 85% of mochitests-plain running right now.


Can you elaborate on the kinds of things that make tests fail on e10s? I
have some idea in my head of what they might be, but I don't know how
accurate it is with all the Black Magic we do these days.

bholley
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: New e10s tests on tinderbox

2014-04-08 Thread Bill McCloskey
 Most of the work for this was done by Ted, Armen, Aki, and Mark Hammond.
 Thanks guys!

And RyanVM! I knew I'd forget someone. Sorry.

-Bill
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: New e10s tests on tinderbox

2014-04-08 Thread Bill McCloskey
- Original Message -
 From: Bobby Holley bobbyhol...@gmail.com
 To: Bill McCloskey wmcclos...@mozilla.com
 Cc: dev-platform dev-platform@lists.mozilla.org
 Sent: Tuesday, April 8, 2014 2:35:26 PM
 Subject: Re: New e10s tests on tinderbox
 
 Can you elaborate on the kinds of things that make tests fail on e10s? I
 have some idea in my head of what they might be, but I don't know how
 accurate it is with all the Black Magic we do these days.

There isn't really any black magic in mochitests-plain. That's why I started 
with this suite first :-). The most common causes of failures that I've seen:

1. Sometimes code just wasn't designed for e10s and it will assert if we try to 
use it. Bug 989139 is an example. There, we assert any time we encounter the 
keygen tag.

2. Opening a new window will open a new tab in e10s. This is bug 989501. It's 
usually harmless, but sometimes it causes tests to get unexpected values for 
the window size or position.

3. Tests that use plugins don't work because e10s has no way to find the test 
plugin. That will eventually be fixed by bug 874016.

Also, one thing I forgot to point out is that testing on e10s is fairly close 
to testing on b2g, so I think b2g will benefit from the work we do in trying to 
fix some of these issues. For example, the keygen issue happens on b2g too 
(although admittedly it's not the most important issue).

-Bill
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: New e10s tests on tinderbox

2014-04-08 Thread Blake Kaplan
Bill McCloskey wmcclos...@mozilla.com wrote:
 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:

This is great! Thanks for driving this!
-- 
Blake Kaplan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: New e10s tests on tinderbox

2014-04-08 Thread Shih-Chiang Chien
Hi Bill,

Many thanks for working on the M-e10s. Does it means we can remove all these 
“test_ipc.html” mochitests? AFAIK these test cases are manually emulating an 
e10s environment with some hacks.

Here is the list of test_ipc.html:
http://dxr.mozilla.org/mozilla-central/source/content/media/webspeech/synth/ipc/test/test_ipc.html
http://dxr.mozilla.org/mozilla-central/source/dom/devicestorage/ipc/test_ipc.html
http://dxr.mozilla.org/mozilla-central/source/dom/indexedDB/ipc/test_ipc.html
http://dxr.mozilla.org/mozilla-central/source/dom/media/tests/ipc/test_ipc.html

Best Regards,
Shih-Chiang Chien
Mozilla Taiwan

On Apr 9, 2014, at 5:28 AM, Bill McCloskey wmcclos...@mozilla.com 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.
 
 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: Message signed with OpenPGP using GPGMail
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: New e10s tests on tinderbox

2014-04-08 Thread Kyle Huey
Not yet, because M-e10s is only running on Linux opt, and these test_IPC
tests run everywhere in opt and debug.

- Kyle
On Apr 8, 2014 6:58 PM, Shih-Chiang Chien sch...@mozilla.com wrote:

 Hi Bill,

 Many thanks for working on the M-e10s. Does it means we can remove all
 these “test_ipc.html” mochitests? AFAIK these test cases are manually
 emulating an e10s environment with some hacks.

 Here is the list of test_ipc.html:

 http://dxr.mozilla.org/mozilla-central/source/content/media/webspeech/synth/ipc/test/test_ipc.html

 http://dxr.mozilla.org/mozilla-central/source/dom/devicestorage/ipc/test_ipc.html

 http://dxr.mozilla.org/mozilla-central/source/dom/indexedDB/ipc/test_ipc.html

 http://dxr.mozilla.org/mozilla-central/source/dom/media/tests/ipc/test_ipc.html

 Best Regards,
 Shih-Chiang Chien
 Mozilla Taiwan

 On Apr 9, 2014, at 5:28 AM, Bill McCloskey wmcclos...@mozilla.com 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.
 
  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


 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform