Features that developers love

Demystify memory access violations

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
        

Use-after-free

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 highlighted 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 highlighted line crash?

            
            Test it
        

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