Cppcheck-1.90 is late

[Daniel Marjamäki]

We can't release Cppcheck-1.90 for a while because of the quality issues.

I would like to get the number of defects down. We used to have ~200. There are 246 right now and it feels unacceptable.

There are a couple of daca@home issues that need to be fixed ... crashes and stuff.

I still think that minor improvements can be added but not major.

[Daniel Marjamäki]

If you see some issue you think is a blocker.. feel free to discuss that here.. For instance I did not mention any specific hang/crash/ticket.. feel free to do that.

[Daniel Marjamäki]

I have been working on verification and Z3 integration. For your information this analysis is still too unmature and I do not plan to release it in 1.90.

[Paul Fultz]

We should try to fix these syntax errors:

https://trac.cppcheck.net/ticket/9444
https://trac.cppcheck.net/ticket/9443
https://trac.cppcheck.net/ticket/9301
https://trac.cppcheck.net/ticket/9245
https://trac.cppcheck.net/ticket/9185

Among other FPs we have to fix as well.

[Robert Reif]

I would like to see the clang testsuite in travis added back because it would have stopped a lot of these new regressions. daca doesn't run the clang testsuite.

I use the clang testsuite for testing but it hasn't passed in months despite me fixing several bugs it found.

[Daniel Marjamäki]

I would like to see the clang testsuite in travis added back because it would have stopped a lot of these new regressions. daca doesn't run the clang testsuite.

Yes. It would be very valuable to scan clang.

In my humble opinion the commit-triggered builds are way too slow. If I push something bad I sometimes learn about it the next day. You try to fix such problem and don't know if it pass all checks until hours later.

How about putting "slow" or "not very important" tests in a nightly cron job:
https://docs.travis-ci.com/user/cron-jobs/

[Daniel Marjamäki]

I started experimenting with a nightly travis job. to start with it will be in a parallell branch nightly. I use a parallell branch because the cron job will also execute .travis.yml and I envision we want to have two separate .travis.yml files for commit-triggered and cron jobs.

[versat]

Currently there are about 25 packages with crashes: http://cppcheck1.osuosl.org:8000/crash.html
The number of crashes has increased in the last days.

[Daniel Marjamäki]

Thanks! That was a drastic and unfortunate change. Hopefully it's easy to fix.

[Daniel Marjamäki]

Currently there are about 25 packages with crashes

If anybody wants to help out without programming... feel free to download the source code for a crash and reduce it.

[Robert Reif]

I reduced the sparse-0.6.1 crash to:

void test_address ( int arg )
{ 
lab :
if ( & arg ) return ;
if ( && lab ) return ;
}

&& of a label is a gnu extension: https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html

[versat]

I reduced the rodbc_1.3-16 crash to:

void f()
{
    while(1)
    {
        if (retval == ){}
    }
}

The code does not make sense / is syntactically not correct.
But interestingly if while(1) is removed it does no longer crash.
RODBC is one .c file so it is easy to reproduce.
Actually retval is compared to a macro which is defined to be nothing.
I guess when running configure or so this macro normally is not empty/nothing.
So the code is not always invalid i think.

[Daniel Marjamäki]

syntax error is added

[versat]

The reduced code of libmemcached_1.0.18 crash seems to be also invalid (when the macros are (not) set accordingly):

# define atomic_add_32_nv(X, Y)

static int ms_reconn(ms_conn_t *c)
{
  c->tcpsfd[c->cur_idx] = 0;

  if (atomic_add_32_nv(&ms_setting.servers[srv_idx].disconn_cnt, 1)
      % srv_conn_cnt == 0)
  {
  }
}

The crash can be easily reproduced when analyzing ms_conn.c and making ms_atomic.h available. All other sources are not necessary.
The empty macros are some sort of fallback and it sounds like they should work. But maybe this code path is not tested.

[x-flow]

Cppcheck is accessing a null pointer so it will crash. This line:

astutils.cpp:1649
if (condTok->hasKnownIntValue()) {

(not checking if condTok is null)

[Robert Reif]

Here is a reduced nyquist:

a() {
  char inline;
  int b = 0;
  if (inline)
    ;
}

This requires --std=c89 to compile.

[x-flow]

Same problem as libmemcached_1.0.18 :

Cppcheck is accessing a null pointer so it will crash. This line:

astutils.cpp:1649
if (condTok->hasKnownIntValue()) {

(not checking if condTok is null)

Maybe previous releases never returned a null astOperand2. Still the condition should be checked.

[versat]

I have reduced the crash in z3_4.8.6 to:

namespace sat {
    void f() {
        for (unsigned i = m_entries.size(); i-- > m_exposed_lim; ) {
            DEBUG_CODE({
                bool undef = false;
                for (literal const& l : e.m_clauses)
                {
                    if (sat)
                        continue;
                }
            });
        }
    }
};

I guess that the missing definition for macro DEBUG_CODE() causes the crash.
It is defined in a header file debug.h that is not seen without corresponding include path configuration.
The definition looks like this:

#ifdef Z3DEBUG
#define DEBUG_CODE(CODE) { CODE } ((void) 0)
#else
#define DEBUG_CODE(CODE) ((void) 0)
#endif

If this would be seen by Cppcheck there would be no crash.
I guess Cppcheck should issue an error that the definition of macro DEBUG_CODE() is not seen but necessary and then maybe abort analysis to avoid a crash (or handle the unexpected code somehow).

To reproduce the crash it is enough to let Cppcheck analyze the file sat_model_converter.cpp. No other files needed.

[Daniel Marjamäki]

I guess Cppcheck should issue an error that the definition of macro DEBUG_CODE() is not seen but necessary and then maybe abort analysis to avoid a crash (or handle the unexpected code somehow).

that is a reasonable solution

[Daniel Marjamäki]

I changed my mind and want to try to handle this anyway. It seems we could handle this and lambdas in a similar way.

I tried to fix this with: https://github.com/danmar/cppcheck/commit/ab2274b8ad8981bd8cab431bfbe36d15873da729

[x-flow]

Seems fixed.

[versat]

Here is some reduced code from the crash in wiggle_1.1:

static __exit void md_exit(void)
{
    mddev_t *mddev;

    for (({ mddev = NULL;});
         ({if(!mddev) printf("a"); if(mddev) printf("b"); });
        )
}

The if constructs in the non-standard GCC Statement Expressions seem to cause the crash. But the not reduced source code is very likely valid GCC code.

For reproducing the crash it is enough to analyze the file md.c from the package ftp://ftp.de.debian.org/debian/pool/main/w/wiggle/wiggle_1.1.orig.tar.gz

[x-flow]

Same problem as nyquist and libmemcached_1.0.18. Good thing solving this bug solves several crashes.

Cppcheck is accessing a null pointer so it will crash. This line:

astutils.cpp:1649
if (condTok->hasKnownIntValue()) {

(not checking if condTok is null)

Maybe previous releases never returned a null astOperand2. Still the condition should be checked.

[versat]

Reduced C code from crash in gdb_7.7.1:

void f (int restrict)
{
  int code;

  if ((code & 0x4) == 0)
  {
    if (restrict)
    {}
  }
}

restrict is a keyword since C99
When specifying --std=c89 Cppcheck does not crash:

$ ./cppcheck --std=c89 m68hc11_sim.c
Checking m68hc11_sim.c ...
m68hc11_sim.c:5:8: error: Uninitialized variable: code [uninitvar]
  if ((code & 0x4) == 0)
       ^

When leaving the default or explicitly specifying some other standard, then Cppcheck crashes:

$ ./cppcheck --std=c99 m68hc11_sim.c
Checking m68hc11_sim.c ...
Segmentation fault (core dumped)

I guess it would be better to issue some syntax error or so instead of crashing.

The crash occurrs when analyzing m68hc11_sim.c. Instead of downloading and extracting the whole package it worked for me to test the file found here: http://bggit.ihub.org.cn/p70142835/riscv-binutils-gdb/blob/ae9a127f867f404d20b8010b401ca9aaae9018d9/sim/m68hc11/m68hc11_sim.c

[x-flow]

All these crashes are related with not checking if condTok is null.

astutils.cpp:1649
if (condTok->hasKnownIntValue()) {