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 _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
