[Bf-committers] Using assert()?

[Campbell Barton]

problem either with an array (to small or not initialized) or with
some pointer. With
On Fri, Aug 13, 2010 at 6:23 PM, Torsten Rupp <torsten.rupp at gmx.net> wrote:
> Dear Sergey,
>
>> IMHO assert will help only with obvious problems (as you wrote NULL
>> pointers, i.e.) Such problems would be easily catched by gdb or
>> valgrind. So i don't think asserts are necessary for pointers
>> check.
>
> The problem with gdb or valgrind and any other tool is that you must
> execute Blender with it. If you just use Blender as a user and it is
> crashing for some reason and the situation is hard to reproduce I
> know nothing about the problem. Currently I have such a problem: it
> is crashing in around 50% of all runs, but for some reason never
> inside gdb :-(. Depending on the bug a crash even may occur hours
> after starting it, e. g. when rendering a complete animation. A core
> dump may be the only usefull source for information in that case
> (currently I try this), but unfortunatelly bugs which cause a SigSegV
> and a core dump may be located at completely different locations in
> the sources than the location where the SigSegV occur. To get aware
> of all correlations and to understand what went wrong is quit a
> difficult job if you only have broken fragments in your hands :-)
>
> Thus I think some basic self-checking inside the application would
> help to get some early hint where to look for problems even before the
> application terminates with a SigSegV or do some other strange thing.
>
>> Another thing is memory damage (i.e., due to invalid write range to
>> dynamically allocated memory) In this case SigSegV can't be caught
>> reliable. But such mistakes can't be handled with asserts. valgrind
>> should help with handling such problems.
>
> valgrind is a very good tool, but it is hard to use with big
> applications because it slow down the execution speed dramatically. I
> just tried it with the problem I'm currently investigating: it took
> around 5min to see the SigSegV without using valgrind when I just call
> Blender directly. But with valgrind it took around 50min to get to the
> point where the error may become visible - but I did not get the
> error in this run nor do I see anything which seems to be
> related to the problem :-(
>
> BTW: there are many issues reported by valgrind which must be
> filterted out. Of course I'm not sure if this output of valgrind are
> real issues or just false-positives. This have to be investigated in
> detail to clarify it.
>
> Nevertheless, if nobody thinks asserts() may help to track down bugs,
> I will accept this. I just wanted to know if there is any general
> directive how to handle such problems.
>
> Torsten

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.

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

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.

>From reading Pythons source code this is how they use assert() and I
have found it useful when tracking down problems there even though I
have a debug build.

-- 
- Campbell