Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* [RFA] target.c/read_whatever_is_readable: fix memory leak
@ 2011-02-27 23:50 Michael Snyder
  2011-03-07 20:16 ` Michael Snyder
  2011-03-08  5:13 ` Joel Brobecker
  0 siblings, 2 replies; 4+ messages in thread
From: Michael Snyder @ 2011-02-27 23:50 UTC (permalink / raw)
  To: gdb-patches

[-- Attachment #1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #2: read_whatever.txt --]
[-- Type: text/plain, Size: 1194 bytes --]

2011-02-27  Michael Snyder  <msnyder@vmware.com>

	* target.c (read_whatever_is_readable): Fix memory leak.

Index: target.c
===================================================================
RCS file: /cvs/src/src/gdb/target.c,v
retrieving revision 1.275
diff -u -p -u -p -r1.275 target.c
--- target.c	15 Feb 2011 17:22:21 -0000	1.275
+++ target.c	27 Feb 2011 23:27:16 -0000
@@ -1954,7 +1954,7 @@ read_whatever_is_readable (struct target
 			   ULONGEST begin, ULONGEST end,
 			   VEC(memory_read_result_s) **result)
 {
-  gdb_byte *buf = xmalloc (end-begin);
+  gdb_byte *buf = xmalloc (end - begin);
   ULONGEST current_begin = begin;
   ULONGEST current_end = end;
   int forward;
@@ -1962,7 +1962,10 @@ read_whatever_is_readable (struct target
 
   /* If we previously failed to read 1 byte, nothing can be done here.  */
   if (end - begin <= 1)
-    return;
+    {
+      xfree (buf);
+      return;
+    }
 
   /* Check that either first or the last byte is readable, and give up
      if not.  This heuristic is meant to permit reading accessible memory
@@ -1981,6 +1984,7 @@ read_whatever_is_readable (struct target
     }
   else
     {
+      xfree (buf);
       return;
     }
 

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [RFA] target.c/read_whatever_is_readable: fix memory leak
  2011-02-27 23:50 [RFA] target.c/read_whatever_is_readable: fix memory leak Michael Snyder
@ 2011-03-07 20:16 ` Michael Snyder
  2011-03-08  5:13 ` Joel Brobecker
  1 sibling, 0 replies; 4+ messages in thread
From: Michael Snyder @ 2011-03-07 20:16 UTC (permalink / raw)
  To: gdb-patches

Ping?


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [RFA] target.c/read_whatever_is_readable: fix memory leak
  2011-02-27 23:50 [RFA] target.c/read_whatever_is_readable: fix memory leak Michael Snyder
  2011-03-07 20:16 ` Michael Snyder
@ 2011-03-08  5:13 ` Joel Brobecker
  2011-03-08 19:39   ` Michael Snyder
  1 sibling, 1 reply; 4+ messages in thread
From: Joel Brobecker @ 2011-03-08  5:13 UTC (permalink / raw)
  To: Michael Snyder; +Cc: gdb-patches

> 2011-02-27  Michael Snyder  <msnyder@vmware.com>
> 
> 	* target.c (read_whatever_is_readable): Fix memory leak.

Looks correct to me.

>  {
> -  gdb_byte *buf = xmalloc (end-begin);
> +  gdb_byte *buf = xmalloc (end - begin);

I applied this change myself (as well as a couple of other reformatting
changes), mostly because I have a fairly strong preference over
separating this type of change (reformatting - no code change) from
code changes. It simplifies our task if/when a revert is needed.

With git, there is a neat way to commit those changes separately
from your other changes: It's "git add -p" - it then asks you
hunk by hunk whether to put the change in the index or not (and
you and further divide hunks if necessary). Really useful in this
sort of situation.

-- 
Joel


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [RFA] target.c/read_whatever_is_readable: fix memory leak
  2011-03-08  5:13 ` Joel Brobecker
@ 2011-03-08 19:39   ` Michael Snyder
  0 siblings, 0 replies; 4+ messages in thread
From: Michael Snyder @ 2011-03-08 19:39 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: gdb-patches

Joel Brobecker wrote:
>> 2011-02-27  Michael Snyder  <msnyder@vmware.com>
>>
>> 	* target.c (read_whatever_is_readable): Fix memory leak.
> 
> Looks correct to me.
> 
>>  {
>> -  gdb_byte *buf = xmalloc (end-begin);
>> +  gdb_byte *buf = xmalloc (end - begin);
> 
> I applied this change myself (as well as a couple of other reformatting
> changes), mostly because I have a fairly strong preference over
> separating this type of change (reformatting - no code change) from
> code changes. It simplifies our task if/when a revert is needed.
> 
> With git, there is a neat way to commit those changes separately
> from your other changes: It's "git add -p" - it then asks you
> hunk by hunk whether to put the change in the index or not (and
> you and further divide hunks if necessary). Really useful in this
> sort of situation.
> 

Thanks - committed.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2011-03-08 18:59 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-02-27 23:50 [RFA] target.c/read_whatever_is_readable: fix memory leak Michael Snyder
2011-03-07 20:16 ` Michael Snyder
2011-03-08  5:13 ` Joel Brobecker
2011-03-08 19:39   ` Michael Snyder

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox