assert in malloc.c:383

Joel Sherrill <> joel.sherrill at
Fri Jan 14 15:23:14 UTC 2005

Karel Gardas wrote:
> Hello Bogdan,
> there is small misunderstanding going here. When I asked if the assert(0)
> in free is really needed, I meant something like `is this situation really
> that critical that we should assert because of invalid invariant here'?
> The reason is that sometime I found my own code to be too restrictive and
> so some asserts might be removed during the later development phases,
> hence I asked if this assert is not just relict from the history which
> might be removed.

This discussion comes up periodically.  What do you do when the user
does something really bad or the system gets into a weird state?
Do you shutdown, print a message, return an error, etc.?

I suppose that since this is in the malloc family and I already lean 
toward some type of dynamic control over dynamic heap checking and
statistics, it would be reasonably OK to not assert and just keep 
moving.  This isn't a horrible error with RTEMS but very easily could
be one in the application.

But this is still indicative of a programming error in the application
which could be a hint at a very serious problem.  I would try to
find it but you could take out that line for now and just print
something so you can continue on with the porting.  You have the source.


> Thanks,
> Karel
> On Fri, 14 Jan 2005, Bogdan Vacaliuc wrote:
>>>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
>>In regards to your question on whether assert() is really needed, please
>>remember that assert() is typically (always!) a conditional macro, whose
>>code is eliminated by the definition of _NDEBUG.  Its operation is generally
>>a system halt with diagnostic output to enable you to identify the problem
>>Code written with assert() should not *rely* on assert() as the error
>>handling method; it is not that.  It is a *debugging* tool.
>>Best Regards,
> --
> Karel Gardas                  kgardas at
> ObjectSecurity Ltd. 

Joel Sherrill, Ph.D.             Director of Research & Development
joel at                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

More information about the users mailing list