Many static analyzer failures building XEmacs 21.5-b28

[llvmbot]

Bugzilla Link	2745
Resolution	WORKSFORME
Resolved on	Feb 22, 2010 12:47
Version	unspecified
OS	Linux
Attachments	configure log file for llvm
Reporter	LLVM Bugzilla Contributor
CC	@efriedma-quic,@tkremenek

Extended Description

The static analyzer has problems (crashes?) with 79 files in the XEmacs source tree.

Steps to reproduce:
cd
hg clone http://hg.debian.org/hg/xemacs/xemacs-beta
cd xemacs-beta
scan-build ./configure
scan-build make

uname -a ==>
Linux scarlatti 2.6.25-gentoo-r8 #​1 PREEMPT Fri Aug 29 04:45:27 PDT 2008 x86_64 AMD Turion(tm) 64 Mobile Technology MT-32 AuthenticAMD GNU/Linux

Please contact me (vladimir@acm.org) if you need any more information or help. I'd really like to see clang and scan-build work flawlessly, and I'll help wherever I can. (Unfortunately I am not fluent in C, but I do do a lot of compiling with Gentoo & XEmacs, and I'm a long-time user of Linux and XEmacs.)

[llvmbot]

assigned to @tkremenek

[efriedma-quic]

I just tried compiling XEmacs with clang, and the first issue I ran into is bug 2015, the lack of support for attribute ((transparent_union)). That's likely causing a lot of the failures.

[llvmbot]

"attribute" is only used in compiler.h, but compiler.h is included in lisp.h which is included by 216 C files in src. But only 79 files cause clang problems. The numbers don't match. Something's awry: either my understanding, or I've left something out, or "attribute" doesn't cause problems.

[efriedma-quic]

"attribute" is only used in compiler.h, but compiler.h is included in
lisp.h which is included by 216 C files in src. But only 79 files cause clang
problems. The numbers don't match. Something's awry: either my understanding,
or I've left something out, or "attribute" doesn't cause problems.

The attribute in question comes from a system header; anything that calls wait or connect or a few other similar functions will get hit by that bug.

[efriedma-quic]

Oh, and hacking around that, I've found some other issues which might be a bit more important... I'll keep this updated as I commit fixes.

[efriedma-quic]

Okay, I think I've fixed all the outstanding issues for compiling xemacs; would you mind trying an updated version? (The fixes are in svn; if you're using the packaged checker, you'll have to wait for checker-88.)

[llvmbot]

Great! I'm rebuilding llvm, clang and I'll test the checker on XEmacs ASAP.

[tkremenek]

In the analysis results that scan-build generates, the index.html file typically lists a set of source files that scan-build had problems on. These are given as a table of links to preprocessed files that either crashed the analyzer or were rejected by the parser (these will be categorized as "parser rejects" and "crashes" respectively). Feel free to attached some of those .i files to this PR (these are test cases useful for tracking down problems).

[tkremenek]

Steps to reproduce:
cd
hg clone http://hg.debian.org/hg/xemacs/xemacs-beta
cd xemacs-beta
scan-build ./configure
scan-build make

I did this on Mac OS X and only encountered compilation problems with etags.c:

xemacs-beta/lib-src/etags.c:135:11: error: 'io.h' file not found
xemacs-beta/lib-src/etags.c:266:11: error: 'chkmalloc.h' file not found
...

The main culprit I saw in Vladimir's output is that we aren't finding limits.h:

$ grep limits.h *.output
clang_crash_oxvAr0.i.output:/usr/include/limits.h:125:16: error: 'limits.h' file not found
clang_crash_oxvAr0.i.output:# include_next <limits.h>
clang_crash_p_CrOv.i.output:/usr/X11R6/include/limits.h:125:16: error: 'limits.h' file not found
clang_crash_p_CrOv.i.output:# include_next <limits.h>
...

This is likely an issue of not searching the right directories for this header file.

Vladimir: Can you provide the following (as attachments)?

1. The output of "locate limits.h"

2. The output of "gcc -print-search-dirs"

Also, please provide "gcc -v"

[tkremenek]

1. The output of "locate limits.h"

2. The output of "gcc -print-search-dirs"

Also, please provide "gcc -v"

Vladimir:

Can you also provide the output of the following:

$ cd /tmp
$ touch foo.c
$ gcc -v -c foo.c

This should list the default system include directories.

[llvmbot]

typescript of requested commands (see comment)
locate limits.h
gcc -print-search-dirs
gcc -v
cd /tmp
touch foo.c
gcc -v -c foo.c

[As an aside: Since my laptop runs Gentoo, I compile every package update for ~3000 installed packages, usually successfully. (Today I have no errors and a fully updated system.) I tend to update my system at least once per day, so if there were something drastically wrong with my compilation environment, I'd know about it in short order.]

[tkremenek]

patch that adds x86_64 gcc 4.3.1 include paths
Vladimir: Please give this patch a try against top-of-tree clang.

Within the clang directory:

patch -p0 < gentoo_x86_64.patch

[llvmbot]

Sorry, no. scan-build (or clang) still can't find <limits.h>, so there are lots of crashes. I'll send the zip file to kremenek@apple.com.

Is there perhaps some issue with "#include_next" vs "#include" being used? The docs say that the search for the directory containing the included file starts after the directory of the including file in the directory search path.

I applied the patch and re-made LLVM including clang successfully. I then re-configured xemacs with scan-build ($ scan-build ./configure ...) and made it ($ scan-build -k make).

$ pd /usr/local/src/llvm/tools/clang/
/usr/local/src/llvm/tools/clang ~
$ patch -p0 <clang.patch
patching file lib/Driver/InitHeaderSearch.cpp
Hunk #​1 succeeded at 208 (offset -15 lines).
$ cd ..
$ cd ..
$ make
...
llvm[1]: Regenerating LibDeps.txt.tmp
...
make[4]: Entering directory /usr/local/src/llvm/tools/clang/lib/Driver' llvm[4]: Compiling InitHeaderSearch.cpp for Release build llvm[4]: Building Release Archive Library libclangDriver.a make[4]: Leaving directory /usr/local/src/llvm/tools/clang/lib/Driver'
make[3]: Leaving directory /usr/local/src/llvm/tools/clang/lib' make[3]: Entering directory /usr/local/src/llvm/tools/clang/Driver'
llvm[3]: Linking Release executable clang (without symbols)
llvm[3]: ======= Finished Linking Release Executable clang (without symbols)
make[3]: Leaving directory `/usr/local/src/llvm/tools/clang/Driver'
...
llvm[0]: ***** Completed Release Build

The version of clang that I used was the one just built ;-):

$ type clang
clang is /usr/local/src/llvm/Release/bin/clang
$ dir /usr/local/src/llvm/Release/bin/clang
-rwxr-xr-x 1 vladimir users 6100137 2008-09-13 09:24 /usr/local/src/llvm/Release/bin/clang*

[efriedma-quic]

Would you mind trying this again? AFAIK, this should be working.

[llvmbot]

Text output of xemacs link failure