Bug 1663372 - pcp does not set include dir for cppcheck
Summary: pcp does not set include dir for cppcheck
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: pcp
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Mark Goodwin
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-01-04 05:45 UTC by Mark Goodwin
Modified: 2019-03-17 19:35 UTC (History)
9 users (show)

Fixed In Version: pcp-4.3.1-1 pcp-4.3.1-2.fc28 pcp-4.3.1-2.fc29
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-03-17 07:20:27 UTC


Attachments (Terms of Use)
cppcheck log whith --quiet removed (1.93 KB, text/plain)
2019-01-04 07:33 UTC, Mamoru TASAKA
no flags Details

Description Mark Goodwin 2019-01-04 05:45:08 UTC
Description of problem:
cppcheck v1.86 on PCP source fails when it should pass. In fact, the previous version of cppcheck (1.85) does pass on the same source tree. The new version seems to ignore certain macros and/or fails to include headers correctly.

Version-Release number of selected component (if applicable): cppcheck-1.86-1

How reproducible: easily

Steps to Reproduce:
1. git clone https://github.com/performancecopilot/pcp.git
2. cd pcp; sudo dnf builddep build/rpm/fedora.spec
3. ./configure; make check

Actual results: cppcheck fails on src/pmcd/src/config.c

Expected results: cppcheck should pass, like it used to with v1.85


Additional info:

See the travis-ci raw logs at https://travis-ci.org/performancecopilot/pcp
And the following, as posted to the PCP upstream development list :

mgoodwin@~/src/pcp/src/pmcd/src[master]$ make check
cppcheck --std=posix --force --quiet --error-exitcode=1 pmcd.c config.c dofetch.c dopdus.c dostore.c client.c agent.c client.h pmcd.h
[config.c:2430]: (error) syntax error
make: *** [GNUmakefile:45: check] Error 1

there doesn't seem to be anything wrong with the PCP code :

mgoodwin@~/src/pcp/src/pmcd/src[master]$ cat -n config.c | head -2431 | tail -21
  2411	     */
  2412	#if defined(HAVE_ST_MTIME_WITH_SPEC)
  2413	    if (pmDebugOptions.appl0)
  2414		fprintf(stderr, "ParseRestartAgents: new configFileTime=%ld.%09ld sec\n",
  2415		    (long)statBuf.st_mtimespec.tv_sec, (long)statBuf.st_mtimespec.tv_nsec);
  2416	    if (statBuf.st_mtimespec.tv_sec == configFileTime.tv_sec &&
  2417	        statBuf.st_mtimespec.tv_nsec == configFileTime.tv_nsec)
  2418	#elif defined(HAVE_STAT_TIMESPEC_T) || defined(HAVE_STAT_TIMESTRUC) || defined(HAVE_STAT_TIMESPEC)
  2419	    if (pmDebugOptions.appl0)
  2420		fprintf(stderr, "ParseRestartAgents: new configFileTime=%ld.%09ld sec\n",
  2421		    (long)statBuf.st_mtim.tv_sec, (long)statBuf.st_mtim.tv_nsec);
  2422	    if (statBuf.st_mtim.tv_sec == configFileTime.tv_sec &&
  2423	        statBuf.st_mtim.tv_nsec == configFileTime.tv_nsec)
  2424	#elif defined(HAVE_STAT_TIME_T)
  2425	    if (pmDebugOptions.appl0)
  2426		fprintf(stderr, "ParseRestartAgents: new configFileTime=%ld sec\n",
  2427		    (long)configFileTime);
  2428	    if (statBuf.st_mtime == configFileTime)
  2429	#else
  2430	!bozo!
  2431	#endif

mgoodwin@~/src/pcp/src/pmcd/src[master]$ grep 'HAVE.*TIME' ../../include/pcp/config.h
#define HAVE_CLOCK_GETTIME 1
#define HAVE_MKTIME 1
#define HAVE_STAT_TIMESPEC 1
/* #undef HAVE_STAT_TIMESPEC_T */
/* #undef HAVE_STAT_TIMESTRUC */
/* #undef HAVE_STAT_TIME_T */
#define HAVE_STRFTIME_z 1
#define HAVE_STRUCT_TIMESPEC 1
/* #undef HAVE_ST_MTIME_WITH_E */
/* #undef HAVE_ST_MTIME_WITH_SPEC */
#define HAVE_SYS_TIMES_H 1

The latest cppcheck on f28 (and f29) is cppcheck-1.86-1.fc28.x86_64. The issue doesn't occur with cppcheck-1.85-1. So this appears to be a bug in the new version of cppcheck. The changelog doesn't reveal much. Until that's fixed, our the PCP travis-ci checks will continue to fail.

Manually running the 1.85 version (copied to /tmp/cppcheck) passes :

mgoodwin@~/src/pcp/src/pmcd/src[master]$ /tmp/cppcheck --std=posix --force --quiet --error-exitcode=1 pmcd.c config.c dofetch.c dopdus.c dostore.c client.c agent.c client.h pmcd.h

Manually running the 1.86 version fails:

mgoodwin@~/src/pcp/src/pmcd/src[master]$ cppcheck --std=posix --force --quiet --error-exitcode=1 pmcd.c config.c dofetch.c dopdus.c dostore.c client.c agent.c client.h pmcd.h
[config.c:2430]: (error) syntax error

Comment 1 Mamoru TASAKA 2019-01-04 07:33:10 UTC
Created attachment 1518312 [details]
cppcheck log whith --quiet removed

I don't think this is cppcheck bug and rather I think this is expected.

You can see what is occuring here with removing "--quiet" option as attached. Now lots of macros appears in the output lines.

As explained in "-D" or "-U" option of "$ man cppcheck", when cppcheck cannot find out header files and cannot determine if macros in the source file is defined or not, cppcheck tries to examine "all" the configurations (although Ι don't think cppcheck will check all the "combinations" of whether macros is defined or not)  - when include directory is insufficient.

Here cppcheck cannot find out config.h because include directory is not specified, so cppcheck cannot find out whether HAVE_STAT_TIMESPEC or so is defined or not, then it tries to check all (perhaps actually some) macros combination pattern. And actually when HAVE_ST_MTIME_WITH_SPEC, HAVE_STAT_TIMESPEC_T, .... are all undefined, the source actually causes error.

Comment 2 Mark Goodwin 2019-01-04 11:24:45 UTC
Hi, thanks for the quick response. I agree the include directories should be specified with -I. That way cppcheck would at least have a chance to find the macros. The syntax error ("bozo!") is deliberate when none of the expected HAVE_.*TIME.* macros are defined, which is kind of like an assert in the code. One point of the BZ was that this used to work with cppcheck v1.85, but now fails with v1.86.

Regardless, src/pmcd/src/GNUMakefile knows the correct -I directories to specify (${CFLAGS} and/or ${LCFLAGS}), so I guess it should specify those directories for cppcheck in the "make check" target. I'll investigate adding those flags in the PCP src tomorrow .. and report back.

Regards

Comment 3 Mark Goodwin 2019-01-06 20:51:09 UTC
Fixed upstream (and will be in pcp-4.3.1-1) by adding include paths to the cppcheck invocation.

Mark Goodwin (1):
      build: add -I paths for cppcheck, fix travis-ci checking

 src/include/builddefs.in |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Details :

commit c4388d3ee80bb14c96fe8eb46735abcfdc84606e (HEAD -> master, upstream-goodwinos/master)
Author: Mark Goodwin <mgoodwin@redhat.com>
Date:   Sat Jan 5 08:43:17 2019 +1100

    build: add -I paths for cppcheck, fix travis-ci checking
    
    RHBZ#1663372 - "pcp does not set include dir for cppcheck"
    
    Tweak the CPPCHECK definition in buildefs.in to specify some include
    paths, as recommended by the cppcheck maintainers in BZ1663372.
    
    modified:   src/include/builddefs.in

Comment 4 Fedora Update System 2019-02-27 06:20:20 UTC
pcp-4.3.1-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-05aa494895

Comment 5 Fedora Update System 2019-02-27 06:20:56 UTC
pcp-4.3.1-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2019-2f1f39ec7a

Comment 6 Fedora Update System 2019-02-28 18:55:32 UTC
pcp-4.3.1-1.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-2f1f39ec7a

Comment 7 Fedora Update System 2019-02-28 21:26:22 UTC
pcp-4.3.1-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-05aa494895

Comment 8 Fedora Update System 2019-03-07 05:02:13 UTC
pcp-4.3.1-2.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-dc1a78c8d2

Comment 9 Fedora Update System 2019-03-07 05:02:41 UTC
pcp-4.3.1-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2019-26d6a351e6

Comment 10 Fedora Update System 2019-03-07 20:32:02 UTC
pcp-4.3.1-2.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-dc1a78c8d2

Comment 11 Fedora Update System 2019-03-07 21:03:49 UTC
pcp-4.3.1-2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-26d6a351e6

Comment 12 Fedora Update System 2019-03-17 07:20:27 UTC
pcp-4.3.1-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

Comment 13 Fedora Update System 2019-03-17 19:35:35 UTC
pcp-4.3.1-2.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.