Dealing with bugs in release builds

Hey guys, I am developing a commercial fork of Blender that is adding a new icon based interface to Blender 2.8

My problem is that I experience a crash in my release build (both make full [build without Cuda] and make release [built with Cuda] ) that I do not experience with the debug build. I am not looking for a ready made solution from you, cause I like to figure out things myself. But still I have to admit being very inexperienced with C and more so with Blender source I was wondering how you deal with bugs that appear in release builds but not in the debug builds.

I just discovered the problem so I have not the time to really find a solution , my course of action is to insert breakpoints in my code for the release build until I find when exactly Blender crashes. I am using VS 2017 and I dont make use of the command line.

The only things I know so far is that its a memory access violation bug or so it reports in the command line.

Read prefs: C:\Users\kilon\AppData\Roaming\Blender Foundation\Blender\2.80\config\userpref.blend
found bundled python: c:\ephestos\ephestos001\bin\Release\2.80\python
Traceback (most recent call last):
  File "c:\ephestos\ephestos001\bin\Release\2.80\scripts\modules\", line 383, in enable
    raise Exception(f"Add-on '{module_name:s}' has not been upgraded to 2.8, ignoring")
Exception: Add-on 'io_curve_svg' has not been upgraded to 2.8, ignoring
Traceback (most recent call last):
  File "c:\ephestos\ephestos001\bin\Release\2.80\scripts\modules\", line 383, in enable
    raise Exception(f"Add-on '{module_name:s}' has not been upgraded to 2.8, ignoring")
Exception: Add-on 'pie_menus_official' has not been upgraded to 2.8, ignoring
Address : 0x00007FF776DC3F43
Module  : c:\ephestos\ephestos001\bin\Release\blender.exe

Are there tools and techniques to help me identify such tricky bugs ?

Any not so obvious debug tools for Blender I can use to assist me ? For example I have seen that Blender employs its own printf functions to print debug information.

Any tip and tricks, experiences or general advice is more than welcomed. Thanks :slight_smile:

For a commercial fork, be aware that generally you must still make the modified source code available due to the GPL license.

I suggest to make a RelWithDebInfo build, to get a release build with debug symbols. It’s not guaranteed to work exactly the same as release and crash but it’s closer.

If that doesn’t work, then breakpoints and printf are pretty much the best you can do unless you have a guess for the bug might be.

1 Like

Yes source code wise, the code will be available on purchase (and of course every single update which will be free for existing customers) exactly like its done with commercial Blender addons and of course free of charge and of course GPL. As a matter of fact the whole design of the fork is to be more an extension/addon of the existing code base than a modification. Or to be precise I try to make it so cause I still learning the basics. In any case everything will be GPL compliant.

I also plan to provide documentation for my source code( in addition of course to the user manual), probably in the form of a dev_manual.pdf , although probably not straightaway because still everything is in a state of flux. I also try to follow Blender’s code design as close as possible and my fork will be 100% compatible with Blender. So overall I try to keep everything as open and as Blender friendly as possible in the context of a commercial project.

Thanks for the RelWithDebInfo idea , I will give it a try. Do you think something like Vangrind could help here ? I know that Blender has support for Valgrind but I never used it myself, I just use VS Debugger.

Valgrind is a linux tool, won’t work on windows.

1 Like

oh bummer, thanks for the info. Well old trusted printf here I come :smiley: