On Wed, Dec 4, 2013 at 12:02 PM, Nicholas Nethercote
wrote:
>
> I'm working on getting Valgrind (Linux64-only) runs visible on TBPL.
> https://bugzilla.mozilla.org/show_bug.cgi?id=valgrind-green is the tracking
> bug.
> [...]
>
> 5) Easily run on try server
catlee got Valgrind jobs running on try
On 12/12/2013 3:43 AM, Nicholas Nethercote wrote:
>
> I tracked this down to one of the Quitter files being a symlink with a
> relative path, and that path was going awry when the file was copied
> elsewhere within the chroot that the tests run in on the build
> slaves(!) And by the time I worked
On Thu, Dec 12, 2013 at 9:48 AM, Nicholas Nethercote
wrote:
>>
>> Unfortunately, on December 5th, just before the changes were enabled,
>> something
>> else happened that caused the Valgrind jobs to start timing out all the time.
>> This is being tracked in https://bugzilla.mozilla.org/show_bug.c
On Tue, Dec 10, 2013 at 4:12 PM, Nicholas Nethercote
wrote:
>
> Unfortunately, on December 5th, just before the changes were enabled,
> something
> else happened that caused the Valgrind jobs to start timing out all the time.
> This is being tracked in https://bugzilla.mozilla.org/show_bug.cgi?id
On Tue, Dec 10, 2013 at 5:05 PM, Karl Tomlinson wrote:
>
> Yes, sounds like all processes in the test are being killed. Most tests
> have a shorter time out to kill with signals that generate stacks,
> before this higher level time out kicks in.
Here's an excerpt from the log, with tons of setup
Nicholas Nethercote writes:
> - When a job times out, the output produced by Valgrind is
> usually chopped off in the middle of a line. In fact, it's
> often chopped off in the middle of a line that would have been
> produced by a single write() system call. So it feels like the
> test harness i
ush to m-c, m-i, fx-team, etc. This is
great.
Unfortunately, on December 5th, just before the changes were enabled, something
else happened that caused the Valgrind jobs to start timing out all the time.
This is being tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=948145.
The Valgrind-on-TBPL
On Tue, Dec 03, 2013 at 05:54:12PM -0800, Jesse Ruderman wrote:
> In the long run, it may be more efficient to use the clang "sanitizer"
> suite instead of Valgrind. It will need two runs (ASan+LSan+UBSan and
> MSan) but the total run time should be lower.
>
> http://clang.llvm.org/docs/UsersManua
On Wed 04 Dec 2013 04:21:33 AM PST, Ted Mielczarek wrote:
> On 12/3/2013 8:02 PM, Nicholas Nethercote wrote:
>> 3) Runs on mozilla-central and all trees that merge into it
>
> This is something that Release Engineering needs to fix. You've already
> got a bug open, so you should touch base with the
On 12/3/2013 8:02 PM, Nicholas Nethercote wrote:
> 3) Runs on mozilla-central and all trees that merge into it
This is something that Release Engineering needs to fix. You've already
got a bug open, so you should touch base with them.
> 4) Scheduled on every push
This is also RelEng. These both h
Nick, this is great. Even just having the "PGO" tests passing under
Valgrind means we can use V to diagnose intermittent failures in any
suite. And maybe even to fuzz, although I'd like to see reftest and
crashtest passing first.
> 8) Must avoid patterns known to cause non deterministic failures
In the long run, it may be more efficient to use the clang "sanitizer"
suite instead of Valgrind. It will need two runs (ASan+LSan+UBSan and
MSan) but the total run time should be lower.
http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation
> Valgrind can find the following kind
Hi,
I'm working on getting Valgrind (Linux64-only) runs visible on TBPL.
https://bugzilla.mozilla.org/show_bug.cgi?id=valgrind-green is the tracking
bug. This aim of this email is to (a) get answers to some questions I have,
and (b) serve as a heads-up for people I will have to co-ordinate with.
13 matches
Mail list logo
