The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=38489 

------------------------------------------------------------------------
r38489 | pkasting@chromium.org | 2010-02-09 11:41:23 -0800 (Tue, 09 Feb 2010) | 6 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/tools/valgrind/memcheck/suppressions_mac.txt?r1=38489&r2=38488

Add suppression for a new valgrind failure.

TBR=stuartmorgan
BUG=35164
TEST=none
Review URL: http://codereview.chromium.org/593020
------------------------------------------------------------------------

This looks related to the GPU work.

(No comment was entered for this change.)

See also https://code.google.com/p/chromium/issues/detail?id=22519 .

I think this is a bug in the CARender class, not in Chromium code. The new code does 
not use client-side vertex arrays, only simple immediate mode rendering.

How would we go about reporting this to Apple? What is needed in the bug description 
and as a test case?

(No comment was entered for this change.)

(No comment was entered for this change.)

Assuming you can't come up with a reduced test case outside of Chromium, what I've done in the past is provide:
1) a link to the Mac Chromium build instructions
2) valgrind build instructions (which are much easier now, since they can just run src/tools/valgrind/build-valgrind-for-
chromium.sh
3) instructions to run just that test under valgrind, either using the scripts and gtest_filter (although if they use the script 
as-is they'll need to remove the suppression we've added, since those scripts read the suppression files) or manually (with 
the right flags, like fork-following, which you can extract from the scripts; I don't know the current set offhand).

It's also good to be very clear about the fact that when valgrind says "uninitialized" it refers to *memory*, not the variable, 
and that uninitialized-ness is transitive, since people not familiar with valgrind often make that mistake and then think that 
valgrind is wrong. (It might even be worth giving an example, just to be sure it's clear. e.g., if the code is:
  void foo(int x) {
    if (x > 0) {
      // do something
    }
  }

  int main() {
    int garbage;
    foo(garbage);
    return 0;
  }
valgrind will give this warning on the first line of foo(), because even though x is initialized, the memory is not.)

(No comment was entered for this change.)

(No comment was entered for this change.)

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=53895 

------------------------------------------------------------------------
r53895 | thakis@chromium.org | 2010-07-27 18:35:56 -0700 (Tue, 27 Jul 2010) | 6 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/tools/valgrind/memcheck/suppressions_mac.txt?r1=53895&r2=53894

Widen a Valgrind suppression for an OS X system library.

BUG=35164

Review URL: http://codereview.chromium.org/2832087
Patch from Evan Martin <evan@chromium.org>.
------------------------------------------------------------------------

(No comment was entered for this change.)

Changing milestone from Mstone8 to Mstone-9

(No comment was entered for this change.)

(No comment was entered for this change.)

Given our current velocity, we need to punt 500 bugs from m9.  Moving p2 bugs, that are not started and have an owner, to the next milestone.  If this issue absolutely needs to be fixed in the current milestone please move it back, however, at this time the focus should be on p1 bugs.

P2 bugs with an owner that are not marked as started are being automatically moved to mstone:11.

Decommitting from milestone. Unclear whether there is anything we can do about this.

The Mac UI valgrind bot is consistently failing with "uninitialized 
condition check" on stacks like the following:

  glColorPointer_Exec
  gl_context_init_client_state
  ogl_begin_rendering
  CARenderOGLRender
  view_draw
  view_display_link
  link_callback
  CVDisplayLink::performIO(CVTimeStamp*)
  CVDisplayLink::runIOThread()
  _pthread_start
  thread_start

It looks like this started on 
http://build.chromium.org/buildbot/memory/builders/Chromium%20Mac%20UI%20(v
algrind)(4)/builds/947 .  Adding everyone on the blamelist to this bug.

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/818fa793ce5442028821c484f91fa8c1c96ab54d

commit 818fa793ce5442028821c484f91fa8c1c96ab54d
Author: thestig <thestig@chromium.org>
Date: Thu Sep 25 00:46:24 2014

Valgrind Mac: Remove many obsolete suppressions.

BUG=17297,18218,20582,21479,27315,27644,28847,28072,31634,35164,35625,40429,40659,47949,50286,50297,50638,50968,52681,53742,53989,55773,58860,51682,60873,61737,61929,63024,63670,64463,65940,67291,68090,73036,73299,75136,75142,75714,77265,77388,79994,80239,82328,82682,84329,86303,87461,90976,91889,91892,92579,93036,96300,96559,96671,96689
NOTRY=true
TBR=ericwilligers@chromium.org

Review URL: https://codereview.chromium.org/605543003

Cr-Commit-Position: refs/heads/master@{#296596}

[modify] https://chromium.googlesource.com/chromium/src.git/+/818fa793ce5442028821c484f91fa8c1c96ab54d/tools/valgrind/memcheck/suppressions_mac.txt

(No comment was entered for this change.)