[Bf-cycles] Cycles memory leaks

Thomas Krebs Thomas.Krebs at mecadtron.de
Wed Jul 13 10:08:34 CEST 2016


In blender_python.cpp:exit_func() I can see that you do:


I copied the first three statements into the cycles main but this didn't 
help anything.

Such initializers that produce leaks are e.g. in nodes.cpp in:
static NodeEnum texture_mapping_projection_init()
which are triggerered by:
NodeEnum TextureMapping::projection_enum = 

AFAICS there is no interface in NodeEnum to properly free the allocated 

Anyway, thanks for your effort.


Am 12.07.2016 um 20:12 schrieb Sergey Sharybin:
> Hi,
> In Blender we do use guarded allocator everywhere, including Cycles (at
> least for it's major parts). I did not see any leaks reported. So can
> you elaborate a bit more which exact memory is leaking?
> Think it worth addressing the issue unless it leads to some nasty code
> workaorunds or makes integration into other software creepier.
> But all that being said, please make sure you're doing similar thing to
> what we do in blender_python.cpp:exit_func(). This was the trick to make
> staticly initialized data to be freed and make Blender's integration happy.
> We should probably need to move that code to ccl::Session::exit() and
> call from standalone app as well.
> On Tue, Jul 12, 2016 at 6:31 PM, Thomas Krebs <Thomas.Krebs at mecadtron.de
> <mailto:Thomas.Krebs at mecadtron.de>> wrote:
>     Hi,
>     We are currently trying to integrate cycles into our 3d app.
>     We have successfully implemented a collada exporter from our app
>     and produced some nice images in Blender.
>     Now we got the standalone cycles app compiled and running.
>     We found that cycles leaks quite some bit from some static
>     initializers. As we try to solve leaks by monitoring leaks reports from
>     MSVC this is somewhat problematic.
>     Personally I would prefer not to have static initializers rather than
>     some initialize/terminate functions, which would make cycles even more
>     usable for integration in other systems.
>     Is there some effort going on to address that situation or would such
>     an effort be welcome?
>     We might supply changes for that but we would leave it up to more
>     experienced submitters to integrate such changes, if at all.
>     Thomas
>     _______________________________________________
>     Bf-cycles mailing list
>     Bf-cycles at blender.org <mailto:Bf-cycles at blender.org>
>     https://lists.blender.org/mailman/listinfo/bf-cycles
> --
> With best regards, Sergey Sharybin
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles

More information about the Bf-cycles mailing list