-
Notifications
You must be signed in to change notification settings - Fork 11
/
Copy pathREADME
executable file
·288 lines (223 loc) · 12.8 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
==============
Aspirator: A simple checker for exception handler bugs
==============
- Aspirator is a tool that checks for trivial bug patterns in exception
handlers for Java or JVM compatible programs. Specifically, it reports
a warning if an important exception is ignored, system aborts on
over-caught exceptions, or the exception handler contains "TODO" or
"FIXME" in the comments. These trivial bugs in exception handlers have
been shown to have caused a significant number of deadly failures for
distributed systems. See more details in the paper:
Simple Testing Can Prevent Most Critical Failures: An Analysis of
Production Failures in Distributed Data-intensive Systems,
Ding Yuan, Yu Luo, Xin Zhuang, Guilherme Rodrigues, Xu Zhao, Yongle Zhang,
Pranay U. Jain, and Michael Stumm. In the Proceedings of the 11th USENIX
Symposium on Operating Systems Design and Implementation (OSDI'14), October 2014.
- Aspirator is built on Chord. The later part of this documents describes
how to install and run chord. A copy of the Chord source is included
here.
- After Chord is installed, the following three analysis can be used to
detect bugs in exception handling code:
- exception-empty-handler-java: detecting empty exception handler
- terminating-handler-java: detecting unexpected abort in exception
overcatch
- exception-todo-in-handler-java: detecting "TODO" and "FIXME" in
exception handler
- You will need to read the user guide of Chord to understand how to
run an analysis.
- We also extended Chord to easier analyze big real-world project by adding
a few more options. As an example, in the example/cassandra directory,
there is a chord.properties file showing how to run the
"exception-empty-hanler-java" analysis on Cassandra. Here is a brief
overview of the required options:
- chord.class.path: paths to .jar files containing the bytecode of the
target software to analyze. Normally you can find them in the
"build/" or "target/" directories in the target software's source
directory after you compiled it.
- chord.src.path: paths to the java source files. The source files are
used by the "exception-todo-in-handler-java" analysis to analyze the
comments; they are also used to print the analysis result.
- chord.run.analyses: the value should be one of the followings:
"exception-empty-handler-java", "terminating-handler-java", or
"exception-todo-in-handler-java".
- chord.extraclasses.file: contains a list of classes to be analyzed.
aspirator will only analyze these classes. The reason for us to add
this option is that by default, chord automatically discovers which
classes to analyze (see Chapter 7 in chord's user guide). However,
there are two problems with this default approach: first, it
requires user to specify a main class, which contains the main
method, and then analyze all the classes that can be reached by this
main class. For large projects, it is hard to find the appropriate
main classes that can be used to reach all the code we want to
analyze, thus we found a large amount of the target code is not
analyzed by chord simply because they couldn't be reached; second,
it will also analyze all the library bytecode, such as java.lang.
By using this file, it tells aspirator exactly which classes we are
interested to analyze, and you do not have to provide a main class.
We also provided an example class file, "classNames.txt", that
contains all the classes in cassandra. You can easily generate this
file by scripting over the .jar file, which contains all the names
of classes.
- chord.ignore.exceptions: an optional list of exceptions, separated by comma,
that aspirator will not report a warning if their handlers are empty.
This is to reduce the false positives of aspirator. By default,
aspirator ignores "FileNotFoundException".
- chord.ignore.methods: an optional list of exceptions, separated by comma,
that aspirator will not report a warning if the exceptions thrown by them
are not handled. This is to reduce the false positives of aspirator. By
default, aspirator ignores exceptions thrown by methods whose names
contain "close", "cleanup", "stop", and "shutdown".
- All other properties do not need to be modified.
- Note: when running aspirator, you should set "chord.verbose", the verbosity
level, to 0, otherwise there will be huge amount of debugging information
printed.
- After the analysis, the output is in the chord_output/log.txt file. Each
warning is in the format of:
==========================================
WARNING 1: empty handler for exception: java.lang.Throwable
There are log messages..
Line: 192, File: "org/apache/cassandra/auth/CassandraAuthorizer.java"
186: try
187: {
188: process(String.format("DELETE FROM %s.%s WHERE username = '%s'", Auth.AUTH_KS, PERMISSIONS_CF, escape(droppedUser)));
188: process(String.format("DELETE FROM %s.%s WHERE username = '%s'", Auth.AUTH_KS, PERMISSIONS_CF, escape(droppedUser)));
189: }
190: catch (Throwable e)
191: {
192: logger.warn("CassandraAuthorizer failed to revoke all permissions of {}: {}", droppedUser, e);
193: }
==========================================
Aspirator will report whether the exception handler is logged or not. In
addition, the exception-throwing line is highlighted by repeating itself
(e.g., line 188 in this example).
===============
OBTAINING CHORD
===============
You can either obtain pre-built binaries of Chord or you can obtain the source
code of Chord and build it yourself. Both these options are described below.
===================
BINARY INSTALLATION
===================
To obtain Chord's pre-built binaries, download and uncompress file
http://jchord.googlecode.com/files/chord-bin-2.1.tar.gz. It primarily contains
the following files:
- chord.jar, which contains the class files of Chord and of libraries used by
Chord.
- libbuddy.so, buddy.dll, and libbuddy.dylib: you can keep one of these files
depending upon whether you intend to run Chord on Linux, Windows/Cygwin, or
MacOS, respectively. These files are needed only if you want the high
performance BDD library BuDDy to be used when the BDD-based Datalog solver
bddbddb in Chord runs analyses written in Datalog.
- libchord_instr_agent.so: this file is needed only if you want the JVMTI-based
bytecode instrumentation agent to be used when Chord runs dynamic analyses.
Novice users can ignore items (2) and (3) until they become more familiar with
Chord. The binaries mentioned in items (2) and (3) might not be compatible with
your machine, in which case you can either forgo using them (with hardly any
noticeable difference in functionality), or you can download the sources and
build them yourself, as described below.
===================
SOURCE INSTALLATION
===================
To obtain Chord's source code, download and uncompress file
http://jchord.googlecode.com/files/chord-src-2.1.tar.gz. It contains Chord's
source code and jars of libraries used by Chord.
If you also want the source code of libraries used by Chord (e.g., joeq,
javassist, bddbddb, etc.), download and uncompress file
http://jchord.googlecode.com/files/chord-libsrc-2.1.tar.gz.
Alternatively, you can obtain the latest development snapshot from the SVN
repository by running the following command:
svn checkout http://jchord.googlecode.com/svn/trunk/ chord
Instead of checking out the entire trunk/, which contains several
sub-directories, you can check out specific sub-directories:
- main/ contains Chord's source code and jars of libraries used by Chord.
- libsrc/ contains the source code of libraries used by Chord (e.g., joeq,
javassist, bddbddb, etc.).
- test/ contains Chord's regression tests.
- many more; these might eventually move into main/.
Files chord-2.1-src.tar.gz and chord-2.1-libsrc.tar.gz mentioned above are
essentially stable releases of the main/ and libsrc/ directories, respectively.
=========================
COMPILING THE SOURCE CODE
=========================
Compiling Chord's source code requires the following software:
- A JVM with JDK 5 or higher, e.g. IBM J9 or Oracle HotSpot.
- Apache Ant, a Java build tool.
Chord's main directory contains a file named build.xml which is interpreted by
Apache Ant. To see the various possible targets, simply run command "ant" in
that directory.
To compile Chord, run command "ant compile" in the same directory. This will
compile Chord's Java sources from src/ to class files in classes/, as well as
build a jar file chord.jar that contains these class files as well as the those
in the jars of libraries that are used by Chord and are provided under lib/
(e.g., joeq.jar, javassist.jar, bddbddb.jar, etc.). Additionally:
- If system property chord.use.buddy is set to true, then the C source code of
BDD library BuDDy from directory bdd/ will be compiled to a shared library
named libbuddy.so on Linux, buddy.dll on Windows, and libbuddy.dylib on MacOS;
this library is used by BDD-based Datalog solver bddbddb in Chord for running
analyses written in Datalog.
- If system property chord.use.jvmti is set to true, then the C++ source code of
the JVMTI-based bytecode instrumentation agent from directory agent/ will be
compiled to a shared library named libchord_instr_agent.so on all
architectures; this agent is used in Chord for computing analysis scope
dynamically and for running dynamic analyses.
Properties chord.use.buddy and chord.use.jvmti are defined in file
chord.properties in Chord's main directory. The default value of both these
properties is false. If you set either of them to true, then you will also need
a utility like GNU Make (to run the Makefile's in directories bdd/ and agent/)
and a C++ compiler.
=============
RUNNING CHORD
=============
Running Chord requires a JVM with JDK 5 or higher. There are two equivalent ways
to run Chord. One way, which is available only in the source installation of
Chord, is to run the following command:
ant -f <CHORD_MAIN_DIR>/build.xml -D<key1>=<val1> ... -D<keyN>=<valN> run
The above requires Apache Ant (a Java build tool) to be installed on your
machine. The alternative, which does not require Apache Ant and is available in
both the source and binary installations of Chord, is to run the following
command:
java -cp <CHORD_MAIN_DIR>/chord.jar -D<key1>=<val1> ... -D<keyN>=<valN> chord.project.Boot
where <CHORD_MAIN_DIR> denotes the directory containing file chord.jar; that
directory is also expected to contain any other binaries in Chord's installation
(e.g., libbuddy.so and libchord_instr_agent.so).
Each "-D<key>=<val>" argument above sets the system property named <key> to the
value denoted by <val>. The only way to specify inputs to Chord is via system
properties; there is no command-line argument processing. All system properties
recognized by Chord are described at
http://chord.stanford.edu/user_guide/properties.html.
QUICK START
===========
To ensure that Chord is installed successfully, run it on a provided example
Java program as follows. First run command "ant" in directory
examples/hello_world/. This will compile the Java source code of that example.
Then, run the following command:
java -cp <CHORD_MAIN_DIR>/chord.jar -Dchord.work.dir=<CHORD_MAIN_DIR>/examples/hello_world \
-Dchord.run.analyses=cipa-0cfa-dlog chord.project.Boot
This will run a basic may-alias and call-graph analysis (called 0CFA) on the
example Java program. It will produce somewhat verbose output of the form:
Chord run initiated at: Mar 13, 2011 10:31:08 PM
ENTER: cipa-0cfa-dlog
... (truncated here for brevity)
LEAVE: cipa-0cfa-dlog
Chord run completed at: Mar 13, 2011 10:31:36 PM
Total time: 00:00:27:671 hh:mm:ss:ms
To reduce the verbosity of Chord's output, set -Dchord.verbose=0 on the command
line.
The names and descriptions of analyses besides cipa-0cfa-dlog that are provided
in Chord are available here:
http://chord.stanford.edu/user_guide/predefined.html
To setup your own Java program for analysis using Chord, see here:
http://chord.stanford.edu/user_guide/setup.html
To write your own analyses, possibly atop provided ones, see here:
http://chord.stanford.edu/user_guide/writing.html
FURTHER DOCUMENTATION
=====================
Chord's User Guide is available at:
http://chord.stanford.edu/user_guide/
The Javadoc of Chord's source code is available at:
http://chord.stanford.edu/javadoc/
For questions about Chord, send email to <[email protected]>, or
browse previous postings at:
http://groups.google.com/group/chord-discuss/
Posting does not require membership but posts by non-members are moderated to
avoid spamming group members.