Continuing after BLI_Assrt

Blender Development
#1

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.

#2

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.

#3

Thank you for your reply, but I think you misunderstand my question.

I know what asserts are for :slight_smile:, 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 ?

#4

It sounds like an assert fails, then a crash happens soon after.

Best report a bug.

#5

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.