GitLab

Weston heavily uses assert() to ensure sanity and core constraints are not violated. This is particularly notable in the DRM backend and repaint machinery, where any unexpected condition (e.g. output paint completion being called at an unexpected time) will take Weston down hard with an assert() failure.

On one hand, this is good because we can be pretty sure our compositor works like how we think it does, and we find out about problems pretty quickly. On the other hand, this is a terrible user experience: internal errors (which may be harmless!) result in Weston instantly crashing hard, with the only indication why in stderr.

This indication is not in itself always useful: telling us that output->repaint_status != REPAINT_IDLE is helpful, but printing the exact repaint status would be even more helpful. Even more helpful again would be dumping as much output as possible from the core timeline (#142 (closed)) and backend (#133 (closed)).

Most of the time these asserts don't catch memory-safety errors (e.g. use-after-free, type mismatch), but impossible internal states. Therefore we can assume that inspecting memory is mostly safe to do, and that the compositor isn't in a death spiral.

I suggest we:

• switch uses of assert() to new Weston-specific assert macros; the kernel uses BUG_ON() for 'something bad has happened and I'm going to crash immediately', and WARN_ON() for 'something bad happened but I think I can recover', which might be something to consider
• where possible, use operator-specific macros from ZUC; this lets us print something like `error: expected output->repaint_status to be 0 but it was 3', which makes bug reports far more useful
• dump this information not just to stderr, but to the Weston log and any clients streaming the Weston log through the debug protocol (flushing those FDs so it gets out before we die)
• at the end of this, still throw SIGABRT or similar so core dumps are generated
• include a link to our bug-reporting guide as well as our bug-report form