Detection of mismatching allocation and deallocation

[Markus Elfring]

I needed another moment to realise that I submitted the bug report “Fix a mismatching allocation and deallocation for the variable “buf”” based on an analysis result by the program version “1.84 dev”.
Now I wonder why the same information is not presented by the version “1.88-24.d_t.13” here.

[Markus Elfring]

I have taken another look at the following function implementation.

    void getErrorMessages(ErrorLogger *e, const Settings *settings) const OVERRIDE {
// …
        const std::list<const Token *> callstack;
        c.mismatchAllocDealloc(callstack, "varname");
// …
    }

Now I wonder about the properties for this local variable.
🔮 Should the “call stack” be filled with useful data anyhow?

[Daniel Marjamäki]

no file has been analysed so there are no locations

[Markus Elfring]

• Should the check be called with a parameter less if such a list is kept empty so far?
• Is this variable superfluous at the moment?

[Daniel Marjamäki]

I don't want to debate how we implement this. there are more productive ways to spend time.

[Markus Elfring]

🔮 I hope that ways can be clarified to improve the software situation also around the reported false negative.

[Daniel Marjamäki]

I wonder if you could create some small testsuite. short code examples with some known bugs.

[versat]

Just to get it right:
You wrote in the issue report that you used 1.88, but in fact 1.84 has been used?
And with 1.88 it is no longer detected?
Can you try to create a reduced example with 1.84 where the issue is detected?
I can imagine that in the line NEWCHECK(buf = new unsigned char[len]); the macro NEWCHECK() is not known to Cppcheck and that has something to do with the false negative.

[Markus Elfring]

You wrote in the issue report that you used 1.88,

Such a version was also installed on my system by a software package.

but in fact 1.84 has been used?

Yes.

And with 1.88 it is no longer detected?

Two developers got this impression.

Can you try to create a reduced example with 1.84 where the issue is detected?

The questionable source code can be extracted from a single function implementation.
But my motivation would be low at the moment to reduce it further.

[Markus Elfring]

I have determined that a commit between the program versions “1.85” and “1.86” influenced this source code search pattern in undesirable ways.
Would you like to narrow questionable changes down further?

[Daniel Marjamäki]

i would like to see a short code example. I assume that the false negative is caused by incomplete/inconclusive code. but without a short code example it's not easy to say.

[Markus Elfring]

• How do you think about any help with bisecting such an issue?
• Do you find the source file “vglclient.cpp” (which was affected before the commit “Use delete[] instead of free() for memory allocated with new.” on 2019-12-12) interesting for further clarification?

[Daniel Marjamäki]

no that is not interesting. the code example must be 5-10 lines of code at most.

[Markus Elfring]

I am curious then how our different source code size tolerance can be adjusted to fix this issue easier.

[Markus Elfring]

My bisection approach pointed the commit “comment out old memleak checking. maybe it can be removed.” (from 2018-11-20) out as “the first” questionable one for this issue.
Now I am curious how the software evolution will be continued since further adjustments were applied also around the implementation of the function “runSimplifiedChecks”.

[Daniel Marjamäki]

for information. I think "mismatching allocation and deallocation" is quite important. I wish we had more people and that somebody could work on everything that was important.
as it is we can't work on everything that is important. And personally this is not checking I personally prioritize as highly as some other checks. It's more a problem in C code than in modern C++. However maybe somebody else will feel that this should be fixed.