From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Meyering Subject: Re: [PATCH hail] lib/hstor.c: avoid an unconditional leak in append_qparam Date: Mon, 27 Sep 2010 19:05:47 +0200 Message-ID: <87tylbt8us.fsf@meyering.net> References: <87tylbeff1.fsf@meyering.net> <20100927102927.45686afa@lembas.zaitcev.lan> Mime-Version: 1.0 Return-path: In-Reply-To: <20100927102927.45686afa@lembas.zaitcev.lan> (Pete Zaitcev's message of "Mon, 27 Sep 2010 10:29:27 -0600") Sender: hail-devel-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Pete Zaitcev Cc: Project Hail Pete Zaitcev wrote: > On Mon, 27 Sep 2010 10:53:06 +0200 > Jim Meyering wrote: > >> - stmp = huri_field_escape(strdup(val), QUERY_ESCAPE_MASK); >> + v = strdup(val); >> + stmp = huri_field_escape(v, QUERY_ESCAPE_MASK); >> str = g_string_append(str, stmp); >> free(stmp); >> + free(v); > > I think you may be fooled by the ridiculous calling convention > of huri_field_escape(). It takes a pointer to heap, then either > returns its argument, or reallocates it, frees the argument, and > returns the reallocated area. It frees with g_free, so it assumes > its equivalence with free(), haha. > > The end result, it either returns what strdup returned of frees it. > Therefore if you free what strudup returned, you double-free it. Oh! You're right. I missed the "g_free (signed_str);" at the end of huri_field_escape. Sorry about that. > I honestly think this madness must stop and huri_field_escape > must allocate a new buffer every time. Then we would not need > the strdup there at all. It only exists to satisfy the requirement > to pass a pointer to heap in case val is a const or whatnot. Making a function like huri_field_escape free a buffer allocated by the caller does seem to violate something fundamental.