Closed
Bug 794627
Opened 13 years ago
Closed 8 years ago
Run mochitests in Valgrind tbpl builds on test slaves
Categories
(Release Engineering :: General, defect, P3)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: gkw, Unassigned)
References
Details
(Keywords: valgrind, Whiteboard: [valgrind])
Attachments
(2 files)
We should be striving to run more tests in Valgrind tbpl builds. This bug is about running mochitests.
![]() |
Reporter | |
Updated•13 years ago
|
OS: Mac OS X → Linux
Hardware: x86 → All
![]() |
Reporter | |
Comment 1•13 years ago
|
||
ted mentions that we could probably just use makefile targets, e.g. `make xpcshell-tests`.
Comment 2•13 years ago
|
||
Assuming you're OK running on the build machines. All of the other unit tests run on the test pool, though, and don't have an objdir.
![]() |
Reporter | |
Comment 3•13 years ago
|
||
(In reply to Ben Hearsum [:bhearsum] from comment #2)
> Assuming you're OK running on the build machines. All of the other unit
> tests run on the test pool, though, and don't have an objdir.
On second thoughts, I'm not sure if running on the build machines is the most ideal situation. (it might turn up oranges specific to build machines) I think we would want to share as much infrastructure as possible.
Comment 4•13 years ago
|
||
I've run Mochitests on Valgrind quite a lot. Timeouts due to the
added slowness are a real problem, so I use this patch to allow extra
time. Note that the numbers are not exactly scientifically derived.
Also, be sure to use x86_64-linux for this. The performance of
Valgrind running Firefox on MacOS is very poor compared to running on
Linux.
Memory use can be a problem. Running all the tests in a single
process takes 10+ CPU hours on a fast machine, and 5+ GB memory, and
that's if nothing goes wrong. Better to divide the run into about 20
pieces; that also makes it parallelisable. Here's the command I use,
more or less. "v38BRANCH" is the 3.8.x branch. I strongly recommend
you use 3.8.1 for this.
Here's the command I use to start it. It's been evolved over many
runs, so might be a useful starting point. In its raw form:
for ((qq = 1; qq <= 100; qq++)); do (DISPLAY=:3.0 make -C ff-opt mochitest-plain EXTRA_TEST_ARGS="--this-chunk=$qq --total-chunks=100 --close-when-done --debugger=/home/sewardj/VgTRUNK/hgde3/Inst/bin/valgrind --debugger-args='--smc-check=all --suppressions=/home/sewardj/MOZ/mochitest-mc.supp --suppressions=/home/sewardj/MOZ/SUPPS/mc-helgrind-not-our-problem.supp --error-limit=no --stats=no --trace-children=yes --child-silent-after-fork=yes "--trace-children-skip=/usr/bin/hg,/bin/rm,*/bin/certutil,*/bin/pk12util,*/bin/ssltunnel,*/bin/uname,*/bin/which,*/bin/ps,*/bin/grep" "--trace-children-skip-by-arg=*/npviewer*" --fullpath-after=-HG/ --tool=helgrind --history-level=none --profile-heap=no --read-var-info=no --num-callers=20 --free-is-write=yes'") 2>&1 | tee spew-hg-none--chunk-$qq-of-100 ; done
Formatted nicely, that is (I don't know if this line breaking is
really valid, but anyway:)
for ((qq = 1; qq <= 20; qq++)); do \
(DISPLAY=:3.0 \
make -C ff-opt mochitest-plain \
EXTRA_TEST_ARGS="--this-chunk=$qq --total-chunks=20 --close-when-done \
--debugger=v38BRANCH \
--debugger-args='--fair-sched=yes --smc-check=all-non-file \
--suppressions=/home/sewardj/MOZ/SUPPS/mochitest-mc.supp \
--error-limit=no --stats=no --trace-children=yes \
--child-silent-after-fork=yes \
"--trace-children-skip=/usr/bin/hg,/bin/rm,*/bin/certutil,*/bin/pk12util,*/bin/ssltunnel,*/bin/uname,*/bin/which,*/bin/ps,*/bin/grep" \
--tool=memcheck --track-origins=no'")
2>&1 \
| tee spew-mc-1--chunk-$qq-of-20 ; \
done
Which isn't pretty, but basically runs V on large process trees, but
uses --trace-children-skip to avoid following into a whole bunch of
processes (hg, rm, certutil, etc) which we're not interested in.
Maybe should be turned into a proper shell script and added to the
tree?
It traces also into Python and generates a lot of noise -- Python
confuses Memcheck. Hence I find it essential to use the listed supp
file, /home/sewardj/MOZ/SUPPS/mochitest-mc.supp, to get sane
behaviour. I'll attach that in the next comment.
I run it on a 16 bit deep, 800x600 VNC server, hence the
"(DISPLAY=:3.0" above. It runs with no window manager, with input
disabled and the mouse pointer "frozen" pretty much in the middle, so
that Fx has mouse focus most of the time. It still has problems
losing focus sometimes, though. I don't know why.
Comment 5•13 years ago
|
||
These are baseline suppressions needed for runs on x86_64-linux,
Ubuntu 10.04.4. You will need them or something very similar to get
sane behaviour. They are partially for Firefox itself, but partially
for the Python process(es) that also wound up getting run on Valgrind
as part of the game.
Comment 6•13 years ago
|
||
(In reply to Julian Seward from comment #4)
> Created attachment 667390 [details] [diff] [review]
> Adjust Mochitests timeouts more suitable for Valgrind runs
One further comment. Probably obvious, but .. once this patch
is applied, you still need to do "make" at the top level to
get it to take effect, before starting the Mochitest run.
Updated•13 years ago
|
Priority: -- → P3
![]() |
Reporter | |
Updated•13 years ago
|
Summary: Run mochitests in Valgrind tbpl builds → Run mochitests in Valgrind tbpl builds on test slaves
Assignee | ||
Updated•12 years ago
|
Product: mozilla.org → Release Engineering
Updated•8 years ago
|
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Assignee | ||
Updated•7 years ago
|
Component: General Automation → General
You need to log in
before you can comment on or make changes to this bug.
Description
•