This is a quality-of-life bug report to make it easier to spot if a bug report is about an assertion failed error (the alias will be shown in the Blocks field). Asserts are predicates that are expected to be true, but are only checked in debug builds. While they are disregarded, and thus cause no crash in release builds, they usually mean something went really wrong during execution, and should be taken seriously. Some information: https://en.wikipedia.org/wiki/Assertion_(software_development)
Aron: are you sure tdf#104920 should still be related to this one? Indeed, it seems assert concerned another tracker (tdf#105077)
Julien, you're right, bug 104920 doesn't cause an assertion error anymore. I'm removing the "dependency".
Let's remove the non-assertions. Dávid, a good principle when evaluating if a crashing bug belongs here is: - it only happens with a build with debug symbols, - the backtrace or the crash message mentions: assertion failed.
In case of regressions reproducible in Linux the daily dbgutil bibisect repos [1] could be used to bibisect a regression to the day. Some considerations: - if only the assert was introduced then, the result isn't helpful, - the offending code might be in a completely different place (the assert should give some hints in itself). [1] https://wiki.documentfoundation.org/QA/Bibisect/Linux