public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
* [PATCH] memory leak in libio/wfileops.c do_ftell_wide [BZ #17370]
@ 2014-09-10 20:21 Tim Lammens
  2014-09-10 23:05 ` Siddhesh Poyarekar
  0 siblings, 1 reply; 6+ messages in thread
From: Tim Lammens @ 2014-09-10 20:21 UTC (permalink / raw)
  To: libc-alpha

Hi,

Here is a patch to fix the memory leak in libio/wfileops.c.

Regards,
Tim


diff --git a/libio/wfileops.c b/libio/wfileops.c
index f123add..4b8fda9 100644
--- a/libio/wfileops.c
+++ b/libio/wfileops.c
@@ -711,6 +711,7 @@ do_ftell_wide (_IO_FILE *fp)
                return WEOF;

              offset += outstop - out;
+             free(out);
            }

          /* We don't trust _IO_read_end to represent the current file offset

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

* Re: [PATCH] memory leak in libio/wfileops.c do_ftell_wide [BZ #17370]
  2014-09-10 20:21 [PATCH] memory leak in libio/wfileops.c do_ftell_wide [BZ #17370] Tim Lammens
@ 2014-09-10 23:05 ` Siddhesh Poyarekar
  2014-09-11  7:26   ` Tim Lammens
  2014-09-13  5:48   ` Allan McRae
  0 siblings, 2 replies; 6+ messages in thread
From: Siddhesh Poyarekar @ 2014-09-10 23:05 UTC (permalink / raw)
  To: Tim Lammens; +Cc: libc-alpha

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

On Wed, Sep 10, 2014 at 10:21:23PM +0200, Tim Lammens wrote:
> Hi,
> 
> Here is a patch to fix the memory leak in libio/wfileops.c.

Thanks, I'll push this fix.  Your submission is lacking a ChangeLog,
but I'll write it up for you.  If you're looking to contribute more
regularly, you might want to review the contribution checklist[1].

Siddhesh

[1] https://sourceware.org/glibc/wiki/Contribution%20checklist

> 
> Regards,
> Tim
> 
> 
> diff --git a/libio/wfileops.c b/libio/wfileops.c
> index f123add..4b8fda9 100644
> --- a/libio/wfileops.c
> +++ b/libio/wfileops.c
> @@ -711,6 +711,7 @@ do_ftell_wide (_IO_FILE *fp)
>                 return WEOF;
> 
>               offset += outstop - out;
> +             free(out);
>             }
> 
>           /* We don't trust _IO_read_end to represent the current file offset

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]

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

* Re: [PATCH] memory leak in libio/wfileops.c do_ftell_wide [BZ #17370]
  2014-09-10 23:05 ` Siddhesh Poyarekar
@ 2014-09-11  7:26   ` Tim Lammens
  2014-09-13  5:48   ` Allan McRae
  1 sibling, 0 replies; 6+ messages in thread
From: Tim Lammens @ 2014-09-11  7:26 UTC (permalink / raw)
  To: Siddhesh Poyarekar; +Cc: libc-alpha

Great!

My apologies, I didn't see the checklist in time.

Regards,
Tim

On Thu, Sep 11, 2014 at 1:05 AM, Siddhesh Poyarekar <siddhesh@redhat.com> wrote:
> On Wed, Sep 10, 2014 at 10:21:23PM +0200, Tim Lammens wrote:
>> Hi,
>>
>> Here is a patch to fix the memory leak in libio/wfileops.c.
>
> Thanks, I'll push this fix.  Your submission is lacking a ChangeLog,
> but I'll write it up for you.  If you're looking to contribute more
> regularly, you might want to review the contribution checklist[1].
>
> Siddhesh
>
> [1] https://sourceware.org/glibc/wiki/Contribution%20checklist
>
>>
>> Regards,
>> Tim
>>
>>
>> diff --git a/libio/wfileops.c b/libio/wfileops.c
>> index f123add..4b8fda9 100644
>> --- a/libio/wfileops.c
>> +++ b/libio/wfileops.c
>> @@ -711,6 +711,7 @@ do_ftell_wide (_IO_FILE *fp)
>>                 return WEOF;
>>
>>               offset += outstop - out;
>> +             free(out);
>>             }
>>
>>           /* We don't trust _IO_read_end to represent the current file offset

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

* Re: [PATCH] memory leak in libio/wfileops.c do_ftell_wide [BZ #17370]
  2014-09-10 23:05 ` Siddhesh Poyarekar
  2014-09-11  7:26   ` Tim Lammens
@ 2014-09-13  5:48   ` Allan McRae
  2014-09-15  1:19     ` Siddhesh Poyarekar
  1 sibling, 1 reply; 6+ messages in thread
From: Allan McRae @ 2014-09-13  5:48 UTC (permalink / raw)
  To: Siddhesh Poyarekar, Tim Lammens; +Cc: libc-alpha

On 11/09/14 09:05, Siddhesh Poyarekar wrote:
> On Wed, Sep 10, 2014 at 10:21:23PM +0200, Tim Lammens wrote:
>> Hi,
>>
>> Here is a patch to fix the memory leak in libio/wfileops.c.
> 
> Thanks, I'll push this fix.  Your submission is lacking a ChangeLog,
> but I'll write it up for you.  If you're looking to contribute more
> regularly, you might want to review the contribution checklist[1].
> 
> Siddhesh
> 
> [1] https://sourceware.org/glibc/wiki/Contribution%20checklist
> 

Do we also need to free this in the error case directly above?

>>
>>
>> diff --git a/libio/wfileops.c b/libio/wfileops.c
>> index f123add..4b8fda9 100644
>> --- a/libio/wfileops.c
>> +++ b/libio/wfileops.c
>> @@ -711,6 +711,7 @@ do_ftell_wide (_IO_FILE *fp)
>>                 return WEOF;
>>
>>               offset += outstop - out;
>> +             free(out);
>>             }
>>
>>           /* We don't trust _IO_read_end to represent the current file offset

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

* Re: [PATCH] memory leak in libio/wfileops.c do_ftell_wide [BZ #17370]
  2014-09-13  5:48   ` Allan McRae
@ 2014-09-15  1:19     ` Siddhesh Poyarekar
  2014-09-15 12:00       ` Allan McRae
  0 siblings, 1 reply; 6+ messages in thread
From: Siddhesh Poyarekar @ 2014-09-15  1:19 UTC (permalink / raw)
  To: Allan McRae; +Cc: Tim Lammens, libc-alpha

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

On Sat, Sep 13, 2014 at 03:48:11PM +1000, Allan McRae wrote:
> Do we also need to free this in the error case directly above?

Ugh, yes, thanks for catching that.  Here's a patch to do that.
Tested on x86_64.

Siddhesh

	[BZ #17370]
	* libio/wfileops.c (do_ftell_wide): Free OUT on error path.

diff --git a/libio/wfileops.c b/libio/wfileops.c
index ebc06e8..c5ec5f7 100644
--- a/libio/wfileops.c
+++ b/libio/wfileops.c
@@ -708,7 +708,10 @@ do_ftell_wide (_IO_FILE *fp)
 		 sequences must be complete since they are accepted as
 		 wchar_t; if not, then that is an error.  */
 	      if (__glibc_unlikely (status != __codecvt_ok))
-		return WEOF;
+		{
+		  free (out);
+		  return WEOF;
+		}
 
 	      offset += outstop - out;
 	      free (out);

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]

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

* Re: [PATCH] memory leak in libio/wfileops.c do_ftell_wide [BZ #17370]
  2014-09-15  1:19     ` Siddhesh Poyarekar
@ 2014-09-15 12:00       ` Allan McRae
  0 siblings, 0 replies; 6+ messages in thread
From: Allan McRae @ 2014-09-15 12:00 UTC (permalink / raw)
  To: Siddhesh Poyarekar; +Cc: Tim Lammens, libc-alpha

On 15/09/14 11:19, Siddhesh Poyarekar wrote:
> On Sat, Sep 13, 2014 at 03:48:11PM +1000, Allan McRae wrote:
>> Do we also need to free this in the error case directly above?
> 
> Ugh, yes, thanks for catching that.  Here's a patch to do that.
> Tested on x86_64.
> 
> Siddhesh
> 

Looks good.

Allan

> 	[BZ #17370]
> 	* libio/wfileops.c (do_ftell_wide): Free OUT on error path.
> 
> diff --git a/libio/wfileops.c b/libio/wfileops.c
> index ebc06e8..c5ec5f7 100644
> --- a/libio/wfileops.c
> +++ b/libio/wfileops.c
> @@ -708,7 +708,10 @@ do_ftell_wide (_IO_FILE *fp)
>  		 sequences must be complete since they are accepted as
>  		 wchar_t; if not, then that is an error.  */
>  	      if (__glibc_unlikely (status != __codecvt_ok))
> -		return WEOF;
> +		{
> +		  free (out);
> +		  return WEOF;
> +		}
>  
>  	      offset += outstop - out;
>  	      free (out);
> 

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

end of thread, other threads:[~2014-09-15 12:00 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-10 20:21 [PATCH] memory leak in libio/wfileops.c do_ftell_wide [BZ #17370] Tim Lammens
2014-09-10 23:05 ` Siddhesh Poyarekar
2014-09-11  7:26   ` Tim Lammens
2014-09-13  5:48   ` Allan McRae
2014-09-15  1:19     ` Siddhesh Poyarekar
2014-09-15 12:00       ` Allan McRae

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).