bug-cvs
[Top][All Lists]
Advanced

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

[bug #36276] Potential problem in parse_config() which may leak file des


From: anonymous
Subject: [bug #36276] Potential problem in parse_config() which may leak file descriptor
Date: Mon, 23 Apr 2012 20:26:36 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.162 Safari/535.19

URL:
  <http://savannah.nongnu.org/bugs/?36276>

                 Summary: Potential problem in parse_config() which may leak
file descriptor
                 Project: Concurrent Versions System
            Submitted by: None
            Submitted on: Mon Apr 23 20:26:36 2012
                Category: Bug Report
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
                 Release: 
         Discussion Lock: Any
           Fixed Release: None
   Fixed Feature Release: None

    _______________________________________________________

Details:

We are developing a tool to find bugs, and it flagged a potential error in
CVS.
We are checking CVS version 1.11.23.
In parse_config() in src/parseinfo.c, the config file is opened at line 274:

274:    fp_info = CVS_FOPEN (infopath, "r");

The file is closed if everything goes well:

461:    if (fclose (fp_info) < 0)

But if there is a syntax error, the file is not closed:

321:    p = strchr (line, '=');
322:    if (p == NULL)
323:    {
323:        /* Probably should be printing line number.  */
324:        error (0, 0, "syntax error in %s: line '%s' is missing '='",
325:               infopath, line);
326:        goto error_return;
327:    }
...
474: error_return:
475:    if (!logHistory)
476:    logHistory = xstrdup (ALL_HISTORY_REC_TYPES);
477:    if (infopath != NULL)
478:    free (infopath);
479:    if (line != NULL)
480:    free (line);
          // Shall we have something like
          // if (fp_info) fclose(fp_info);
          // here?
481:    return -1;
482:}

Since the problem is due to a syntax error, shall we still close the file?
We may just move the call to fclose() into the error_return block.
Else the file would be left opened after the function returns.

Is this a real problem? Any confirmation or clarification is
appreciated. Thanks.





    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?36276>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/




reply via email to

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