1631197 - make ./mach valgrind-test work for thunderbird

Status: RESOLVED FIXED

(Thunderbird :: Build Config, task)

Description

[Magnus Melin [:mkmelin]]

Firefox has a mach valgrind-test that you can use to run Firefox under valgrind.

It's currently not possible to run for Thunderbird (without patching) at least due to this condition: https://searchfox.org/mozilla-central/rev/aec63591821712236a522f7f55116f582ed7c920/build/valgrind/mach_commands.py#39

Would be nice if that worked for Thunderbird too.

In general it could be useful to have an in-tree way supported way to run tests with valgrind enabled.

See also https://developer.mozilla.org/en-US/docs/Mozilla/Testing/Valgrind_test_job as well as bug 1629433 comment 8.

Comment 1

[Rob Lemley [:rjl]]

I got it to run, but it doesn't quite work right I suspect. For one thing, I ran out of threads like Chiaki mentions in bug 1629433.

Phabricator is being a pain right now, so I will have to post what I have so far later.

Comment 2

[Rob Lemley [:rjl]]

Attachment: Bug 1631197 - Make mach valgrind-test work for Thunderbird builds.

Create a new MachCommandCondition, "is_firefox_or_thunderbird" which is then used
to allow mach valgrind-test work for Thunderbird builds.

Comment 3

[ISHIKAWA, Chiaki]

You can add
--max-threads=5000
to the option of valgrind to run TB under valgrind.
I have not checked what is the minimum value for this max-threads. It is somewhere between (1500, 5000].
-max-threads=1500 failed.

Comment 4

[ISHIKAWA, Chiaki]

I could make mochitest under valgrind run finally after increasing the thread to 5000.
(I did it out of ./mach valgrind-test by creating a wrapper program to run TB under valgrind as noted in Bug 1629433
Running thunderbird binary under valgrind while trying to run mochitest requires way TOO MANY threads (> 1500) !? )

But there was a catch. mochitest under valgrind slows down significantly as one expects, and
although I did detect a few memory issues that happen very early in the execution of tests,
I got the following timeout from mochitest framework, and unfortunately, I realize I don't get any serious memory test coverage of
mochitest under valgrind. (My setup worked fine with |make mozmill| AFTER I extended timeout in various mozmill test files.
Either I have to do this manually for mochitest files or have to find a global way to extend the timeout up to a large value...)

...
2041:39.38 GECKO(116476) {debug} SetSpec failed : aSpec=messenger/otr/chat.ftl
2042:48.84 GECKO(116476) --116480-- memcheck GC: 78624 nodes, 23241 survivors (29.6%)
2042:48.85 GECKO(116476) --116480-- memcheck GC: 79803 new table size (driftup)
2048:50.88 INFO Buffered messages finished
2048:50.88 INFO TEST-UNEXPECTED-TIMEOUT | automation.py | application timed out after 370 seconds with no output
2048:50.88 ERROR Force-terminating active process(es).
2048:50.88 INFO Determining child pids from psutil...
2048:50.89 INFO [116477]
2048:50.89 INFO ==> process 116480 launched child process 116520

...
grep TEST-UNEXPECTED-TIMEOUT log1208-mochitest-memcheck.txt |wc 
   48     720    5419

I think this basically means that all the tests under subdirectories of ./comm fail due to timeout when valgrind tests run.

I am filing a different bug to block this entry since the long timeout value is necessary to run mochitest under valgrind successfully.
(There may be a bloat factor automatically involved for timeout value when |./mach valgrind-test| is issued, but this will require find tuning by each local developer and thus, we need manual override for such longer timeout value.

TIA

Comment 5

[Rob Lemley [:rjl]]

I'll get this patch reviewed and landed, then there's at least incremental progress being made somewhere to get Valgrind working.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/280e966bc942
Make mach valgrind-test work for Thunderbird builds. r=froydnj

Comment 7

[ISHIKAWA, Chiaki]

(In reply to Rob Lemley [:rjl] from comment #5)

I'll get this patch reviewed and landed, then there's at least incremental progress being made somewhere to get Valgrind working.

That will be great. Thank you. I will try to find out what is hold up the execution of mochitest under valgrind. Not much progress so far. But I suspect competing 1500+ (not exactly how many) threads are slowing down execution under valgrind.

Comment 8

[Rob Lemley [:rjl]]

Yes, that definitely sounds like it would slow things down. Since you're working on that angle I'll let this bug close out when it hits mozilla-central later.

Comment 9

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/280e966bc942