(Just this once, I post to m.d.platform and m.d.a.firefox) I found out that firefox's mochitest can be run under valgrind according to "How Do I Run A Mochitest Under Valgrind?" in https://developer.mozilla.org/en-US/docs/Mozilla/Testing/Valgrind
e.g.: ./mach mochitest-plain --debugger="valgrind" --debugger-args="--smc-check=all-non-file --vex-iropt-register-updates=allregs-at-mem-access" relative/path/to/tests [not tested yet.] Maybe I should try to see if some timeout values are extended during the execution of the above command (and if so, how.) However, I have a nagging feeling that mozmill test of TB seems to run a TB as a DOM object that can be manipulated from an external driver program via XPCOM to simulate user-interaction, and the framework may be very different from mochitest framework. Even if the framework may be similar, but the initial setup of running TB as a daemon that can be manipulated by external program (setting up proxy called a bridge in test framework) seems to take a very long time in the case of TB. That is the problem. Oh, I hasten to say that running C-C TB under valgrind as a standalone program to be manipulated by a user using mouse and keyboard runs fine under suitable linux kernel revision. (I have an issue with 3.16.0 under Debian GNU/Linux.) Testing manually is not exhaustive and thus I want to run TB under valgrind through mazmill test and xpshell-tests, and that is where the timeout issues raise ugly head! Short of good idea, I will create a monstrous bundle of editor scripts to change many timeout values found in .py files under MOZOBJ directory used for testing to a much larger fixed value. I wonder if it will work. [But this is not desirable in principle. I want to extend only the relevant timeout values to handle the slowdown by the execution under valgrind. Network delay observed between a remote deamon should not be handled with extended timeout, for example. I may have to wait unduly long for such cases if all the timeout values are extended.] Anyway, I will appreciate feedback, tips, comments, etc. Again, followup-to m.d.a.thunderbird. TIA On 2015/04/16 13:41, ishikawa wrote: > I wonder if someone has any idea about the following issues: > > I used to be able to run C-C TB under valgrind by creating a wrapper binary > during mozmill test. > This wrapper is named as .../dist/bin/thunderbird and invokes > thunderbird-bin under valgrind. > > By extending, timeout values in a few places in mozmill script files, I > could run this valgrind + TB combination successfully > during mozmill test and this helped me uncover about a dozen uninitialized > memory references > and one out of bound memory reference which was caused by badly crafted > Date: line, etc. > > But after the major build infrastructure change, which eventually led to the > use of mozharness, etc., > the timeout value changes that I performed no longer are enough to prevent > the test framework to timeout prematurely. > I could not get valgrind+TB run before the timeout kicks in. > > I wonder if anyone has an idea of how to extend the timeout value(s) > successfully. > > I checked the source files recently, but there are so many timeout values > scattered around in many files, > I don't know exactly which ones I should change. > (The first timeout I hit is related to connect/setup bridge to running TB, I > think.) > > Another thing is that the comments suggest there is a mixture of timeout > values that are > in milliseonds and seconds used in the code. > From the experience I had until last spring/summer, I am quite sure that the > timeout values > used for socket timeout, etc. are in milliseconds. > However, browsing through a few .py files at the top-level, I noticed that > they are commented as "seconds" and not "milliseconds", and so got confused. > Maybe the timeout values needs to be multipled by 1000 to make sure > that valgrind can run. I have no idea. > > Any hint / tips regarding how to extend the timeout values globally > will be appreciated. > > (One other thing, these values are embedded inside .py files that are > expanded/created during > the build process from archive under the source directory, and so I have to > modify the .py files JUST BEFORE running tests. > If there is a way to change the values in the archive so that they will > persist, that will be great.) > > I need to make sure TB won't crash due to these memory issues during normal > usage and that is why > I want to test it throughly. > > TIA > > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform