Re: Running C-C TB under valgrind during mozmill test: extending timeout values (but where?)

[ISHIKAWA, Chiaki]

(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
>
>
>