[Bf-committers] Using assert()?

Torsten Rupp torsten.rupp at gmx.net
Fri Aug 13 23:09:27 CEST 2010


Dear Campbell,

thank you for your message:

> Hi Torsten, I'm ok with using more assert() calls in blender but
> think they should be added in places which could potentially get
> into an invalid state and which would otherwise crash or cause
> blenders internal state to become unstable - corrupt memory etc.

That is my idea with the assert: detecting if Blender is going to run 
into a serious problem in an early state.

> As you say, this would help with users bug reports if they have a
> useful message rather then just a segfault.

That would be a big help, for both developers who try to find bugs and 
users who detect a problem and send a bug report.

From the view point of a user, a software which report some error 
message like an assert do and then stops imho looks more reliable 
than some software which just reports "unknown error" or simply crash 
without any error message, even in both cases the user cannot 
continue with his work.

> Of course these kinds of changes should be reviewed by the
> maintainers of each area, I don't think adding checks all over
> blenders code will help.

I also think cluttering the code with asserts all over should not be 
the way. This will hardly be a help. But code sections where implicit 
assumptions are made by the developer about an expected certain state 
of Blender should be checked, e. g. if a variable is initialized at 
all or a array have the expected size (I already found some errors in 
Blender related to these two common development bugs).

And of course: asserts are only compiled in into the debug version of 
Blender. There is no harm for the non-debug version. My suggesting 
would be to offer a debug-version during the beta-phase resp. 
developers can enable the debug-version by themself (which most will 
do anyway; development with optimization enabled and debug-symbols 
disabled is not easy). For the final release a non-debug version 
(with asserts disabled) and for helping to trace still unknown bugs 
by users additionally a debug-version (with asserts enabled) may be 
offered.

I'm looking forward that more asserts will be added to the Blender 
code to make the code in the long-term more stable and safe. There 
are already so many arrays and pointers in Blender that it is quite 
dangerous to operate with them without any "safety net".

BTW: I think I found the reason for the occasional SigSegV I see when 
rendering a scene. It looks like it is a multi-threading problem in 
source/blender/render/intern/source/pipeline.c which cause 
do_render_seq() to crash, because the pointer to "result" in the 
structure "Render" is changing, but the previous pointer value is 
stored in a local variable. Thus accessing "result" through this 
shadow pointer cause the SigSegV. I will investigate this a little 
more, try to find a fix and then create a bug entry.

BTW 2: the run with valgrind probably showed that there are also some 
string-problems. I will investigate these problems, too.

Though, still many things to do, but Blender is getting more and more 
better!

Torsten


More information about the Bf-committers mailing list