Slightly modified quote from https://bugzilla.mozilla.org/show_bug.cgi?id=1631197#c4 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, (e.g. Bug 1591177 ) 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 because of premature termination due to timeout. (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 again, or have to find a global way to extend the timeout up to a large value. I prefer the latter.) ... 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. There may be an automatic bloat factor automatically involved for timeout value when |./mach valgrind-test| is issued, but this value obviously will require find tuning by each local developer who uses different hardware, and thus we need manual override for such longer timeout value. I searched in the help message from |mach| but could not find any mention of such override. So, unless such manual override for timeout exists for valgrind-test, I wish it is implemented as such.
Bug 1636945 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Slightly modified quote from https://bugzilla.mozilla.org/show_bug.cgi?id=1631197#c4 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, (e.g. Bug 1591177 ) 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 because of premature termination due to timeout. (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 again, or have to find a global way to extend the timeout up to a large value. I prefer the latter.) ``` 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. There may be an automatic bloat factor automatically involved for timeout value when |./mach valgrind-test| is issued, but this value obviously will require find tuning by each local developer who uses different hardware, and thus we need manual override for such longer timeout value. I searched in the help message from |mach| but could not find any mention of such override. So, unless such manual override for timeout exists for valgrind-test, I wish it is implemented as such.
Slightly modified quote from https://bugzilla.mozilla.org/show_bug.cgi?id=1631197#c4 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, (e.g. Bug 1591177 ) 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 because of premature termination due to timeout. (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 again, or have to find a global way to extend the timeout up to a large value. I prefer the latter.) ``` 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. There may be an automatic bloat factor automatically involved for timeout value when |./mach valgrind-test| is issued, but this value obviously will require fine tuning by each local developer who uses different hardware, and thus we need manual override for such longer timeout value. I searched in the help message from |mach| but could not find any mention of such override. So, unless such manual override for timeout exists for valgrind-test, I wish it is implemented as such.