Re: [PATCH 2/7] lockfile: introduce alloc_lock_file() to avoid valgrind noise
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Oct 6, 2010, 20:10 UTC
- 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 1from 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?