Features that developers love

Demystify the common causes of segmentation fault

Stensal SDK reports unambiguous error messages for memory access violations to developers. Below is a list of the memory access violations. For each category of memory access violation, Stensal offers:
  • An explanation of the memory access violation
  • A code snippet that illustrates what code causes the relevant category of memory access violation
  • A live test to show how Stensal SDK can help developers find the cause with unambiguous error message.

Out-of-bounds array access

Out-of-bounds (OOB) array access (buffer overrun or buffer overflow) is the most common mistake made by developers. Traditional C/C++ implementations often do not enforce complete array bounds checking. OOB array access can read undefined values, silently corrupt data, or cause segmentation faults without any diagnostic information.

Stensal DTS enforces array bounds checking, and pinpoints OOB array accesses with diagnostic information and backtrace. It helps developers fix them much more quickly.

The highlighted line accesses array OOB, but it does not always crash the program. It confused a developer.

            Test it

Null (or uninitialized) pointer dereference

Accessing null (or uninitialized) pointers is a common mistake resulting in "unexpected" segmentation faults.

Stensal DTS helps developers identify and fix the causes of "unexpected" segmentation fault by enforcing null pointer checks and reporting dereference of null pointers with diagnostic information and backtrace.

a is a stack allocated variable and is not initialized before being used at the highlighted line.

            Test it


In C/C++, stack allocated memory can be out-of-scope, and heap allocated memory can be freed even if it is still accessible in a program. Consequently, reading from a freed (or out-of-scope) memory might read undefined values, and writing a freed (or out-of-scope) memory might cause segmentation fault or corrupt data if the freed memory (or out-of-scope memory) is recycled and reused. Use-after-free, a term for such bugs, causes unpredictable behavior and is often hard to diagnose.

Stensal DTS detects use-after-free memory access violations with high probability, and reports the allocation information and the backtrace of access violation.

The highlighted line uses the address of stack allocated memory that is out-of-scope (freed).

            Test it

Double free

In C/C++, the pointer (or address) of a freed memory might still be accessible in a program, and be freed again. The memory that is freed once can be reallocated and reinitialized before the second free, which can cause intermittent crashes.

Stensal DTS detects double free with high probability. Double free is reported with the first allocation information and the backtrace of second free.

The pointer of x after the second malloc might be equal to the previous allocated address of y. The hightlighted free(y) could free the memory pointed by x and the subsequent using of x causes intermittent crashes.

            Test it

Constant data corruption

Constant data are mapped to read-only memory address space in C/C++. Writing data to read-only memory address space causes segmentation fault. Stensal DTS reports constant data corruption.

Why does the hightlighted line crash?

            Test it

Check all memory accesses

Applications depends on third party libraries. Memory accession violations in third party libraries cause memory corruption as these in the applications. Stensal DTS can check all memory accesses of applications and their dependency. Any memory access violations in your code and its dependencies will be caught and reported. Example 1 shows how the test driver of a popular blockchain library causes an OOB array read in musl libc through boost_1_62_0.

DTS_MSG: Stensal DTS detected a fatal program error!
DTS_MSG: Continuing the execution will cause unexpected behaviors, abort!
DTS_MSG: Reading 1 bytes at 0x14b500d8 will read undefined values.
DTS_MSG: Diagnostic information:

- The object to-be-read (start:0x14b50080, size:88 bytes) is allocated at
-     file:/src/consecutive_malloc.ipp::10, 16
-  0x14b50080               0x14b500d7
-  +------------------------+
-  | the object  to-be-read |......
-  +------------------------+
-                            ^~~~~~~~~~
-        the read starts at 0x14b500d8 that is right after the object end.
- Stack trace (most recent call first):
-[1]  file:/musl-1.1.10/src/string/memchr.c::25, 9
-[2]  file:/musl-1.1.10/src/stdio/vfprintf.c::602, 8
-[3]  file:/musl-1.1.10/src/stdio/vfprintf.c::678, 8
-[4]  file:/musl-1.1.10/src/stdio/vsnprintf.c::37, 6
-[5]  file:/boost/src/boost_1_62_0/./boost/test/impl/execution_monitor.ipp::244, 5
-[6]  file:/boost/src/boost_1_62_0/./boost/test/impl/execution_monitor.ipp::275, 5
-[7]  file:/boost/src/boost_1_62_0/./boost/test/impl/execution_monitor.ipp::1217, 9
-[8]  file:/boost/src/boost_1_62_0/./boost/test/impl/execution_monitor.ipp::1312, 5
-[9]  file:/boost/src/boost_1_62_0/./boost/test/impl/unit_test_monitor.ipp::46, 9

Report deterministic error message

Unlike other memory error finding tools, Stensal SDK's reporting is deterministic and unambiguous. It always reports the cause and the source location at which a memory access violation occurs. The deterministic and unambiguous messages accelerate the remediation of memory access violations.

Example 2, which has an OOB array access vulnerability at the highlighted mark, is used to demonstrate the reporting differences among Stensal DTS, AddressSanitizer, and Valgrind.

Stensal DTS reports the correct cause and the source location for any input greater than or equal to 10. You can test it with other inputs.

AddressSanitizer does not report the overruns caused by some inputs such as 50, and it reports the right cause for input 10, and a wrong cause (stack-overflow) for input 10000.

Valgrind does not report for input 10 and 50, and reports invalid write for input 10000 with a wrong cause.

            test it