bug-wget
[Top][All Lists]
Advanced

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

Re: [Bug-wget] Some potential memory leaks in wget-1.3


From: Tim Ruehsen
Subject: Re: [Bug-wget] Some potential memory leaks in wget-1.3
Date: Wed, 11 Apr 2012 17:50:49 +0200
User-agent: KMail/1.13.7 (Linux/3.2.0-2-amd64; KDE/4.7.4; x86_64; ; )

Am Wednesday 11 April 2012 schrieb Zhenbo Xu:
> Hi, wget,
> I have applied a memory leak detection tool
> Melton<http://lcs.ios.ac.cn/~xuzb/melton.html> to
> find memory leaks in wget-1.3.
> Some potential bugs were found, and I check them manually as the real bugs.
> Here is the index url of thes bugs:
> http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/wget-1.13/realbugs/index.html
> 
> Or you can download it from the following url:
> http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/wget-1.13/realbugs_wget_1.13.t
> ar.gz
> 
> Hope for your replies.

Thanks for reporting.

BTW, nice tool - I have to check it out.

#7 and #8 are obvious memory leaks.
#9 irritates me, since the real code is different from what Melton displays.
Melton:
              if (remaining_chunk_size == 0)
                        if (fd_read_line (fd) == ((void *)0))
                          {
                            ret = -1;
                            break;
                          }
                    }

wget code:
              if (remaining_chunk_size == 0)
                {
                  char *line = fd_read_line (fd);
                  if (line == NULL)
                    {
                      ret = -1;
                      break;
                    }
                  else
                    {
                      if (out2 != NULL)
                        fwrite (line, 1, strlen (line), out2);
                      xfree (line);
                    }
                }

Either Melton uses a different code base or it is a bug.

As long as nobody complains, I check the reports tomorrow and create patch(s).

Tim
> 
> Some explanations are given below:
> 
> *Bug No. 7 and No. 8:*
> a heap object is allocated to respline at :
> 8030 err = ftp_response (csock,
> &respline)<http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/wget-1.13/realbugs/
> report-KG45QU.html#Path9_2> ;
> and it's not freed at
> 8043 return FTPINVPASV;
> 
> *Bug No. 9 ~ No. 16:*
> As function fd_read_line(..) returns a heap object and there is not any
> free statement in programs, memory leaks may occur.
> 
> 
> *Bug No. 17:*
> req = request_new
> ()<http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/wget-1.13/realbugs/report-5
> 5xqty.html#Path49_2> ;
> req is not freed along the annotated path.
> 
> *Bug No. 20:*
> There are two kinds of bugs in this report.
> The first one:
> at function setval_internal_tilde,
> 8278 home = home_dir
> ()<http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/wget-1.13/realbugs/report-M
> uxcQK.html#Path11_3>;
> 
> home should be released at the end of this function.
> 
> The second one:
> before the following assignment
> *pstring = concat_strings (home, "/", val, (char *)0);
> As pstring = commands[comind].place, Should we free commands[comind].place
> at first to avoid the reassignment?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]