[Gluster-devel] Query regarding GF_ASSERT macro

Harshavardhana harsha at harshavardhana.net
Fri Jan 3 06:02:17 UTC 2014


> assert() macro also behaves in the same manner. It is an usual practice to
> have assert() be a NOOP in production builds. assert()'s normal usage is to
> assert that the expression is TRUE and it _should_ not be considered as a
> replacement for NULL pointer checks. If we want to avoid NULL pointer
> dereferences, it is a good idea to handle such scenarios and bail out
> gracefully.
>>
>>
>> A typical example of this scenario is :
>>
>>
>> GF_ASSERT (shandle);
>> GF_ASSERT (shandle->path);
>>
>> My question is why don't we abort in case of production build? Any
>> specific reason?
>

This question has come before and many times clang checks and other
debugging tools "warn" about NULL deference issues after this macro
has been invoked.

But from what i gather GF_ASSERT in GlusterFS context is much like
BUG_ON for Linux kernel - assert is only necessary during debugging -
a backtrace is valid in case of a crash for production where we get
something called gluster dump synonymous with 'Kernel dump'

I guess we can have much more broader discussion on its implications,
FWIW it was necessary from GlusterFS context to not have "assert()"
with in that macro.




More information about the Gluster-devel mailing list