When you allocate memory by calling malloc(), and you want to free that memory, you have to call free() on every pointer that you initialized it with a call to malloc().
For example, if you have something like
tasklist_container *cont = malloc(sizeof(tasklist_container)); // 1 allocation
for (int i = 0 i < TASKLISTLENGTH; i++)
cont -> list[i] =...
The problem lies in fread(&storage, sizeof(char), 1, old_file); This line is storing the data read directly in the pointer, overwriting the address of the malloc'd memory. It isn't storing the data at the memory pointed to by the address stored in the pointer. When the free() call is executed, it's trying to free an invalid address. It is also creating a ...
Short answer: yes!
Long answer: looking at the code of GetString()
// growable buffer for chars
string buffer = NULL;
// capacity of buffer
unsigned int capacity = 0;
// number of chars actually in buffer
unsigned int n = 0;
// character read or EOF
// iteratively get chars from ...
You have to keep in mind that a node is only accessible through a previous node when dealing with a singly-linked-list.
Also, since you've allocated memory separately for the string named word which is a member of struct words, you also have to free that separately "before" freeing the data associated with the pointer to the struct that contains this word ...
The function free is used to free memory that was allocated on the heap using a function like malloc or calloc.
You declared root as a global variable of type node. Global variables are stored on the data segment in memory not on the heap.
@SFri: I agree that it's hard to tell without seeing some code, but I'll tell you what i think can happen from the errors and the pseudocode.
The reason to set a recently freed pointer to null is to clean up and be tidy, but it should not affect how your function works. If you get a double free error by commenting out the line that sets the freed pointer to ...
You overlooked something. Here's a hint. What is the integer value of ' - 'a'? Or, subtract the ASCII value of 'a' from the value of an apostrophe?
I'm actually surprised that your code isn't generating an error. Oh, wait, it does, sort of. Try turning off the printing of misspelled words and run against a large text under valgrind --leak-checks=full. ...
This is a great lesson that a problem in one place is caused by a bug somewhere else. While the code in unload is mostly correct (there is a small flaw), the data that it's processing is flawed.
If you run the program under debug50, you would see that as unload runs, both cursor and cursor->next contain the same address. In fact, if you search through ...
I see a few problems in the code that are causing problems.
First, table is not initialized. That means that all the pointers in the array contain garbage data instead of NULL when the program starts.
Second, there's this:
while (fscanf(file, "%s", word) != EOF)
fscanf(file, "%s", word);
This is executing two sequential reads. ...
You cannot free the memory in load because it needs to be used throughout the entire program. It needs to wait until the program is done and then can be freed in unload.
It also appears that you have a misconception about how the memory is used, so I'll try to explain it in that context.
When memory is malloc'd to new_word in load, the memory is allocated, ...
You shouldn't free memory in load(). That's where unload() comes in. All of the memory allocated in the code should be freed in unload() only, except very specific cases (this was answered by a mentor in discord). Since you didn't post the rest of the code, I'm not sure if that's what you tried in unload() but let me know.
I believe the problem might be here:
for (int i = 0; i < N; i++)
//temp points to what table points to
temp = table[i];
//cursor points to what table points to
cursor = table[i];
//cursor goes to the next node
cursor = cursor->next;
} while (cursor != NULL);
Take a look at the ...
Hehe, put the word "zebra" in your small dictionary and see if it still works! ;-)
I'm assuming that hashtable represents words that start with 'z'. I'll wager that your small dictionary contains no words that start with z, or more precisely, no words that hash to 25.
Here's the problem. The free() function will release the memory pointed to by a ...
Without even looking at anything but this:
(if (start->child[i] != NULL))
I would ask if start actually exists at this point in the execution. I'll look at the code and edit my answer if/when I find something, while you keep looking.
[EDIT: ok, I looked at the code.]
So, my initial thought was right. Something is not there any longer.
One question. ...
I think I found the answer. The main problem was that I was setting the ppixelIndex variable out of the for loop and I was incrementing it way too much. So when the first iteration for the first row finishes, I wasn't resetting it so during the second iteration I was trying to reach the memory that wasn't allocated. I've also modified my code a little bit, ...
You have a tree structure (yes, a trie, but that's more a variation), and I don't see how you intend to free all nodes.
One misconception you seem to have is that freeing something makes the pointer NULL (your head would never turn NULL with that code!)
The easiest way to visit all nodes is to use recursion, or another kind of stack. That would require a ...
Does valgrind return the leak if it finds index.html or index.php? I would predict this indexes would leak memory only if neither of those files is "found". Generally speaking, one would not change anything about "main" for this assignment, so adding a free to main is not the right approach. Since the memory for pathCopy is allocated in the indexes function, ...
It appears that check50 is using a slightly older version of the CS50 Library than the CS50 IDE is currently using. In that version, all strings created using GetString are freed for you before the program finishes. So when your program hits the free(text), the program segfaults with a 'double free' error.
You don't see this in the IDE because the CS50 ...
Looks like a small memory leak in loookup. Maybe you're declaring a variable to store extension, but it's not allocated to include a null-terminator?
The indexes function looks fine. I think index is the victim of a memory leak, not the cause. Based on the valgrind results, it looks like a memory leak in load. If load is putting bytes into memory it doesn't ...
You can use your recursive function, but to do so, you need to pass the FILE* target variable by reference, rather than by value as you have done.
Recall Prof Malan's noswap.c example in Week 3. Or perhaps as an even simpler example, this:
void addOne(int num);
int num = 99;
printf("num before: %d\n", num);...
Per man free (3),
The free() function frees the memory space pointed to by ptr,
must have been returned by a previous call to malloc(), calloc() or
realloc(). Otherwise, or if free(ptr) has already been called before,
undefined behavior occurs. If ptr is NULL, no operation is performed.
First, arrayX[i] is ...
Pretty much. In very specific environments Application allocated memory may not be fully freed when the application exits. But it's safe to say that in any regular OS'es (including the one you're working in) all memory gets freed up when you terminate the application.
So in that sense:
Yeah the memory leak reported by Valgrind refers to something that's not ...