Exceptions are raised in a compositing thread and not handled

[Alan Griffiths]

Allowing an exception to propagate out of the thread that throws it results in terminate being called (which can loses most of the diagnostic information[1]).

If the condition being reported is truly fatal an exception is the wrong way to report it.

If the condition is not fatal then the exception should be handled.

[1] ​ bug 1237332 "Fatal exceptions raised in a compositing thread have no usable stack trace"

[Daniel van Vugt (vanvugt)]

Interesting: "If the condition being reported is truly fatal an exception is the wrong way to report it."

I think an abort() is most useful for generating clean core files with the greatest chance of being debuggable.

I'm not aware of any uncaught exceptions in the compositing threads that are themselves logically recoverable. As such, this bug might be invalid and/or should not be fixed. The more you try to handle exceptions, the less readable the core file and stack trace becomes, hindering post-mortem analysis in Launchpad. A clean core file and stack trace provides the greatest chance of fully understanding the root cause and fixing the bug.

Remember it's not just the location of the error you need, but full stack trace and the ability to examine variable values, memory regions, as well as other threads running concurrently at the time of the crash. Only a core file gives you all this.

[Alan Griffiths (alan-griffiths)]

Why do think think this bug is invalid?

If we want a core it easier and more reliable to call abort() than to throw an exception and hope that nothing catches it (and that this results in a usable core).

[Daniel van Vugt (vanvugt)]

If we can agree that the offending throws in the compositor thread (like the DRM/KMS code) are never recoverable then yes they should be non-exception aborts. I feel there might however be edge cases where someone could argue: "Keep it as an exception because I might find a way to catch that error and recover". Not sure...

[kevin gunn (kgunn72)]

discussed potentially manually uploading a core file, then throwing excpetion on the mir stand up

[Cemil Azizoglu (cemil-azizoglu)]

Isn't this addressed by the fix to lp# 1237332, and the fatal-error branch that's already been checked in?

[Daniel van Vugt (vanvugt)]

Bug 1237332 isn't actually fixed any more. We regressed and it's open again as bug 1316867.

This bug 1285084 is a subset of that. I think Alan's defined it as the subset that he did fix with his branch. So bug 1285084 can probably be declared fixed. But bug 1316867 is not fixed.