Menu

Found a regression between 1.80 and 1.83

2018-04-22
2018-04-24
  • Steve Grubb

    Steve Grubb - 2018-04-22

    Hello,

    I was doing some testing and found that 1.83 is giving a false positive for code that checks OK on 1.80. The reproducer looks like this:

    void fopen_test(const char *filename)
    {
            FILE *fp;
    
            if (!filename || !(fp = fopen(filename, "r")))
                    return;
            fclose(fp);
    }
    

    On 1.80 it checks good. On 1.83 I get a message like this:
    : (error) Resource leak: fp

    Is this a known issue?

    Thanks,
    -Steve

     

    Last edit: Steve Grubb 2018-04-24
  • versat

    versat - 2018-04-23

    Hi Steve, thanks for the report.
    The code looks a bit broken, can you please use the code formatting syntax, for example:

    ~~~
    code goes here
    ~~~

    You can also attach a source file to be sure nothing gets changed.
    Have you searched trac already if there is a ticket for this?

     
  • versat

    versat - 2018-04-23

    I think that the ticket https://trac.cppcheck.net/ticket/8103 and the duplicate https://trac.cppcheck.net/ticket/8396 are about your reported issue.
    Can you have a look at them and verify it?

     
  • Steve Grubb

    Steve Grubb - 2018-04-23

    Hello,

    Sorry about the formatting. Looks like the asterisk got eaten. That ticket looks very close to the problem I run across. Since its a regression, I'm wondering if anyone tried git bisect to locate the commit that caused it?

    -Steve

     
    • versat

      versat - 2018-04-24

      You should be able to edit the post and fix the formatting.
      Maybe no one noticed that it is a regression up to now.

       
  • Steve Grubb

    Steve Grubb - 2018-04-23

    Hello,

    Git bisect says this is the first bad commit:
    94031ef11d1821c4974e859c8df7bf5f2a1727ad

    -Steve

     
  • Steve Grubb

    Steve Grubb - 2018-04-24

    What I found is the problem showed up on 1.82 and it was OK in 1.81. Ticket 8103 was opened before the patch that git bisect found. My guess, now that I've had time to think about it, is that it missed the allocation in 1.81 and thus no report. The patch fixes a problem to catch memory allocations but does not account for an error condition that leads to no allocation.

    In doing more modelling of a bunch of linux kernel syscalls, I started to wonder if there should be some generic way to specify a return code that signals no allocation because of error? IOW, if I teach cppcheck that eventfd allocates a resource, how does it know when no allocation was made? I think that fopen could use the same mechanism to decide if an allocation was made or not.

     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.