"memory clobbered before allocated block"...? 
Author Message
 "memory clobbered before allocated block"...?

Greetings.

I have a program that among other things utilizes a large array of structs,
which is frequently accessed throughout the program. However, when I try to
free() or realloc() that array (in order to resize it), it says what I typed
in the title...For now, I'm left with a known, substantial even though
infrequent memory leak.
I've run the program under gdb, but found nothing of real value there,
either before the "allocated block" nor in the structs in the array I've
looked into. I've also searched the 'net for some info, but all I could find
was some pretty vague reference to "char subscripting" whatever that means.
I've also looked at the calloc(), memset() and malloc() calls that are used
with this array and some of the structs in it. Still no luck. The structs in
the array contain pointers (to strings, functions and other structs) as
well...
How can I find the source of this anomaly? What's the best method here?

Since the program is over 100 kloc and this array used throughout it, I'm
afraid I can't show any really good example here.

TIA,
   Fredrik



Sun, 23 Mar 2003 03:00:00 GMT  
 "memory clobbered before allocated block"...?
Fredrik,

"Fredrik L?nnergren" schrieb:

Quote:
> Greetings.

> I have a program that among other things utilizes a large array of structs,
> which is frequently accessed throughout the program. However, when I try to
> free() or realloc() that array (in order to resize it), it says what I typed
> in the title...For now, I'm left with a known, substantial even though
> infrequent memory leak.
> I've run the program under gdb, but found nothing of real value there,
> either before the "allocated block" nor in the structs in the array I've
> looked into. I've also searched the 'net for some info, but all I could find
> was some pretty vague reference to "char subscripting" whatever that means.
> I've also looked at the calloc(), memset() and malloc() calls that are used
> with this array and some of the structs in it. Still no luck. The structs in
> the array contain pointers (to strings, functions and other structs) as
> well...
> How can I find the source of this anomaly? What's the best method here?

> Since the program is over 100 kloc and this array used throughout it, I'm
> afraid I can't show any really good example here.

> TIA,
>    Fredrik

just a thought - can it be that you are malloc()ing a zero size array somewhere?
freeing it later would cause exactly the problem you describe.

consider

void foo()
{
    char *cPtr;
    unsigned aSize=get_how_many_bytes_needed();
    cPtr=malloc(aSize);
    free(cPtr);

Quote:
}

the free() will fail (most likely crash) if get_how_many_bytes_needed() returns
0
HTH Robert

- Show quoted text -

Quote:
}



Sun, 23 Mar 2003 03:00:00 GMT  
 "memory clobbered before allocated block"...?

Quote:

>Fredrik,

*snip*
>just a thought - can it be that you are malloc()ing a zero size array
somewhere?
>freeing it later would cause exactly the problem you describe.

>consider

>void foo()
>{
>    char *cPtr;
>    unsigned aSize=get_how_many_bytes_needed();
>    cPtr=malloc(aSize);
>    free(cPtr);
>}
>the free() will fail (most likely crash) if get_how_many_bytes_needed()
returns
>0
>HTH Robert

Hmm...it's possible, I'm not the only one coding on that...
But in the occasions when this happens the array is always allocated for and
populated by about 12000 elements. Could it be that one of the structs in a
struct in the array has been 0-malloc()ed? Is the behavior you describe
recursive into "members" so to speak?

TIA,
   Fredrik



Sun, 23 Mar 2003 03:00:00 GMT  
 "memory clobbered before allocated block"...?

Quote:
>just a thought - can it be that you are malloc()ing a zero size array somewhere?
>freeing it later would cause exactly the problem you describe.

>consider

>void foo()
>{
>    char *cPtr;
>    unsigned aSize=get_how_many_bytes_needed();
>    cPtr=malloc(aSize);
>    free(cPtr);
>}
>the free() will fail (most likely crash) if get_how_many_bytes_needed() returns
>0
>HTH Robert

It doesn't help because it's pure bullshit!

    If the size of the space requested is zero, the behavior is
    implementation-defined; the value returned shall be either a null
    pointer or a unique pointer.
...
    The free function causes the space pointed to by ptr to be
    deallocated, that is, made available for further allocation.  If ptr
    is a null pointer, no action occurs.  Otherwise, if the argument does
    not match a pointer earlier returned by the calloc, malloc, or
    realloc function, or if the space has been deallocated by a call to
    free or realloc , the behavior is undefined.

So free(malloc(0)) has well defined behaviour, regardless of what
malloc(0) returns.

Dan
--
Dan Pop
CERN, IT Division

Mail:  CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland



Sun, 23 Mar 2003 03:00:00 GMT  
 "memory clobbered before allocated block"...?

)Greetings.
)
)I have a program that among other things utilizes a large array of structs,
)which is frequently accessed throughout the program. However, when I try to
)free() or realloc() that array (in order to resize it), it says what I typed
)in the title...For now, I'm left with a known, substantial even though
)infrequent memory leak.

If you are doing exactly what you said, then it is an illegal act.

        #include <stdlib.h>

        #define SOME_SIZE       27      /* or something */

        typedef struct {
                /* stuff */
        } Some_t;

        Some_t  MyArray[SOME_SIZE];
        Some_t  *MyPointer;

        ...

        MyPointer = realloc(MyArray,NewSize);

is *illegal*.

)I've run the program under gdb, but found nothing of real value there,
)either before the "allocated block" nor in the structs in the array I've
)looked into. I've also searched the 'net for some info, but all I could find
)was some pretty vague reference to "char subscripting" whatever that means.
)I've also looked at the calloc(), memset() and malloc() calls that are used
)with this array and some of the structs in it. Still no luck. The structs in
)the array contain pointers (to strings, functions and other structs) as
)well...
)How can I find the source of this anomaly? What's the best method here?

Well, first make sure that whatever you pass to realloc() and free()
came from malloc() or calloc(), and not somewhere else.

If this is the case, then it appears that you are accessing your array
with a negative subscript, or otherwise using invalid addresses in your
program.

)Since the program is over 100 kloc and this array used throughout it, I'm
)afraid I can't show any really good example here.
)
)TIA,
)   Fredrik
)
)

--
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I can explain it for you, but I can't understand it for you.
I don't speak for Alcatel      <- They make me say that.



Sun, 23 Mar 2003 03:00:00 GMT  
 "memory clobbered before allocated block"...?


[snip realloc() problem]

)just a thought - can it be that you are malloc()ing a zero size array somewhere?
)freeing it later would cause exactly the problem you describe.

This is not permitted by the Standard. If malloc() succeeds, then it
must pass back a pointer (non-NULL) which can be used by free(). If it
fails, it must pass back NULL.

)consider
)
)void foo()
){
)    char *cPtr;
)    unsigned aSize=get_how_many_bytes_needed();
)    cPtr=malloc(aSize);
)    free(cPtr);
)}
)the free() will fail (most likely crash) if get_how_many_bytes_needed() returns

The Standard forbids this.
--
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I can explain it for you, but I can't understand it for you.
I don't speak for Alcatel      <- They make me say that.



Sun, 23 Mar 2003 03:00:00 GMT  
 "memory clobbered before allocated block"...?

Dan Pop schrieb:

Quote:

> >just a thought - can it be that you are malloc()ing a zero size array somewhere?
> >freeing it later would cause exactly the problem you describe.

> >consider

> >void foo()
> >{
> >    char *cPtr;
> >    unsigned aSize=get_how_many_bytes_needed();
> >    cPtr=malloc(aSize);

Of course, the fault in my prog was:
*cPtr=some_character;

Quote:

> >    free(cPtr);
> >}
> >the free() will fail (most likely crash) if get_how_many_bytes_needed() returns
> >0
> >HTH Robert

> It doesn't help because it's pure bullshit!

>     If the size of the space requested is zero, the behavior is
>     implementation-defined; the value returned shall be either a null
>     pointer or a unique pointer.
> ...
>     The free function causes the space pointed to by ptr to be
>     deallocated, that is, made available for further allocation.  If ptr
>     is a null pointer, no action occurs.  Otherwise, if the argument does
>     not match a pointer earlier returned by the calloc, malloc, or
>     realloc function, or if the space has been deallocated by a call to
>     free or realloc , the behavior is undefined.

> So free(malloc(0)) has well defined behaviour, regardless of what
> malloc(0) returns.

> Dan
> --
> Dan Pop
> CERN, IT Division

> Mail:  CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland

Dan,
Oops - you are right, of course, should have switched on my brain and read my own
failing code before posting.

My problem was of course caused by assigning something to the location pointed to by
the returned pointer.
Shame on me and thanks for correcting me.
<off topic note>
Anyway, I think it is easy to stumble into that trap. Some API calls return the
amount of bufferspace they require for the structs where they fill in the requested
information, then you have to malloc that amount and to set the size member of the
first struct to sizeof(this struct) before you call the API again and alas, if the
required size returned was zero -- bang, either immidiately or later, when you free()

<end off topic note>
Regards - Robert



Mon, 24 Mar 2003 03:00:00 GMT  
 "memory clobbered before allocated block"...?
Frederik,

"Fredrik L?nnergren" schrieb:

Quote:

> >Fredrik,

> *snip*
> >just a thought - can it be that you are malloc()ing a zero size array
> somewhere?

correction: and someting assigned to it..

Quote:

> >freeing it later would cause exactly the problem you describe.

> >consider

> >void foo()
> >{
> >    char *cPtr;
> >    unsigned aSize=get_how_many_bytes_needed();
> >    cPtr=malloc(aSize);

assert(cPtr);
*cPtr=something; /*cPtr is OK, but....*/

Quote:

> >    free(cPtr);
> >}
> >the free() will fail (most likely crash) if get_how_many_bytes_needed()
> returns
> >0
> >HTH Robert

> Hmm...it's possible, I'm not the only one coding on that...
> But in the occasions when this happens the array is always allocated for and
> populated by about 12000 elements. Could it be that one of the structs in a
> struct in the array has been 0-malloc()ed? Is the behavior you describe
> recursive into "members" so to speak?

> TIA,
>    Fredrik

Sorry, my posting was bu..hit as Dan Pop pointed out :(, pls see my correction
above.
To your question: yes, if one of the struct has a pointer to something in it and
this pointer is malloc()ed and abused in the abovementioned way.
Regards Robert


Mon, 24 Mar 2003 03:00:00 GMT  
 "memory clobbered before allocated block"...?

Quote:

>Well, first make sure that whatever you pass to realloc() and free()
>came from malloc() or calloc(), and not somewhere else.

>If this is the case, then it appears that you are accessing your array
>with a negative subscript, or otherwise using invalid addresses in your
>program.

Bneh...
Was afraid of that answer; was hoping I could weasel out of going over all
that code, somehow... Oh well, thanks for the answers, everyone.

/Fredrik



Mon, 24 Mar 2003 03:00:00 GMT  
 "memory clobbered before allocated block"...?

Quote:

>Dan Pop schrieb:


>> >just a thought - can it be that you are malloc()ing a zero size array somewhere?
>> >freeing it later would cause exactly the problem you describe.

>> >consider

>> >void foo()
>> >{
>> >    char *cPtr;
>> >    unsigned aSize=get_how_many_bytes_needed();
>> >    cPtr=malloc(aSize);

>Of course, the fault in my prog was:
>*cPtr=some_character;

That's because you lied to malloc :-)  You said that you need 0 bytes,
then you used 1 byte!

Dan
--
Dan Pop
CERN, IT Division

Mail:  CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland



Mon, 24 Mar 2003 03:00:00 GMT  
 "memory clobbered before allocated block"...?

Dan Pop schrieb:

Quote:

> >Dan Pop schrieb:


> >> >just a thought - can it be that you are malloc()ing a zero size array somewhere?
> >> >freeing it later would cause exactly the problem you describe.

> >> >consider

> >> >void foo()
> >> >{
> >> >    char *cPtr;
> >> >    unsigned aSize=get_how_many_bytes_needed();
> >> >    cPtr=malloc(aSize);

> >Of course, the fault in my prog was:
> >*cPtr=some_character;

> That's because you lied to malloc :-)  You said that you need 0 bytes,
> then you used 1 byte!

> Dan
> --
> Dan Pop
> CERN, IT Division

> Mail:  CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland

Perfectly true, Dan
I was fooled by an
<off topic>
!"$& OS"  - i am sure you know that sequence: call an API function, it returns how much
space you have to allocate and then you have to put something into the first element of
the allocated array and call the API again. Of course you are checking the pointer
returned by malloc() but (I, not you) forget to check the requested size. It is not _so_
obvious, is'nt it :(
<end off topic>
I just thought, the OP might have that kind of problem
thanks again for replying
Robert


Mon, 24 Mar 2003 03:00:00 GMT  
 "memory clobbered before allocated block"...?


Quote:
> just a thought - can it be that you are malloc()ing a zero size array somewhere?
> freeing it later would cause exactly the problem you describe.

> consider

> void foo()
> {
>     char *cPtr;
>     unsigned aSize=get_how_many_bytes_needed();
>     cPtr=malloc(aSize);
>     free(cPtr);
> }
> the free() will fail (most likely crash) if get_how_many_bytes_needed()
> returns 0

Not if it's an ANSI C implementation of `free` it won't.

--
Chris "electric hedgehog" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html



Mon, 24 Mar 2003 03:00:00 GMT  
 "memory clobbered before allocated block"...?
On Thu, 05 Oct 2000 09:28:13 +0100, Robert Stankowic
...

Quote:
>> >    cPtr=malloc(aSize);

>assert(cPtr);

There are a few things wrong with this.
In C89, cPtr is not a valid argument for assert, which takes an
int argument.  (In C99, any scalar argument is okay).  If you
want to use assert to check that cPtr is not a null pointer, do
that explicitly, with assert(cPtr != NULL) or assert(cPtr != 0).

But assert is a poor choice to use for run-time error checking.
If NDEBUG is not #defined with the correct value, the check won't
even appear in your code.  And if it does, reporting the source
location of the error and then aborting the program is rather
unfriendly to the end user.

--

Lucent Technologies Software Products Group



Mon, 24 Mar 2003 03:00:00 GMT  
 "memory clobbered before allocated block"...?

"Morris M. Keesan" schrieb:

Quote:
> On Thu, 05 Oct 2000 09:28:13 +0100, Robert Stankowic

> ...
> >> >    cPtr=malloc(aSize);

> >assert(cPtr);

> There are a few things wrong with this.
> In C89, cPtr is not a valid argument for assert, which takes an
> int argument.  (In C99, any scalar argument is okay).  If you
> want to use assert to check that cPtr is not a null pointer, do
> that explicitly, with assert(cPtr != NULL) or assert(cPtr != 0).

> But assert is a poor choice to use for run-time error checking.
> If NDEBUG is not #defined with the correct value, the check won't
> even appear in your code.  And if it does, reporting the source
> location of the error and then aborting the program is rather
> unfriendly to the end user.

> --

> Lucent Technologies Software Products Group

True, Morris, thank you
Robert


Tue, 25 Mar 2003 14:20:13 GMT  
 
 [ 14 post ] 

 Relevant Pages 

1. char *ptr="Is memory allocated here?"

2. Error "free"-ing "malloc"-ed memory

3. Allocating a memory block that doesn't overlap physical memory

4. "No memory" while plenty of memory

5. Free a "2D dynamically allocated array"

6. Allocating "Space"

7. "Heap block" error

8. "Heap block" error

9. "duplicate insert block" message

10. UDP Win32 Socket: "recvfrom" completely blocks

11. "duplicate insert block" message

12. Allocating memory blocks

 

 
Powered by phpBB® Forum Software