Bugzilla

valgrind run (I did it out of ./mach valgrind-test 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
despite I did detect a few memory issues that happen very early in the execution of test,
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...)

I am filing a different bug to block this entry since the long timeout value is necessary to run mochitest under valgrind successfully.

TIA

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