Interpreting Mudflap output

The type of errors that Mudflap detects includes overflow/underflow (running off the ends of buffers and strings) and memory leaks.


Figure 1. Sample Mudflap outputs results in the Mudflap Violations view
For example, the following Mudflap output results are the result of an illegal deallocation of memory, which is illustrated by the following code segment:
#include <stdio.h> 
#include <stdlib.h> 
#include <string.h> 

int main(int argc, char ** argv){ 
   char * str = ""; 
   if (argc>1) { 
      str = malloc(10); 
      // ... 
      } 
   printf("Str: %s\n",str); 
   free(str); 
   return 0; 
}

The object name includes the name identified by Mudflap (i.e. if it's a local variable); otherwise, it can include the area, size and/or reference number (a pointer).

The output from the Console for this example looks like this:
Str: ******* mudflap violation 1 (unregister): time=1238449399.353085
ptr=0x804a4b0 size=0 pc=0xb8207109, thread=1 
       libmudflapth.so.0(__mfu_unregister+0xa8) [0xb8206d2c]
       libmudflapth.so.0(__mf_unregister+0x3c) [0xb8207104]
       libmudflapth.so.0(__real_free+0xad) [0xb82091c9]
       AQNXCProject(main+0x41) [0x804902d] 
Nearby object 1: checked region begins 0B into and ends 0B into mudflap 
       object 0x8055500: name=`string literal' 
bounds=[0x804a4b0,0x804a4b0] size=1 area=static check=0r/0w liveness=0 
alloc time=1238449399.352085 pc=0xb8207593 thread=1 
number of nearby objects: 1 
Leaked object 1: 
mudflap object 0x8055290: name=`malloc region' 
bounds=[0x8055248,0x805525b] size=20 area=heap check=0r/0w liveness=0 
alloc time=1238449399.350085 pc=0xb8207593 thread=1 
       libmudflapth.so.0(__mf_register+0x3e) [0xb820758e] 
       libmudflapth.so.0(__real_malloc+0xba) [0xb8208b6a] 
       libc.so.3(atexit+0x19) [0xb032ac99]
       libc.so.3(_init_libc+0x33) [0xb03641b3] 
Leaked object 2:
mudflap object 0x8055360: name=`malloc region'
bounds=[0x8055318,0x805532b] size=20 area=heap check=0r/0w liveness=0 
alloc time=1238449399.351085 pc=0xb8207593 thread=1
       libmudflapth.so.0(__mf_register+0x3e) [0xb820758e]
       libmudflapth.so.0(__real_malloc+0xba) [0xb8208b6a]
       libc.so.3(atexit+0x19) [0xb032ac99] 
       AQNXCProject(_start+0x42) [0x8048f2a] 
Leaked object 3: 
mudflap object 0x8055430: name=`malloc region' 
bounds=[0x80553e8,0x80553fb] size=20 area=heap check=0r/0w liveness=0 
alloc time=1238449399.351085 pc=0xb8207593 thread=1 
       libmudflapth.so.0(__mf_register+0x3e) [0xb820758e] 
       libmudflapth.so.0(__real_malloc+0xba) [0xb8208b6a] 
       libc.so.3(atexit+0x19) [0xb032ac99]
       AQNXCProject(_start+0x61) [0x8048f49] 
Leaked object 4: 
mudflap object 0x80576a0: name=`malloc region'
bounds=[0x805a098,0x805a09f] size=8 area=heap check=0r/0w liveness=0 
alloc time=1238449399.352085 pc=0xb8207593 thread=1
       libmudflapth.so.0(__mf_register+0x3e) [0xb820758e]
       libmudflapth.so.0(__real_malloc+0xba) [0xb8208b6a]
       libc.so.3(_Initlocks+0x4c) [0xb0357aac]
       libc.so.3(__pthread_once+0x92) [0xb0320e32] 
Leaked object 5: mudflap object 0x8057708: name=`malloc region'
bounds=[0x8063bd8,0x8063fd7] size=1024 area=heap check=0r/0w liveness=0 
alloc time=1238449399.353085 pc=0xb8207593 thread=1
       libmudflapth.so.0(__mf_register+0x3e) [0xb820758e]
       libmudflapth.so.0(__real_malloc+0xba) [0xb8208b6a]
       libc.so.3(_Fbuf+0x4a) [0xb0352dea] 
       libc.so.3(_Fwprep+0x73) [0xb0353433] 
number of leaked objects: 5
And this information from the console for the example above can be explained as follows:

To summarize a conclusion for the information above, some code in the main function for the project called AQNXCProject contains an illegal deallocation of memory because an operation is being performed on a pointer that doesn't point to an appropriate heap memory segment (a heap-allocated block that has not yet been properly deallocated). This situation is detected by the -internal-checking option.

Descriptions of Mudflap results

In the Mudflap Violations view, you might see errors similar to the following: