I am creating a simple dictionary in C using generic linked lists, thus in the process I am using malloc and free.
Anyway, Valgrind sadly doesn't support OS X 10.9, therefore I am using Xcode's Leaks Instrument. However, I have a bit trouble understanding the feedback this tool is providing me. Simpler, from the data output I can't understand if I have leaks or not.
Here is a screenshot of what the tool is telling me:
link to image
Here is the code that is creating the linked list:
typedef struct Element {
struct Element *next;
void *value;
} TElelemt, *TList, **AList;
typedef void (*PrintF) (void *);
int Insert_Elm(AList list, void *value, size_t dimension) {
TList aux = (TList) malloc(sizeof(TElelemt));
if (!aux) {
printf("Allocation error!\n");
return 0;
}
aux->value = malloc(dimension);
if (!aux->value) {
printf("Allocation error!\n");
return 0;
}
memcpy(aux->value, value, dimension);
aux->next = *list;
*list = aux;
return 1;
}
void Delete_Elm(AList list) {
TList elm = *list;
if (!elm) {
return;
}
free(elm->value);
*list = elm->next;
free(elm);
return;
}
void Delete_List(AList list) {
while (*list) {
Delete_Elm(list);
}
return;
}
// In main() I am doing something like this where TWord cuv is allocated in stack:
for (i = 0; i < 1000000; i++) {
Insert_Elm(&list, &cuv, sizeof(TWord));
}
Delete_List(&list);
What is the tool saying and are there any memory leaks?
Your screenshot is showing no memory leaks. In your screenshot the Allocations instruments has graphed your memory usage in blue. If Instruments had detected any memory leaks, it would show them in the graph for the Leaks instrument. But in your screenshot the graph for the Leaks instrument is blank, which means Instruments detected no memory leaks.
One additional thing, your screenshot is showing the statistics for the Allocations instrument. It's telling you the amount of memory your program allocated. Select the Leaks instrument from the instrument list to see the Leaks instrument's statistics. Selecting the Leaks instrument will also tell you whether or not any memory leaks were detected. If you have any leaks, Instruments will list them in the table below the graphs.
Related
I'm a bit confused on how to check if a memory allocation failed in order to prevent any undefined behaviours caused by a dereferenced NULL pointer.
I know that malloc (and similiar functions) can fail and return NULL, and that for this reason the address returned should always be checked before proceeding with the rest of the program. What I don't get is what's the best way to handle these kind of cases. In other words: what is a program supposed to do when a malloc call returns NULL?
I was working on this implementation of a doubly linked list when this doubt raised.
struct ListNode {
struct ListNode* previous;
struct ListNode* next;
void* object;
};
struct ListNode* newListNode(void* object) {
struct ListNode* self = malloc(sizeof(*self));
if(self != NULL) {
self->next = NULL;
self->previous = NULL;
self->object = object;
}
return self;
}
The initialization of a node happens only if its pointer was correctly allocated. If this didn't happen, this constructor function returns NULL.
I've also written a function that creates a new node (calling the newListNode function) starting from an already existing node and then returns it.
struct ListNode* createNextNode(struct ListNode* self, void* object) {
struct ListNode* newNext = newListNode(object);
if(newNext != NULL) {
newNext->previous = self;
struct ListNode* oldNext = self->next;
self->next = newNext;
if(oldNext != NULL) {
newNext->next = oldNext;
oldNext->previous = self->next;
}
}
return newNext;
}
If newListNode returns NULL, createNextNode as well returns NULL and the node passed to the function doesn't get touched.
Then the ListNode struct is used to implement the actual linked list.
struct LinkedList {
struct ListNode* first;
struct ListNode* last;
unsigned int length;
};
_Bool addToLinkedList(struct LinkedList* self, void* object) {
struct ListNode* newNode;
if(self->length == 0) {
newNode = newListNode(object);
self->first = newNode;
}
else {
newNode = createNextNode(self->last, object);
}
if(newNode != NULL) {
self->last = newNode;
self->length++;
}
return newNode != NULL;
}
if the creation of a new node fails, the addToLinkedList function returns 0 and the linked list itself is left untouched.
Finally, let's consider this last function which adds all the elements of a linked list to another linked list.
void addAllToLinkedList(struct LinkedList* self, const struct LinkedList* other) {
struct ListNode* node = other->first;
while(node != NULL) {
addToLinkedList(self, node->object);
node = node->next;
}
}
How should I handle the possibility that addToLinkedList might return 0? For what I've gathered, malloc fails when its no longer possible to allocate memory, so I assume that subsequent calls after an allocation failure would fail as well, am I right? So, if 0 is returned, should the loop immediately stop since it won't be possible to add any new elements to the list anyway?
Also, is it correct to stack all of these checks one over another the way I did it? Isn't it redundant? Would it be wrong to just immediately terminate the program as soon as malloc fails? I read that it would be problematic for multi-threaded programs and also that in some istances a program might be able to continue to run without any further allocation of memory, so it would be wrong to treat this as a fatal error in any possible case. Is this right?
Sorry for the really long post and thank you for your help!
It depends on the broader circumstances. For some programs, simply aborting is the right thing to do.
For some applications, the right thing to do is to shrink caches and try the malloc again. For some multithreaded programs, just waiting (to give other threads a chance to free memory) and retrying will work.
For applications that need to be highly reliable, you need an application level solution. One solution that I've used and battle tested is this:
Have an emergency pool of memory allocated at startup.
If malloc fails, free some of the emergency pool.
For calls that can't sanely handle a NULL response, sleep and retry.
Have a service thread that tries to refill the emergency pool.
Have code that uses caching respond to a non-full emergency pool by reducing memory consumption.
If you have the ability to shed load, for example, by shifting load to other instances, do so if the emergency pool isn't full.
For discretionary actions that require allocating a lot of memory, check the level of the emergency pool and don't do the action if it's not full or close to it.
If the emergency pool gets empty, abort.
How to handle malloc failing and returning NULL?
Consider if the code is a set of helper functions/library or application.
The decision to terminate is best handled by higher level code.
Example: Aside from exit(), abort() and friends, the Standard C library does not exit.
Likewise returning error codes/values is a reasonable solution for OP's low-level function sets too. Even for addAllToLinkedList(), I'd consider propagating the error in the return code. (Non-zero is some error.)
// void addAllToLinkedList(struct LinkedList* self, const struct LinkedList* other) {
int addAllToLinkedList(struct LinkedList* self, const struct LinkedList* other) {
...
if (addToLinkedList(self, node->object) == NULL) {
// Do some house-keepeing (undo prior allocations)
return -1;
}
For the higher level application, follow your design. For now, it may be a simple enough to exit with a failure message.
if (addAllToLinkedList(self, ptrs)) {
fprintf(stderr, "Linked List failure in %s %u\n", __func__, __LINE__);
exit(EXIT_FAILURE);
}
Example of not exiting:
Consider a routine that read a file into a data structure with many uses of LinkedList and the file was somehow corrupted leading to excessive memory allocations. Code may want to simply free everything for that file (but just for that file), and simply report to the user "invalid file/out-of-memory" - and continue running.
if (addAllToLinkedList(self, ptrs)) {
free_file_to_struct_resouces(handle);
return oops;
}
...
return success;
Take away
Low level routines indicate an error somehow. Higher level routines can exit code if desired.
I tried to implement a singly linked linked List in c. I wanted to be able to use multiple instances of the list and I wanted to create the list in the main function. That is why i chose to implement it in the way I did.
The code works perfectly fine but i am concerned because of the output valgrind creates. Also I tried to use the code in a project on an embedded system and strange errors happen.
The valgrind output is:
starting...
==3570== Conditional jump or move depends on uninitialised value(s)
==3570== at 0x100000E8E: push_cfront (in ./map_test)
==3570== by 0x100000D4F: main (in ./map_test)
==3570== Uninitialised value was created by a heap allocation
==3570== at 0x100008EBB: malloc (in /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==3570== by 0x100000E80: push_cfront (in ./map_test)
==3570== by 0x100000D4F: main (in ./map_test)
==3570==
...finished
Also it tells me that i am loosing one block. Where do i make a mistake freeing it
==3570== LEAK SUMMARY:
==3570== definitely lost: 16 bytes in 1 blocks
==3570== indirectly lost: 0 bytes in 0 blocks
==3570== possibly lost: 2,064 bytes in 1 blocks
==3570== still reachable: 0 bytes in 0 blocks
==3570== suppressed: 24,525 bytes in 186 blocks
Please give me a hint on where i went wrong.
test.c:
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#include "command_list.h"
int main() {
printf("starting...\n");
Clist * command_list = malloc(sizeof(Clist));
if (command_list == NULL) printf("Malloc Failed\n");
command_list->head = NULL;
//push_cback(command_list, 0);
push_cfront(command_list,1);
free_clist(command_list);
free(command_list);
printf("\n...finished\n");
return 0;
}
command_list.h:
#ifndef __COMMAND_LIST_H
#define __COMMAND_LIST_H
typedef struct cnode {
uint8_t command;
struct cnode * next;
} Cnode;
typedef struct clist {
Cnode * head;
} Clist;
void push_cback(Clist * list, uint8_t command);
void push_cfront(Clist * list, uint8_t command);
void free_clist(Clist * list);
#endif
command_list.c
void push_cfront(Clist * list, uint8_t command){
Cnode * new_node;
new_node = malloc(sizeof(Cnode));
if (new_node->next == NULL) {
return;
}
new_node->command = command;
new_node->next = list->head;
list->head = new_node;
}
void free_clist(Clist * list){
if (list->head == NULL){
return; //already empty
}
Cnode * current = list->head;
while (current->next != NULL){
Cnode* temp = current->next;
free(current);
current = temp;
}
free(current);
list->head = NULL;
}
You have a few problems. You are checking new_node->next (uninitialized data in malloc'd memory) instead of new_node (the return value of malloc). On my computer at least this also causes memory not to be freed because by chance new_node->next is null so you return without freeing new_node. Also, if you want to support pushing to the back of a linked list, you should consider a circularly linked list because it allows that operation without having to traverse the whole thing.
Finally, a few tips: it's good that you are using valgrind, but it will be more helpful if you compile with -g to enable debugging symbols so valgrind will tell you line numbers. Also, when I make linked lists, I like to use a dummy head node for some operations to avoid a special case for empty or singleton lists. For inserting into a sorted linked list, that technique looks like:
int sorted_insert(Clist *list, char new_command){
Cnode _head = {NULL, list->head}, *head = &_head, *prev = head, *tmp;//head is an auto dummy node obviating null checks.
int ord = -1;//If there are no existing nodes, newObj would be less than all objects.
while(prev->next && (ord = (int)newObj - prev->next->command)) > 0){//Iterate by prev->next not curr to use only one pointer.
prev = prev->next;//Looping while there is a next node and its data compares less than new_command.
}
if((!ord) || !(tmp = malloc(sizeof(Cnode))){//newObj is already in the list or allocation failed.
return 0;
}
*tmp = (Cnode){.next=prev->next, .command=new_command};
prev->next = tmp;
list->head = head->next;//un- add head which is then deallocated by stack frame cleanup.
return 1;
}
The new_node->next is uninitialized when you check it's value. You don't need that.
If you look for malloc failures, set a return code for the function and check it upon invocation.
Until that, the if branch in push_cfront is not needed.
... or you wanted to check list->head instead?
Also there's a problem with this piece of code in push_cfront
new_node = malloc(sizeof(Cnode));
if (new_node->next == NULL) {
return;
}
It's undefined behaviour since new_node memory is not initialised. You probably wanted to check if (new_node == NULL) to see if memory was actually allocated.
I am having an issue with the table of a little hashmap I am trying to implement.
map.h
typedef struct Map Map;
Map *map_create();
int map_set(Map *map, char *key, void *val);
map.c
const int MAP_INITIAL_SIZE = 100;
typedef struct MapPair MapPair;
struct MapPair
{
char *key;
void *val;
};
struct Map
{
MapPair **table;
int count;
int limit;
};
Map *map_create(void)
{
Map *map = (Map*)malloc(sizeof(Map));
if (!map) return NULL;
map->table = (MapPair**)malloc(MAP_INITIAL_SIZE * sizeof(MapPair));
if (!map->table)
{
free(map);
return NULL;
}
map->count = 0;
map->limit = MAP_INITIAL_SIZE;
return map;
}
void add(MapPair **context, int start, MapPair *pair, int limit)
{
int i = start;
while (context[i] != NULL && strcmp(context[i]->key, pair->key) != 0) // crashing here
{
i++;
if (i == limit) i = 0;
}
context[i] = pair;
}
int map_set(Map *map, char *key, void *val)
{
if (map->count >= map->limit / 2)
{
if (!expand(map)) return 0;
}
MapPair *pair = (MapPair*)malloc(sizeof(MapPair));
if (!pair) return 0;
pair->key = key;
pair->val = val;
add(map->table, hash(key, map->limit), pair, map->limit);
++map->count;
return 1;
}
I was originally developing in pelles c but moved to vs2013 for the debugger when I was experiencing problems. Then in vs2013 the program would crash at the add function but not in pelles c. I am assuming it has something to do with my dynamic array that I plan to be able to expand later.
Can anybody tell me why the program seems to crash when I try to access an index of the dynamic array?
In add function you are checking the table, until you reach the NULL pointer:
while (context[i] != N ...
But when you allocate this table you never set any of those pointers to NULL:
map->table = (MapPair**)malloc(MAP_INITIAL_SIZE * sizeof(MapPair));
You should set them to NULL:
for( size_t i = 0 ; i < MAP_INITIAL_SIZE ; i++ )
map->table[i] = NULL ;
Otherwise you will go out of bounds of that array.
I didn't know Visual could compile pure C projects ! Anyway, your crash is caused by a magic string : http://en.wikipedia.org/wiki/Magic_number_(programming)
* 0xABABABAB : Used by Microsoft's HeapAlloc() to mark "no man's land" guard bytes after allocated heap memory
* 0xABADCAFE : A startup to this value to initialize all free memory to catch errant pointers
* 0xBAADF00D : Used by Microsoft's LocalAlloc(LMEM_FIXED) to mark uninitialised allocated heap memory
* 0xBADCAB1E : Error Code returned to the Microsoft eVC debugger when connection is severed to the debugger
* 0xBEEFCACE : Used by Microsoft .NET as a magic number in resource files
* 0xCCCCCCCC : Used by Microsoft's C++ debugging runtime library to mark uninitialised stack memory
* 0xCDCDCDCD : Used by Microsoft's C++ debugging runtime library to mark uninitialised heap memory
* 0xDEADDEAD : A Microsoft Windows STOP Error code used when the user manually initiates the crash.
* 0xFDFDFDFD : Used by Microsoft's C++ debugging heap to mark "no man's land" guard bytes before and after allocated heap memory
* 0xFEEEFEEE : Used by Microsoft's HeapFree() to mark freed heap memory
(SO source : In Visual Studio C++, what are the memory allocation representations?)
Unlike GCC (or pelles I imagine), Visual Studio set uninitialized heap array pointers as 0xCDCDCDCD, not NULL. So your check of context[i] != NULL returns true even though context is not initialized.
... And that's why explicit is always better than implicit.
I have a list in C that is something like this:
typedef struct _node
{
int number;
DWORD threadID;
HANDLE threadH;
struct *_node next;
} *node;
And you have somthing like this:
node new_node = malloc(sizeof(node));
As you may have guessed out, this list will store information for threads, including their handlers and Id's. Still I am having trouble when I try to do this:
free(new_node);
Everytime I try to do this I encounter an unexpected error, VS saying that there was a data corruption. I've pinned down as much as possible and I found that the problem resides when I try to use free the handle.
I've searched on MSDN how to do this but the only thing I can find is the function that closes the thread (which is not intended here, since I want the thread to run, just deleting it's record from the list).
The question is: how I am supposed to free an handle from the memory? (Considering that this is only a copy of the value of the handle, the active handle is not being deleted).
EDIT: This is the function to insert nodes from the list:
int insereVisitanteLista(node* lista, DWORD threadID, HANDLE threadH, int num_visitante)
{
node visitanteAnterior;
node novoVisitante = (node)malloc(sizeof(node));
if(novoVisitante == NULL)
return 0;
novoVisitante->threadID = threadID;
novoVisitante->threadH = threadH;
novoVisitante->number = num_visitante;
novoVisitante->next = NULL;
if(*lista == NULL)
{
*lista = novoVisitante;
return 1;
}
visitanteAnterior = *lista;
while(visitanteAnterior->next != NULL)
visitanteAnterior = visitanteAnterior->next;
visitanteAnterior->next =novoVisitante;
return 1;
}
And this is the function to delete nodes:
int removeVisitanteLista(node * lista, DWORD threadID)
{
node visitanteAnterior = NULL, visitanteActual;
if(*lista == NULL)
return 0;
visitanteActual = *lista;
if((*lista)->threadID == threadID)
{
*lista = visitanteActual->next;
visitanteActual->next = NULL;
free(visitanteActual);
return 1;
}
while(visitanteActual != NULL && visitanteActual->threadID != threadID)
{
visitanteAnterior = visitanteActual;
visitanteActual = visitanteActual->next;
}
if (visitanteActual == NULL)
return 0;
visitanteAnterior->next = visitanteActual->next;
free(visitanteActual);
return 1;
}
What exactly is a node that you are trying to free? Is this a pointer to a struct _node? If yes, have you allocated it previously? If no, free is not needed, otherwise you have to check if node is not NULL and make sure you do not free it multiple times. It is hard to guess what you are doing and where is an error without a minimal working example reproducing the problem. The only thing I can suggest is to read about memory management in C. This resource might help.
UPDATE:
node in your code is a pointer to _node. So sizeof (node) is a size of a pointer, which is either 4 or 8 bytes (depending on architecture). So you allocate 8 bytes, for example, but assume you have a pointer to the structure which is much larger. As a result, you corrupt memory, and behavior of the program becomes undefined. So changing node novoVisitante = (node)malloc(sizeof(node)) to node novoVisitante = (node)malloc(sizeof(_node)) should fix the problem.
You haven't shown us the context of your call to free() so I need to speculate a little but my first concern is that you didn't mention removing the node from the list before deleting it.
Start by unlinking the node by modifying the next field of the previous (or head) node. If you still get the error, then you have corrupted memory somehow by writing past the end of one of your allocated memory structures or something similar.
Also, I assume node is a pointer. You really haven't provided much information about what you're doing.
I'm attempting to write a solver for a particular puzzle. It tries to find a solution by trying every possible move one at a time until it finds a solution. The first version tried to solve it depth-first by continually trying moves until it failed, then backtracking, but this turned out to be too slow. I have rewritten it to be breadth-first using a queue structure, but I'm having problems with memory management.
Here are the relevant parts:
int main(int argc, char *argv[])
{
...
int solved = 0;
do {
solved = solver(queue);
} while (!solved && !pblListIsEmpty(queue));
...
}
int solver(PblList *queue) {
state_t *state = (state_t *) pblListPoll(queue);
if (is_solution(state->pucks)) {
print_solution(state);
return 1;
}
state_t *state_cp;
puck new_location;
for (int p = 0; p < puck_count; p++) {
for (dir i = NORTH; i <= WEST; i++) {
if (!rules(state->pucks, p, i)) continue;
new_location = in_dir(state->pucks, p, i);
if (new_location.x != -1) {
state_cp = (state_t *) malloc(sizeof(state_t));
state_cp->move.from = state->pucks[p];
state_cp->move.direction = i;
state_cp->prev = state;
state_cp->pucks = (puck *) malloc (puck_count * sizeof(puck));
memcpy(state_cp->pucks, state->pucks, puck_count * sizeof(puck)); /*CRASH*/
state_cp->pucks[p] = new_location;
pblListPush(queue, state_cp);
}
}
}
free(state->pucks);
return 0;
}
When I run it I get the error:
ice(90175) malloc: *** mmap(size=2097152) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
Bus error
The error happens around iteration 93,000.
From what I can tell, the error message is from malloc failing, and the bus error is from the memcpy after it.
I have a hard time believing that I'm running out of memory, since each game state is only ~400 bytes. Yet that does seem to be what's happening, seeing as the activity monitor reports that it is using 3.99GB before it crashes. I'm using http://www.mission-base.com/peter/source/ for the queue structure (it's a linked list).
Clearly I'm doing something dumb. Any suggestions?
Check the result of malloc. If it's NULL, you might want to print out the length of that queue.
Also, the code snippet you posted didn't include any frees...
You need to free() the memory you've allocated manually after you're done with it; dynamic memory doesn't just "free itself"