[Mono-dev] Fwd: [eglib] Warning: assertion function returning

[Alex J Lennon]

On 30/10/2014 18:57, Rodrigo Kumpera wrote:
> Forgot to CC dev
>
> ---------- Forwarded message ----------
> From: *Rodrigo Kumpera* <kumpera at gmail.com <mailto:kumpera at gmail.com>>
> Date: Thu, Oct 30, 2014 at 1:57 PM
> Subject: Re: [Mono-dev] [eglib] Warning: assertion function returning
> To: Alex J Lennon <ajlennon at dynamicdevices.co.uk
> <mailto:ajlennon at dynamicdevices.co.uk>>
>
>
>
>
> On Thu, Oct 30, 2014 at 12:34 PM, Alex J Lennon
> <ajlennon at dynamicdevices.co.uk <mailto:ajlennon at dynamicdevices.co.uk>>
> wrote:
>
>     Hi Rodrigo,
>
>     On 30/10/2014 17:28, Rodrigo Kumpera wrote:
>>     Since the noreturn behavior is not verifiable by the compiler
>>     (it's part of the API contract) we can a hack to silence the warning.
>>
>
>     If that's what's wanted that's fine by me of course. Easily done.
>
>     But I don't understand: Surely the fact the compiler is
>     complaining shows that it does know that the function is
>     returning, when it has been told via the attributing that the
>     function should not?
>
>     As a test, if I add a while(1); at the bottom of the function then
>     the complaint goes away as the compiler knows that the return is
>     unreachable.
>
>     I am guessing I am misunderstanding your point?
>
>     More importantly, should the assertion handler return or not... ?
>
>
> The problem is that the abort happens through the logging callback and
> that can't be verified by the compiler.
>
> Any well behaved implementation must make sure it does not return. I
> think adding a while (1); at the end is a good enough solution.
> We want the noreturn semantics there.
>

OK thanks. I agree I tend to think an assertion handler shouldn't
continue execution (if things have blown up to that extent then it's
perhaps better not to try to soldier on...)

I am sort of wondering what that means in real world production systems
though. e.g. Something unexpected happens, Mono outputs an assertion and
hangs with the CPU full on?

That would be less than ideal for the type of use cases I have, with an
black box embedded system possibly running on batteries.

Most simplistic system watchdog / error condition handling probably just
checks for the existence of the process, restarting the process or the
hardware on error, so Mono getting locked into a while(1); look wouldn't
be caught I imagine?

Wouldn't it be better for the process to log an error and exit in some
manner when the assertion handler is called?

(Just some thoughts...)

Cheers, Alex

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20141030/872e40d6/attachment.html>