Received: by 10.151.63.23 with SMTP id q23mr11301215ybk.7.1281534007379;
        Wed, 11 Aug 2010 06:40:07 -0700 (PDT)
X-BeenThere: chromium-...@chromium.org
Received: by 10.151.28.20 with SMTP id f20ls3071631ybj.1.p; Wed, 11 Aug 2010 
	06:40:01 -0700 (PDT)
Received: by 10.150.2.8 with SMTP id 8mr21648946ybb.394.1281534001838;
        Wed, 11 Aug 2010 06:40:01 -0700 (PDT)
Received: by 10.150.2.8 with SMTP id 8mr21648933ybb.394.1281534001631;
        Wed, 11 Aug 2010 06:40:01 -0700 (PDT)
Return-Path: <eisin...@google.com>
Received: from smtp-out.google.com (wpay12.hot.corp.google.com [172.24.198.12])
        by mx.google.com with ESMTPS id v41si441091yba.71.2010.08.11.06.39.57
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Wed, 11 Aug 2010 06:40:00 -0700 (PDT)
Received-SPF: pass (google.com: domain of eisin...@google.com designates 172.24.198.12 as permitted sender)
Authentication-Results: mx.google.com; spf=pass (google.com: domain of eisin...@google.com designates 172.24.198.12 as permitted sender) smtp.mail=eisin...@google.com; dkim=pass (test mode) header...@google.com
Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75])
	by smtp-out.google.com with ESMTP id o7BDdvfV026964;
	Wed, 11 Aug 2010 06:39:57 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1281533997; bh=/2wZ1iNshcsOhEi2QO+B//74TqA=;
	h=MIME-Version:Sender:In-Reply-To:References:From:Date:Message-ID:
	 Subject:To:Cc:Content-Type:Content-Transfer-Encoding;
	b=uk5Ue2WZeAdK7XhffMVUyGQne8fiEdOJoW3cTk3y/ignqwGfwEu4+aCXGNiS7tuNJ
	 phbjBOEc891XTy/tm9PPw==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;
	h=mime-version:sender:in-reply-to:references:from:date:
	x-google-sender-auth:message-id:subject:to:cc:content-type:
	content-transfer-encoding:x-system-of-record;
	b=QBXQr+hCvgmgbU2k6sIz6OV0UAuOA/7ftugWrVInVRqOyl0rMjG8nAqNKe2h9FP6G
	Ej5v78YiPdeIoLbiWrYqA==
Received: from gwb10 (gwb10.prod.google.com [10.200.2.10])
	by kpbe11.cbf.corp.google.com with ESMTP id o7BDdsA8027729;
	Wed, 11 Aug 2010 06:39:55 -0700
Received: by gwb10 with SMTP id 10so49880gwb.8
        for <multiple recipients>; Wed, 11 Aug 2010 06:39:54 -0700 (PDT)
Received: by 10.151.107.15 with SMTP id j15mr4106988ybm.231.1281533994317; 
	Wed, 11 Aug 2010 06:39:54 -0700 (PDT)
MIME-Version: 1.0
Sender: eisin...@google.com
Received: by 10.150.181.9 with HTTP; Wed, 11 Aug 2010 06:39:33 -0700 (PDT)
In-Reply-To: <AANLkTiktGGT58etx3MRkq8iT+r0yzQ1kt+rbVq-Yq...@mail.gmail.com>
References: <AANLkTinqSRu6sF+ovaXobY2aX14rxoz4126wQox=1...@mail.gmail.com> 
	<AANLkTiktGGT58etx3MRkq8iT+r0yzQ1kt+rbVq-Yq...@mail.gmail.com>
From: Jochen Eisinger <joc...@chromium.org>
Date: Wed, 11 Aug 2010 15:39:33 +0200
Message-ID: <AANLkTi=QhPgH9aoQ3-sWFOccwWwpWMaDxNsm4zuK4...@mail.gmail.com>
Subject: Re: A script to simplify writing Valgrind suppressions to keep the 
	memory waterfall green
To: Timur Iskhodzhanov <timur...@chromium.org>
Cc: chromium-dev <chromium-...@chromium.org>, cbent...@chromium.org,
        glider <gli...@chromium.org>, hb...@chromium.org,
        jhawk...@chromium.org, osh...@chromium.org, stuartmor...@chromium.org,
        thestig <thes...@chromium.org>, k...@chromium.org,
        Nicolas Sylvain <nsylv...@chromium.org>,
        Marc-Antoine Ruel <mar...@chromium.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true

I've added an command "blame" to this script. "waterfall.sh match"
will now also output the error hashes. With a given hash, you can
search for the first run when this specific suppression was observed
on a specific builder and output the blame list for that revision:

waterfall.sh blame <bot> <test> <hash>

e.g.

tools/valgrind/waterfall.sh blame "Linux Tests (valgrind)(3)" ui 152F078A
Searching for latest revision without this hash........
Hash #152F078A# occurs in build #6327 for the first time.
Receiving blame list.
Revision: 55620
Blamelist:
...

Please use this command with care, since it hammers the waterfall quite a b=
it.

-jochen

On Wed, Aug 4, 2010 at 11:18 PM, Timur Iskhodzhanov
<timur...@chromium.org> wrote:
> Hi,
> After filing a few dozens of Valgrind suppressions to keep the memory
> waterfall green I've started thinking there should be some easier and mor=
e
> effective way to do it.
> What I disliked the most was that once a suppression is commited, one had=
 to
> wait 2-4 hours for the current build cycle to end and one more cycle with
> the new suppression.
> Since we have three different platforms which can have the same report wi=
th
> subtle differences in mangling (I hate mangling btw), this complicates st=
uff
> a lot and sometimes it's quite a waste of time for the suppression writer=
s.
> Recently I've created a script to simplify this routine and we've (me and
> glider@) tried it with good results.
> You can give it a try:
> ./tools/valgrind/waterfall.sh fetch|match
> fetch: download memory waterfall logs for those builds which have failed
> Valgrind steps
> =A0(usually that means there is an unsuppressed Valgrind report)
> Nicolas, Marc-Antoine, I hope the fetch doesn't DDoS the waterfall. At le=
ast
> it downloads almost the same amount of logs a Valgrind sheriff would
> download manually to get the reports. Probably we can optimize here if
> needed.
> match: list all the fetched reports that don't match local suppressions
> Typical workflow is as follows:
> ./tools/valgrind/waterfall.sh fetch
> svn up tools/valgrind/memcheck=A0# get your suppressions in sync
> ./tools/valgrind/waterfall.sh match=A0# get the list of reports
> <write new suppressions or generalize existing>
> ./tools/valgrind/waterfall.sh match=A0# make sure the number of reports
> decreased
> [optional: generalize the new suppression to match more reports - vimdiff=
 is
> your friend]
> ./tools/valgrind/waterfall.sh match=A0# make sure the number of reports
> decreased even more
> <file a bug>
> <commit a suppression>
> Your feedback and patches are welcome!
> Timur Iskhodzhanov,
> Google Russia
>
>
>