Initial troubleshooting of malloc fragmentation

mlTp clean(mlTp mmList){    mlTp mm = mmList->next;      mlTp nextm = NULL;      while (mm != NULL){          nextm = mm->next;          del(mm);          mm = unite(mm);          mmList = add(mmList,mm);          mm = nextm;      }      return  mmList;  }  

The above is the original fragment function.

In the while {} range, nextm points to mm-> next. In normal cases, this works well (in fact, it is not rigorous here ), when the fragments adjacent to mm are mm-> next, mm and its adjacent fragments are merged into one, and the fragments are no longer in the linked list, nextm still points to the shard, but the memory is described by two nodes. There will be no problems at the beginning. After the application is released for multiple times. the linked list is a completely wrong memory description. It is more dangerous to skip the core. A memory may be allocated to multiple applications. the consequences are unimaginable.

Of course, this is not enough for the vomit condition, because the description of the memory block is connected before the memory, if the large block is allocated, this damages the description of this memory. When applying for this memory, it will have a chance to vomit.

Although the problem seems to have been solved, I still don't worry, because I only allocate the memory for testing and do not read or write the allocated memory, the probability of all damages is not great. this may be a bug.

The modified defragmentation program is as follows:

For other functions, see the implementation of malloc.

mlTp clean(mlTp ml){    mlTp mm = ml->next;    mlTp nextm = NULL;    while(mm != NULL){        nextm = mm->root;        del(mm);        unsigned long size = 0;        do{            size = mm->size;            mm = unite(mm);        }while(size != mm->size);        ml = add(ml,mm);        if(mm != nextm->next)            mm = nextm->next;        else            mm = nextm->next->next;    }    return ml;}