Re: *** glibc detected *** ./a.out: double free or corruption



On Tue, 11 Dec 2007 23:56:17 +0100, ramif <ramif_47@xxxxxxxxxxx>
wrote:

Hi,


Sometimes i have (strange) problems when freeing the memory of certain
"pages"


here is the definition of page...

struct pageType //data stucture for page
{
int pageNo; //stores the page number (unique)

char *data; //holds data from a text file
struct pageType *next; //points to the next page
struct pageType *previous; //points to the previous page
};


and here there is that of buffer...

struct bufferType //data structure for buffer -- Linked Queue
{
struct pageType *front; //points to the front page of queue
struct pageType *end; //points to the last page
struct pageType *current; //points to the current page
};


The idea is basically, a buffer containing a certain amount of pages.


But the problem is when I free a page's data. When i free the page's
data, 9 times of all cases it works... but sometimes the compiler (or
rather the OS) displays the following error: *** glibc detected ***
./a.out: double free or corruption (+ other data about stack ...)


here is a piece of code of the function that is freeing a page:


//deletes the first inputted page of the queue...
void removeFPage(bufferStruct **buffer)
{
if ( ((*buffer)->front->data) != NULL ) /*************** Here is
where the error is OCCURING!!
free( ((*buffer)->front->data) );

The test is not strictly necessary since you are allowed to pass NULL
to free.


free( ((*buffer)->front) );
((*buffer)->front) = NULL;
}



My QUESTION is, What am i doing wrong in the above function???

If this is really the entire function, your error lies somewhere else.


Everthing seems to be okay. I literally spent hours trying to figure
out where is the problem...

There are two frequent causes of this problem:

1 - You modified the value returned by malloc and are trying
to free the modified value instead of the returned value. Calling
free with anything other than the value returned by m/c/realloc or
NULL invokes undefined behavior.

2 - You accessed memory beyond the end (or before the
beginning) of the area you requested, which also invokes undefined
behavior. Many implementations store critical information in either
(or both) of these places and get somewhat confused when you break the
rules.

One debugging technique would be to print out each address as it is
returned from malloc and again when it is received by removeFPage. If
the address that experiences the error is the same as one returned by
malloc that has not been freed previously, then cause 2 is the likely
culprit.


Remove del for email
.



Relevant Pages

  • Re: Relation between free() and remove_vm_struct()
    ... first of all, glibc malloc doesn't always use mmap for it's allocations, ... (>= 128Kb uses mmap, smaller uses brk(). ... glibc delays freeing of some memory area) ...
    (Linux-Kernel)
  • Relation between free() and remove_vm_struct()
    ... In an application I am freeing some memory address, ... malloc. ... Please read the FAQ at http://www.tux.org/lkml/ ...
    (Linux-Kernel)
  • Re: Do memory allocations need to be freeed every time?
    ... program like this as freeing doesnâ??t bring in any change w.r.t memory ... space will it become a memleak some where down the line if it is ... To avoid memory leaks, for each and every time you call malloc(), you ...
    (comp.lang.c)
  • Re: Do memory allocations need to be freeed every time?
    ... program like this as freeing doesn’t bring in any change w.r.t memory ... space will it become a memleak some where down the line if it is ... To avoid memory leaks, for each and every time you call malloc(), you ...
    (comp.lang.c)
  • Re: C99 VLAs (was Re: Stack or Heap)
    ... If a VLA exceeds available memory, it invokes undefined behavior. ... other than the implicit release of the memory, ... it is very likely that for local allocations specialized versions of malloc() will provide some benefit. ...
    (comp.lang.c)