potential memory leaks

["Gary Yee" <gary@pressler.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1898 bytes --]

Hi!
I'm currently looking over the code for version 
3.113 of GNATS.  I think there are some potential memory 
leaks.
 
Here is some code from main.c:
 
  /* Check if the message is a reply to an 
existing PR; if it is, then
     just append this message to 
the end of that PR. Otherwise, process
     it normally. */
  pr_path = check_if_reply ();
  if (pr_path)
    {
    /* Before inserting the reply, see 
if someone's got the PR
       locked; if 
they do, then try it at the next run of the queue. */
      char *buf = 
get_lock_path (pr_path);
      if (access (buf, R_OK) 
== 0)
        
{
          
unlock_gnats ();
          
exit (1);
        
}
      append_report (fp, 
pr_path);
      xfree 
(pr_path);
    }
  else
    gnats (fp);
 
  /* Clean up. */
  if (log_method == MAIL)
    close_mail_file 
(gnats_logfile);
#ifdef HAVE_SYSLOG_H
  else if (log_method == 
SYSLOG)
    closelog ();
#endif
 
  /* unlock the whole thing. */
  unlock_gnats ();
  free_db_conf();
  exit (0);
}
 
If the call to access() returns 0, which means that 
the PR is already locked, shouldn't there be calls to close_mail_file(), 
free_db_conf(), and xfree() along with the call to unlock_gnats()?
 
In headers.c, the call to set_continued_header() is 
immediately followed by the line
 
    buf = NULL;
 
This assumes that the memory originally pointed to 
by buf gets assigned to something in the set_continued_header function.  
This is true except when header[i].value is not NULL and (keep_rec && i 
== RECEIVED) is false.  In this case, nothing is done with 
buf.
 
That's all for now.
 
Regards,
Gary