assert in malloc.c:383

[Joel Sherrill <joel@OARcorp.com>]

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.

--joel

> 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
>>quickly.
>>
>>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,
>>
>>-bogdan
>>
>>
>>
> 
> 
> --
> Karel Gardas                  kgardas at objectsecurity.com
> ObjectSecurity Ltd.           http://www.objectsecurity.com
> 


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