* [PATCH hail] lib/hstor.c: avoid an unconditional leak in append_qparam
@ 2010-09-27 8:53 Jim Meyering
2010-09-27 16:29 ` Pete Zaitcev
2010-09-27 16:53 ` Jeff Garzik
0 siblings, 2 replies; 6+ messages in thread
From: Jim Meyering @ 2010-09-27 8:53 UTC (permalink / raw)
To: Project Hail
Signed-off-by: Jim Meyering <meyering@redhat.com>
---
I would have preferred to insert a single line right before the
huri_field_escape call:
char *v = strdup(val);
[would result in a more compact, single-hunk patch]
but it looks like hail uses the anachronistic (pre-C99)
"declare all vars at outer scope" style, so I conformed.
lib/hstor.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/lib/hstor.c b/lib/hstor.c
index 6c67bfa..79e0420 100644
--- a/lib/hstor.c
+++ b/lib/hstor.c
@@ -676,6 +676,7 @@ static GString *append_qparam(GString *str, const char *key, const char *val,
char *arg_char)
{
char *stmp;
+ char *v;
str = g_string_append(str, arg_char);
arg_char[0] = '&';
@@ -683,9 +684,11 @@ static GString *append_qparam(GString *str, const char *key, const char *val,
str = g_string_append(str, key);
str = g_string_append(str, "=");
- 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);
return str;
}
--
1.7.3.234.g7bba3
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH hail] lib/hstor.c: avoid an unconditional leak in append_qparam
2010-09-27 8:53 [PATCH hail] lib/hstor.c: avoid an unconditional leak in append_qparam Jim Meyering
@ 2010-09-27 16:29 ` Pete Zaitcev
2010-09-27 17:05 ` Jim Meyering
2010-09-28 0:23 ` Jeff Garzik
2010-09-27 16:53 ` Jeff Garzik
1 sibling, 2 replies; 6+ messages in thread
From: Pete Zaitcev @ 2010-09-27 16:29 UTC (permalink / raw)
To: Jim Meyering; +Cc: Project Hail, zaitcev
On Mon, 27 Sep 2010 10:53:06 +0200
Jim Meyering <jim@meyering.net> 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.
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.
-- Pete
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH hail] lib/hstor.c: avoid an unconditional leak in append_qparam
2010-09-27 8:53 [PATCH hail] lib/hstor.c: avoid an unconditional leak in append_qparam Jim Meyering
2010-09-27 16:29 ` Pete Zaitcev
@ 2010-09-27 16:53 ` Jeff Garzik
2010-09-28 0:24 ` Pete Zaitcev
1 sibling, 1 reply; 6+ messages in thread
From: Jeff Garzik @ 2010-09-27 16:53 UTC (permalink / raw)
To: Jim Meyering; +Cc: Project Hail
On 09/27/2010 04:53 AM, Jim Meyering wrote:
>
>
> Signed-off-by: Jim Meyering<meyering@redhat.com>
> ---
> I would have preferred to insert a single line right before the
> huri_field_escape call:
>
> char *v = strdup(val);
>
> [would result in a more compact, single-hunk patch]
> but it looks like hail uses the anachronistic (pre-C99)
> "declare all vars at outer scope" style, so I conformed.
>
> lib/hstor.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/lib/hstor.c b/lib/hstor.c
> index 6c67bfa..79e0420 100644
> --- a/lib/hstor.c
> +++ b/lib/hstor.c
> @@ -676,6 +676,7 @@ static GString *append_qparam(GString *str, const char *key, const char *val,
> char *arg_char)
> {
> char *stmp;
> + char *v;
>
> str = g_string_append(str, arg_char);
> arg_char[0] = '&';
> @@ -683,9 +684,11 @@ static GString *append_qparam(GString *str, const char *key, const char *val,
> str = g_string_append(str, key);
> str = g_string_append(str, "=");
>
> - 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);
>
applied
Yeah, I don't like C++ var decls; I think the code gets too
disorganized, making it really easy to miss a decl when reviewing.
Jeff
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH hail] lib/hstor.c: avoid an unconditional leak in append_qparam
2010-09-27 16:29 ` Pete Zaitcev
@ 2010-09-27 17:05 ` Jim Meyering
2010-09-28 0:23 ` Jeff Garzik
1 sibling, 0 replies; 6+ messages in thread
From: Jim Meyering @ 2010-09-27 17:05 UTC (permalink / raw)
To: Pete Zaitcev; +Cc: Project Hail
Pete Zaitcev wrote:
> On Mon, 27 Sep 2010 10:53:06 +0200
> Jim Meyering <jim@meyering.net> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH hail] lib/hstor.c: avoid an unconditional leak in append_qparam
2010-09-27 16:29 ` Pete Zaitcev
2010-09-27 17:05 ` Jim Meyering
@ 2010-09-28 0:23 ` Jeff Garzik
1 sibling, 0 replies; 6+ messages in thread
From: Jeff Garzik @ 2010-09-28 0:23 UTC (permalink / raw)
To: Pete Zaitcev; +Cc: Jim Meyering, Project Hail
On 09/27/2010 12:29 PM, Pete Zaitcev wrote:
> On Mon, 27 Sep 2010 10:53:06 +0200
> Jim Meyering<jim@meyering.net> 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
Doh, my memory and I were fooled, too.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH hail] lib/hstor.c: avoid an unconditional leak in append_qparam
2010-09-27 16:53 ` Jeff Garzik
@ 2010-09-28 0:24 ` Pete Zaitcev
0 siblings, 0 replies; 6+ messages in thread
From: Pete Zaitcev @ 2010-09-28 0:24 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Jim Meyering, Project Hail
On Mon, 27 Sep 2010 12:53:48 -0400
Jeff Garzik <jeff@garzik.org> 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);
>
> applied
I'm going to post a patch that undoes the damage. It's in testing.
-- Pete
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-09-28 0:24 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-09-27 8:53 [PATCH hail] lib/hstor.c: avoid an unconditional leak in append_qparam Jim Meyering
2010-09-27 16:29 ` Pete Zaitcev
2010-09-27 17:05 ` Jim Meyering
2010-09-28 0:23 ` Jeff Garzik
2010-09-27 16:53 ` Jeff Garzik
2010-09-28 0:24 ` Pete Zaitcev
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox