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.
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
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 ?
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.