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