[Bf-committers] Using assert()?
torsten.rupp at gmx.net
Fri Aug 13 23:09:27 CEST 2010
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
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
More information about the Bf-committers