@@ -108,7 +108,7 @@ functions.
108108
109109You may also build Scudo like this:
110110
111- .. code ::
111+ .. code :: console
112112
113113 cd $LLVM/projects/compiler-rt/lib
114114 clang++ -fPIC -std=c++11 -msse4.2 -O2 -I. scudo/*.cpp \
@@ -117,7 +117,7 @@ You may also build Scudo like this:
117117
118118 and then use it with existing binaries as follows:
119119
120- .. code ::
120+ .. code :: console
121121
122122 LD_PRELOAD=`pwd`/libscudo.so ./a.out
123123
@@ -151,7 +151,7 @@ can be assigned in the same string, separated by colons.
151151
152152For example, using the environment variable:
153153
154- .. code ::
154+ .. code :: console
155155
156156 SCUDO_OPTIONS="DeleteSizeMismatch=1:QuarantineSizeKb=64" ./a.out
157157
@@ -201,3 +201,53 @@ Allocator related common Sanitizer options can also be passed through Scudo
201201options, such as ``allocator_may_return_null `` or ``abort_on_error ``. A detailed
202202list including those can be found here:
203203https://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