Re: [PATCH v3 1/2] t/helper/test-truncate: close file descriptor after truncation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hoyoung Lee <lhywkd22@xxxxxxxxx> writes:

> Fix a resource leak where the file descriptor was not closed after
> truncating a file in t/helper/test-truncate.c.
>
> Signed-off-by: Hoyoung Lee <lhywkd22@xxxxxxxxx>
> ---
>  t/helper/test-truncate.c | 3 +++
>  1 file changed, 3 insertions(+)

While it is not wrong per-se, it is not like a function that can
potentially be called number of times returns without closing it.
Nobody other than the main() function would be calling this
function, so the only thing that is done after this function returns
to its caller is for the caller to return leading to exit from the
process at which point the leftover file descriptor would be
closed.

So I am a bit curious what triggered you to send in these changes.
Are there some automated resource leak checker, without fixes like
these whose output would be noisy with complaints about these "known
leaking, no ill effects in practice, yet gets flagged by checkers"
code to be useful, or something?

Will queue; thanks.

> diff --git a/t/helper/test-truncate.c b/t/helper/test-truncate.c
> index 3931deaec7..104bc36cc0 100644
> --- a/t/helper/test-truncate.c
> +++ b/t/helper/test-truncate.c
> @@ -21,5 +21,8 @@ int cmd__truncate(int argc, const char **argv)
>  
>  	if (ftruncate(fd, (off_t) sz) < 0)
>  		die_errno("failed to truncate file");
> +	
> +	close(fd);
> +
>  	return 0;
>  }




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux