assert in malloc.c:383

[Sergei Organov]

"Joel Sherrill <joel at OARcorp.com>" <joel.sherrill at OARcorp.com> writes:
> 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.?

Panic, obviously, with printing as a customizable part of the panic.
What's a reason to return an error to an application if unrecoverable
error has happened? Allow application to ignore the error (or just to
forget to check) and continue execution in a hope that the error won't
affect behavior significantly? Too dangerous, I'm afraid.

> 
> 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.

Moving to the point where nuclear missile is mistakenly launched due to
a horrible error in the application?!

> This isn't a horrible error with RTEMS but very easily could be one in
> the application.

Yes, it's a horrible error in the application, not in RTEMS. That
doesn't mean RTEMS should keep silence though. Setting errno in this
particular case is useless (did anybody ever check errno after a call to
free()?!). What's a reason not to report the error condition as loudly
as possible?

Overall, panic is the only reasonable option in this case, I think.

> 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.

Personally, I wouldn't continue until the problem is isolated and fixed.
Using unstable system as a vehicle for future porting is a waste of
time, IMHO.

-- 
Sergei.