@@ -108,7 +108,7 @@ functions.
108
108
109
109
You may also build Scudo like this:
110
110
111
- .. code ::
111
+ .. code :: console
112
112
113
113
cd $LLVM/projects/compiler-rt/lib
114
114
clang++ -fPIC -std=c++11 -msse4.2 -O2 -I. scudo/*.cpp \
@@ -117,7 +117,7 @@ You may also build Scudo like this:
117
117
118
118
and then use it with existing binaries as follows:
119
119
120
- .. code ::
120
+ .. code :: console
121
121
122
122
LD_PRELOAD=`pwd`/libscudo.so ./a.out
123
123
@@ -151,7 +151,7 @@ can be assigned in the same string, separated by colons.
151
151
152
152
For example, using the environment variable:
153
153
154
- .. code ::
154
+ .. code :: console
155
155
156
156
SCUDO_OPTIONS="DeleteSizeMismatch=1:QuarantineSizeKb=64" ./a.out
157
157
@@ -201,3 +201,53 @@ Allocator related common Sanitizer options can also be passed through Scudo
201
201
options, such as ``allocator_may_return_null `` or ``abort_on_error ``. A detailed
202
202
list including those can be found here:
203
203
https://github.com/google/sanitizers/wiki/SanitizerCommonFlags.
204
+
205
+ Error Types
206
+ ===========
207
+
208
+ The allocator will output an error message, and potentially terminate the
209
+ process, when an unexpected behavior is detected. The output usually starts with
210
+ ``"Scudo ERROR:" `` followed by a short summary of the problem that occurred as
211
+ well as the pointer(s) involved. Once again, Scudo is meant to be a mitigation,
212
+ and might not be the most useful of tools to help you root-cause the issue,
213
+ please consider `ASan <https://github.com/google/sanitizers/wiki/AddressSanitizer >`_
214
+ for this purpose.
215
+
216
+ Here is a list of the current error messages and their potential cause:
217
+
218
+ - ``"corrupted chunk header" ``: the checksum verification of the chunk header
219
+ has failed. This is likely due to one of two things: the header was
220
+ overwritten (partially or totally), or the pointer passed to the function is
221
+ not a chunk at all;
222
+
223
+ - ``"race on chunk header" ``: two different threads are attempting to manipulate
224
+ the same header at the same time. This is usually symptomatic of a
225
+ race-condition or general lack of locking when performing operations on that
226
+ chunk;
227
+
228
+ - ``"invalid chunk state" ``: the chunk is not in the expected state for a given
229
+ operation, eg: it is not allocated when trying to free it, or it's not
230
+ quarantined when trying to recycle it, etc. A double-free is the typical
231
+ reason this error would occur;
232
+
233
+ - ``"misaligned pointer" ``: we strongly enforce basic alignment requirements, 8
234
+ bytes on 32-bit platforms, 16 bytes on 64-bit platforms. If a pointer passed
235
+ to our functions does not fit those, something is definitely wrong.
236
+
237
+ - ``"allocation type mismatch" ``: when the optional deallocation type mismatch
238
+ check is enabled, a deallocation function called on a chunk has to match the
239
+ type of function that was called to allocate it. Security implications of such
240
+ a mismatch are not necessarily obvious but situational at best;
241
+
242
+ - ``"invalid sized delete" ``: when the C++14 sized delete operator is used, and
243
+ the optional check enabled, this indicates that the size passed when
244
+ deallocating a chunk is not congruent with the one requested when allocating
245
+ it. This is likely to be a `compiler issue <https://software.intel.com/en-us/forums/intel-c-compiler/topic/783942 >`_,
246
+ as was the case with Intel C++ Compiler, or some type confusion on the object
247
+ being deallocated;
248
+
249
+ - ``"RSS limit exhausted" ``: the maximum RSS optionally specified has been
250
+ exceeded;
251
+
252
+ Several other error messages relate to parameter checking on the libc allocation
253
+ APIs and are fairly straightforward to understand.
0 commit comments