Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 5 months ago.
Improve this question
So currently I am writing a XMLParser into a Tree and its working fine but the problem is its using too much Memmory and when I am trying to run it with a 4GB XML file it is not working due to lack of memmory.
So what im doing is going through first converting the XML File into a char* and then Parsing throught it and using malloc to allocate memmory for each Node structure.
When exactly am I supposed to Free() these nodes ? Am I even supposed to do that ? I just dont understand when exactly am I supposed to free stuff basically.
I am getting Valgrind errors
==3002== HEAP SUMMARY:
==3002== in use at exit: 8,995 bytes in 423 blocks
==3002== total heap usage: 427 allocs, 137 frees, 24,691 bytes allocated
==3002==
==3002== 19 bytes in 1 blocks are indirectly lost in loss record 1 of 8
==3002== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==3002== by 0x491460E: strdup (strdup.c:42)
==3002== by 0x109B9D: parse (main.c:223)
==3002== by 0x10A06B: main (main.c:333)
==3002==
==3002== 48 bytes in 1 blocks are indirectly lost in loss record 2 of 8
==3002== at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==3002== by 0x10934B: new_node (main.c:9)
==3002== by 0x10A054: main (main.c:332)
==3002==
==3002== 206 bytes in 32 blocks are definitely lost in loss record 3 of 8
==3002== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==3002== by 0x491460E: strdup (strdup.c:42)
==3002== by 0x1096E9: parse (main.c:108)
==3002== by 0x10A06B: main (main.c:333)
==3002==
==3002== 551 bytes in 101 blocks are indirectly lost in loss record 4 of 8
==3002== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==3002== by 0x491460E: strdup (strdup.c:42)
==3002== by 0x1096E9: parse (main.c:108)
==3002== by 0x10A06B: main (main.c:333)
==3002==
==3002== 608 bytes in 19 blocks are indirectly lost in loss record 5 of 8
==3002== at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==3002== by 0x109648: add_attribute (main.c:85)
==3002== by 0x109DC4: parse (main.c:275)
==3002== by 0x10A06B: main (main.c:333)
==3002==
==3002== 1,083 bytes in 134 blocks are indirectly lost in loss record 6 of 8
==3002== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==3002== by 0x491460E: strdup (strdup.c:42)
==3002== by 0x109D13: parse (main.c:255)
==3002== by 0x10A06B: main (main.c:333)
==3002==
==3002== 6,432 bytes in 134 blocks are indirectly lost in loss record 7 of 8
==3002== at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==3002== by 0x10934B: new_node (main.c:9)
==3002== by 0x109C3A: parse (main.c:238)
==3002== by 0x10A06B: main (main.c:333)
==3002==
==3002== 8,789 (48 direct, 8,741 indirect) bytes in 1 blocks are definitely lost in loss record 8 of 8
==3002== at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==3002== by 0x10934B: new_node (main.c:9)
==3002== by 0x109B7E: parse (main.c:221)
==3002== by 0x10A06B: main (main.c:333)
==3002==
==3002== LEAK SUMMARY:
==3002== definitely lost: 254 bytes in 33 blocks
==3002== indirectly lost: 8,741 bytes in 390 blocks
==3002== possibly lost: 0 bytes in 0 blocks
==3002== still reachable: 0 bytes in 0 blocks
==3002== suppressed: 0 bytes in 0 blocks
==3002==
==3002== For lists of detected and suppressed errors, rerun with: -s
My thought process was that If I free these nodes then the Tree is destroyed in the proccess. Or is it because I am allocating EXTRA stuff that is not needed?
TY
When exactly am I supposed to Free() these nodes ? Am I even supposed to do that ? I just dont understand when exactly am I supposed to free stuff basically. I am getting Valgrind errors
After using either malloc(), calloc() or realloc(), a pointer will be returned to you to some memory on the heap (assuming no error occurred).
You should free() the memory using the pointer returned from these functions once you no longer need the memory that was allocated.
Example:
struct node* new_node = malloc(sizeof(struct node));
if (new_node == NULL) {
// malloc() failed
}
// do stuff with new_node
free(new_node); // no longer need new_node
Related
I am currently working on cs50 pset5.
I have encountered a memory leak when I attempt to free all the memory I have located in the program.
The error seems to occur in my unload function, where it malloc for pointer cursor.
If anyone can provide me directions on how to approach this issue, please let me know.
I have also provided comments to my code to highlight what it is doing.
// Represents a node in a hash table
typedef struct node
{
char word[LENGTH + 1];
struct node *next;
}
node;
// Number of buckets in hash table
const unsigned int N = 50;
node *table[N] = {NULL};
// Unloads dictionary from memory, returning true if successful else false
bool unload(void)
{
// allocate memory for struct type `node` pointer
node *cursor = (node*)malloc(sizeof(node)); // MEMORY LEAK happens here !!!! :(
node *tmp = (node*)malloc(sizeof(node));
// if memory cannot be allocated successfully, return false
if (cursor == NULL || tmp == NULL)
{
return false;
}
// iterate the table for N'times (N = 50, for now)
for (int i = 0; i < N; i++)
{
// if the table has nothing inside the i'th bucket, return false
// this means, table has no linked list inside i'th bucket
if (table[i] == NULL)
{
continue;
}
else
{
// assign tmp pointer to the head node, and cursor to anything next to tmp
tmp = table[i];
cursor = tmp;
cursor = cursor->next;
// free memory for tmp pointer
free(tmp);
// continue traversing the linked list until cursor pointer points to NULL (end of the linked list)
while (cursor != NULL)
{
tmp = cursor;
cursor = cursor->next;
free(tmp);
}
}
}
// free memory for cursor
free(cursor);
return true;
}
The error I get, after running, help50 valgrind ./speller dictionaries/small texts/cat.txt.
==14685== Memcheck, a memory error detector
==14685== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==14685== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==14685== Command: ./speller dictionaries/small texts/cat.txt
==14685==
32
==14685== Invalid write of size 1
==14685== at 0x40121F: hash (dictionary.c:67)
==14685== by 0x401354: load (dictionary.c:99)
==14685== by 0x400A2B: main (speller.c:41)
==14685== Address 0x55cc88a is 2 bytes after a block of size 8 alloc'd
==14685== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14685== by 0x4011D5: hash (dictionary.c:61)
==14685== by 0x401354: load (dictionary.c:99)
==14685== by 0x400A2B: main (speller.c:41)
==14685==
==14685== Invalid read of size 1
==14685== at 0x40122C: hash (dictionary.c:68)
==14685== by 0x401354: load (dictionary.c:99)
==14685== by 0x400A2B: main (speller.c:41)
==14685== Address 0x55cc88a is 2 bytes after a block of size 8 alloc'd
==14685== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14685== by 0x4011D5: hash (dictionary.c:61)
==14685== by 0x401354: load (dictionary.c:99)
==14685== by 0x400A2B: main (speller.c:41)
==14685==
19
MISSPELLED WORDS
47
A
32
20
is
27
not
47
a
==14685== Invalid write of size 1
==14685== at 0x40121F: hash (dictionary.c:67)
==14685== by 0x401124: check (dictionary.c:32)
==14685== by 0x400D50: main (speller.c:114)
==14685== Address 0x55cdf9a is 2 bytes after a block of size 8 alloc'd
==14685== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14685== by 0x4011D5: hash (dictionary.c:61)
==14685== by 0x401124: check (dictionary.c:32)
==14685== by 0x400D50: main (speller.c:114)
==14685==
==14685== Invalid read of size 1
==14685== at 0x40122C: hash (dictionary.c:68)
==14685== by 0x401124: check (dictionary.c:32)
==14685== by 0x400D50: main (speller.c:114)
==14685== Address 0x55cdf9a is 2 bytes after a block of size 8 alloc'd
==14685== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14685== by 0x4011D5: hash (dictionary.c:61)
==14685== by 0x401124: check (dictionary.c:32)
==14685== by 0x400D50: main (speller.c:114)
==14685==
19
WORDS MISSPELLED: 4
WORDS IN DICTIONARY: 2
WORDS IN TEXT: 6
TIME IN load: 0.03
TIME IN check: 0.00
TIME IN size: 0.00
TIME IN unload: 0.00
TIME IN TOTAL: 0.03
==14685==
==14685== HEAP SUMMARY:
==14685== in use at exit: 1,000 bytes in 9 blocks
==14685== total heap usage: 23 allocs, 14 frees, 10,944 bytes allocated
==14685==
==14685== 56 bytes in 1 blocks are definitely lost in loss record 1 of 4
==14685== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14685== by 0x4013F1: unload (dictionary.c:128)
==14685== by 0x400ED0: main (speller.c:154)
==14685==
==14685== 56 bytes in 1 blocks are definitely lost in loss record 2 of 4
==14685== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14685== by 0x4013FF: unload (dictionary.c:129)
==14685== by 0x400ED0: main (speller.c:154)
==14685==
==14685== 336 bytes in 6 blocks are definitely lost in loss record 3 of 4
==14685== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14685== by 0x401131: check (dictionary.c:33)
==14685== by 0x400D50: main (speller.c:114)
==14685==
==14685== 552 bytes in 1 blocks are still reachable in loss record 4 of 4
==14685== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14685== by 0x5258E49: __fopen_internal (iofopen.c:65)
==14685== by 0x5258E49: fopen##GLIBC_2.2.5 (iofopen.c:89)
==14685== by 0x4012DE: load (dictionary.c:83)
==14685== by 0x400A2B: main (speller.c:41)
==14685==
==14685== LEAK SUMMARY:
==14685== definitely lost: 448 bytes in 8 blocks
==14685== indirectly lost: 0 bytes in 0 blocks
==14685== possibly lost: 0 bytes in 0 blocks
==14685== still reachable: 552 bytes in 1 blocks
==14685== suppressed: 0 bytes in 0 blocks
==14685==
==14685== For counts of detected and suppressed errors, rerun with: -v
==14685== ERROR SUMMARY: 15 errors from 7 contexts (suppressed: 0 from 0)
Asking for help...
==14685== 56 bytes in 1 blocks are definitely lost in loss record 1 of 4
==14685== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14685== by 0x4013F1: unload (dictionary.c:128)
==14685== by 0x400ED0: main (speller.c:154)
Looks like your program leaked 56 bytes of memory. Did you forget to free memory that you allocated via malloc? Take a closer look at line 128 of dictionary.c.
So why does memory leak happen?
A memory leak happens when a programmer creates a memory from heap but forgets to free it.
However, in my code, I have free'd both cursor and tmp pointer after it's used.
I do not know why I am encountering the error, although I am freeing it at the end of the function.
Yes, "MEMORY LEAK happens here !!!!" as you say.
You allocated two buffers, but later their pointers are overwritten by table[i] without being freed. This is memory leak.
To avoid memory leak, stop allocating unused buffers.
The part
// allocate memory for struct type `node` pointer
node *cursor = (node*)malloc(sizeof(node)); // MEMORY LEAK happens here !!!! :(
node *tmp = (node*)malloc(sizeof(node));
// if memory cannot be allocated successfully, return false
if (cursor == NULL || tmp == NULL)
{
return false;
}
should be just
// allocate memory for struct type `node` pointer
node *cursor;
node *tmp;
The memory for pointer is allocated on the stack.
Also the part
// free memory for cursor
free(cursor);
should be removed because the list is already freed and the memory for cursor will be automatically freed (from the stack) on returning from the function.
I have a multi-threaded application which uses joinable threads.
In order to create the threads (which are in total nthreads workers+1 additional thread) I use a regular call to pthread_create.
However, when I try to debug memory leaks, I get a x bytes in y blocks are possibly lost in loss record z of w error, caused by the pthread_create calls.
Here is the part of the code of the program relevant to the issue :
#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
#include <errno.h>
int main(){
int i=0;
int nthreads=8;
pthread_t tid_w[nthreads+1];
if( pthread_create(&tid_w[0], NULL, dispatcher, (void*) (size_t) i)<0){
perror("Creating dispatcher thread");
return -1;
}
for(i=1; i<nthreads+1; i++){
if( pthread_create(&tid_w[i], NULL, worker, (void*) (size_t) i)<0){
perror("Creating worker thread");
return -1;
}
}
// thread joining
for(i=0; i<nthreads+1; i++){
if( pthread_join(tid_w[i], NULL)<0){
perror("Joining thread");
return -1;
}
}
return 0;
}
This is the output of valgrind (3.11)
==14418==
==14418== HEAP SUMMARY:
==14418== in use at exit: 14,496 bytes in 21 blocks
==14418== total heap usage: 25 allocs, 4 frees, 15,724 bytes allocated
==14418==
==14418== 560 bytes in 1 blocks are possibly lost in loss record 12 of 14
==14418== at 0x4C2DB95: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14418== by 0x40134C4: allocate_dtv (dl-tls.c:322)
==14418== by 0x40134C4: _dl_allocate_tls (dl-tls.c:544)
==14418== by 0x4E400D2: allocate_stack (allocatestack.c:588)
==14418== by 0x4E400D2: pthread_create##GLIBC_2.2.5 (pthread_create.c:537)
==14418== by 0x4018AE: main (chatty.c:132)
==14418==
==14418== 4,480 bytes in 8 blocks are possibly lost in loss record 13 of 14
==14418== at 0x4C2DB95: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14418== by 0x40134C4: allocate_dtv (dl-tls.c:322)
==14418== by 0x40134C4: _dl_allocate_tls (dl-tls.c:544)
==14418== by 0x4E400D2: allocate_stack (allocatestack.c:588)
==14418== by 0x4E400D2: pthread_create##GLIBC_2.2.5 (pthread_create.c:537)
==14418== by 0x401909: main (chatty.c:138)
==14418==
==14418== LEAK SUMMARY:
==14418== definitely lost: 0 bytes in 0 blocks
==14418== indirectly lost: 0 bytes in 0 blocks
==14418== possibly lost: 5,040 bytes in 9 blocks
==14418== still reachable: 9,456 bytes in 12 blocks
==14418== suppressed: 0 bytes in 0 blocks
==14418== Reachable blocks (those to which a pointer was found) are not shown.
==14418== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==14418==
==14418== For counts of detected and suppressed errors, rerun with: -v
==14418== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Line numbers might not match because I have removed a few socket-related parts from the code.
I also have read a lot about pthread_create causing memory leaks but it seems like the issue presents itself when in use of detached threads, which is not my case.
Any idea on how to solve the issue?
I'm running valgrind and it's telling me that I need to free something and I'm not sure where I would do that. It specifically points to this line "toInsert->value = linkedlist->copy(element);
Where would I run free and on what data?
"
void linkedlist_append(LinkedList *linkedlist, void *element) {
ListNode *toInsert = (ListNode*)malloc(sizeof(ListNode));
toInsert->value = linkedlist->copy(element);
toInsert->next = NULL;
ListNode *last = linkedlist->head;
if (last==NULL)
linkedlist->head = toInsert;
else{
while(last-> next !=NULL){
last = last->next;
}
last->next = toInsert;
}
linkedlist->size++;
}
Output from Valgrind:
> ^C==30515==
==30515== HEAP SUMMARY:
==30515== in use at exit: 287 bytes in 47 blocks
==30515== total heap usage: 95 allocs, 1,038 frees, 2,159 bytes allocated
==30515==
==30515== 247 bytes in 46 blocks are definitely lost in loss record 2 of 2
==30515== at 0x4C28C20: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==30515== by 0x4011AC: string_copy (string_fns.c:27)
==30515== by 0x4012CE: linkedlist_append (linkedlist.c:87)
==30515== by 0x4017BD: add_file (tester.c:194)
==30515== by 0x400FE1: main (tester.c:136)
==30515==
==30515== LEAK SUMMARY:
==30515== definitely lost: 247 bytes in 46 blocks
==30515== indirectly lost: 0 bytes in 0 blocks
==30515== possibly lost: 0 bytes in 0 blocks
==30515== still reachable: 40 bytes in 1 blocks
==30515== suppressed: 0 bytes in 0 blocks
==30515== Reachable blocks (those to which a pointer was found) are not shown.
==30515== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==30515==
==30515== For counts of detected and suppressed errors, rerun with: -v
==30515== ERROR SUMMARY: 2200 errors from 10 contexts (suppressed: 0 from 0)
Valgrind is pointing you to the location of a malloc that is never freed. Before you terminate your program, you will need to iterate through the list an free all its elements.
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[]){
char *str = malloc(sizeof(char)*5);
str = strcpy(str, "test");
printf("%s\n", str);
free(str);
return 0;
}
When I use Valgrind on my Mac (OS X, 10.9.5) I get the following message:
==77215== HEAP SUMMARY:
==77215== in use at exit: 29,211 bytes in 374 blocks
==77215== total heap usage: 451 allocs, 77 frees, 35,160 bytes allocated
==77215==
==77215== 4,096 bytes in 1 blocks are still reachable in loss record 76 of 76
==77215== at 0x66CB: malloc (in /usr/local/Cellar/valgrind/3.10.0/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==77215== by 0x182855: __smakebuf (in /usr/lib/system/libsystem_c.dylib)
==77215== by 0x197217: __swsetup (in /usr/lib/system/libsystem_c.dylib)
==77215== by 0x1B0158: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==77215== by 0x1B06AF: __xvprintf (in /usr/lib/system/libsystem_c.dylib)
==77215== by 0x187B29: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==77215== by 0x18596F: printf (in /usr/lib/system/libsystem_c.dylib)
==77215== by 0x100000F2B: main (test.c:8)
==77215==
==77215== LEAK SUMMARY:
==77215== definitely lost: 0 bytes in 0 blocks
==77215== indirectly lost: 0 bytes in 0 blocks
==77215== possibly lost: 0 bytes in 0 blocks
==77215== still reachable: 4,096 bytes in 1 blocks
==77215== suppressed: 25,115 bytes in 373 blocks
==77215==
==77215== For counts of detected and suppressed errors, rerun with: -v
==77215== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 15)
Does printf allocate memory by itself? If I remove the printf I only get the following:
==77237== HEAP SUMMARY:
==77237== in use at exit: 25,115 bytes in 373 blocks
==77237== total heap usage: 450 allocs, 77 frees, 31,064 bytes allocated
==77237==
==77237== LEAK SUMMARY:
==77237== definitely lost: 0 bytes in 0 blocks
==77237== indirectly lost: 0 bytes in 0 blocks
==77237== possibly lost: 0 bytes in 0 blocks
==77237== still reachable: 0 bytes in 0 blocks
==77237== suppressed: 25,115 bytes in 373 blocks
==77237==
==77237== For counts of detected and suppressed errors, rerun with: -v
==77237== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 15)
Where does the 373 blocks come from?
Until the Valgrind team prioritizes OS X, you can safely assume that it will not give correct results on Apple systems running OS X versions newer than 10.7.
On my Mavericks (10.9.5) machine, I still get the following warning from Valgrind (3.9.0)
WARNING: Support on MacOS 10.8/10.9 is experimental and mostly broken.
WARNING: Expect incorrect results, assertions and crashes.
WARNING: In particular, Memcheck on 32-bit programs will fail to
WARNING: detect any errors associated with heap-allocated data.
For what it's worth, Valgrind 3.10.0 shows no leaks on my Debian Jessie installation.
It isn't telling you that there is a leak:
==77215== LEAK SUMMARY:
==77215== definitely lost: 0 bytes in 0 blocks
==77215== indirectly lost: 0 bytes in 0 blocks
==77215== possibly lost: 0 bytes in 0 blocks
==77215== still reachable: 4,096 bytes in 1 blocks
==77215== suppressed: 25,115 bytes in 373 blocks
it's telling you that there is a block which is still reachable; whether or not there is a leak is dependent on your definition of 'leak'. What it does mean is that there is a pointer to the block somewhere.
Refer to Still Reachable Leak detected by Valgrind for more information.
I am trying to allocate a memory to node in linked list using malloc function. However, I am getting segmentation fault on malloc call. I am unable to understand report generated by valgrind.
==28861== total heap usage: 76 allocs, 73 frees, 14,544 bytes allocated
==28861==
==28861== 48 bytes in 1 blocks are still reachable in loss record 1 of 3
==28861== at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==28861== by 0x4027A2: create_server_entry_into_connection_list (all.c:734)
==28861== by 0x401BF8: server_call (all.c:410)
==28861== by 0x40103F: main (all.c:108)
==28861==
==28861== 568 bytes in 1 blocks are still reachable in loss record 2 of 3
==28861== at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==28861== by 0x3E3C260309: __fopen_internal (in /lib64/libc-2.5.so)
==28861== by 0x4012E2: myip (all.c:174)
==28861== by 0x400FE7: main (all.c:101)
==28861==
==28861== 1,024 bytes in 1 blocks are still reachable in loss record 3 of 3
==28861== at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==28861== by 0x4027B3: create_server_entry_into_connection_list (all.c:736)
==28861== by 0x401BF8: server_call (all.c:410)
==28861== by 0x40103F: main (all.c:108)
==28861==
==28861== LEAK SUMMARY:
==28861== definitely lost: 0 bytes in 0 blocks
==28861== indirectly lost: 0 bytes in 0 blocks
==28861== possibly lost: 0 bytes in 0 blocks
==28861== still reachable: 1,640 bytes in 3 blocks
==28861== suppressed: 0 bytes in 0 blocks
==28861==
==28861== For counts of detected and suppressed errors, rerun with: -v
==28861== Use --track-origins=yes to see where uninitialised values come from
==28861== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 4 from 4)
Segmentation fault
Could anyone explain what can be reason behind such error.
The reason? There are lots of possible reasons.
Try using errno.h it may be able to determine some problems.
strerror(errno) then returns the error as a string instead of a number.
Start with the first error from the debug console.. look at it carefully.
total heap usage: 76 allocs, 73 frees, 14,544 bytes allocated
...I think you should restructure your code. This time pay more attention and test the program oftenly. 76 allocs, 73 frees. Only 14,544 bytes allocated?
Use tests such as printf("p1 : %p\np2 : %p", pointer1, pointer2); to investiage memory address. valgrind sometimes behaves weird. It is dependable.
If your code is too large.. maybe use hastebin.com to provide a common view of your code for us.
Don't typecast the pointer.
Usually still reachable memory points towards the memory allocated to a global pointer and not being freed upon program completion. This does not always point to a memory leak. You can read more about that here.