scan-build failure

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

scan-build failure

Michael Blumenkrantz
Hi,

I have a C project which fails to build with scan-build.  It can be accessed at
http://svn.zentific.com/trunk/Zentific-console/shellinabox and checked out from
the same path using svn.  and built with the usual autoreconf -fi &&
scan-build ./configure && scan-build make.  The problem is that it is
incorrectly failing function detection tests (isnan and strcasestr) during
configure.

This is the output:

Running autoreconf...
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
Configuring...
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... /usr/bin/ccc-analyzer
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether /usr/bin/ccc-analyzer accepts -g... yes
checking for /usr/bin/ccc-analyzer option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of /usr/bin/ccc-analyzer... gcc3
checking how to run the C preprocessor... /usr/bin/ccc-analyzer -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... no
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... no
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for a sed that does not truncate output... /bin/sed
checking for fgrep... /bin/grep -F
checking for ld used by /usr/bin/ccc-analyzer... /usr/x86_64-pc-linux-gnu/bin/ld
checking if the linker (/usr/x86_64-pc-linux-gnu/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 98304
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /usr/x86_64-pc-linux-gnu/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from /usr/bin/ccc-analyzer
object... ok checking for dlfcn.h... yes
checking for objdir... .libs
checking if /usr/bin/ccc-analyzer supports -fno-rtti -fno-exceptions... no
checking for /usr/bin/ccc-analyzer option to produce PIC... -fPIC -DPIC
checking if /usr/bin/ccc-analyzer PIC flag -fPIC -DPIC works... yes
checking if /usr/bin/ccc-analyzer static flag -static works... yes
checking if /usr/bin/ccc-analyzer supports -c -o file.o... yes
checking if /usr/bin/ccc-analyzer supports -c -o file.o... (cached) yes
checking whether the /usr/bin/ccc-analyzer linker
(/usr/x86_64-pc-linux-gnu/bin/ld -m elf_x86_64) supports shared libraries...
yes checking whether -lc should be explicitly linked in... no checking dynamic
linker characteristics... GNU/Linux ld.so checking how to hardcode library
paths into programs... immediate checking for shl_load... no
checking for shl_load in -ldld... no
checking for dlopen... no
checking for dlopen in -ldl... no
checking for dlopen in -lsvld... no
checking for dld_link in -ldld... no
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for an ANSI C-conforming const... no
checking whether /usr/bin/ccc-analyzer needs -traditional... no
checking for __attribute__... no
checking libutil.h usability... no
checking libutil.h presence... no
checking for libutil.h... no
checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
checking pty.h usability... yes
checking pty.h presence... yes
checking for pty.h... yes
checking for strings.h... (cached) yes
checking sys/prctl.h usability... yes
checking sys/prctl.h presence... yes
checking for sys/prctl.h... yes
checking sys/uio.h usability... yes
checking sys/uio.h presence... yes
checking for sys/uio.h... yes
checking util.h usability... no
checking util.h presence... no
checking for util.h... no
checking utmp.h usability... yes
checking utmp.h presence... yes
checking for utmp.h... yes
checking utmpx.h usability... yes
checking utmpx.h presence... yes
checking for utmpx.h... yes
checking for login_tty... no
checking for login_tty in -lutil... no
checking for strlcat... no
checking for getgrgid_r... no
checking for getgrnam_r... no
checking for getpwnam_r... no
checking for getpwuid_r... no
checking for openpty... no
checking for strcasestr... no
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for OPENSSL... yes
checking security/pam_appl.h usability... yes
checking security/pam_appl.h presence... yes
checking for security/pam_appl.h... yes
checking security/pam_client.h usability... yes
checking security/pam_client.h presence... yes
checking for security/pam_client.h... yes
checking security/pam_misc.h usability... yes
checking security/pam_misc.h presence... yes
checking for security/pam_misc.h... yes
checking for security/pam_appl.h... (cached) yes
checking for security/pam_misc.h... (cached) yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating demo/Makefile
config.status: creating logging/Makefile
config.status: creating libhttp/Makefile
config.status: creating shellinabox/Makefile
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing libtool commands
scan-build: Removing directory '/tmp/scan-build-2010-08-29-8' because it
contains no reports.

Running make...
scan-build: Emitting reports for this run to '/tmp/scan-build-2010-08-29-8'.
make  all-recursive
Making all in demo
make[2]: Nothing to be done for `all'.
Making all in logging
  CC     logging.lo
ANALYZE: logging.c debugMsg
ANALYZE: logging.c debug
ANALYZE: logging.c info
ANALYZE: logging.c warn
ANALYZE: logging.c error
ANALYZE: logging.c message
ANALYZE: logging.c fatal
ANALYZE: logging.c logIsDebug
ANALYZE: logging.c logIsInfo
ANALYZE: logging.c logIsWarn
ANALYZE: logging.c logIsError
ANALYZE: logging.c logIsMessage
ANALYZE: logging.c logIsQuiet
ANALYZE: logging.c logIsDefault
ANALYZE: logging.c logIsVerbose
ANALYZE: logging.c logSetLogLevel
ANALYZE: logging.c vStringPrintf
logging.c:167:7: warning: Assigned value is garbage or undefined
      check(buf = realloc(buf, offset + len));
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
logging.c:167:13: note: instantiated from:
      check(buf = realloc(buf, offset + len));
            ^     ~~~~~~~~~~~~~~~~~~~~~~~~~~
logging.c:149:3: warning: Assigned value is garbage or undefined
  check(buf     = realloc(buf, offset + len));
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
logging.c:149:9: note: instantiated from:
  check(buf     = realloc(buf, offset + len));
        ^         ~~~~~~~~~~~~~~~~~~~~~~~~~~
logging.c:155:5: warning: Assigned value is garbage or undefined
    check(buf   = realloc(buf, offset + p + 1));
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
logging.c:155:11: note: instantiated from:
    check(buf   = realloc(buf, offset + p + 1));
          ^       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
logging.c:157:5: warning: Allocated memory never released. Potential memory
leak. check(vsnprintf(buf + offset, p + 1, fmt, aq) == p);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from logging.c:53:
../logging/logging.h:61:23: note: instantiated from:
                      fatal("Check failed at "__FILE__":%d in %s(): %s",      \
                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ANALYZE: logging.c stringPrintf
4 diagnostics generated.
  CCLD   liblogging.la
Making all in libhttp
  CC     hashmap.lo
  CC     trie.lo
ANALYZE: hashmap.c newHashMap
ANALYZE: hashmap.c initHashMap
ANALYZE: hashmap.c destroyHashMap
ANALYZE: trie.c newTrie
ANALYZE: hashmap.c deleteHashMap
ANALYZE: hashmap.c stringHashFunc
ANALYZE: hashmap.c addToHashMap
ANALYZE: trie.c initTrie
ANALYZE: trie.c destroyTrie
ANALYZE: trie.c deleteTrie
ANALYZE: trie.c addLeafToTrie
trie.c:105:3: warning: Allocated memory never released. Potential memory leak.
  check(trie->children  = malloc(sizeof(struct Trie)));
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from trie.c:52:
../logging/logging.h:61:23: note: instantiated from:
                      fatal("Check failed at "__FILE__":%d in %s(): %s",      \
                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
trie.c:108:25: warning: Allocated memory never released. Potential memory leak.
  trie->children->value = value;
  ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
ANALYZE: trie.c addToTrie
hashmap.c:155:3: warning: Allocated memory never released. Potential memory
leak. return value;
  ^
hashmap.c:149:3: warning: Allocated memory never released. Potential memory
leak. check(hashmap->entries[idx]    = realloc(hashmap->entries[idx],
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from hashmap.c:52:
../logging/logging.h:61:23: note: instantiated from:
                      fatal("Check failed at "__FILE__":%d in %s(): %s",      \
                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ANALYZE: hashmap.c deleteFromHashMap
ANALYZE: hashmap.c getRefFromHashMap
ANALYZE: hashmap.c getFromHashMap
ANALYZE: hashmap.c iterateOverHashMap
ANALYZE: hashmap.c getHashmapSize
2 diagnostics generated.
trie.c:163:5: warning: Assigned value is garbage or undefined
    check(trie->children          = realloc(
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
trie.c:163:17: note: instantiated from:
    check(trie->children          = realloc(
                ^                   ~~~~~~~~
trie.c:123:9: warning: Allocated memory never released. Potential memory leak.
        check(child->key          = malloc(trie->idx - i - 1));
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from trie.c:52:
../logging/logging.h:61:23: note: instantiated from:
                      fatal("Check failed at "__FILE__":%d in %s(): %s",      \
                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
trie.c:169:7: warning: Allocated memory never released. Potential memory leak.
      addLeafToTrie(newNode, *key, key + 1, len - 1, value);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
trie.c:143:9: warning: Allocated memory never released. Potential memory leak.
        return;
        ^
trie.c:172:35: warning: Allocated memory never released. Potential memory leak.
      newNode->value              = value;
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
ANALYZE: trie.c getFromTrie
  CC     httpconnection.lo
httpconnection.c:71:1: warning: "isnan" redefined
In file included from httpconnection.c:52:
/usr/include/math.h:257:1: warning: this is the location of the previous
definition httpconnection.c:214: error: conflicting types for 'strcasestr'
/usr/include/string.h:371: note: previous declaration of 'strcasestr' was here
httpconnection.c: In function 'httpDestroyHeaders':
httpconnection.c:274: warning: unused parameter 'arg'
make[2]: *** [httpconnection.lo] Error 1
make[2]: *** Waiting for unfinished jobs....
7 diagnostics generated.
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
scan-build: 15 bugs found.
scan-build: Run 'scan-view /tmp/scan-build-2010-08-29-8' to examine bug reports.


--
Mike Blumenkrantz
Zentific: Our boolean values are huge.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: scan-build failure

Ted Kremenek
Hi Michael,

It is possible that ccc-analyzer is not correctly forwarding to your intended compiler.  By default it forwards to the 'gcc' in your path.  A frontend error from the analyzer itself won't cause the build to halt.  The 'error' you are seeing is likely from the compiler, not the analyzer.  Is there a specific compiler you intended to use?

Ted

On Aug 29, 2010, at 8:27 PM, Michael Blumenkrantz wrote:

> Hi,
>
> I have a C project which fails to build with scan-build.  It can be accessed at
> http://svn.zentific.com/trunk/Zentific-console/shellinabox and checked out from
> the same path using svn.  and built with the usual autoreconf -fi &&
> scan-build ./configure && scan-build make.  The problem is that it is
> incorrectly failing function detection tests (isnan and strcasestr) during
> configure.
>
> This is the output:
>
> Running autoreconf...
> libtoolize: putting auxiliary files in `.'.
> libtoolize: copying file `./ltmain.sh'
> libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
> libtoolize: copying file `m4/libtool.m4'
> libtoolize: copying file `m4/ltoptions.m4'
> libtoolize: copying file `m4/ltsugar.m4'
> libtoolize: copying file `m4/ltversion.m4'
> libtoolize: copying file `m4/lt~obsolete.m4'
> Configuring...
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... /bin/mkdir -p
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking for gcc... /usr/bin/ccc-analyzer
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether /usr/bin/ccc-analyzer accepts -g... yes
> checking for /usr/bin/ccc-analyzer option to accept ISO C89... none needed
> checking for style of include used by make... GNU
> checking dependency style of /usr/bin/ccc-analyzer... gcc3
> checking how to run the C preprocessor... /usr/bin/ccc-analyzer -E
> checking for grep that handles long lines and -e... /bin/grep
> checking for egrep... /bin/grep -E
> checking for ANSI C header files... no
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking minix/config.h usability... no
> checking minix/config.h presence... no
> checking for minix/config.h... no
> checking whether it is safe to define __EXTENSIONS__... no
> checking build system type... x86_64-unknown-linux-gnu
> checking host system type... x86_64-unknown-linux-gnu
> checking for a sed that does not truncate output... /bin/sed
> checking for fgrep... /bin/grep -F
> checking for ld used by /usr/bin/ccc-analyzer... /usr/x86_64-pc-linux-gnu/bin/ld
> checking if the linker (/usr/x86_64-pc-linux-gnu/bin/ld) is GNU ld... yes
> checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
> checking the name lister (/usr/bin/nm -B) interface... BSD nm
> checking whether ln -s works... yes
> checking the maximum length of command line arguments... 98304
> checking whether the shell understands some XSI constructs... yes
> checking whether the shell understands "+="... yes
> checking for /usr/x86_64-pc-linux-gnu/bin/ld option to reload object files... -r
> checking for objdump... objdump
> checking how to recognize dependent libraries... pass_all
> checking for ar... ar
> checking for strip... strip
> checking for ranlib... ranlib
> checking command to parse /usr/bin/nm -B output from /usr/bin/ccc-analyzer
> object... ok checking for dlfcn.h... yes
> checking for objdir... .libs
> checking if /usr/bin/ccc-analyzer supports -fno-rtti -fno-exceptions... no
> checking for /usr/bin/ccc-analyzer option to produce PIC... -fPIC -DPIC
> checking if /usr/bin/ccc-analyzer PIC flag -fPIC -DPIC works... yes
> checking if /usr/bin/ccc-analyzer static flag -static works... yes
> checking if /usr/bin/ccc-analyzer supports -c -o file.o... yes
> checking if /usr/bin/ccc-analyzer supports -c -o file.o... (cached) yes
> checking whether the /usr/bin/ccc-analyzer linker
> (/usr/x86_64-pc-linux-gnu/bin/ld -m elf_x86_64) supports shared libraries...
> yes checking whether -lc should be explicitly linked in... no checking dynamic
> linker characteristics... GNU/Linux ld.so checking how to hardcode library
> paths into programs... immediate checking for shl_load... no
> checking for shl_load in -ldld... no
> checking for dlopen... no
> checking for dlopen in -ldl... no
> checking for dlopen in -lsvld... no
> checking for dld_link in -ldld... no
> checking whether stripping libraries is possible... yes
> checking if libtool supports shared libraries... yes
> checking whether to build shared libraries... yes
> checking whether to build static libraries... yes
> checking for an ANSI C-conforming const... no
> checking whether /usr/bin/ccc-analyzer needs -traditional... no
> checking for __attribute__... no
> checking libutil.h usability... no
> checking libutil.h presence... no
> checking for libutil.h... no
> checking pthread.h usability... yes
> checking pthread.h presence... yes
> checking for pthread.h... yes
> checking pty.h usability... yes
> checking pty.h presence... yes
> checking for pty.h... yes
> checking for strings.h... (cached) yes
> checking sys/prctl.h usability... yes
> checking sys/prctl.h presence... yes
> checking for sys/prctl.h... yes
> checking sys/uio.h usability... yes
> checking sys/uio.h presence... yes
> checking for sys/uio.h... yes
> checking util.h usability... no
> checking util.h presence... no
> checking for util.h... no
> checking utmp.h usability... yes
> checking utmp.h presence... yes
> checking for utmp.h... yes
> checking utmpx.h usability... yes
> checking utmpx.h presence... yes
> checking for utmpx.h... yes
> checking for login_tty... no
> checking for login_tty in -lutil... no
> checking for strlcat... no
> checking for getgrgid_r... no
> checking for getgrnam_r... no
> checking for getpwnam_r... no
> checking for getpwuid_r... no
> checking for openpty... no
> checking for strcasestr... no
> checking for pkg-config... /usr/bin/pkg-config
> checking pkg-config is at least version 0.9.0... yes
> checking for OPENSSL... yes
> checking security/pam_appl.h usability... yes
> checking security/pam_appl.h presence... yes
> checking for security/pam_appl.h... yes
> checking security/pam_client.h usability... yes
> checking security/pam_client.h presence... yes
> checking for security/pam_client.h... yes
> checking security/pam_misc.h usability... yes
> checking security/pam_misc.h presence... yes
> checking for security/pam_misc.h... yes
> checking for security/pam_appl.h... (cached) yes
> checking for security/pam_misc.h... (cached) yes
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: creating demo/Makefile
> config.status: creating logging/Makefile
> config.status: creating libhttp/Makefile
> config.status: creating shellinabox/Makefile
> config.status: creating config.h
> config.status: executing depfiles commands
> config.status: executing libtool commands
> scan-build: Removing directory '/tmp/scan-build-2010-08-29-8' because it
> contains no reports.
>
> Running make...
> scan-build: Emitting reports for this run to '/tmp/scan-build-2010-08-29-8'.
> make  all-recursive
> Making all in demo
> make[2]: Nothing to be done for `all'.
> Making all in logging
>  CC     logging.lo
> ANALYZE: logging.c debugMsg
> ANALYZE: logging.c debug
> ANALYZE: logging.c info
> ANALYZE: logging.c warn
> ANALYZE: logging.c error
> ANALYZE: logging.c message
> ANALYZE: logging.c fatal
> ANALYZE: logging.c logIsDebug
> ANALYZE: logging.c logIsInfo
> ANALYZE: logging.c logIsWarn
> ANALYZE: logging.c logIsError
> ANALYZE: logging.c logIsMessage
> ANALYZE: logging.c logIsQuiet
> ANALYZE: logging.c logIsDefault
> ANALYZE: logging.c logIsVerbose
> ANALYZE: logging.c logSetLogLevel
> ANALYZE: logging.c vStringPrintf
> logging.c:167:7: warning: Assigned value is garbage or undefined
>      check(buf = realloc(buf, offset + len));
>      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> logging.c:167:13: note: instantiated from:
>      check(buf = realloc(buf, offset + len));
>            ^     ~~~~~~~~~~~~~~~~~~~~~~~~~~
> logging.c:149:3: warning: Assigned value is garbage or undefined
>  check(buf     = realloc(buf, offset + len));
>  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> logging.c:149:9: note: instantiated from:
>  check(buf     = realloc(buf, offset + len));
>        ^         ~~~~~~~~~~~~~~~~~~~~~~~~~~
> logging.c:155:5: warning: Assigned value is garbage or undefined
>    check(buf   = realloc(buf, offset + p + 1));
>    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> logging.c:155:11: note: instantiated from:
>    check(buf   = realloc(buf, offset + p + 1));
>          ^       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> logging.c:157:5: warning: Allocated memory never released. Potential memory
> leak. check(vsnprintf(buf + offset, p + 1, fmt, aq) == p);
>    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from logging.c:53:
> ../logging/logging.h:61:23: note: instantiated from:
>                      fatal("Check failed at "__FILE__":%d in %s(): %s",      \
>                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ANALYZE: logging.c stringPrintf
> 4 diagnostics generated.
>  CCLD   liblogging.la
> Making all in libhttp
>  CC     hashmap.lo
>  CC     trie.lo
> ANALYZE: hashmap.c newHashMap
> ANALYZE: hashmap.c initHashMap
> ANALYZE: hashmap.c destroyHashMap
> ANALYZE: trie.c newTrie
> ANALYZE: hashmap.c deleteHashMap
> ANALYZE: hashmap.c stringHashFunc
> ANALYZE: hashmap.c addToHashMap
> ANALYZE: trie.c initTrie
> ANALYZE: trie.c destroyTrie
> ANALYZE: trie.c deleteTrie
> ANALYZE: trie.c addLeafToTrie
> trie.c:105:3: warning: Allocated memory never released. Potential memory leak.
>  check(trie->children  = malloc(sizeof(struct Trie)));
>  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from trie.c:52:
> ../logging/logging.h:61:23: note: instantiated from:
>                      fatal("Check failed at "__FILE__":%d in %s(): %s",      \
>                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> trie.c:108:25: warning: Allocated memory never released. Potential memory leak.
>  trie->children->value = value;
>  ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
> ANALYZE: trie.c addToTrie
> hashmap.c:155:3: warning: Allocated memory never released. Potential memory
> leak. return value;
>  ^
> hashmap.c:149:3: warning: Allocated memory never released. Potential memory
> leak. check(hashmap->entries[idx]    = realloc(hashmap->entries[idx],
>  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from hashmap.c:52:
> ../logging/logging.h:61:23: note: instantiated from:
>                      fatal("Check failed at "__FILE__":%d in %s(): %s",      \
>                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ANALYZE: hashmap.c deleteFromHashMap
> ANALYZE: hashmap.c getRefFromHashMap
> ANALYZE: hashmap.c getFromHashMap
> ANALYZE: hashmap.c iterateOverHashMap
> ANALYZE: hashmap.c getHashmapSize
> 2 diagnostics generated.
> trie.c:163:5: warning: Assigned value is garbage or undefined
>    check(trie->children          = realloc(
>    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> trie.c:163:17: note: instantiated from:
>    check(trie->children          = realloc(
>                ^                   ~~~~~~~~
> trie.c:123:9: warning: Allocated memory never released. Potential memory leak.
>        check(child->key          = malloc(trie->idx - i - 1));
>        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from trie.c:52:
> ../logging/logging.h:61:23: note: instantiated from:
>                      fatal("Check failed at "__FILE__":%d in %s(): %s",      \
>                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> trie.c:169:7: warning: Allocated memory never released. Potential memory leak.
>      addLeafToTrie(newNode, *key, key + 1, len - 1, value);
>      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> trie.c:143:9: warning: Allocated memory never released. Potential memory leak.
>        return;
>        ^
> trie.c:172:35: warning: Allocated memory never released. Potential memory leak.
>      newNode->value              = value;
>      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
> ANALYZE: trie.c getFromTrie
>  CC     httpconnection.lo
> httpconnection.c:71:1: warning: "isnan" redefined
> In file included from httpconnection.c:52:
> /usr/include/math.h:257:1: warning: this is the location of the previous
> definition httpconnection.c:214: error: conflicting types for 'strcasestr'
> /usr/include/string.h:371: note: previous declaration of 'strcasestr' was here
> httpconnection.c: In function 'httpDestroyHeaders':
> httpconnection.c:274: warning: unused parameter 'arg'
> make[2]: *** [httpconnection.lo] Error 1
> make[2]: *** Waiting for unfinished jobs....
> 7 diagnostics generated.
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
> scan-build: 15 bugs found.
> scan-build: Run 'scan-view /tmp/scan-build-2010-08-29-8' to examine bug reports.
>
>
> --
> Mike Blumenkrantz
> Zentific: Our boolean values are huge.
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: scan-build failure

Michael Blumenkrantz
On Mon, 30 Aug 2010 10:35:16 -0700
Ted Kremenek <[hidden email]> wrote:

> Hi Michael,
>
> It is possible that ccc-analyzer is not correctly forwarding to your intended
> compiler.  By default it forwards to the 'gcc' in your path.  A frontend
> error from the analyzer itself won't cause the build to halt.  The 'error'
> you are seeing is likely from the compiler, not the analyzer.  Is there a
> specific compiler you intended to use?
>
> Ted
>
> On Aug 29, 2010, at 8:27 PM, Michael Blumenkrantz wrote:
>
> > Hi,
> >
> > I have a C project which fails to build with scan-build.  It can be
> > accessed at http://svn.zentific.com/trunk/Zentific-console/shellinabox and
> > checked out from the same path using svn.  and built with the usual
> > autoreconf -fi && scan-build ./configure && scan-build make.  The problem
> > is that it is incorrectly failing function detection tests (isnan and
> > strcasestr) during configure.
> >
> > This is the output:
> >
> > Running autoreconf...
> > libtoolize: putting auxiliary files in `.'.
> > libtoolize: copying file `./ltmain.sh'
> > libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
> > libtoolize: copying file `m4/libtool.m4'
> > libtoolize: copying file `m4/ltoptions.m4'
> > libtoolize: copying file `m4/ltsugar.m4'
> > libtoolize: copying file `m4/ltversion.m4'
> > libtoolize: copying file `m4/lt~obsolete.m4'
> > Configuring...
> > checking for a BSD-compatible install... /usr/bin/install -c
> > checking whether build environment is sane... yes
> > checking for a thread-safe mkdir -p... /bin/mkdir -p
> > checking for gawk... gawk
> > checking whether make sets $(MAKE)... yes
> > checking for gcc... /usr/bin/ccc-analyzer
> > checking whether the C compiler works... yes
> > checking for C compiler default output file name... a.out
> > checking for suffix of executables...
> > checking whether we are cross compiling... no
> > checking for suffix of object files... o
> > checking whether we are using the GNU C compiler... yes
> > checking whether /usr/bin/ccc-analyzer accepts -g... yes
> > checking for /usr/bin/ccc-analyzer option to accept ISO C89... none needed
> > checking for style of include used by make... GNU
> > checking dependency style of /usr/bin/ccc-analyzer... gcc3
> > checking how to run the C preprocessor... /usr/bin/ccc-analyzer -E
> > checking for grep that handles long lines and -e... /bin/grep
> > checking for egrep... /bin/grep -E
> > checking for ANSI C header files... no
> > checking for sys/types.h... yes
> > checking for sys/stat.h... yes
> > checking for stdlib.h... yes
> > checking for string.h... yes
> > checking for memory.h... yes
> > checking for strings.h... yes
> > checking for inttypes.h... yes
> > checking for stdint.h... yes
> > checking for unistd.h... yes
> > checking minix/config.h usability... no
> > checking minix/config.h presence... no
> > checking for minix/config.h... no
> > checking whether it is safe to define __EXTENSIONS__... no
> > checking build system type... x86_64-unknown-linux-gnu
> > checking host system type... x86_64-unknown-linux-gnu
> > checking for a sed that does not truncate output... /bin/sed
> > checking for fgrep... /bin/grep -F
> > checking for ld used
> > by /usr/bin/ccc-analyzer... /usr/x86_64-pc-linux-gnu/bin/ld checking if the
> > linker (/usr/x86_64-pc-linux-gnu/bin/ld) is GNU ld... yes checking for BSD-
> > or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name
> > lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works...
> > yes checking the maximum length of command line arguments... 98304
> > checking whether the shell understands some XSI constructs... yes
> > checking whether the shell understands "+="... yes
> > checking for /usr/x86_64-pc-linux-gnu/bin/ld option to reload object
> > files... -r checking for objdump... objdump
> > checking how to recognize dependent libraries... pass_all
> > checking for ar... ar
> > checking for strip... strip
> > checking for ranlib... ranlib
> > checking command to parse /usr/bin/nm -B output from /usr/bin/ccc-analyzer
> > object... ok checking for dlfcn.h... yes
> > checking for objdir... .libs
> > checking if /usr/bin/ccc-analyzer supports -fno-rtti -fno-exceptions... no
> > checking for /usr/bin/ccc-analyzer option to produce PIC... -fPIC -DPIC
> > checking if /usr/bin/ccc-analyzer PIC flag -fPIC -DPIC works... yes
> > checking if /usr/bin/ccc-analyzer static flag -static works... yes
> > checking if /usr/bin/ccc-analyzer supports -c -o file.o... yes
> > checking if /usr/bin/ccc-analyzer supports -c -o file.o... (cached) yes
> > checking whether the /usr/bin/ccc-analyzer linker
> > (/usr/x86_64-pc-linux-gnu/bin/ld -m elf_x86_64) supports shared libraries...
> > yes checking whether -lc should be explicitly linked in... no checking
> > dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode
> > library paths into programs... immediate checking for shl_load... no
> > checking for shl_load in -ldld... no
> > checking for dlopen... no
> > checking for dlopen in -ldl... no
> > checking for dlopen in -lsvld... no
> > checking for dld_link in -ldld... no
> > checking whether stripping libraries is possible... yes
> > checking if libtool supports shared libraries... yes
> > checking whether to build shared libraries... yes
> > checking whether to build static libraries... yes
> > checking for an ANSI C-conforming const... no
> > checking whether /usr/bin/ccc-analyzer needs -traditional... no
> > checking for __attribute__... no
> > checking libutil.h usability... no
> > checking libutil.h presence... no
> > checking for libutil.h... no
> > checking pthread.h usability... yes
> > checking pthread.h presence... yes
> > checking for pthread.h... yes
> > checking pty.h usability... yes
> > checking pty.h presence... yes
> > checking for pty.h... yes
> > checking for strings.h... (cached) yes
> > checking sys/prctl.h usability... yes
> > checking sys/prctl.h presence... yes
> > checking for sys/prctl.h... yes
> > checking sys/uio.h usability... yes
> > checking sys/uio.h presence... yes
> > checking for sys/uio.h... yes
> > checking util.h usability... no
> > checking util.h presence... no
> > checking for util.h... no
> > checking utmp.h usability... yes
> > checking utmp.h presence... yes
> > checking for utmp.h... yes
> > checking utmpx.h usability... yes
> > checking utmpx.h presence... yes
> > checking for utmpx.h... yes
> > checking for login_tty... no
> > checking for login_tty in -lutil... no
> > checking for strlcat... no
> > checking for getgrgid_r... no
> > checking for getgrnam_r... no
> > checking for getpwnam_r... no
> > checking for getpwuid_r... no
> > checking for openpty... no
> > checking for strcasestr... no
> > checking for pkg-config... /usr/bin/pkg-config
> > checking pkg-config is at least version 0.9.0... yes
> > checking for OPENSSL... yes
> > checking security/pam_appl.h usability... yes
> > checking security/pam_appl.h presence... yes
> > checking for security/pam_appl.h... yes
> > checking security/pam_client.h usability... yes
> > checking security/pam_client.h presence... yes
> > checking for security/pam_client.h... yes
> > checking security/pam_misc.h usability... yes
> > checking security/pam_misc.h presence... yes
> > checking for security/pam_misc.h... yes
> > checking for security/pam_appl.h... (cached) yes
> > checking for security/pam_misc.h... (cached) yes
> > configure: creating ./config.status
> > config.status: creating Makefile
> > config.status: creating demo/Makefile
> > config.status: creating logging/Makefile
> > config.status: creating libhttp/Makefile
> > config.status: creating shellinabox/Makefile
> > config.status: creating config.h
> > config.status: executing depfiles commands
> > config.status: executing libtool commands
> > scan-build: Removing directory '/tmp/scan-build-2010-08-29-8' because it
> > contains no reports.
> >
> > Running make...
> > scan-build: Emitting reports for this run to '/tmp/scan-build-2010-08-29-8'.
> > make  all-recursive
> > Making all in demo
> > make[2]: Nothing to be done for `all'.
> > Making all in logging
> >  CC     logging.lo
> > ANALYZE: logging.c debugMsg
> > ANALYZE: logging.c debug
> > ANALYZE: logging.c info
> > ANALYZE: logging.c warn
> > ANALYZE: logging.c error
> > ANALYZE: logging.c message
> > ANALYZE: logging.c fatal
> > ANALYZE: logging.c logIsDebug
> > ANALYZE: logging.c logIsInfo
> > ANALYZE: logging.c logIsWarn
> > ANALYZE: logging.c logIsError
> > ANALYZE: logging.c logIsMessage
> > ANALYZE: logging.c logIsQuiet
> > ANALYZE: logging.c logIsDefault
> > ANALYZE: logging.c logIsVerbose
> > ANALYZE: logging.c logSetLogLevel
> > ANALYZE: logging.c vStringPrintf
> > logging.c:167:7: warning: Assigned value is garbage or undefined
> >      check(buf = realloc(buf, offset + len));
> >      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > logging.c:167:13: note: instantiated from:
> >      check(buf = realloc(buf, offset + len));
> >            ^     ~~~~~~~~~~~~~~~~~~~~~~~~~~
> > logging.c:149:3: warning: Assigned value is garbage or undefined
> >  check(buf     = realloc(buf, offset + len));
> >  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > logging.c:149:9: note: instantiated from:
> >  check(buf     = realloc(buf, offset + len));
> >        ^         ~~~~~~~~~~~~~~~~~~~~~~~~~~
> > logging.c:155:5: warning: Assigned value is garbage or undefined
> >    check(buf   = realloc(buf, offset + p + 1));
> >    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > logging.c:155:11: note: instantiated from:
> >    check(buf   = realloc(buf, offset + p + 1));
> >          ^       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > logging.c:157:5: warning: Allocated memory never released. Potential memory
> > leak. check(vsnprintf(buf + offset, p + 1, fmt, aq) == p);
> >    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > In file included from logging.c:53:
> > ../logging/logging.h:61:23: note: instantiated from:
> >                      fatal("Check failed at "__FILE__":%d in %s():
> > %s",      \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > ANALYZE: logging.c stringPrintf
> > 4 diagnostics generated.
> >  CCLD   liblogging.la
> > Making all in libhttp
> >  CC     hashmap.lo
> >  CC     trie.lo
> > ANALYZE: hashmap.c newHashMap
> > ANALYZE: hashmap.c initHashMap
> > ANALYZE: hashmap.c destroyHashMap
> > ANALYZE: trie.c newTrie
> > ANALYZE: hashmap.c deleteHashMap
> > ANALYZE: hashmap.c stringHashFunc
> > ANALYZE: hashmap.c addToHashMap
> > ANALYZE: trie.c initTrie
> > ANALYZE: trie.c destroyTrie
> > ANALYZE: trie.c deleteTrie
> > ANALYZE: trie.c addLeafToTrie
> > trie.c:105:3: warning: Allocated memory never released. Potential memory
> > leak. check(trie->children  = malloc(sizeof(struct Trie)));
> >  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > In file included from trie.c:52:
> > ../logging/logging.h:61:23: note: instantiated from:
> >                      fatal("Check failed at "__FILE__":%d in %s():
> > %s",      \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > trie.c:108:25: warning: Allocated memory never released. Potential memory
> > leak. trie->children->value = value;
> >  ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
> > ANALYZE: trie.c addToTrie
> > hashmap.c:155:3: warning: Allocated memory never released. Potential memory
> > leak. return value;
> >  ^
> > hashmap.c:149:3: warning: Allocated memory never released. Potential memory
> > leak. check(hashmap->entries[idx]    = realloc(hashmap->entries[idx],
> >  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > In file included from hashmap.c:52:
> > ../logging/logging.h:61:23: note: instantiated from:
> >                      fatal("Check failed at "__FILE__":%d in %s():
> > %s",      \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > ANALYZE: hashmap.c deleteFromHashMap
> > ANALYZE: hashmap.c getRefFromHashMap
> > ANALYZE: hashmap.c getFromHashMap
> > ANALYZE: hashmap.c iterateOverHashMap
> > ANALYZE: hashmap.c getHashmapSize
> > 2 diagnostics generated.
> > trie.c:163:5: warning: Assigned value is garbage or undefined
> >    check(trie->children          = realloc(
> >    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > trie.c:163:17: note: instantiated from:
> >    check(trie->children          = realloc(
> >                ^                   ~~~~~~~~
> > trie.c:123:9: warning: Allocated memory never released. Potential memory
> > leak. check(child->key          = malloc(trie->idx - i - 1));
> >        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > In file included from trie.c:52:
> > ../logging/logging.h:61:23: note: instantiated from:
> >                      fatal("Check failed at "__FILE__":%d in %s():
> > %s",      \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > trie.c:169:7: warning: Allocated memory never released. Potential memory
> > leak. addLeafToTrie(newNode, *key, key + 1, len - 1, value);
> >      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > trie.c:143:9: warning: Allocated memory never released. Potential memory
> > leak. return;
> >        ^
> > trie.c:172:35: warning: Allocated memory never released. Potential memory
> > leak. newNode->value              = value;
> >      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
> > ANALYZE: trie.c getFromTrie
> >  CC     httpconnection.lo
> > httpconnection.c:71:1: warning: "isnan" redefined
> > In file included from httpconnection.c:52:
> > /usr/include/math.h:257:1: warning: this is the location of the previous
> > definition httpconnection.c:214: error: conflicting types for 'strcasestr'
> > /usr/include/string.h:371: note: previous declaration of 'strcasestr' was
> > here httpconnection.c: In function 'httpDestroyHeaders':
> > httpconnection.c:274: warning: unused parameter 'arg'
> > make[2]: *** [httpconnection.lo] Error 1
> > make[2]: *** Waiting for unfinished jobs....
> > 7 diagnostics generated.
> > make[1]: *** [all-recursive] Error 1
> > make: *** [all] Error 2
> > scan-build: 15 bugs found.
> > scan-build: Run 'scan-view /tmp/scan-build-2010-08-29-8' to examine bug
> > reports.
> >
> >
> > --
> > Mike Blumenkrantz
> > Zentific: Our boolean values are huge.
> > _______________________________________________
> > cfe-dev mailing list
> > [hidden email]
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
No, I was just assuming it would default to using clang?

--
Mike Blumenkrantz
Zentific: Our boolean values are huge.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: scan-build failure

Ted Kremenek
scan-build is not smart enough to know what compiler your build intended to use.  It defaults to assuming 'gcc', since that is still the standard compiler used on most systems.

To correct this, check out the --use-cc option to scan-build

 --use-cc [compiler path]   - By default, scan-build uses 'gcc' to compile and link
 --use-cc=[compiler path]     your C and Objective-C code. Use this option
                              to specify an alternate compiler.

 --use-c++ [compiler path]  - By default, scan-build uses 'g++' to compile and link
 --use-c++=[compiler path]    your C++ and Objective-C++ code. Use this option
                              to specify an alternate compiler.



On Aug 30, 2010, at 1:07 PM, Michael Blumenkrantz wrote:

> No, I was just assuming it would default to using clang?


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: scan-build failure

Michael Blumenkrantz
On Mon, 30 Aug 2010 13:11:04 -0700
Ted Kremenek <[hidden email]> wrote:

> scan-build is not smart enough to know what compiler your build intended to
> use.  It defaults to assuming 'gcc', since that is still the standard
> compiler used on most systems.
>
> To correct this, check out the --use-cc option to scan-build
>
>  --use-cc [compiler path]   - By default, scan-build uses 'gcc' to compile
> and link --use-cc=[compiler path]     your C and Objective-C code. Use this
> option to specify an alternate compiler.
>
>  --use-c++ [compiler path]  - By default, scan-build uses 'g++' to compile
> and link --use-c++=[compiler path]    your C++ and Objective-C++ code. Use
> this option to specify an alternate compiler.
>
>
>
> On Aug 30, 2010, at 1:07 PM, Michael Blumenkrantz wrote:
>
> > No, I was just assuming it would default to using clang?
>
No, specifying --use-cc to set clang gives the same result so I guess it
correctly sets clang for scan-build.  clang cannot compile this project.

--
Mike Blumenkrantz
Zentific: Our boolean values are huge.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: scan-build failure

Tom Care
Neither can GCC, it would seem. Have you tried building without scan-build?

The errors about isnan and strcasestr in your original post don't look like clang errors.

Tom

On Aug 31, 2010, at 6:33 PM, Michael Blumenkrantz wrote:

> On Mon, 30 Aug 2010 13:11:04 -0700
> Ted Kremenek <[hidden email]> wrote:
>
>> scan-build is not smart enough to know what compiler your build intended to
>> use.  It defaults to assuming 'gcc', since that is still the standard
>> compiler used on most systems.
>>
>> To correct this, check out the --use-cc option to scan-build
>>
>> --use-cc [compiler path]   - By default, scan-build uses 'gcc' to compile
>> and link --use-cc=[compiler path]     your C and Objective-C code. Use this
>> option to specify an alternate compiler.
>>
>> --use-c++ [compiler path]  - By default, scan-build uses 'g++' to compile
>> and link --use-c++=[compiler path]    your C++ and Objective-C++ code. Use
>> this option to specify an alternate compiler.
>>
>>
>>
>> On Aug 30, 2010, at 1:07 PM, Michael Blumenkrantz wrote:
>>
>>> No, I was just assuming it would default to using clang?
>>
> No, specifying --use-cc to set clang gives the same result so I guess it
> correctly sets clang for scan-build.  clang cannot compile this project.
>
> --
> Mike Blumenkrantz
> Zentific: Our boolean values are huge.
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: scan-build failure

Michael Blumenkrantz
On Tue, 31 Aug 2010 19:46:29 -0700
Tom Care <[hidden email]> wrote:

> Neither can GCC, it would seem. Have you tried building without scan-build?
>
> The errors about isnan and strcasestr in your original post don't look like
> clang errors.
>
> Tom
>
> On Aug 31, 2010, at 6:33 PM, Michael Blumenkrantz wrote:
>
> > On Mon, 30 Aug 2010 13:11:04 -0700
> > Ted Kremenek <[hidden email]> wrote:
> >
> >> scan-build is not smart enough to know what compiler your build intended to
> >> use.  It defaults to assuming 'gcc', since that is still the standard
> >> compiler used on most systems.
> >>
> >> To correct this, check out the --use-cc option to scan-build
> >>
> >> --use-cc [compiler path]   - By default, scan-build uses 'gcc' to compile
> >> and link --use-cc=[compiler path]     your C and Objective-C code. Use this
> >> option to specify an alternate compiler.
> >>
> >> --use-c++ [compiler path]  - By default, scan-build uses 'g++' to compile
> >> and link --use-c++=[compiler path]    your C++ and Objective-C++ code. Use
> >> this option to specify an alternate compiler.
> >>
> >>
> >>
> >> On Aug 30, 2010, at 1:07 PM, Michael Blumenkrantz wrote:
> >>
> >>> No, I was just assuming it would default to using clang?
> >>
> > No, specifying --use-cc to set clang gives the same result so I guess it
> > correctly sets clang for scan-build.  clang cannot compile this project.
> >
> > --
> > Mike Blumenkrantz
> > Zentific: Our boolean values are huge.
> > _______________________________________________
> > cfe-dev mailing list
> > [hidden email]
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
I've built it with gcc literally hundreds of times without issue.  I misspoke
in my most recent email; it is not that clang cannot compile the project, it is
that when using scan-build I cannot compile the project.  This is regardless of
which compiler I use. Using a compiler without scan-build works fine.

--
Mike Blumenkrantz
Zentific: Our boolean values are huge.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: scan-build failure

Tom Care
Hi Michael,

ccc-analyzer has a variable that might be able to help us debug this. If you set CCC_ANALYZER_VERBOSE in your environment, ccc-analyzer will print out the CC command it executes for every file that passes through it. If we can find a missing argument or something, then it might help us figure out what's going on.

Tom

On Aug 31, 2010, at 7:54 PM, Michael Blumenkrantz wrote:

> On Tue, 31 Aug 2010 19:46:29 -0700
> Tom Care <[hidden email]> wrote:
>
>> Neither can GCC, it would seem. Have you tried building without scan-build?
>>
>> The errors about isnan and strcasestr in your original post don't look like
>> clang errors.
>>
>> Tom
>>
>> On Aug 31, 2010, at 6:33 PM, Michael Blumenkrantz wrote:
>>
>>> On Mon, 30 Aug 2010 13:11:04 -0700
>>> Ted Kremenek <[hidden email]> wrote:
>>>
>>>> scan-build is not smart enough to know what compiler your build intended to
>>>> use.  It defaults to assuming 'gcc', since that is still the standard
>>>> compiler used on most systems.
>>>>
>>>> To correct this, check out the --use-cc option to scan-build
>>>>
>>>> --use-cc [compiler path]   - By default, scan-build uses 'gcc' to compile
>>>> and link --use-cc=[compiler path]     your C and Objective-C code. Use this
>>>> option to specify an alternate compiler.
>>>>
>>>> --use-c++ [compiler path]  - By default, scan-build uses 'g++' to compile
>>>> and link --use-c++=[compiler path]    your C++ and Objective-C++ code. Use
>>>> this option to specify an alternate compiler.
>>>>
>>>>
>>>>
>>>> On Aug 30, 2010, at 1:07 PM, Michael Blumenkrantz wrote:
>>>>
>>>>> No, I was just assuming it would default to using clang?
>>>>
>>> No, specifying --use-cc to set clang gives the same result so I guess it
>>> correctly sets clang for scan-build.  clang cannot compile this project.
>>>
>>> --
>>> Mike Blumenkrantz
>>> Zentific: Our boolean values are huge.
>>> _______________________________________________
>>> cfe-dev mailing list
>>> [hidden email]
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
> I've built it with gcc literally hundreds of times without issue.  I misspoke
> in my most recent email; it is not that clang cannot compile the project, it is
> that when using scan-build I cannot compile the project.  This is regardless of
> which compiler I use. Using a compiler without scan-build works fine.
>
> --
> Mike Blumenkrantz
> Zentific: Our boolean values are huge.


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: scan-build failure

Michael Blumenkrantz
On Tue, 31 Aug 2010 20:16:53 -0700
Tom Care <[hidden email]> wrote:

> Hi Michael,
>
> ccc-analyzer has a variable that might be able to help us debug this. If you
> set CCC_ANALYZER_VERBOSE in your environment, ccc-analyzer will print out the
> CC command it executes for every file that passes through it. If we can find
> a missing argument or something, then it might help us figure out what's
> going on.
>
> Tom
>
> On Aug 31, 2010, at 7:54 PM, Michael Blumenkrantz wrote:
>
> > On Tue, 31 Aug 2010 19:46:29 -0700
> > Tom Care <[hidden email]> wrote:
> >
> >> Neither can GCC, it would seem. Have you tried building without scan-build?
> >>
> >> The errors about isnan and strcasestr in your original post don't look like
> >> clang errors.
> >>
> >> Tom
> >>
> >> On Aug 31, 2010, at 6:33 PM, Michael Blumenkrantz wrote:
> >>
> >>> On Mon, 30 Aug 2010 13:11:04 -0700
> >>> Ted Kremenek <[hidden email]> wrote:
> >>>
> >>>> scan-build is not smart enough to know what compiler your build intended
> >>>> to use.  It defaults to assuming 'gcc', since that is still the standard
> >>>> compiler used on most systems.
> >>>>
> >>>> To correct this, check out the --use-cc option to scan-build
> >>>>
> >>>> --use-cc [compiler path]   - By default, scan-build uses 'gcc' to compile
> >>>> and link --use-cc=[compiler path]     your C and Objective-C code. Use
> >>>> this option to specify an alternate compiler.
> >>>>
> >>>> --use-c++ [compiler path]  - By default, scan-build uses 'g++' to compile
> >>>> and link --use-c++=[compiler path]    your C++ and Objective-C++ code.
> >>>> Use this option to specify an alternate compiler.
> >>>>
> >>>>
> >>>>
> >>>> On Aug 30, 2010, at 1:07 PM, Michael Blumenkrantz wrote:
> >>>>
> >>>>> No, I was just assuming it would default to using clang?
> >>>>
> >>> No, specifying --use-cc to set clang gives the same result so I guess it
> >>> correctly sets clang for scan-build.  clang cannot compile this project.
> >>>
> >>> --
> >>> Mike Blumenkrantz
> >>> Zentific: Our boolean values are huge.
> >>> _______________________________________________
> >>> cfe-dev mailing list
> >>> [hidden email]
> >>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >>
> > I've built it with gcc literally hundreds of times without issue.  I
> > misspoke in my most recent email; it is not that clang cannot compile the
> > project, it is that when using scan-build I cannot compile the project.
> > This is regardless of which compiler I use. Using a compiler without
> > scan-build works fine.
> >
> > --
> > Mike Blumenkrantz
> > Zentific: Our boolean values are huge.
>
Attached are the output for running configure and make with
CCC_ANALYZER_VERBOSE set (log.txt) as well as the config.log file.  For
whatever reason, when using scan-build it seems to be unable to compile using
certain headers.

--
Mike Blumenkrantz
Zentific: Our boolean values are huge.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

log.txt (14K) Download Attachment
config.log.bz2 (14K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: scan-build failure

Ted Kremenek
Hi Michael,

>From the error diagnostics it appears that they are coming from Clang when httpconnection.c is compiled.  I know you said that GCC is being used as the compiler, but that doesn't seem to be the case.

BTW, are you doing a parallel build?  It appears that url.c is analyzed before httpconnection.c, so it is difficult to tell from the log what is going on.

FWIW, all ccc-analyzer does is directly forward the command line arguments to your compiler (e.g., gcc), and then calls clang with various analyzer comment line options.  If the analyzer fails, however, that shouldn't cause the build to fail.  The only reason that ccc-analyzer returns an error code is if the compiler it called returned an error code.

Have you tried building your project with Clang?  (not using scan-build).  I suspect that you'll see the same errors, and if so that will at least confirm that the build is failing because clang is being used for compilation.

Also, if clang is indeed being used to build your project, I'm not certain why scan-build is using clang to actually build your project unless...

  (a) the 'gcc' in your path is a symlink to clang

or
 
  (b) the environment variable CCC_CC is set to 'clang'

On Aug 31, 2010, at 9:41 PM, Michael Blumenkrantz wrote:

> Attached are the output for running configure and make with
> CCC_ANALYZER_VERBOSE set (log.txt) as well as the config.log file.  For
> whatever reason, when using scan-build it seems to be unable to compile using
> certain headers.


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: scan-build failure

Michael Blumenkrantz
On Wed, 1 Sep 2010 18:34:40 -0700
Ted Kremenek <[hidden email]> wrote:

> Hi Michael,
>
> From the error diagnostics it appears that they are coming from Clang when
> httpconnection.c is compiled.  I know you said that GCC is being used as the
> compiler, but that doesn't seem to be the case.
>
> BTW, are you doing a parallel build?  It appears that url.c is analyzed
> before httpconnection.c, so it is difficult to tell from the log what is
> going on.
>
Yes, -j2.

> FWIW, all ccc-analyzer does is directly forward the command line arguments to
> your compiler (e.g., gcc), and then calls clang with various analyzer comment
> line options.  If the analyzer fails, however, that shouldn't cause the build
> to fail.  The only reason that ccc-analyzer returns an error code is if the
> compiler it called returned an error code.
>
> Have you tried building your project with Clang?  (not using scan-build).  I
> suspect that you'll see the same errors, and if so that will at least confirm
> that the build is failing because clang is being used for compilation.
>
The project compiles fine with both gcc and clang, but fails when using
scan-build.  You can easily check the code out from
http://svn.zentific.com/trunk/Zentific-console/shellinabox and test this
yourself.
> Also, if clang is indeed being used to build your project, I'm not certain
> why scan-build is using clang to actually build your project unless...
>
>   (a) the 'gcc' in your path is a symlink to clang
>
> or
>  
>   (b) the environment variable CCC_CC is set to 'clang'
I don't remember which cc I was using in the log that I sent just now, but
neither compiler is able to finish a build when using scan-build.  Required
functions that are detected when not using scan-build are no longer detected
when using scan-build.
>
> On Aug 31, 2010, at 9:41 PM, Michael Blumenkrantz wrote:
>
> > Attached are the output for running configure and make with
> > CCC_ANALYZER_VERBOSE set (log.txt) as well as the config.log file.  For
> > whatever reason, when using scan-build it seems to be unable to compile
> > using certain headers.
>
Checking out the code and testing this yourselves will likely be the fastest
way to solve this, unless it is somehow unique to my system.

--
Mike Blumenkrantz
Zentific: Our boolean values are huge.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: scan-build failure

Tom Care
Hi Michael,

Sorry for the late reply, it took me a while to reproduce this.

I successfully reproduced this on Ubuntu (project wouldn't compile under OSX). It looks like a problem with the ccc-analyzer script.  I filed Bug 8070

Thanks for reporting!

Tom

On 01/09/2010, at 6:47 PM, Michael Blumenkrantz wrote:

On Wed, 1 Sep 2010 18:34:40 -0700
Ted Kremenek <[hidden email]> wrote:

Hi Michael,

From the error diagnostics it appears that they are coming from Clang when
httpconnection.c is compiled.  I know you said that GCC is being used as the
compiler, but that doesn't seem to be the case.

BTW, are you doing a parallel build?  It appears that url.c is analyzed
before httpconnection.c, so it is difficult to tell from the log what is
going on.

Yes, -j2.
FWIW, all ccc-analyzer does is directly forward the command line arguments to
your compiler (e.g., gcc), and then calls clang with various analyzer comment
line options.  If the analyzer fails, however, that shouldn't cause the build
to fail.  The only reason that ccc-analyzer returns an error code is if the
compiler it called returned an error code.

Have you tried building your project with Clang?  (not using scan-build).  I
suspect that you'll see the same errors, and if so that will at least confirm
that the build is failing because clang is being used for compilation.

The project compiles fine with both gcc and clang, but fails when using
scan-build.  You can easily check the code out from
http://svn.zentific.com/trunk/Zentific-console/shellinabox and test this
yourself.
Also, if clang is indeed being used to build your project, I'm not certain
why scan-build is using clang to actually build your project unless...

 (a) the 'gcc' in your path is a symlink to clang

or

 (b) the environment variable CCC_CC is set to 'clang'
I don't remember which cc I was using in the log that I sent just now, but
neither compiler is able to finish a build when using scan-build.  Required
functions that are detected when not using scan-build are no longer detected
when using scan-build.

On Aug 31, 2010, at 9:41 PM, Michael Blumenkrantz wrote:

Attached are the output for running configure and make with
CCC_ANALYZER_VERBOSE set (log.txt) as well as the config.log file.  For
whatever reason, when using scan-build it seems to be unable to compile
using certain headers.

Checking out the code and testing this yourselves will likely be the fastest
way to solve this, unless it is somehow unique to my system.

--
Mike Blumenkrantz
Zentific: Our boolean values are huge.


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: scan-build failure

Michael Blumenkrantz
On Fri, 3 Sep 2010 00:04:28 -0700
Tom Care <[hidden email]> wrote:

> Hi Michael,
>
> Sorry for the late reply, it took me a while to reproduce this.
>
> I successfully reproduced this on Ubuntu (project wouldn't compile under
> OSX). It looks like a problem with the ccc-analyzer script.  I filed Bug 8070
>
> Thanks for reporting!
>
> Tom
>
> On 01/09/2010, at 6:47 PM, Michael Blumenkrantz wrote:
>
> > On Wed, 1 Sep 2010 18:34:40 -0700
> > Ted Kremenek <[hidden email]> wrote:
> >
> >> Hi Michael,
> >>
> >> From the error diagnostics it appears that they are coming from Clang when
> >> httpconnection.c is compiled.  I know you said that GCC is being used as
> >> the compiler, but that doesn't seem to be the case.
> >>
> >> BTW, are you doing a parallel build?  It appears that url.c is analyzed
> >> before httpconnection.c, so it is difficult to tell from the log what is
> >> going on.
> >>
> > Yes, -j2.
> >> FWIW, all ccc-analyzer does is directly forward the command line arguments
> >> to your compiler (e.g., gcc), and then calls clang with various analyzer
> >> comment line options.  If the analyzer fails, however, that shouldn't
> >> cause the build to fail.  The only reason that ccc-analyzer returns an
> >> error code is if the compiler it called returned an error code.
> >>
> >> Have you tried building your project with Clang?  (not using scan-build).
> >> I suspect that you'll see the same errors, and if so that will at least
> >> confirm that the build is failing because clang is being used for
> >> compilation.
> >>
> > The project compiles fine with both gcc and clang, but fails when using
> > scan-build.  You can easily check the code out from
> > http://svn.zentific.com/trunk/Zentific-console/shellinabox and test this
> > yourself.
> >> Also, if clang is indeed being used to build your project, I'm not certain
> >> why scan-build is using clang to actually build your project unless...
> >>
> >>  (a) the 'gcc' in your path is a symlink to clang
> >>
> >> or
> >>
> >>  (b) the environment variable CCC_CC is set to 'clang'
> > I don't remember which cc I was using in the log that I sent just now, but
> > neither compiler is able to finish a build when using scan-build.  Required
> > functions that are detected when not using scan-build are no longer detected
> > when using scan-build.
> >>
> >> On Aug 31, 2010, at 9:41 PM, Michael Blumenkrantz wrote:
> >>
> >>> Attached are the output for running configure and make with
> >>> CCC_ANALYZER_VERBOSE set (log.txt) as well as the config.log file.  For
> >>> whatever reason, when using scan-build it seems to be unable to compile
> >>> using certain headers.
> >>
> > Checking out the code and testing this yourselves will likely be the fastest
> > way to solve this, unless it is somehow unique to my system.
> >
> > --
> > Mike Blumenkrantz
> > Zentific: Our boolean values are huge.
>
Excellent!  Always glad to break things :)

--
Mike Blumenkrantz
Zentific: Our boolean values are huge.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev