When a BLI_Assert is triggered in a debug build of blender (ubuntu eoan 64 bit, gcc 9.3.0) the program aborts with a SEGFAULT instead of an ABORT. Is this by design? Or is there something wrong with my setup? If it is by design, is there a standard way of getting BLI_assert to call abort() instead of segfaulting with some cmake flag or anything? You can’t continue execution after a segfault.
Sorry if this is common knowledge. I’m new to the Blender community and I don’t really know my way around the documentation yet.
Yes that is expected. The part where the assert is triggered, cannot work properly if the pre-conditions aren’t met. So sooner or later you’ll get undefined behaviour, better to stop the app early.
There is a Cmake flag, WITH_ASSERT_ABORT which is true by default.
https://developer.blender.org/diffusion/B/browse/master/source/blender/blenlib/BLI_assert.h
asan works with the same design:
If a bug is detected, the program will print an error message to stderr and exit with a non-zero exit code. AddressSanitizer exits on the first detected error. This is by design:
- This approach allows AddressSanitizer to produce faster and smaller generated code (both by ~5%).
- Fixing bugs becomes unavoidable. AddressSanitizer does not produce false alarms. Once a memory corruption occurs, the program is in an inconsistent state, which could lead to confusing results and potentially misleading subsequent reports.
http://clang.llvm.org/docs/AddressSanitizer.html#usage
Also see https://stackoverflow.com/questions/1081409/why-should-i-use-asserts
You can build a release or relwithdebinfo configuration if you want to see the behaviour since release builds don’t have asserts.
Thank you for your reply, but I think you misunderstand my question.
I know what asserts are for 
, I was just wondering if the assert is meant to stop with a SIGSEGV.
Normally asserts stop the program with SIGABRT and not SIGSEGV. That way you can (in a debugger) continue the execution to investigate. Sometimes singlestepping past a failed assert can show you what’s wrong easier, especially in a new codebase.
I was just surprised to see a SIGSEGV instead of a a SIGABRT. To me seeing a sigsegv in an assert looks like something goes wrong inside the assert handler.
Does anybody know why SIGSEGV is used and not SIGABRT ?
It sounds like an assert fails, then a crash happens soon after.
Best report a bug.
Ok, I’ll investigate. I’ve known a few projects where asserts were implemented by causing a segfault on purpose (from way back when all compilers worked differently I guess), but if stopping with a SIGSEGV is not the expected behaviour on assert I’ll try to track down what happens.