[Groff] global variables and valgrind

[Werner LEMBERG]

[valgrind 1.9.3]

Julian,


congratulations to your program!  I use it to find memory problems
with groff, and while doing so, I wonder whether I can suppress
some warning messages.  For example, calling 

  valgrind --show-reachable=yes \
           --leak-check=yes \
           --trace-children=yes \
    groff -pte -ms -ww pic.ms > pic.ps 2> pic.ps.log

  [pic.ms is part of groff's distribution]

I get a lot of messages like this (omitting the file names; this is
the current CVS snapshot of groff):

  15360 bytes in 5 blocks are still reachable in loss record 21 of 29
     at 0x401678D8: __builtin_vec_new
     by 0x808D915: color::operator new(unsigned int)
     by 0x805FC60: read_rgb(char)
     by 0x8060611: define_color(void)

The `new' operator of the color class uses a memory pool which is
assigned to a global variable (in src/libs/libgroff/color.cc):

  color *color::free_list = 0;

  void *color::operator new(size_t n)
  {
    assert(n == sizeof(color));
    if (!free_list) {
      const int BLOCK = 128;
      free_list = (color *)new char[sizeof(color)*BLOCK];
      for (int i = 0; i < BLOCK - 1; i++)
        free_list[i].next = free_list + i + 1;
      free_list[BLOCK-1].next = 0;
    }
    color *p = free_list;
    free_list = (color *)(free_list->next);
    p->next = 0;
    return p;   
  }

Now I can say this:

  color *fill = new color(...)
  ...
  color *fill = new color(...)
  ...

and pointers to the previous value of `fill' are still valid.  Calling
a special `new' function repeatedly without `delete' to get this
behaviour is used extensively in groff.

How can I make valgrind suppress messages about memory blocks handled
by `color::free_list' and similar global variables which are expected
to be deallocated at exit?  (Please don't say that I shall not use
--leak-check=no :-) For me, none of the possible suppression classes
seem appropriate.


    Werner