assert in malloc.c:383

Thomas Rauscher trauscher at loytec.com
Fri Jan 14 14:53:09 UTC 2005


> -----Original Message-----
> From: Joel Sherrill <joel at OARcorp.com> 
> [mailto:joel.sherrill at OARcorp.com] 
> Sent: Friday, January 14, 2005 3:03 PM
> To: Karel Gardas
> Cc: rtems-users at rtems.com
> Subject: Re: assert in malloc.c:383
> 
> Karel Gardas wrote:
> > Hello,
> > 
> > while trying to start my application, it asserts deeply in 
> RTEMS code in
> > cpukit/libcsupport/src/malloc.c:383 -- I'm talking here 
> about 4-6-branch.
> > 
> > The problematic code is a part of free function and it looks:
> > 
> >      380   status = rtems_region_return_segment( 
> RTEMS_Malloc_Heap, ptr );
> >      381   if ( status != RTEMS_SUCCESSFUL ) {
> >      382     errno = EINVAL;
> >      383     assert( 0 );
> >      384   }
> > 
> > my question is: how to prevent it? Is assert on this place 
> really needed,
> > especially when I consider that you set errno on this 
> place. What does
> > this assert mean?
> 
> This means you are freeing memory which was not allocated from
> the heap.  The address given to free MUST match that given to
> you by malloc.  So this could be a double free or a free of a bogus
> address.
> 

This can also happen if the heap control structures 
preceding and following the allocated memory area are violated. 

E.g.

#define BUF_MAX 64
#define MAX_BUF 68

p=malloc(BUF_MAX); 
...
much code in between to make this less obvious
...
memset(p,0,MAX_BUF);
...


--
Thomas Rauscher
LOYTEC electronics GmbH
Stolzenthalergasse 24/3
A-1080 Wien
Austria/Europe
trauscher at loytec.com
www.loytec.com
Phone: +43-1-4020805-15
FAX:   +43-1-4020805-99




More information about the users mailing list