From: Junio C Hamano <gitster@pobox.com>
Date: Wed, 06 Oct 2010 20:10:27 GMT
Subject: Re: [PATCH 2/7] lockfile: introduce alloc_lock_file() to avoid valgrind noise
Message-ID: <7vocb7yte4.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20101002083216.GC29638@burratino>

Jonathan Nieder <jrnieder@gmail.com> writes:

> ...The
> ((optimize("-fno-optimize-sibling-calls"))) attribute is needed on
> platforms with GCC to ensure that the stack frame for
> alloc_lock_file() is not replaced by the stack frame for xcalloc().

Hmm, I am getting

    cc1: warnings being treated as errors
    lockfile.c:189: error: 'optimize' attribute directive ignored
    make: *** [lockfile.o] Error 1

from this patch with gcc (Debian 4.3.2-1.1) 4.3.2

Aren't "struct lock_file" instances supposed to be reachable from the
linked list, i.e. lock_file_list?  Why does valgrind consider that
elements on that list are leaked in the first place?

We keep loaded objects in *obj_hash[] and they sure are "leaked" by the
same definition of leakage, no?  How are we squelching valgrind on them?